Some time ago I posted the following question to this list:
>Date: Tue, 19 Nov 91 02:42:32 EST
>From: Filipe Santos <FVSANTOS@BRLNCC.BITNET>
>Subject: NEWSprint won't print some characters
To: Sun Managers Distribution List <sun-managers@eecs.nwu.edu>
> Hi,
> Our lab recently got some SPARCstations and a SPARCprinter. Everywhere
>I read it says that NEWSprint will take any legal postscript file and
>will print it on that printer. Well, we have some ps files generated in
>IBM PC Windows applications (Ventura/Pagemaker/Word) for the Apple
>LaserWriter. These files print ok on all postscript printers I tried,
>but not on the SPARCprinter. The problem is, all accented characters
>(foreign, for english speaking people) used in portuguese (our language)
>texts do not print. What comes out instead is a nice round black dot,
>irrespective of font style (but scaled to the proper font size :-) ).
>All other text characters are printed ok, and so do graphics, even color
>ones.
stuff deleted...
>All files were transfered by floppy disk, and dos2unix was run over them
>afterwards. The ps file is recognized as such by pageview, and is show
>correctly on-screen (minus the troublesome characters, censored by the black
>dots).
Later I ftp-ed the files. Same results...
>I suspect that the F3 (yet another format!) fonts shipped with
>Openwindows/NEWS/NEWSprint are not complete, in the sense that they do
>not contain the full ISO Latin 1 character set. This fact suggests that
the xfont dumping command shows all chars are there.
>buying a SPARCprinter instead of a true Postscript printer may not be
>such a good idea, for one knows not what perils lurk within that ps
>interpreter/rasterizer.
True, but not the fault of the SPARCprinter. Anyway, get a true PS
printer, with built-in interpreter.
Not all the chips are in yet, but I can already summarize some conclusions.
I analyzed the ps files that wouldn't print, all generated by Windows
3.0 apps. All these files have a common header, where the Postscript
VM (virtual machine) environment is set up.
Within this header the ps fonts are reencoded according to the ANSI char
table Windows likes. Reencoding means, reassigning the char code<->char
face correspondence, from the ps standard encoding to any other. In the
standard encoding most of the accented chars have no char code assigned,
and therefore cannot be accessed. All apps then usually reencode the
standard fonts so that the all desired char faces are mapped to a char
code, which can be anything between 0 and 255. Those codes that are not
used are usually mapped, BY THE APP, to the .notdef symbol, which is a
no-op. Nothing gets printed when one of these codes appear.
Well, the windows ps header does things a little differently than
everybody else. Before assigning a char code to a char face it checks
whether the char face EXISTS within the font or not. In case the char
face does not exist the char code is mapped to the BULLET (a nice round
black dot!) char face. Every ps interpreter I tried returned that the
accented char faces EXISTED within the font but was not MAPPED to any
char code yet, just the way the w3 ps header expected. OpenWindows 2.0
reports (through pageview) that all char faces that are not MAPPED to a
char code do not EXIST. That's why the w3ps header sets all foreign
chars to bullets.
But the faces DO EXIST under Openwindows, for I wrote a small ps program
that does the mapping, then check the mapping and the face existence.
Openwindows then reports both that they are MAPPED and EXIST, and will
happily print all of them.
Ok, so much for the long explanation. But there's a mad crowd out there
and the door won't hold much longer, so where's the solution ?
1.A quick fix would be to edit the w3 ps header to disable the existance
check. This works, but there are other problems (with underlines,
text/graphics alignment) that remain. I have not solved these, but they
show up only when the user is printing something fancy. Since there are
few such users here I'm relying on my authoritative tone to get them off
my back. :-) Definitely some better scheme must be found. read on.
2. Get a NeWS patch that supposedly corrects this. I'm waiting for my
Sun representative to get me all Sun patches. But I'm not standing up.
Someone whose msg I lost told me "had the same problem, installed patch,
now I'm worry-free". Thanks for the pointer! Anyway, I haven't been able
to test this yet.
3. Get Openwindows 3.0 (beta). Maybe this "feature" is corrected in this
NeWS release. Drop me a note in case you'd like some w3 ps code for
testing. A good test is the char set table that comes with VP 3.0 for
Windows 3.0. I don't have OW3.0 .
Thanks to all who sent me suggestions,
From: stanley@oce.orst.edu (John Stanley)
From: erueg@cfgauss.uni-math.gwdg.de (Eckhard Rueggeberg)
From: stumpf@sun8.psychologie.uni-freiburg.de (Michael Stumpf)
From: zjat02@trc.amoco.com
From: Lost your msg... :-( Sorry!
Filipe Santos
FVSANTOS@BRLNCC.BITNET
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:21 CDT