[reportlab-users] Umlaut Bug with Adobe Reader and Arial

[Volker Haas]

I just realized that the ttfAsciiReadable=0 trick does only work in the
minimal example script I posted. If I use it in our rendering stack the
fix does not work (I am confident that I am actually changing the
configuration since the PDF files are significantly smaller after
setting ttfAsciiReadable=0).

Therefore my question is: if you think this is a bug in reportlab, do
you plan on fixing it?

Best Regards,
Volker



Am 23.05.2014 13:23, schrieb Volker Haas:
> Am 23.05.2014 12:50, schrieb Robin Becker:
>> I tried some options; turning off ascii readability made the problem
>> go away.
>>
>> Try
>>
>> set rl_ttfAsciiReadable=0
>> python broken_umlauts.py
>>
>> to see what happens. I did some quick checking with an older (2012)
>> version of reportlab and can see the problem there as well so this
>> isn't related to all the bytes/str changes.
>>
>>
>> The difference between set rl_ttfAsciiReadable=0 / 1 is that for
>> debugging purposes we want to map the standard ascii characters to the
>> first subset in the correct position. That means the default setting
>> makes most ttf strings readable in the (and the whole file a bit
>> longer). When we have ascii readablity = 0 then we try to subset the
>> used characters plus some messing about to preserve space positioning
>> which is required for some reason. At any rate a quick fix for modern
>> reportlab might be to create a reportlab_settings.py somewhere on the
>> python path and put
>>
>> ttfAsciiReadable=0
>>
>> in it.
>>
>> This isn't an answer to the underlying problem, but it may ameliorate
>> the effects.
> Hi Robin,
> thanks for the quick response. I can confirm that the workaround solves
> the problem. Thanks a lot for the hint!
>
> Best Regards,
> Volker
>


-- 
PGP Key: http://pool.sks-keyservers.net:11371/pks/lookup?search=volker.haas@brainbot.com&fingerprint=on

Volker Haas
Senior Developer
brainbot technologies ag
Taunusstraße 61
55120 Mainz
Phone: +49 (0)6131 2116394