On Wed, 19 Jun 2002, Mike Fabian wrote:
> > Am Montag, 17. Juni 2002 08:28 schrieb Wolfgang Slany:
> >> Since updating to suse 8.0 the following problem appeared:
> >> I cannot print Japanese pages from netscape (nor mozilla): only bakemoji
> >> result. Printing to file and inspecting the file via gv on the screen
> >> works fine, but printing the same file via gv results in the same bakemoji
> >> output. Printing Japanese pages from konqueror (with option embed fonts)
> >> works OK (though konqueror has some other problems when printing Japanese,
> >> i.e., the characters are printed but there is no space between them, and
> >> often characters are overwritten with the following text etc). Print
> >> command in all cases was lpr.
> >> Cjk-LaTeX postscript prints fine.
> >> Could it be that the update reset the print filter so that lpr since then
> >> can print only embedded fonts? Any fix for this known?
> > Thats the same problem I had. Mike helped me to solve it. Shortly,
> > use qtconfig to choose the right fonts as substitution (see als
> > Mike's CJK-manual). Since this time everything worked fine.
> Wolfgangs problem seems to be different. Printing with embedded fonts,
> e.g. from KDE3 works for Wolfgang. What does not work is Japanese
> printing when the fonts are not embedded but only font names to use
> like "Ryumin-Light" or "GothicBBB-Medium" are specified in the
> PostScript files. Netscape 4.x does print like this, it doesn't embed
> fonts. Mozilla does the same.
> To print such files, you need to do one of the following things:
> 1) use a Japanese PostScript printer and setup your printing
> queue with YaST2 to use a PostScript device
I have only a HP Laserjet 5L without postscript, so this was never a
possibility in my case.
> 2) use any printer (PostScript or not) and setup your printing queue
> with YaST2 *not* to use PostScript but a printer specific
> format instead (for example ljet4, deskjet, epson, necp6, ...
> whatever). But even if your printer is a PostScript printer,
> do *not* configure it as a PostScript printer! Configure
> the printer specific driver instead, then Ghostscript will
> be used automatically to render the fonts.
I tried it but it did not work: lj5mono driver with ghostscript produced
only garbage (the output was not recognized as pcl5 from the printer
despite claiming to be so from the one line that printed), and the ljet4
driver produced the same result (mojibake for Japanese) as before when I
install a new ljet4 printer via yast2 and printed to it.
> 3) Preprocess the file manually with Ghostscript, for example:
> gs -dNOPAUSE -dBATCH -sPAPERSIZE=a4 -sDEVICE=pswrite -sOutputFile=file.pswrite file.ps
> Instead of 'pswrite' you can use a printer specific device
> like 'ljet4'. If you use a printer specific devide, you
> can print the result on a raw printer queue, which does
> nor further filtering. In that case you need to setup
> such a queue with YaST2.
> If you use 'pswrite', Ghostscript will write PostScript
> output again, but embed *all* used fonts as Vector graphics
> in the file. I.e. you can print such a file on any
> any PostScript printer, no matter what fonts the printer has.
> I manually use Ghostscript with the 'pswrite' device to
> preprocess Japanese Postscript files quite often, because
> this allows me to correctly print them on systems
> where I have no idea how the printing queue is setup and
> whether the printer has Japanese fonts or not.
> For example, here at SuSE I often print using some network
> print server, like:
> lpr -P printername@servername filename
> I am not the sysadmin of this server and therefore I cannot
> install Japanese fonts for Ghostscript and setup a printer
> queue to use Ghostscript. And the printers here in Germany
> don't have Japanese fonts.
> But if I preprocess the PostScript file locally with
> Ghostscript's 'pswrite' device, I can send the result
> even to such a printer queue and have it printed correctly.
> Usually I use the attached 'ps2dev' script for that purpose:
> ps2dev file.ps
> which will then produce file.pswrite. Or use it like
> ps2dev -sDEVICE=ljet4 file.ps
> to produce file.ljet4 which can be sent via a raw queue
> to a HP Lasejet4.
> The 'pswrite' output device is also useful if you want
> to create portable PostScript file which you can take
> with you and print somewhere else on some unknown
> System, where you don't know what type of printer is used
> there (therefore you may not want to use something
> like 'ljet4') and you don't know what fonts are available.
> A file preprocessed with Ghostscript using the 'pswrite'
> device can be printed almost everywhere.
This (both via ps2dev as via gs -sDEVICE=ljet4 and printing to lp-raw)
finally worked. I still do not understand what goes wrong with the normal
print queue since it is sure that it must also use gs (as I have no
postscript printer) and the same device ljet4 (where I specified the ljet4
printer name). In netscape I can now specify
gs -q -dNOPAUSE -dBATCH -sPAPERSIZE=a4 -sDEVICE=ljet4 -sOutputFile=- - |lpr -Plp-raw
gs -q -dNOPAUSE -dBATCH -sPAPERSIZE=a4 -sDEVICE=ljet4 -sOutputFile=- - |lpr
gs -q -dNOPAUSE -dBATCH -sPAPERSIZE=a4 -sDEVICE=pswrite -sOutputFile=- - |lpr
as printer and it will print correctly. The last one (with the pswrite) is
the best as the others feed some empty pages after the actual printing.
What I cannot currently explain is that being able to see the correct
characters on the screen using gv and printing from gv still produces only
mojibake (romaji appear correctly, as do graphics), as if gv knew the
Japanese fonts only for the screen but not for the printer, while at the
same time printing is only possible directly via gs with the ljet4 device
specified. Basically, why does gs know the Japanese fonts when it is
called directly but not when it is called implicitly in the print queue?
Does the print queue use a different gs?
Best regards, Wolfgang
Wolfgang SLANY mailto:email@example.com