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.

or

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.

or

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 or gs -q -dNOPAUSE -dBATCH -sPAPERSIZE=a4 -sDEVICE=ljet4 -sOutputFile=- - |lpr or 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:wsi@dbai.tuwien.ac.at