When compiling Ghostscript for 64 bit (LP64) Unix configurations, precompiled fonts produce incorrect code which results in all documents being rejected when Ghostscript initialises. The problem is in ccfont.h. The integer_v and real_v macros at lines 30 and 32 produce 32 bit aligned structures which should be 64 bit aligned. I kludged my way around the problem by replacing line 29 #define ref_(t) struct { struct tas_s tas; t value; } with the following struct tasc_s { union tasc_v { ushort type_attrs; void *alignxx; } tasc_val; }; #define ref_(t) struct { struct tasc_s tas; t value; }
Initial Note: I don't object to cleaning up the code as the patch suggests... Follow up comments... The precompiled fonts are soon to be deprecated in favor of using COMPILE_INITS=1 and placing ANY desired fonts into the Resource/Font directory before building. The precompiled font approach doesn't support other (Asian) CIDFont types and has other maintentance issues, not extending well to more fonts. While it isn't quite "ready for prime time" because we don't automatically rename the fonts in the Fontmap file and copy them to the %rom%Resource/Font romfs pseudo file system in the executable image, IMHO it is a better long term solution to "ccfont". The 'rename' is needed because fonts in the %rom%Resource/Font directory must have the actual font name, not the typical file name (i.e., n019003l.pfb). An alternative to the renaming would be to add a '%rom%fonts/' path to the romfs and copy the font files there (with names like "n019003l.pfb" from the Fontmap) and add the %rom%fonts/ path to the LIBPATH list (as we do with %rom%lib/). I'm leaving this assigned to Ralph for now, but if he wants to reassign it to me or someone else, that's fine.
*** Bug 689342 has been marked as a duplicate of this bug. ***
Precompiled fonts have been superseded by the %rom% filesystem - so closing.