[reportlab-users] Ok to ask a simple z3c.rml question?

[Werner Thie]

Hi

Switched to svn://svn.zope.org/repos/main/z3c.rml/trunk instead of the 
distrib on pypi, but problems persist. The easy-install of pypi pulls 
lxml Version 2.0.2 which causes some of the observed problems:

- when using lxml.etree.__version__ 2.0.2 there are namespace problems
   such that the local TAL implementation does not work

- therefore one is not able to rerun the production of reference.pdf

- there is in fact a problem with the opening of the output docs which
   gets opened like
   outputFile = open(self.element.get('filename'), 'w') instead of
   outputFile = open(self.element.get('filename'), 'wb')

- the unittests fail obviously due to the facts given above

After patching open, the rml2pdf at least works like advertised.

Too bad that the zope3-dev at zope.org mailing list seems unattended at the 
moment, they are not answering to register requests, so I am quite at a 
loss as where to post my findings. In the meantime I'll do it here for 
any lost soul swimming in the same fishbowl.

Thxs, Werner Thie



Robin Becker wrote:

> Werner Thie wrote:

>> Hi

>>

>> Just stumbled over the z3c.rml package and tried to produce some PDFs 

>> on MSWindows/Python25. Funny enough that all the produced PDFs do not 

>> contain 0x0d 0x0a lien terminating sequences but 0x0d 0x0d 0x0a which 

>> sends Acrobat Reader into Neverland. When exchanging the produced 

>> patterns with correct line terminating sequences 0x0d 0x0a, the docs 

>> rendered diff ok to the expected ones, or in other words - they are 

>> correct and show up ok in Acrobat.

>>

>> Is there a simple explanation for this behavior or should I have 

>> configured something before running test code?

>>

>> Thxs, Werner Thie

> .......

> Unfortunately that sounds like a bug in z3c.rml. When reportlab runs the 

> eol character is supposed to be LINEEND = '\015\012'; and that should be 

> preserved as PDF is not a text format. I suspect something is writing 

> the files in the wrong mode ie text. They should always be written in 

> binary. Since 0x0a is '\n' and python converts '\n' --> '\r\n' for text 

> files that would seem to make '\r\n' become '\r\r\n' ie what you observe.