Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 4.4, 5.0.0 beta1
-
Component/s: Font Engine
-
Labels:None
-
Environment:any
-
ICEsoft Forum Reference:
Description
Attached to the form is a PDF document that contains a embedded TrueType font program that is failing to load and causing the first page not to load.
After taking quick look at the file in question the font has format 4 flag which we currently don't support. The bad thing is that when the flag is encountered an IllegalStateException is thrown which causes the page to fail to load.
After taking quick look at the file in question the font has format 4 flag which we currently don't support. The bad thing is that when the flag is encountered an IllegalStateException is thrown which causes the page to fail to load.
Some info on what the format 4 is used for:
Composite fonts on Japanese, Chinese or Korean printers work only with character codes. QuickDraw GX printer drivers only know about glyph index values. The TrueType scaler uses format 4 'post' table to reencode a font that maps to a composite font on a printer. This encoding consists of naming the glyphs by using their character codes. The driver has PostScript code that knows how to take this ASCII string, strip the leading "a," and convert the rest to hexadecimal. The resulting hexadecimal number is the character code of the glyph. In this manner, the composite fonts on the printer are used.
Any font that maps to a composite font on the printer needs to include a format 4 'post' table. The structure of a format 4 'post' table is as follows: the 'post' table header is followed by an array of uint16 values. An entry for every glyph is required. The index into the array is the glyph index. The data in the array is the character code that maps to that glyph, or 0xFFFF if there is no associated character code for that glyph.