[reportlab-users] Possible bug in ReportLab 3.5.68
david.vogt at adfinis.com
Thu Jul 22 09:37:24 EDT 2021
Thanks Robin for forwarding it.
On 22/07/2021 10.27, Robin Becker wrote:
> On 21/07/2021 17:32, Tim Roberts wrote:
>> Robin Becker wrote:
>> That's very odd. That would be an octal escape, not hex. \200 would
>> be 0x80 or decimal 128, which is a Unicode padding character.
>> u-with-umlaut is \xFC or \374 or decimal 252, but in ISO-8859-1 and in
>> I wonder if this is a substitution from a failed character map
>> encoding somewhere.
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
> You are correct in the values the actual PDF that works had these bytes
> /Name (Sonderfarbe "F<fc>rungslinien")
> which can be decoded into unicode and then back into pdfdoc.
> It looks like a failure somewhere in the production of the two pdfs, but
> the error shows up when another script using reportlab processes them. I
> guess the OP should consider the producer process before we see if
> there's a bug in RL.
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.
David Vogt, Software Engineer
Adfinis AG, Giessereiweg 5, CH-3007 Bern | +41 (0)31 550 31 12
More information about the reportlab-users