Re: Possible bug in ReportLab 3.5.68

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, [email protected]
Providenza & Boekelheide, Inc.