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
>