Bug 690692 - Issue with fonts on MacPro
Summary: Issue with fonts on MacPro
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Config/Install (show other bugs)
Version: master
Hardware: Macintosh MacOS X
: P4 normal
Assignee: Chris Liddell (chrisl)
URL:
Keywords: bountiable
Depends on:
Blocks:
 
Reported: 2009-08-05 09:28 UTC by Marcos H. Woehrmann
Modified: 2013-06-25 09:10 UTC (History)
3 users (show)

See Also:
Customer:
Word Size: ---


Attachments
patch to clamp the name to 65535 (544 bytes, patch)
2013-06-15 00:26 UTC, Hin-Tak Leung
Details | Diff
patch to fix the font scanning code against strange fonts or non-fonts. (1.88 KB, patch)
2013-06-18 01:25 UTC, Hin-Tak Leung
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Marcos H. Woehrmann 2009-08-05 09:28:11 UTC
There appears to be something odd on Henry's MacPro related to fonts.  This can
be demonstrated with the following:

  % make distclean
  % ./configure
  % make debug
  % debugobj/gs -dDEBUG
  GS> /TimesNewRomanPSMT findfont

On my iMac this results in the expected:

Can't find (or can't open) font file %rom%Resource/Font/TimesNewRomanPSMT.
Can't find (or can't open) font file TimesNewRomanPSMT.
Querying operating system for font files...
Didn't find this font on the system!
Substituting font Times-Roman for TimesNewRomanPSMT.
Loading NimbusRomNo9L-Regu font from %rom%Resource/Font/NimbusRomNo9L-Regu...
2576424 1091681 2621312 1329028 1 done.
GS<1>

On Henry's MacPro:

Can't find (or can't open) font file %rom%Resource/Font/TimesNewRomanPSMT.
Can't find (or can't open) font file TimesNewRomanPSMT.
Querying operating system for font files...
^@^@^@&#65533; 0 0
^@^@^@^@ 0 0
^@^@^@^@ 0 0
^@^@^@^@ 0 0
^@^@^@^@ 0 0
^@^@^@^@ 0 0
^@^@^@^@ 0 0
^@^@^@^@ 0 0
^@^@^@&#65533; 0 0
^@^@^@^@ 0 0
^@^@^@^@ 0 0
^@^@^@^@ 0 0
^@^@^@^@ 0 0
^@^@^@^@ 0 0
^@^@^@^@ 0 0
^@^@^@^@ 0 0
OS/2 284 96
cmap 380 1050
cvt  1432 92
fpgm 1524 104
gasp 1628 16
glyf 1644 71326
head 72972 54
hhea 73028 36
hmtx 73064 1564
kern 74628 6006
loca 80636 784
maxp 81420 32
name 81452 1299
post 82752 2030
prep 84784 10
vhea 84796 36
vmtx 84832 1564
findname: 6 = (LuxiSerif-Oblique)
DSIG 174644 9288
LTSH 3196 667
OS/2 456 86
TSIV 134864 39780
VDMX 3864 5998
cmap 25904 1718
cvt  31032 1390
fpgm 27624 1269
gasp 134848 16
glyf 33752 83718
hdmx 9864 16040
head 332 54
.
.
.
post 300940 3752
prep 201976 387
findname: 6 = (SertoMalankara)
^@^@^@&#65533;0 0
^@^@^@^@ 0 0
^@^@^@^@ 0 0
^@^@^@^@ 0 0
^@^@^@^@ 0 0
^@^@^@^@ 0 0
Error: /rangecheck in /findfont
Operand stack:
   TimesNewRomanPSMT
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--  
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--  
%loop_continue   1753   2   3
Dictionary stack:
   --dict:1146/1684(ro)(G)--   --dict:0/20(G)--   --dict:70/200(L)--
Current allocation mode is local
Current file position is 28
GS<1>

