[reportlab-users] Possible bug in ReportLab 3.5.68

[Tim Roberts]

Robin Becker wrote:
>
> I took a look at your issue and find that there is an encoding 
> difference between the two PDF's.
>
> In works.pdf
> << /CALS_LayerMetadata << >> /Intent [ /View /Design ] /Name 
> (Sonderfarbe "Führungslinien") /Type /OCG /Usage << /CreatorInfo << 
> /Creator (callas pdfToolbox) /Subtype /Artwork >> >> >>
>
> in fail.pdf
> << /CALS_LayerMetadata << >> /Intent [ /View /Design ] /Name 
> (Sonderfarbe "F\200hrungslinien") /Type /OCG /Usage << /CreatorInfo << 
> /Creator (callas pdfToolbox) /Subtype /Artwork >> >> >>
>
> the problem is the string (Sonderfarbe "F\200hrungslinien") in fail; 
> it cannot be encoded using the pdfdoc encoding. The equivalent string 
> in works is fine as u umlaut appears to be encodable.
> ...
> It may well be that there is a mechanism for using the \x200 escape, 
> but obviously that's not working here.

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.

-- 
Tim Roberts, timr at probo.com
Providenza & Boekelheide, Inc.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3389 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://pairlist2.pair.net/pipermail/reportlab-users/attachments/20210721/81e4063a/attachment.bin>