Summary: | Issue with fonts on MacPro | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Marcos H. Woehrmann <marcos.woehrmann> |
Component: | Config/Install | Assignee: | Chris Liddell (chrisl) <chris.liddell> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | christinedelight.top85, htl10, ray.johnston |
Priority: | P4 | Keywords: | bountiable |
Version: | master | ||
Hardware: | Macintosh | ||
OS: | MacOS X | ||
Customer: | Word Size: | --- | |
Attachments: |
patch to clamp the name to 65535
patch to fix the font scanning code against strange fonts or non-fonts. |
Description
Marcos H. Woehrmann
2009-08-05 09:28:11 UTC
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! |