hsg@duke.cs.duke.edu (Henry Greenside) (06/13/91)
Several times, I have tried to print out .ps files from public (ftp) sources (e.g., the apE documentation) on a NeXtstation with a NeXT laserprinter using the 'lpr' utility. The output is 90% ok but has numerous annoying errors, e.g., the letters "fl" appear as an e with an umlaut, and various italicized words appear inside the fractions 1/4 and 1/2. Clearly some error in translation is occurring. Does anyone know how to fix this? Another related question: the pages are printed in numerical order by the laser printer, which is NOT what I want. Instead, the printer should print output in REVERSE numerical order so that the output is already sorted correctly. Is there someway to indicate this with lpr? Henry
eps@toaster.SFSU.EDU (Eric P. Scott) (06/13/91)
In article <676783283@macbeth.cs.duke.edu> hsg@duke.cs.duke.edu (Henry Greenside) writes: >Several times, I have tried to print out .ps files from >public (ftp) sources (e.g., the apE documentation) on a >NeXtstation with a NeXT laserprinter using the 'lpr' >utility. The output is 90% ok but has numerous annoying >errors, e.g., the letters "fl" appear as an e with an >umlaut, and various italicized words appear inside the >fractions 1/4 and 1/2. > >Clearly some error in translation is occurring. Does >anyone know how to fix this? I don't think it's fixable (i.e. sounds like the output of a defective translator). Bitch at OSC. They charge money for apE, they should deliver something that works. >Another related question: the pages are printed in >numerical order by the laser printer, which is NOT what >I want. Instead, the printer should print output in >REVERSE numerical order so that the output is already >sorted correctly. Is there someway to indicate this >with lpr? NeXT's printing software can page-reverse ->Conforming<- PostScript. If you have something that doesn't adhere to Adobe's Document Structuring Conventions, it can only be printed "top to bottom." It really sounds like you got ahold of some bad PostScript. I don't think you're doing anything wrong. -=EPS=-
eps@toaster.SFSU.EDU (Eric P. Scott) (06/15/91)
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. Note that the NeXT version of FrameMaker uses a different prolog and produces proper Conforming PostScript. -=EPS=-
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)