Offer-Ready is built around the concept of dynamically generated content. But of course parts of the content required to build your endpoints may not require being dynamically generated, because they already exist as some sort of “static” content.
Static content such as images or files may be stored in the application’s static directory.
Image paths within an XSL-FO file may have an absolute path (to some URI), or a relative path.
Absolute paths will be "executed" by the PDF reader. Make sure that the path is accessible from your client's device.
Relative paths will use the application’s static directory as a root directory. Images will be embedded in the generated PDF.
Depending on what fonts readers have available on their local computer, fonts used in your PDF will be seen as you intended it to be seen, or the computer may substitute fonts. Substitution can result in significant differences between your intended output and what the reader will see.
Embedding fonts prevents font substitution. This ensures that text is displayed and printed in its original font.
Offer-Ready supports embedding of True Type fonts, which have a “ttf” file extension.
Create a directory “fonts” in the root directory of your configuration. Within this “fonts” directory, there is
an overall fonts configuration file called “apache-fop-config.xml”.
A TTF file for each font refered to in the apache-fop-config.xml. For example: “HelveticaNeue-Light.ttf”.
The “apache-fop-config.xml” declares the ttf fonts in the fop processor:
On developing your XSL-FO template, use the (embedded) font-triplet name as if it were available on your local computer. Technically your XSL-FO file may contain any font-name with any font-style and font-weight. The behaviour of a common PDF reader will be:
If a font-name/font-style/font-weight triplet used in the PDF is available as an embedded font-triplet, than this will be used.
If a font-name/font-style/font-weight triplet used in the PDF is not available as an embedded font-triplet, but on the local computer, than the font from the local computer will be used.
If both previous options do not apply, the PDF reader will substitute that font by some other font.
Beware of these “traps”:
If your PDF for example does not show a text in bold letters, although your intention was to use bold letters, than you maybe have defined the font-triplet for “weight=normal”, but not also for “weight=bold”. You need to declare all required combinations of name/style/weight.
If your local computer has a font “Helvetica Neue”, and your font-triplet name is “HelveticaNeue” (without a blank), than you must use “HelveticaNeue” in your XSL-FO. A WYSIWYG editor (like Altova Stylevision) likely will offer local fonts only in a dropdown.
The preview of your PDF in a local development environment may look different than the PDF generated by Offer-Ready. The fonts used by the local development environment will use fonts on your computer, and not fonts checked in in the above structure.
Using a font may require a licence
It is your responsibility to respect license constraints. While many fonts can be used without restrictions, other fonts for example might require to pay a license fee.
<fop>
<renderers>
<renderer mime="application/pdf">
<fonts>
<!-- zero or many font tags -->
<font kerning="yes" embed-url="the-name-of-the-ttf-file.ttf">
<font-triplet name="Font Name as used in your XSL Template" style="normal" weight="normal">
</font>
</fonts>
</renderer>
</renderers>
</fop>Originally XSLT specifically was designed to support a 2-step process of
Transformation: In the first step an XML document transforms into another XML document containing information about how to display the document: what font to use, the size of a page, etc. This markup is called Formatting Objects. Note that the resulting XML document not only contains formatting information, but is also stores all of the document's data within itself.
Formatting: Some software (called “FO-Processor”) transforms the result of the first step (transformation) into the intended output format. For example, Apache™ FOP (Formatting Objects Processor) is an output independent formatter, which can generate PDF.
OpenEndpoints uses Apache™ FOP to generate PDF.
The data-source transformer refers to a XSLT that creates XSL-FO (=an xml containing content + formatting options).
In the example above the 2-step process is:
[xslt-which-creates-xsl-fo] transforms [data-source] into the xsl-fo-output = an xml containing content + formatting options.
The option <convert-output-xsl-fo-to-pdf/> triggers the function to send xsl-fo-output to Apache FOP, which will generate PDF.
The Apache FOP integration with OpenEndpoints includes easy to use options to
into the generated PDF
Embedding Fonts such as Google Fonts into your generated PDF
XSL-FO is a very mature standard for page composition, which was designed for paged media. It is capable of comprehensive layout functionality, which makes it possible to create error-free but also beautiful layouts. For example: Pagination controls to avoid “widows” and “orphans”, the support of multiple columns, indexing, etc. It is the perfect technology to produce “content-driven” design.
For more advantages and disadvantages of XSL-FO see:
<transformer data-source="[data-source]">
<xslt-file name="[xslt-which-creates-xsl-fo]"/>
<convert-output-xsl-fo-to-pdf/>
</transformer>