[reportlab-users] Surprising clash of encoders with pikepdf (with patch)

[Lennart Regebro]

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 <robin at reportlab.com> 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
> reportlab-users at lists2.reportlab.com
> https://pairlist2.pair.net/mailman/listinfo/reportlab-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/reportlab-users/attachments/20220112/128de62f/attachment.htm>