Re: [m17n] Japanese printing in Firefox
Mike Shegedin
Do you have the ghghostscriptjcjkackage installed?
[...]
Yes, I had recently installed ghghostscriptjcjkHere are the GS packages I have now: ghghostscriptonts-other-7.07.1rcrc207.1 ghghostscriptonts-std-7.07.1rcrc207.1 ghghostscriptibrary-7.07.1rcrc207.1 ghghostscriptjcjk0021119-211 ghghostscript11-7.07.1rcrc207.1
After installing ghghostscriptjcjkI also ran the following SuSuSEconfig-module ghghostscriptjcjkper your directions on hthttp/wwwwwususeedemfmfabianususejcjkhghostscriptthtmlhghostscriptbut
OK.
I wasn't able to do much after that.
Let's check whether your firefox/Mozilla prints with fontembedding
or not (Both is possible, depending on the settings in
firefox/Mozilla).
Print to a file instead of directly to the printer and then run
Ghostscript on that file:
gs mozilla.ps
You will see messages about fonts which are loaded on standard
output. Do you see any messages about missing fonts?
If Mozilla prints without font embedding, it writes a request
for the standard Japanese font name "Ryumin-Light" into the
Postscript output because this font is available in most
Japanese PostScript printers and also supported by Ghostscript
with the ghostscript-cjk extras. I.e., if you Mozilla prints
without fontembedding, you should see a message about loading
Ryumin-Light in the standard output of Ghostscript.
On the other hand, if you Mozilla prints with font embedding, you will
not see Ghostscript loading Ryumin-Light because the fonts are already
contained in the Postscript document.
You should then see which fonts were embedded by grepping in the
Postscript file, for example:
mike@kibou:~$ grep %%BeginResource mozilla.ps
%%BeginResource: CMap IPAPGothic.Regular.0.0_cmap
%%BeginResource: CIDFont IPAPGothic.Regular.0.0
mike@kibou:~$
--
Mike FABIAN
--- Mike FABIAN
Mike Shegedin
����Ͻޤ���: Do you have the ghghostscriptjcjkackage installed?
[...]
Yes, I had recently installed ghghostscriptjcjkHere are the GS packages I have now: ghghostscriptonts-other-7.07.1rcrc207.1 ghghostscriptonts-std-7.07.1rcrc207.1 ghghostscriptibrary-7.07.1rcrc207.1 ghghostscriptjcjk0021119-211 ghghostscript11-7.07.1rcrc207.1
After installing ghghostscriptjcjkI also ran the following SuSuSEconfig-module ghghostscriptjcjkper your directions on
hthttp/wwwwwususeedemfmfabianususejcjkhghostscriptthtmlhghostscriptbut
OK.
I wasn't able to do much after that.
Let's check whether your firefox/Mozilla prints with fontembedding or not (Both is possible, depending on the settings in firefox/Mozilla).
Print to a file instead of directly to the printer and then run Ghostscript on that file:
gs mozilla.ps
You will see messages about fonts which are loaded on standard output. Do you see any messages about missing fonts? If Mozilla prints without font embedding, it writes a request for the standard Japanese font name "Ryumin-Light" into the Postscript output because this font is available in most Japanese PostScript printers and also supported by Ghostscript with the ghostscript-cjk extras. I.e., if you Mozilla prints without fontembedding, you should see a message about loading Ryumin-Light in the standard output of Ghostscript.
On the other hand, if you Mozilla prints with font embedding, you will not see Ghostscript loading Ryumin-Light because the fonts are already contained in the Postscript document.
You should then see which fonts were embedded by grepping in the Postscript file, for example:
mike@kibou:~$ grep %%BeginResource mozilla.ps %%BeginResource: CMap IPAPGothic.Regular.0.0_cmap %%BeginResource: CIDFont IPAPGothic.Regular.0.0 mike@kibou:~$
-- Mike FABIAN
http://www.suse.de/~mfabian ��̲���Ϥ����Ż���Ũ����
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. --------------------- I also did the grep command you gave me on the output file. I got no output from the grep it whatsoever. 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? Thanks for the hand-holding, Mike. Mike __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/
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
--- 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/
Mike Shegedin
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.
Yes, that is not relevant here.
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?
Why do you use the SuSE 9.1 rpm for ghostscript-cjk on 9.2? There's no reason to do that, you should find the 9.2 version on your 9.2 CD/DVD set. You can also download it from the 9.2 FTP version: ftp://ftp.suse.com/pub/suse/i386/9.2/suse/noarch/ghostscript-cjk-20021119-218.noarch.rpm The 9.1 rpm might work on 9.2 but I never tested that. Better forget that!
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.
That's because you use an obsolete version of ghostscript-cjk.
Don't do that, update to the 9.2 version now!
In old versions of ghostscript-cjk I created the wrappers
directly in the bash script /sbin/conf.d/SuSEconfig.ghostscript-cjk.
Then I added support for artificial bold and italic by creating
additional wrapper scripts and as this became awkward in bash I
switched to using a perl script /usr/sbin/ghostscript-cjk-config
called by the the bash script /usr/sbin/SuSEconfig.ghostscript-cjk
which became almost empty because the perl script did the main work
now.
--
Mike FABIAN
--- Mike FABIAN
Mike Shegedin
����Ͻޤ���: You said: --------------------
Did SuSEconfig --module ghostscript-cjk create the wrapper
for you? If yes, what is in there? Should look
/usr/share/ghostscript/Resource/CIDFont/Ryumin-Light 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.
Yes, that is not relevant here.
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?
Why do you use the SuSE 9.1 rpm for ghostscript-cjk on 9.2? There's no reason to do that, you should find the 9.2 version on your 9.2 CD/DVD set.
You can also download it from the 9.2 FTP version:
ftp://ftp.suse.com/pub/suse/i386/9.2/suse/noarch/ghostscript-cjk-20021119-218.noarch.rpm
The 9.1 rpm might work on 9.2 but I never tested that. Better forget that!
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.
That's because you use an obsolete version of ghostscript-cjk. Don't do that, update to the 9.2 version now!
In old versions of ghostscript-cjk I created the wrappers directly in the bash script /sbin/conf.d/SuSEconfig.ghostscript-cjk.
Then I added support for artificial bold and italic by creating additional wrapper scripts and as this became awkward in bash I switched to using a perl script /usr/sbin/ghostscript-cjk-config called by the the bash script /usr/sbin/SuSEconfig.ghostscript-cjk which became almost empty because the perl script did the main work now.
-- Mike FABIAN
http://www.suse.de/~mfabian ��̲���Ϥ����Ż���Ũ���� -- To unsubscribe, e-mail: m17n-unsubscribe@suse.com For additional commands, e-mail: m17n-help@suse.com
Hello again, Mike. Yep, that was the problem. As soon as I downloaded the correct rpm, uninstalled the old one and installed it, and then ran SuSEconfig --module ghostscript-cjk, Japanese printed out from Firefox like a charm. It recognized all the nice fonts I had and everything. I was actually expecting a little more of a battle and am a bit ashamed that it came down to something so trivial. I can't believe getting Mozilla/Firefox to print Japanese is now so easy. I'm actually anxious to try it again on a fresh install just so I can prove to myself that it actually works. Thank you so much for your time and patients! Mike __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Mike Shegedin
I can't believe getting Mozilla/Firefox to print Japanese is now so easy.
When looking in more detail, you will find that there are still quite
a lot of problems with printing from Mozilla/Firefox. Luckily it
works reasonably well for Japanese with other "exotic" languages you
will find more problems.
--
Mike FABIAN
participants (2)
-
Mike FABIAN
-
Mike Shegedin