- March 13, 2012
- FOXITBLOG
On a solution project we worked on, Sergey and I needed to dump a table of fontname/font file/font data into a file so the list can be reused in the future. We tossed around the idea of creating our own binary data format to hold the content but implementing reading and writing functions for it took away from Tiny Tower time.
We would like thank the ISO3200 committee for having the prescience to develop such an extensible format. Now how can I build my tower higher…Through our daily work with the PDF format we know that it handles a variable amount of various objects of variable size so it was only a small a stroke of brilliance (laziness?) to equate the two. Well, what do you know! Foxit has some PDF technology lying around that allows us to do this easily. Score one for dog-fooding one’s own technology
-Sam
PS for those who wants to know more detail:
For a server-side rendering solution we are providing for a partner, we were asked to implement a lazy-loading mechanism for system fonts. When a PDF renderer is rendering text, it needs to find fonts that it can use to render the content. There are several steps the renderer takes to do this.
1) The renderer checks if the font is embedded in the PDF itself or is one of the fourteen PDF Standard fonts that all PDF standard-compliant renderer needs to support.
2) The font is not embedded in the PDF or is not one of the fourteen fonts, so the renderer searches in its pool of available font to see if the needed font is available.
3) The font is not available in the pool of available font, and the renderer looks for substitution font (this is also one of the reason that different rendering engine can give different result for the same PDF)
The last steps require the renderer to go through a list of font facenames which the Foxit engine has to build real-time, every time it opens a PDF. In a client side solution, this performs normally because we’re opening PDFs one at a time, and intermittently. In a server-side solution where PDFs are opened and closed subsequently and quickly, this is a HUGE time waster.
In comes lazy loading. We compile this list once, save this list in a file, and the list can be loaded quickly in subsequent rendering job, given that the pool of font/rendering environment does not change. As we’ve mentioned before, we dump this data into a PDF file, which is perfect for this type of data dump, and has the added advantage of being able to be read quickly by the Foxit engine, which itself is doing PDF processing anyway. Cute all around.