Re: Possible bug in ReportLab 3.5.68

Hi all,

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
>> Unicode.
>>
>> 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.


Best,
David


-- 
David Vogt, Software Engineer
Adfinis AG, Giessereiweg 5, CH-3007 Bern | +41 (0)31 550 31 12
_______________________________________________
reportlab-users mailing list
[email protected]
https://pairlist2.pair.net/mailman/listinfo/reportlab-users