[reportlab-users] pdfgen creates corrupted pdf files

[Robin Becker]

Thomas Zehbe wrote:
> Hi all,
> I'm programming an app using wxWidgets and VC++ 6.0 on windows.
> To produce reports and documents I use the platypus engine. To run the reports 
> I use the python C++ api linked into the app.
> 
> Everything works fine just until I try use some Microsoft stuff :-((
> What I do is to generate a pdf and then mail it using simple Mapi 
> (MAPI32.dll). The mapi is not called from pyhton but directly from C++.
> The problem:
> Before the first call to the mapi the app generates pdfs without any problems. 
> After calling the mapi once pdfgen still generates pdf-files but they are 
> corrupted. Unreadeable with Acrobat on Windows and LINUX and with KGostview.
> I checked the contents with an Editor. At first sight the corrupte files seem 
> to be ok.
> But there are some differences. Example
> File ok:
> ...
> << /Contents 8 0 R
>  /MediaBox [ 0
>   0
>   595.2756
>   841.8898 ]
>  /Parent 7 0 R
> ...
> File corrupted:
> ...
> << /Contents 8 0 R
>  /MediaBox [ 0
>   0
>   595,2756
>   841,8898 ]
>  /Parent 7 0 R
> ...
> As one can see the decimal paper size (I believe) numbers have changed the 
> decimal point representation from "." to ",".
> And the binary data streamis somewhat different in size an looks totally 
> different due to encoding.
> There are no error messages like tracebacks in the logfile I use. The Current 
> locale (german) seems not to be chagend by the mapi calls because all forms 
> work well before and after.
> The behaviour is not report depent. All reports fail after a mapi call.
> And its the same with 1.19 and 1.20.
> 
> Any hints would be very appreciated!
> Thanks

I don't believe we're deliberately changing our output in response to locale, 
but we have other users in Germany/France etc who may know better.

Could it be that Python is using the locale behind the scenes and it gets 
changed by calling MAPI.

Do you know if you have the _rl_accel.pyd extension? It has some specific code 
in _fp_str which assumes we might be using ',' for the decimal point and 
converts it back.
-- 
Robin Becker