Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Helge Blischke Newsgroups: comp.lang.postscript Subject: Re: PostScript, Fortran, GhostScript: need help pinpointing a problem Followup-To: comp.lang.postscript Date: Sun, 14 Aug 2011 18:39:31 +0200 Lines: 62 Message-ID: <9aqc25Fon7U1@mid.individual.net> References: <4097c3f8-0d56-4a4d-82cc-d08ebc469840@a31g2000vbt.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Trace: individual.net LuPQ+fvzCIrC2PYVgYeMyA+Sj72jcSTwQgwvb0+cNDPRyXVTmI Cancel-Lock: sha1:oBQFkG5VNCEzu3To21FJe6Pdjog= User-Agent: KNode/0.99.01 Xref: x330-a1.tempe.blueboxinc.net comp.lang.postscript:296 Phillip Helbig---undress to reply wrote: > In article > <4097c3f8-0d56-4a4d-82cc-d08ebc469840@a31g2000vbt.googlegroups.com>, > SaGS writes: > >> In short, it's an assumption made by the "reencode" procedure defined >> by the PostScript code that may have been true for languagelevel 1 >> PostScript, but not necessarily for languagelevel 2 or 3. > > OK. In general, does this mean that there is no guaranteed backward > compatibility? > >> More precisely, the code assumes that if a font name is not already >> registered in FontDirectory, then that font does not really exist. >> Then it uses non-existent font names to force reencoding of PostScript >> fonts; these names are formed from the "base" PostScript font names >> with an extra character ("R") at the end, like "Helvetica- >> BoldObliqueR". >> >> Ghostscript starts with an empty FontDirectory, and uses the resource >> machinery (introduced in languagelevel 2) to find and load fonts. The >> "reencode" procedure does not find the name "Symbol" in FontDirectory, >> and assumes it has to be the name of a reencoded version of >> "Symbo" (the name it received less last character). So, the error you >> see. > > OK, now I understand where it's coming from. Since it's a GhostScript > thing, then it is clear why the file prints OK. > >> Workaround: pass "-c /Symbol findfont pop -f" on Ghostscript's command >> line, before the file you want to process. This forces loading the >> Symbol font, so it will be present in the FontDirectory. > > I can't get this to work. (I mainly used GV but am now testing a new > version of GhostScript.) try something like: gs -r72 -c save pop /Symbol findfont pop -f filename > > What, exactly, should I type at the command line (that of the OS or of > GS), when should I hit , should I quote the command etc. I've > tried all permutations. > > Is there an easy way to edit the file (preferably inserting something > only at the beginning of the file) to avoid this error? You may insert the line /Symbol findfont pop just after the line lpemuldict begin to preload the Symbol font into the FontDirectory. > > Another question: Why is the Symbol font not found in the first place? > I thought it was rather standard. as SaGS states above, Ghostscript starts with an empty FontDirectory dictioary, whereas most PostScript printers (still) preload the fonts embedded in the printer (the so called ROM fonts) during a (vendor specific) startup procedure. Helge