eps@toaster.SFSU.EDU (Eric P. Scott) (06/17/91)
In article <534@heaven.woodside.ca.us> glenn@heaven.woodside.ca.us (Glenn Reid) writes: >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. You might find /usr/lib/NextStep/printPackage.ps amusing. Then again, you might not. >Why is this done? Is there a good rationale for it that I'm missing? From "Welcome to 2.0: An Entry Point for Developers" The Text object, in conjunction with the Window Server and packages, supports a new character encoding called NeXTstep encoding. This new encoding includes all of the characters in ISOLatin1, although some of the character codes differ from the standard. This means there is now much better support for European language representation. From "2.0 Release Note: Application Kit" We are using a new character encoding, NextStepEncoding, which is a superset of our previous encoding, AdobeStandardEncoding. The new encoding has all the characters found in the ISOLatin1 character set, although some characters are in different places due to compatibility with our previous character set. The characters NX_EMSPACE, NX_ENSPACE and NX_THINSPACE are no longer defined (these were never generated by the keyboard). Not to resurrect a dead horse, but I think NeXT missed the boat in a BIG way. While the rest of the world has pretty much standardized on ISO 8859-1 as the "new ASCII," NeXT went with something proprietary. It doesn't matter whether it "has all the characters"--it's not the same, so documents NFS-mounted from, say, a Sun aren't going to be compatible. Stupid!!! What's worse is that text characters in NextStep are declared as shorts. Had ISO DIS 10646 been approved as an IS earlier this month, NeXT would have lost its gamble bigtime. I also I think NeXT is backing Unicode for the wrong reasons. (I'm probably going to hear from Rick McGowan on this... :-) ) Back to the original question: I'm as baffled as you are. I think NeXT should have left things alone and reencoded to ISOLatin1 if necessary. -=EPS=- ------- for NeXT on-screen use or NeXT Laser Printer ONLY %!PS-Adobe-2.0 EPSF-1.2 %%BoundingBox: 0 0 468 488 %%DocumentFonts: Helvetica %%EndComments gsave /Helvetica findfont 18 scalefont setfont 74 470 moveto (NeXT default and ISOLatin1 encodings) show /docol1 { currentpoint 4 2 roll 1 exch { dup (???) cvs dup stringwidth pop 21 exch sub 0 rmoveto show 9 0 rmoveto (?) dup 0 3 index put show pop 14 sub 2 copy moveto } for 448 add moveto } bind def /docol2 { currentpoint 4 2 roll 1 exch { 46 0 rmoveto (?) dup 0 3 index put show pop 14 sub 2 copy moveto } for 448 add moveto } bind def 0 setgray /Helvetica findfont 12 scalefont setfont 10 440 moveto 32 63 docol1 67 0 rmoveto 64 95 docol1 67 0 rmoveto 96 127 docol1 67 0 rmoveto 128 159 docol1 67 0 rmoveto 160 191 docol1 67 0 rmoveto 192 223 docol1 67 0 rmoveto 224 255 docol1 /Helvetica findfont dup length dict /newdict exch def { 1 index /FID ne { newdict 3 1 roll put } { pop pop } ifelse } forall newdict /Encoding ISOLatin1Encoding put /I-Helvetica newdict definefont pop /I-Helvetica findfont 12 scalefont setfont 211 440 moveto 128 159 docol2 67 0 rmoveto 160 191 docol2 67 0 rmoveto 192 223 docol2 67 0 rmoveto 224 255 docol2 grestore