The entire output is ~3000 lines, I can attach it if anyone cares.
Comment 1 Marcos H. Woehrmann 2009-08-05 09:28:53 UTC
Sorry, forget to mention this is with gs head (r9931).
Comment 2 Marcos H. Woehrmann 2009-08-05 09:29:55 UTC
s/forget/forgot/
Comment 3 Henry Stiles 2009-08-05 10:03:34 UTC
This is the same as 690653... I didn't make it a duplicate because the garbage
output and the rangecheck is because we do not parse/ignore apple dfonts
correctly.  Fixing 690653 will mask the dfont problem but won't fix it.
Comment 4 Ken Sharp 2013-06-12 09:09:44 UTC
Chris already has bug #690653 and this is both a font issue and related to that one, so passing to CHris.
Comment 5 Hin-Tak Leung 2013-06-13 14:33:38 UTC
Probably similar to:
https://bugzilla.redhat.com/show_bug.cgi?id=969660
? Or the reverse (that is similar to this...)
Comment 6 Hin-Tak Leung 2013-06-14 13:05:13 UTC
A similiar trick (strace -eopen ...) might be able to isolate the offending font on the MacPro - or is this a generic problem of an entire class/type of fonts on Mac OS X?
Comment 7 Hin-Tak Leung 2013-06-14 13:09:14 UTC
(In reply to comment #0)
> The entire output is ~3000 lines, I can attach it if anyone cares.

"strace -eopen ..." might be more interesting. From my own system, the info from -dDEBUG info are irrelevant and misleading. (gs is stopping at a font which it does not output any DEBUG info of).
Comment 8 Hin-Tak Leung 2013-06-15 00:26:28 UTC
Created attachment 9966 [details]
patch to clamp the name to 65535

This is the same patch as:
https://bugzilla.redhat.com/show_bug.cgi?id=969660#c6

here is the detailed description.
------------
The font is legal I think (and was created by fontforge, apparently), but the creator was being creative and put the entire text of the GPL inside the name table. Ghostscript reads the name table as string and is limited by postscript's implementation limit of string to 65535 (Appendix B1, PLRM).

Out of the 1200+ truetype-like fonts on my system, I have 10 fonts with name above 47k and the 2nd highest being 56559 . So while being extreme, close to 65535 is not too rare.
------------

Oh, the name is 108959 in size.

It may or may not be the same issue, but it is probably a similar problem where one of the fonts have attributes, etc which are not expected by the postscript-based font parsing code in Resource/Init/*.ps

So having both "gs -dDEBUG" and "strace -eopen ...", and the actual offending font itself (the last font file opened in "strace -eopen ...") would be useful.
Comment 9 Hin-Tak Leung 2013-06-18 01:15:01 UTC
The patch (to follow) touches something that Ray did a while ago.

The bottom line is that testing for \000 or t or O is really inadequate around line 45 of Resource/Init/gs_ttf.ps . Mac OS X dfonts starts with \000\000\001\000, (that's close enough to truetype's \000\001\000\000 ). So /.findfontvalue calls /.findttfontname which in turns calls .loadttfonttables and comes back with random garbage. The redhat bugzilla bug is related but not the same thing: the fonttables in that font are valid but unexpected by the current code.

Now *while* trying to read ttf tables from random garbage, -dDEBUG also write the offsets of the bogus tables out as it reads, so that's where those "^@^@^@^@ 0 0" comes from. (much of the beginning of dfonts are a lot of zeros).

I got a rangecheck with getinterval (on the 8th line of) .loadttfonttables on every dfonts except 1, so it seems some dfonts (or some versions of them) results in a rangecheck while some don't (and are simply skipped due to not having a font name, but does not cause a visible problem). This comes from testing on the font directories of a Mac OS X 10.7 box.
Comment 10 Hin-Tak Leung 2013-06-18 01:25:26 UTC
Created attachment 9997 [details]
patch to fix the font scanning code against strange fonts or non-fonts.

Check the first 4 bytes of a file before calling .findttfontname, instead of just one byte; Mac OS X dfonts also starts with \000 like truetype fonts, so the old test was inadequate.

Also truncate the name below 65535 to prevent a limitcheck - some font vendors put the entire text of license agreement inside that.
Comment 11 Hin-Tak Leung 2013-06-25 01:41:54 UTC
Any chance of the patch getting tested/committed, and this closed? AFAIC the patch does the job, although there are a few font tests in various places which could be rationalized/refactored. (such as one for ttf, one for ttf+otf, and one for otf only). Having some font test functions as this patch does is a move in the right direction.
Comment 12 Chris Liddell (chrisl) 2013-06-25 06:25:28 UTC
I wasn't able to reproduce the problem on my Mac. Your patch looks fine, but without being to reproduce the problem, I can't be sure that the patch fixes *this* issue.

I suppose I can apply the patch, and assign to Marcos to retest on the Henry's MacPro. I'll see about that later today.
Comment 13 Hin-Tak Leung 2013-06-25 08:31:47 UTC
(In reply to comment #12)
> I wasn't able to reproduce the problem on my Mac. Your patch looks fine, but
> without being to reproduce the problem, I can't be sure that the patch fixes
> *this* issue.
> 
> I suppose I can apply the patch, and assign to Marcos to retest on the
> Henry's MacPro. I'll see about that later today.

I was able to reproduce most (all?) of what Marcos saw, by getting gs to scan two font directories I got off a 10.7 box. (/Library/Fonts and /System/Library/Fonts, I think, on the same machine). Half of the dfonts results in a rangecheck; the others are either skipped or resulted in a "findname 6 not found"/"findname 4 not found"; with -dDEBUG all of them give funny "0 0 0" messages. So the precise behavior appears to be somewhat font/version-dependent.

The 10.7 box is a normal desktop box for use so did have a few non-Apple things installed, in particular, Adobe Illustrator. The dfonts which gives rangecheck are Courier, Geneva, Helvetica, Times, and the ones which don't, are HelveticaNeue, Monaco, CharcoalCY, GenevaCY, HelveticaCY .

I just thought of one other way (other than the problem being font/version-dependent) - if you happen to have "TimesNewRomanPSMT" font fairly early in your system's font scan. So one possible way of trying hard to the rangecheck is to do a bogus font query. i.e. 

/SomeFontThatIsSureNotToBeFound findfont

Besides font/version, and the existence of a genuine TimesNewRomanPSMT font which ends a scan, a 3rd possible difference is explicit FONTPATH/GS_FONTPATH or implicit from say, a different version of fontconfig (e.g. an older one as shipped from Apple vs a more up-to-date one from macport).
Comment 14 Chris Liddell (chrisl) 2013-06-25 08:43:54 UTC
Ah, sorry, I thought you'd only been looking at it on Fedora, if you were able to see the problem, and check the patch on OS X then I'm happy to proceed on that basis.
Comment 15 Hin-Tak Leung 2013-06-25 09:04:37 UTC
(In reply to comment #14)
> Ah, sorry, I thought you'd only been looking at it on Fedora, if you were
> able to see the problem, and check the patch on OS X then I'm happy to
> proceed on that basis.

I started looking at how gs does font scans, with the problem with the Pagul font on Fedora. Then I remember I had a disk image of a Mac OS X 10.7 system disk. So yes, I was on Fedora the entire time, but I did test against fonts found on one Mac OS X box (or rather, a disk image of part of it).
Comment 16 Chris Liddell (chrisl) 2013-06-25 09:10:36 UTC
Patch applied in:

http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=341dfa13

I'm sure you are aware of the process for claiming the bounty by now!