[reportlab-users] Possible bug in ReportLab 3.5.68
Robin Becker
robin at reportlab.com
Thu Jul 22 10:48:16 EDT 2021
On 22/07/2021 14:37, David Vogt wrote:
> Hi all,
>
> Thanks Robin for forwarding it.
>
............
> Something like that, yes. I know of no character encoding where that
> codepoint corresponds to the letter we know should be there, which is weird
>
............
>
> Unfortunately the producer is an Adobe product, so we probably won't
> have a lot of chance to getting it fixed properly. I've tried as many
> PDF reader implementations as I could, but all of them seem to happily
> work with both files.
>
> I'll see with the people working with InDesign whether they can rename
> the styles to a non-umlaut variant and see if this helps in the mean time.
>
.......
I looked in the PDF 1.7 document and there the PDFDoc encoding does have <fc> for u umlaut which means that the works
pdf does have a reasonable value for this string. The character 0x80 == 0o200 is a bullet. So assuming that the original
of this string was converted correctly to pdfdoc it should have been u'Sonderfarbe "F\u2022hrungslinien"'; which is
encodable to b'Sonderfarbe "F\x80hrungslinien"'; The fact that this got through probably implies the test script is
reading it wrong.
I tried our proprietary pageCatcher module on fail.pdf and I'm glad to say that it was able to create an output file
without crashing and there the result still has (Sonderfarbe "F\200hrungslinien") as expected. I'll send the result to
David to show it can be done.
--
Robin Becker
More information about the reportlab-users
mailing list