glenn@heaven.woodside.ca.us (Glenn Reid) (06/17/91)
Eric P. Scott writes > Aha! I just ran into a PostScript document with problems very > much like what Henry described. The culprit here is: > > % FrameMaker PostScript Prolog 2.0, for use with FrameMaker 2.0 > % Copyright (c) 1986,87,89 by Frame Technology, Inc. All rights reserved. > > containing the test > > Encoding StandardEncoding eq > > By changing this to > > Encoding dup StandardEncoding eq exch NextStepEncoding eq or > > I was able to get it to Preview correctly. In my opinion, this is a major bug/faux-pas on NeXT's part. The name "StandardEncoding" is an Adobe standard and has documented in the Red Book for 6 years. The name "NextStepEncoding" should never appear at the user level of PostScript programs. In particular, the fonts SHOULD NOT START OUT with NextStepEncoding before the apps can get their hands on them. They should start out as StandardEncoding, so that peoples' reencoding algorithms work correctly. I don't know exactly where along the way they subvert this, but if you do the following thing in "pft" (low-level interface to the interpreter on a NeXT): /Times-Roman findfont /Encoding get StandardEncoding eq you get "false". It comes with NextStepEncoding when you get it back from "findfont". I think this is wrong. In fact, it broke several things that I wrote, and it obviously causes FrameMaker files from other platforms not to work correctly. I can see maybe that the Text object needs to reencode fonts to match StandardEncoding, but it should not start out that way for a generic PostScript program. I know this changed in version 2.0 of the system, because it caused TouchType and the Font Downloader to break subtly in a few places. Why is this done? Is there a good rationale for it that I'm missing? -- Glenn Reid RightBrain Software glenn@heaven.woodside.ca.us NeXT/PostScript developers ..{adobe,next}!heaven!glenn 415-326-2974 (NeXTfax 326-2977)