1 person found this helpful
PDF/A is very restrictive as to what is acceptable. Its all related to it being an archive format, so it cannot ever change (font embedding is one part of that).
If the font (or a subset of the font) is not already embedded in the PDF, then you will need to make sure the Font is on the LiveCycle server. That way LC can embed it when it transforms the PDF.
There can also be issues as some fonts cannot be embedded due to the font's licensing restrictions. That is, the font creator has said that it cannot be embedded.
The larger question is; do you really need a PDF/A? If you just need to flatten the document you can use the OutputService.generatePDFOutput to make the document non-interactive with a Transformation Format of PDF.
There is no way to retain the fonts in the incoming PDF when flattening. The fonts used need to be on the server when you run the transformPDF (which is the right API).
You ask how these can be installed – don’t know off hand but this must be documented – same place as the fonts required for a rendering using Forms/Output – the transform is a very similar operation under the covers.
A Windows situation is easier since MS provides a bunch of fonts for you to use. On a UNIX or /Linux box you need to acquire legal copies.
When you use PDF/A as a format it is flagging the unavailable font (a useful side benefit of sorts); non PDF/A formats just substitute if the font is not found (with no warning) thus the behavior you see. A PDF/A-1b will be a similar size to a regular PDF with embedded fonts; fonts will be embedded always for PDF/A. A PDF/A-1a will also have a bunch of tagging and so will be bigger.
Hope that helps.