[reportlab-users] Surprising clash of encoders with pikepdf (with patch)
lregebro at shoobx.com
Wed Jan 12 05:31:08 EST 2022
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.
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the reportlab-users