Print documents are the way to create print-ready PDFs directly within Pimcore. They are based on the normal Pimcore documents and therefore support everything as pages do - starting from MVC pattern and template creation to document composing within Pimcore backend with areas, drag&drop etc.
By default, web-to-print documents are disabled. To enable them, you need to activate them in the web-to-print settings:
Web to print flow implemented in Pimcore:
Once activated, print documents are integrated into the default documents tree. But of course you can setup your custom views to have separate trees for web documents and print documents. Just use our completely redesigned custom views and all new perspectives features.
For more detail-information on the settings see later.
Web-To-Print Document Types
PrintPages are the documents that contain the actual content - with all the areas, editables, images, and so on. They are based on the normal Pimcore documents and to content editing should be quite self explaining.
PrintContainers are a special document type to represent containers of PrintPages. They do not have content for their own, they just combine all sub pages to one single output PDF. By doing so they allow to structure big print documents like catalogs, pricelists, books, etc.
Of course, PrintContainers can be nested. So, one can use a root container, that contains several chapter containers that then contain the actual print pages.
Even they don't have content for their own, PrintContainers are based on normal Pimcore documents. Therefore, they also need a controller and a view. They have to make sure, that all sub pages are included into one single output view. Pimcore ships with default implementations (Web2PrintController, container-Action) on new installations. If you updated an existing Pimcore installation, please get the default implementations here:
Both web-to-print documents have an additional tab that is the place for rendering documents to print-ready PDFs. When rendering, the print is first rendererd to HTML and then rendered to an PDF. PDF rendering itself is done by an third party renderer. Currently we support wkhtmltopdf and pdfreactor. Please see their documentation for details concerning template possibilities.
Depending on the renderer, there might be settings possible for the rendering process. The provided settings might be extended in future. For details of settings please see section below or renderer documentation.
Special PDFreactor Settings
Printermarks: With PDFreactor there comes a out-of-the-box feature to add printermarks to the PDF. They can be activated by the printermarks rendering setting. Technically they are implemented by an additional CSS-file which needs to be included. For Details, check links below:
In the web-to-print settings, the used PDF renderer is specified. Depending on the renderer, there are additional settings to be made. Additional explanation can be found directly in the settings form. These settings have to be set properly before starting PDF rendering.
Settings for WkHtmlToPdf
In the binary field enter the path to the wkhtmltopdf binary. For example: "/usr/bin/wkhtmltopdf". If you get an error like "QXcbConnection: Could not connect to display" you will need to install xvfb. More about this error
The command that you enter in the binary field can then be something like this:
xvfb-run -a -s "-screen 0 640x480x16" /usr/bin/wkhtmltopdf
In the host field, enter the full URL, like you would in a web browser, not just the hostname. For example: "http://example.mydevdomain.local"
To test and debug the PDF rendering, open a Print document, go to the tab "Generate & Preview PDF", click the "Generate PDF" button and observe the message field for any errors.
Relevant Log Files
If PDF rendering doesn't work properly, following log files should give you a hit for the reason.
var/logs/prod.log- contains general logging information for rendering process at INFO level
var/logs/web2print-output.log- contains output of rendering PHP process (if any). It is recreated on every rendering process.
Color management and images
If you are using the PDFReactor renderer, use CMYK CSS color specifications (see PDFReactor documentation on details).
There are two possible workflows for images:
Use print-ready source images (for example TIFF files with the correct ICC Profiles) in your documents with "Print (...)" thumbnail format setting. This keeps the colorspace correct when used for print rendering and converts to RGB for preview and edit-mode.
Keep RGB style PNG/Jpeg images in the CMYK PDF files and let the printing house take care of converting them to the correct colorspace.
Option 2) is preferred, as colorspace conversions are tricky and error-prone due to tightly coupled printer hardware dependencies.