LiveDocx in PHP

Please note: This post is part of a five post series. See introduction, part 1, part 2, part 3 and part 4.

Towards the middle of the Ralf’s article in PHP Magazin, in a section which talks about how to populate PDF templates, the author expresses some concern about how tricky it is to get the positioning of pseudo text fields just right in a PDF template (an English translation of this passage is directly after the quotation):

In der Regel werden die PDF-Vorlagen verwendet, um am bestimmten Stellen im Dokument variable Inhalte einzufügen. Da Zend_Pdf intern mit Punkten (1/72 eines Inches) arbeitet, kann die Platzierung von Texten mit PDF-Vorlagen aus anderem Quellen durchaus problematisch werden.

Ich habe diese einmal mit deiner PDF-Vorlage umsetzen müssen, die die zu füllenden Textfelder nicht nach Punkten, sondern eher wahllos auf der Seite verteilt hatte. Es kann schon bei einer Vorlage, die nur aus einer DIN-A4-Seite besteht, aber 20 bis 30 Felder hat, die es zu befühlen gilt, ein paar Stunden dauern, bis man alle Texte einigermaßen gut platziert hat. Der Begriff “Pixelschubser” bekommt da eine ganz neue Bedeutung.

The above quotation can be translated into English as follows:

Typically, PDF templates are used to insert content into documents at pre-defined positions. As Zend_Pdf internally uses points (1/72 of an inch), it can be tricky to get the positioning of text just right in PDF templates originating from sources other than the Zend Framework.

Once I had the task of programmatically populating a PDF template in which text fields were not specified in points, but were rather haphazardly placed all over the page. It can take several hours until you get the positioning of text just right in an A4 document with 20 to 30 text fields. The term “pixel-pimping” takes on a completely new meaning.

To illustrate how the population of PDF templates works with the Zend Framework, Ralf presents an example, which is available on the cover DVD of the magazine or can be downloaded. The logic is as follows:

1. Load a PDF file with Zend_Pdf.
2. Loop through each piece of text, which should be inserted into the template and specify its x and y coordinates, using the drawText() method. For example:

   $page->drawText('Henry', 200, 620);

3. Render and save the PDF file.

The problem here, is that with Zend_Pdf, there is no concept of a text field. For example, it is not possible to specify that a placeholder is called firstName and then programmatically set the value of firstName to say Henry. Instead, it is necessary to specify that at position 200, 620 Henry should be written. It is therefore, very understandable when Ralf writes: The term “pixel-pimping” takes on a completely new meaning.

For each an every piece of text, which should be inserted into a document, exact coordinates must be specified – a very time consuming, nerve-wracking and consequently error prone task.

Furthermore, to be able to use Zend_Pdf at all, the exact coordinates at which text should be inserted must be known in advance. For example, should the graphical design department change the design of say an invoice, then a programmer must update his/her code in the PDF generation process, re-specifying coordinates as applicable. This makes Zend_Pdf a very brittle solution: One small change in the PDF template and the generated PDF document is broken.

In a similar vein, many legacy word processing documents are not stored as PDF files at all. In a typical office environment, the vast majority of documents are stored in DOC and more currently, DOCX formats. These documents often contain text fields (or merge fields, as they are called by Microsoft), into which data can be injected. In the current incarnation of the Zend Framework (v1.7.1) there is no provision whatsoever to load these file formats, let alone populate them with data from disparate data sources.