Background : In September 2008 some users/developers expressed their unhappiness with the existing print solution which uses trml2pdf.py. some alternatives are mentioned. This page is a collection of the approaches used and might be a base for further discussion.
Current (as of Sept. 2008) approach
The templates for the documents used are stored as <DOCUMENTNAME>.rml in SITE/templates/pdf, where SITE is the name of the Django project (aka the root for your project). These are standard Django templates, where all tags can and should be used (eg. translation or currency formating).
During the creation the template is then first rendered and then translated to pdf with the help of trml2pfdf.
pdf = trml2pdf.parseString(smart_str(t.render(c)))
- RML allows very detailed and exact positioning of text and formatting
- Standard templates can be used '''Cons'''
- RML is another mark-up language to learn and remember
- There is an existing automatic translation from SXW (Old Open Office Format). This creates a lot of crappy formatting boilerplate and makes the resulting RML almost unreadable (->unmaintainable).
- The pdf-creation is somehow slow - this is annoying specially when done inside a work flow where customers are involved.
Workaround for some of above limitations
At [http://www.pal-pad.com] the following approach to reduce the cons mentioned is used. (RML Template and document.py <- module used for printing attached).
- RML is only used for the core data (Address, order data, payment specifics).
- After the invoice is generated it is as ''raw'' pdf available. ''raw'' means there is no company data whatsoever around.
- For use in the fulfilment process the ''raw'' pdf is simply printed (b/w Lase, no colour) on the standard (preprinted) business paper. In our case SCRIBUS [http://www.scribus.net] is used to create the pdfs with the printer (in 600 DPI set-up).
- For use in on-line processing, for example to automatically send the order confirmation and terms (which are easily one page of very small text) to the customer, the same virtual business paper is used. This time just one exported with 90 DPI from SCRIBUS). The ''raw'' pdf is virtually printed on the business paper by merging. This is done with with the pdftk (pdf tool kit [http://www.accesspdf.com/pdftk]).
- To speed up the send process and to give the users a fast response experience a extra thread is spawned for sending, this approach can be used also for the printing if necessary.
Other approaches NOT using trml2pdf
This is the result of a short investigation into the web - there might be much more solutions around.
- Jython/jasper for PDF creation [http://cybernetics.hudora.biz/projects/wiki/pyJasper].
- GENSHI to create odts/html. [http://relatorio.openhex.org]. Then use OO-engine to print it into other formats.
- Appy framework to create odts/pdf/doc/rf/txt. [http://appyframework.org]. The approach for creating the template is similar to GENSHI.