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... ^@^@^@� 0 0 ^@^@^@^@ 0 0 ^@^@^@^@ 0 0 ^@^@^@^@ 0 0 ^@^@^@^@ 0 0 ^@^@^@^@ 0 0 ^@^@^@^@ 0 0 ^@^@^@^@ 0 0 ^@^@^@� 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) ^@^@^@�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.
Sorry, forget to mention this is with gs head (r9931).
s/forget/forgot/
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.
Chris already has bug #690653 and this is both a font issue and related to that one, so passing to CHris.
Probably similar to: https://bugzilla.redhat.com/show_bug.cgi?id=969660 ? Or the reverse (that is similar to this...)
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?
(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).
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.
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.
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.
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.
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.
(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).
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.
(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).
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!