[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