GNOME Bugzilla – Bug 80413
Many large truetype fonts fail to download into Postscript as type42, get converted to type 1
Last modified: 2004-12-22 21:47:04 UTC
There is one major issue which is really causing the problem on the fonts that I tested (from the Microsoft font pack), but two issues of lesser importance that could cause problems. Since all are fixed in the same block of code, I am filing one bug report and patch file. Most important bug listed first below: 1. Major Truetype fonts like Arial, Times New Roman and the Lucida fonts distributed with the Java SDK end up converting to type 1 instead of downloading as type 42 in the Postscipt output (many variants of Lucida still don't work even after converting to type 1). The error "Too big pad at end of GLYF table occurs". At least some of these are fixed by the attached patch. The problem in many of these fonts is that the offsets into the GLYF table that are stored in the LOCA table are not in assending order. By sorting them before slicing the GLYF table, many of the fonts now download correctly as Type 42. Unfortunately, the patch doesn't fix all fonts, some fonts (most notably non-roman slanted Courier New and Many variations of the Jave Lucida fonts) still have > 64k bytes after the last glyph. I suspect these are common jump points used in the hinting instructions, but further research is needed (more difficult Truetype subsetting may be needed to solve the problem for all possible fonts, so I do not have an immediate solution). In any case, the patch does fix many of the most important MS truetype fonts (all variants of Times New Roman, Arial, Georgia, etc., now download fine). 2. When LOCA table offsets into GLYF are in "long" format, the value in the LOCA table is the actual offset, not multiplied by 2 (as in the case of short). The library was multiplying long offsets by two. This could have caused problems, but none of the fonts I tested have this offset style so I didn't actually experience a bug. 3. Minor issue: slices should be made at one byte less than they are now in the Truetype font in order to leave from for the trailing "00" at the end of the Type 42 sfnts array. Odds are that this is unlikely to happen because a font would have to end exactly on a 64k boundary, but since I noticed it, I included a fix in the patch file.
Created attachment 8080 [details] [review] Sorts offsets in GLYF table in ascending order before slicing, other minor fixes
I have revised comments for items 1 and 2 below. Also, please disregard the first patch, the second one that I have uploaded really fixes the problem properly. 1. The problem was not due to the LOCA table offsets not being ascending, it only appeared that way due to debugging data I was getting out of the program. The problem is that the program was not using the correct offset into HEAD for the IndexToLocFormat. Thus, it was always thinking it had short offsets, when in fact it has long. The second patch that I have uploaded fixes the problems. Now, all of my truetype fonts (even the largest) download as Type 42. 2. Once I fixed (1), it became apparant that this really is a problem, so I left the fix in the patch. Item (3) is unchanged from the first report. Once the second attached patch is applied, this bug is fully fixed.
Created attachment 8107 [details] [review] Disregard prior patch, this is the correct one
I'll check this patch. Thanks.
Applied it today to both branches. The patch looked fine, i wanted to understand the reasons behind the fix before applying it. your patches are great, I hope you can keep contributing to gnome-print. bug, is fixed.