--- Mike FABIAN
Mike Shegedin
����Ͻޤ���: Hey, Mike. I printed the Japanese google homepage to a file and passed it to gs as you stated. GS diplayed boxes just like it did when they were printed out. Standard output gave me lots of the following: -------------------- Scanning /usr/share/fonts/ for fonts... 0 files, 0 scanned, 0 new fonts. Can't find (or can't open) font file /usr/share/ghostscript/Resource/Font/Ryumin -Light-EUC-H. Can't find (or can't open) font file Ryumin-Light-EUC-H. Substituting font Courier for Ryumin-Light-EUC-H. ---------------------
That means your firefox/Mozilla is setup not to use font embedding but to write requests for the printer resident font Ryumin-Light into the PostScript output.
And somehow your Ghostscript doesn't support that font. That means something is wrong with your ghostscript-cjk. If ghostscript-cjk worked correctly, you would get readable Japanese, the PostScript file produced by firefox/Mozilla is probably OK.
We'll find out ...
I also did the grep command you gave me on the output file. I got no output from the grep it whatsoever.
That confirms that firefox/Mozilla did not embed CJK fonts into the PostScript output.
I'm curious about the font embedding you mentioned. Did you mean that GS will either attempt to embed a font into a ps document before it is rendered or will attempt to either load the requested font or make a substitution when the font is not available to GS? Is this the primary function of ghostscript-cjk?
No, I meant that Mozilla will embed the Japanese fonts into the PostScript. In that case, Ghostscript will not need to support Japanese fonts at all because all the fonts are already in the PostScript.
It is possible to setup Mozilla that way and in the long run it is much better than to use the printer resident fonts. Because when fontembedding is used correctly, this will give you PostScript files which will use exactly the same fonts as you saw on the screen. When using the printer resident fonts, you will only see one font (Ryumin-Light) in the printout, even if several different fonts were used on the screen. And you could copy such PostScript files to any computer and print on any printer without the need of Japanese font support in Ghostscript or the printer. I.e. for the future, this is the way to go and I hope this will already work correctly in SuSE 9.3.
But until very recently, the fontembedding code was still very broken in Mozilla, i.e. you could just as well use the printer resident fonts.
Let's try to find out what is wrong with your ghostscript-cjk. You may need that anyway to print some Japanese PostScript files which don't have fonts embedded, not only because of Mozilla.
Did
SuSEconfig --module ghostscript-cjk
create the wrapper
/usr/share/ghostscript/Resource/CIDFont/Ryumin-Light
for you? If yes, what is in there? Should look like this:
mike@nozomi:/usr/share/ghostscript/Resource$ cat CIDFont/Ryumin-Light %!PS-Adobe-3.0 Resource-CIDFont %%Creator: aliascid.ps by Taiji Yamada
and gs-cjk project %%BeginResource: CIDFont (Ryumin-Light) (Ryumin-Light) (/usr/X11R6/lib/X11/fonts/truetype/HGJMLBMP.TTC) .openttcidfont /CIDFont defineresource pop %%EndResource %%EOF mike@nozomi:/usr/share/ghostscript/Resource$ Only in your case it should be a different font. HGJMLBMP.TTC is from the Novell-ricoh-fonts package which is only included in the version of SuSE 9.3 sold in Japan. The script /usr/sbin/ghostscript-cjk-config will try to insert the "best" installed Japanese Mincho style font there, to see the order in which fonts are preferred you can look into /usr/sbin/ghostscript-cjk-config where you will find:
# install wrappers for standard PostScript names:
install_ps_name ("alias-aj1.sh", "Ryumin-Light", "hgmlsun.ttf", "msmincho.ttc", "HGJMLBMP.TTC", "ricoh-mincho.ttc", "ipamp.ttf", "sazanami-mincho.ttf", "kochi-mincho.ttf", "kochi-mincho-subst.ttf");
The topmost font from this list which exists on your system will be used. In your case this is probably
/usr/X11R6/lib/X11/fonts/truetype/sazanami-mincho.ttf
Is everything correct until here?
-- Mike FABIAN
http://www.suse.de/~mfabian ��̲���Ϥ����Ż���Ũ���� -- To unsubscribe, e-mail: m17n-unsubscribe@suse.com For additional commands, e-mail: m17n-help@suse.com
You said: --------------------
Did SuSEconfig --module ghostscript-cjk create the wrapper /usr/share/ghostscript/Resource/CIDFont/Ryumin-Light for you? If yes, what is in there? Should look like
Mike, no, I don't have a wrapper for Ryumin-Light in that directory. All that is there is: . .. WadaGo-Bold WadaMaruGo-Regular WadaMin-Bold WadaMin-Regular I did check for the wrapper you suggested and the closest thing I could find was: ./usr/lib/ooo-1.1/share/psprint/fontmetric/Ryumin-Light-83pv-RKSJ-H.afm ./usr/lib/ooo-1.1/share/psprint/fontmetric/Ryumin-Light.Roman.afm which seem to have something to do with OpenOffice. I double checked that ghostscript-cjk was in fact installed and performed SuSEconfig --module ghostscript-cjk again with no new results. So why wasn't the wrapper installed? My rpm of ghostscript-cjk would appear to be one made for SuSE9.1 while I'm running 9.2. Make a difference? The instructions you gave about getting into the wrapper seen to be beyond what I can do at this point in the game until we get the Ryumin-Light wrapper resolved. What do you suggest, Mike? BTW, you mentioned:
you can look into /usr/sbin/ghostscript-cjk-config where you will find:
My system does not have "ghostscript-cjk-config" anywhere. Hmm. Bad rpm? In case this is a possibility, where do you recommend I go to get good rpms for SuSE? Mike __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/