Re: Surprising clash of encoders with pikepdf (with patch)

Yeah, I think this will be fine. For some time it might be that PDF's that
include the undefined characters could fail with one encoding and succeed
with the other, but I really think that's a low risk edge case that then
will be solved once both QPDF and Reportlab has new releases. And it hasn't
happened yet, so I wouldn't worry about that.

As far as I'm concerned this is now a solved issue.

Thanks for the help!

On Wed, Jan 12, 2022 at 11:00 AM Robin Becker <[email protected]> wrote:

> On 12/01/2022 08:13, Lennart Regebro via reportlab-users wrote:
> > So, the missing characters like BREVE were indeed missing and overlooked,
> > and this has been fixed now:
> >
> > https://github.com/qpdf/qpdf/issues/606
> >
> > As for the other undefined characters, they are listed in Appendix D in
> > such a way that I think it's reasonable to just pass them through, even
> > though they are undefined, although raising an error is also reasonable.
> It
> > is, after all undefined...
> >
> ........
> Hi Lennart,
>
> yes that was my conclusion as well after looking at the U values. So in
> conclusion I will add the initial U values
> ^@..^W and also the three specials 0x7f, 0x9f & 0xad as pass through
> bytes. I see this gets done in qpdf so will have to
> wait for a while until distros catch up. However, I can presumably create
> a local test to see if it gets through OK.
> --
> Robin Becker
> _______________________________________________
> reportlab-users mailing list
> [email protected]
> https://pairlist2.pair.net/mailman/listinfo/reportlab-users
>