Re: Surprising clash of encoders with pikepdf (with patch)
Lennart Regebro via reportlab-users <[email protected]> Wed, 12 Jan 2022 09:13:10 +0100
| Newsgroups | gmane.comp.python.reportlab.user |
|---|---|
| Message-ID | <CAHT-kBct6Jwcx8mjwiNh6SrBHMvfUGC3MePj-PLcbrGZ2_UMqg@mail.gmail.com> |
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... On Mon, Jan 10, 2022 at 6:56 PM Robin Becker <[email protected]> wrote: > Hi Lennart, > On 10/01/2022 16:16, Lennart Regebro via reportlab-users wrote: > > On the other hand, you now uncovered incompatibilities between the > codecs, > > so I'm still glad I raised the issue, even if it was for the wrong > reason. > > :-D > > > no problem > > > Your interpretation of the spec seems reasonable to me, it seems clear > that > > 0x18 should be decoded as a BREVE, for example, and not 0x18, which is > what > > you get now. > > > > > > Do you want me to start a discussion on QPDF's github about that? > Good idea; report here if you can/they find/suggest anything useful > -- > Robin Becker > _______________________________________________ > reportlab-users mailing list > [email protected] > https://pairlist2.pair.net/mailman/listinfo/reportlab-users >