Internatinal Language Support of SuSE (Pathetic)

older
Re: [m17n] Japanese, CJK and LaTeX

ghugh Song

9 Feb 2003 9 Feb '03

18:42

Hi, It is my impression that just a few people are interested in internationalization of Linux such as Mike Fabian and Jeongshik Shin. One evidence is that every SuSE distribution has had the file /usr/X11R6/lib/X11/locale/ko/Compose. It should be removed. Otherwise ami (the Korean language input method ) gives no effect. Yet, on every version of SuSE, I had to hand-remove this file. Even funny is that inside this file, there is a warning message against tampering. What is going on? I considered the above instance as the pathetic reality of the internationalization effort which is going on inside SuSE. Frustration does not stop here. I will mention just two very frustrating cases: ****Printing ******** I have wished printing Korean characters directly without doing special from mozilla for a very very looooong time. It never happened in all the SuSE distributions up to 8.1. There were promises. Well, they were promises only. All those howto file made by local gurus turned out to be not woking due to distribution changes. They are pretty much focused on RedHat distributions. ****Evolution********* A nice software called Evolutin by Ximian is suppoesed to work with Asian languages (such as Korean in my case.) However, when I grab the executable (Evolution-1.2.2) and try to run it. Something funny is going on. I can type in Korean characters and they show up nicely as I type Korean characters That means the fonts are there and are working properly. However, as soon as I type <space>, the well-viewed Korean characters suddenly change into an <underscoe>, and nothing shows up. The Evolution-1.0.2 provided by SUSE 8.1 does not have this problem. However, such an old version does not support evolution-pilot program which is the whole point of using evolution. +++++++++++++++++++++++++++++++++++++++++++++++++++++ Admittedly, everything is not controlled by SuSE. I can see that gtk-2.2 or something must have a bug. Now, it is by now evident that many things do not work as they supposed to. However not many people really are concerned with it. Only Mike and Jeongshik Shin. All the rest do not seem to care. They might try it, however after finding that it does not work for them, they give up on Linux and continue using Microsoft Windows. That is the pattern I have been finding all years. It did not change. Regards to all. -- ghugh Song MIT PS: Did I mention that I still will appreciate any solutions to the two above-mentioned problems? Please help.

Show replies by date

David Nettles

9 Feb 9 Feb

22:25

New subject: [m17n] Internatinal Language Support of SuSE (Pathetic)

HEY! I have the passion, too! I can't think of running an OS without CJK support well integrated (particularly Japanese). Keep doing the good work Fabian! GAMBAREYO! On Sun, 9 Feb 2003 1:48PM -0500, ghugh Song wrote:

...

Hi,

It is my impression that just a few people are interested in internationalization of Linux such as Mike Fabian and Jeongshik Shin.

One evidence is that every SuSE distribution has had the file /usr/X11R6/lib/X11/locale/ko/Compose.

It should be removed. Otherwise ami (the Korean language input method ) gives no effect. Yet, on every version of SuSE, I had to hand-remove this file. Even funny is that inside this file, there is a warning message against tampering.

What is going on?

I considered the above instance as the pathetic reality of the internationalization effort which is going on inside SuSE.

Frustration does not stop here. I will mention just two very frustrating cases:

****Printing ******** I have wished printing Korean characters directly without doing special from mozilla for a very very looooong time. It never happened in all the SuSE distributions up to 8.1. There were promises. Well, they were promises only. All those howto file made by local gurus turned out to be not woking due to distribution changes. They are pretty much focused on RedHat distributions.

****Evolution********* A nice software called Evolutin by Ximian is suppoesed to work with Asian languages (such as Korean in my case.)

However, when I grab the executable (Evolution-1.2.2) and try to run it. Something funny is going on.

I can type in Korean characters and they show up nicely as I type Korean characters That means the fonts are there and are working properly. However, as soon as I type <space>, the well-viewed Korean characters suddenly change into an <underscoe>, and nothing shows up.

The Evolution-1.0.2 provided by SUSE 8.1 does not have this problem. However, such an old version does not support evolution-pilot program which is the whole point of using evolution.

+++++++++++++++++++++++++++++++++++++++++++++++++++++

Admittedly, everything is not controlled by SuSE. I can see that gtk-2.2 or something must have a bug.

Now, it is by now evident that many things do not work as they supposed to. However not many people really are concerned with it. Only Mike and Jeongshik Shin. All the rest do not seem to care. They might try it, however after finding that it does not work for them, they give up on Linux and continue using Microsoft Windows.

That is the pattern I have been finding all years. It did not change.

Regards to all.

-- ghugh Song MIT

PS: Did I mention that I still will appreciate any solutions to the two above-mentioned problems? Please help.

-- To unsubscribe, e-mail: m17n-unsubscribe@suse.com For additional commands, e-mail: m17n-help@suse.com --david

Mike FABIAN

11 Feb 11 Feb

11:36

New subject: Compose and XMODIFIERS (was: [m17n] Internatinal Language Support of SuSE (Pathetic))

ghugh Song さんは書きました:

...

One evidence is that every SuSE distribution has had the file /usr/X11R6/lib/X11/locale/ko/Compose.

It should be removed. Otherwise ami (the Korean language input method ) gives no effect.

If the /usr/X11R6/lib/X11/locale/ko/Compose exists, you have to set the environment variable XMODIFIERS correctly for Ami: export XMODIFIERS="@im=Ami" If the ko/Compose file exists *and* a Korean XIM server like Ami is running, it looks like as if therer are at two input methods available for this locale, Compose and Ami (Compose is sort of a XIM server built into the X-server). Then you have to indicate which one should be used by setting XMODIFIERS correctly: export XMODIFIERS="@im=Ami" to use Ami and export XMODIFIERS="@im=local" to use Compose. Usually XMODIFIERS="@im=Ami" is set automatically by ~/.xim when the X-session is started in Korean, therefore this problem doesn't occur if the home directory of the user was created during the installation (default user) or later with YaST2, because then you have the dot-files from /etc/skel copied to the users home directory, and among these dot-files is ~/.xim and a ~/.xinitrc which sources ~/.xim. Therefore it works for the majority of users out of the box. It looks like you don't have/don't use ~/.xim for whatever reasons and use some other scripts instead to start Ami. I recommend that you add export XMODIFIERS="@im=Ami" to these scripts. If the ko/Compose file doesn't exist and Ami is *the only* XIM server running, then Ami is selected in Korean locale even if XMODIFIERS is unset. But this works only if no other XIM server besides Ami is running. If you have several XIM servers running at the same time, for example kinput2 for Japanese *and* Ami for Korean, you have to set XMODIFIERS correctly to indicate which one should be used, even if there are no Compose files neither in /usr/X11R6/lib/X11/locale/ko/Compose nor in /usr/X11R6/lib/X11/locale/ja/Compose.

...

Yet, on every version of SuSE, I had to hand-remove this file. Even funny is that inside this file, there is a warning message against tampering.

Yes, the following comment from the {ja,ko}/Compose files appears to be nonsense: # This file currently has no entries. It appears that a compose file (even # just an empty one) is required for the appropriate keysyms to work for # this encoding. it is not true that an empty Compose file is necessary, you can delete it and it still works. You even have the benefit that one XIM server works for that locale without setting XMODIFIERS. I.e. that comment really appears to be bogus. Nevertheless I think it is a good idea to always set XMODIFIERS correctly. If you rely on Ami working with XMODIFIERS unset because the Compose file is deleted, you will probably be very confused when Ami suddenly stops working as soon as a second XIM server is started. If XMODIFIERS is set, the existance of the Compose file doesn't hurt. That's why I didn't delete it, because I assumed that XMODIFIERS is always set correctly. I'll probably delete the {ja,ko}/Compose files for SuSE 8.2 though because such an empty compose file really makes no sense. And even a non-empty Compose file is probably useless for ja_JP.eucJP and ko_KR.eucKR locales, because most of the characters which you typically can input via the compose mechanism are not possible to display in EUC-KR or EUC-JP encoding anyway. I'm not yet sure about the Compose files in /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose /usr/X11R6/lib/X11/locale/ko_KR.UTF-8/Compose /usr/X11R6/lib/X11/locale/ja_JP.UTF-8/Compose (The directories ko_KR.UTF-8 and ja_JP.UTF-8 are new in XFree86 4.3.0, previously the contents of the en_US.UTF-8 directory were used for ko_KR.UTF-8 and ja_JP.UTF-8 as well). In CJK UTF-8 locales, using Compose may make sense, but I don't yet understand it fully. I found that it is possible to switch between using Compose, Ami, and kinput2 when using mlterm >= 2.6.3 in en_US.UTF-8 locale like this: XMODIFIERS=@im=local LC_ALL=en_US.UTF-8 mlterm & now Compose can be used to input special European characters, for example German. Then one can open the mlterm config menu by pressing "Control + right-mouse" and switch to Korean input using Ami or Japanese input using kinput2 and also switch back to the "local" input method to use Compose again. What I don't yet understand is why this only works when mlterm is started in en_US.UTF-8 locale with XMODIDIERS=@im=local. When starting mlterm like this: XMODIFIERS=@im=local LC_ALL=ja_JP.UTF-8 mlterm & Compose doesn't work, but switching to Korean input using Ami or Japanese input using kinput2 is possible with the mlterm config menu. And if mlterm is started in en_US.UTF-8 locale like this: XMODIFIERS=@im=kinput2 LC_ALL=en_US.UTF-8 mlterm & Japanese input using kinput2 doesn't work and switching to compose using the config menu of mlterm doesn't work either, although switching to Korean input using Ami works. This behaviour is strange and I don't really understand it, therefore I don't know what to do with the Compose files in the UTF-8 directories: /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose /usr/X11R6/lib/X11/locale/ko_KR.UTF-8/Compose /usr/X11R6/lib/X11/locale/ja_JP.UTF-8/Compose Currently, they are all identical to the one in the en_US.UTF-8 directory. -- Mike Fabian http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。

Mike FABIAN

12:53

New subject: Printing Korean from Mozilla (was: [m17n] Internatinal Language Support of SuSE (Pathetic))

ghugh Song さんは書きました:

...

****Printing ******** I have wished printing Korean characters directly without doing special from mozilla for a very very looooong time. It never happened in all the SuSE distributions up to 8.1. There were promises. Well, they were promises only. All those howto file made by local gurus turned out to be not woking due to distribution changes. They are pretty much focused on RedHat distributions.

I had patched /opt/mozilla/defaults/pref/unix.js in SuSE Linux 7.1 --- mozilla/modules/libpref/src/unix/unix.js Fri Aug 3 14:44:28 2001 +++ mozilla/modules/libpref/src/unix/unix.js Tue Aug 14 09:57:07 2001 @@ -236,8 +236,10 @@ pref("print.psnativefont.ar", ""); pref("print.psnativefont.el", ""); pref("print.psnativefont.he", ""); -pref("print.psnativefont.ja", ""); -pref("print.psnativefont.ko", ""); +pref("print.psnativecode.ja", "euc-jp"); +pref("print.psnativefont.ja", "Ryumin-Light-EUC-H"); +pref("print.psnativecode.ko", "euc-kr"); +pref("print.psnativefont.ko", "Munhwa-Regular-KSC-EUC-H"); pref("print.psnativefont.th", ""); pref("print.psnativefont.tr", ""); pref("print.psnativefont.x-baltic", ""); @@ -246,7 +248,9 @@ pref("print.psnativefont.x-unicode", ""); pref("print.psnativefont.x-user-def", ""); pref("print.psnativefont.x-western", ""); -pref("print.psnativefont.zh-CN", ""); -pref("print.psnativefont.zh-TW", ""); +pref("print.psnativecode.zh-CN", "gb2312"); +pref("print.psnativefont.zh-CN", ""); +pref("print.psnativecode.zh-TW", "big5"); +pref("print.psnativefont.zh-TW", "MOESung-Regular-B5-H"); This patch was there until SuSE Linux 8.0 and it made Korean printing from Mozilla work if you installed Munhwa fonts from the FTP version of SuSE Linux 7.1 - 8.0: ftp://ftp.suse.com/pub/suse/i386/8.1/suse/i586/CID-keyed-fonts-Munhwa-7.05.3-57.i586.rpm ftp://ftp.suse.com/pub/suse/i386/8.1/suse/i586/CMap-Adobe-Korea1-7.05.3-57.i586.rpm Unfortunately these fonts were never on the CDs, only in the FTP version, because they are very big. And, unfortunately the above patch was lost somehow in SuSE Linux 8.1. One way to get Korean printing working in SuSE Linux 8.1 again is to edit /opt/mozilla/defaults/pref/unix.js and to replace the line pref("print.postscript.nativefont.ko", ""); by pref("print.psnativecode.ko", "euc-kr"); pref("print.psnativefont.ko", "Munhwa-Regular-KSC-EUC-H"); and install CID-keyed-fonts-Munhwa and CMap-Adobe-Korea1. Another (better!) way is to edit the following two lines into /opt/mozilla/defaults/pref/unix.js instead pref("print.postscript.nativecode.ko", "UTF-8"); pref("print.postscript.nativefont.ko", "Baekmuk-Gulim-UniKS-UTF8-H"); and install the updated ghostscript packages from my personal FTP directory: ftp://ftp.suse.com/pub/people/mfabian/8.1-i586/ghostscript-fonts-other-7.05.3-99.i586.rpm ftp://ftp.suse.com/pub/people/mfabian/8.1-i586/ghostscript-fonts-rus-7.05.3-99.i586.rpm ftp://ftp.suse.com/pub/people/mfabian/8.1-i586/ghostscript-fonts-std-7.05.3-99.i586.rpm ftp://ftp.suse.com/pub/people/mfabian/8.1-i586/ghostscript-library-7.05.3-99.i586.rpm ftp://ftp.suse.com/pub/people/mfabian/8.1-i586/ghostscript-serv-7.05.3-99.i586.rpm ftp://ftp.suse.com/pub/people/mfabian/8.1-i586/ghostscript-x11-7.05.3-99.i586.rpm ftp://ftp.suse.com/pub/people/mfabian/8.1-noarch/ghostscript-cjk-20021119-9.noarch.rpm ftp://ftp.suse.com/pub/people/mfabian/8.1-nosrc/ghostscript-library-7.05.3-99.nosrc.rpm ftp://ftp.suse.com/pub/people/mfabian/8.1-src/ghostscript-cjk-20021119-9.src.rpm don't forget the new ghostscript-cjk package! These new ghostscript packages can print CJK using CJK TrueType fonts as CID-keyed fonts, therefore you can use the Baekmuk TrueType fonts for printing Korean with Ghostscript. This has the advantage that you don't need to install the extra, huge CID-keyed-fonts-Munhwa package from FTP, you can use the Baekmuk TrueType fonts which are already on the CD set. And you can also print simplified Chinese using the following entries in /opt/mozilla/defaults/pref/unix.js pref("print.postscript.nativecode.zh-CN", "UTF-8"); pref("print.postscript.nativefont.zh-CN", "GB-Song-Medium-UniGB-UTF8-H"); which wasn't possible at all before because there seems to be no free CID-keyed font for simplified Chinese. "GB-Song-Medium-UniGB-UTF8-H" is just an alias generated by /sbin/conf.d/SuSEconfig.ghostscript-cjk (See this script for details). The script makes it an alias to the commercial GB18030 font hya6gb3.ttf if this font is installed and if this font is not installed it uses gbsn00lp.ttf (one of the free Arphic PL fonts) instead. The above improved ghostscript packages are already in UnitedLinux 1.0 (which is based on SuSE Linux 8.1) but was published a few weeks later than SuSE Linux 8.1. SuSE Linux 8.2 will of course have these ghostscript packages as well, therefore I think it is best if you test these packages and give me feedback about problems to make sure Korean printing from Mozilla works out of the box on SuSE Linux 8.2. Thank you very much, Mike -- Mike Fabian http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。

ghugh Song

12 Feb 12 Feb

05:55

New subject: [m17n] Printing Korean from Mozilla (was: [m17n] Internatinal Language Support of SuSE (Pathetic))

Mike FABIAN wrote:

...

ghugh Song さんは書きました:

...
****Printing ******** I have wished printing Korean characters directly without doing special from mozilla for a very very looooong time. It never happened in all the SuSE distributions up to 8.1. There were promises. Well, they were promises only. All those howto file made by local gurus turned out to be not woking due to distribution changes. They are pretty much focused on RedHat distributions.

I had patched /opt/mozilla/defaults/pref/unix.js in SuSE Linux 7.1

--- mozilla/modules/libpref/src/unix/unix.js Fri Aug 3 14:44:28 2001 +++ mozilla/modules/libpref/src/unix/unix.js Tue Aug 14 09:57:07 2001 @@ -236,8 +236,10 @@ pref("print.psnativefont.ar", ""); pref("print.psnativefont.el", ""); pref("print.psnativefont.he", ""); -pref("print.psnativefont.ja", ""); -pref("print.psnativefont.ko", ""); +pref("print.psnativecode.ja", "euc-jp"); +pref("print.psnativefont.ja", "Ryumin-Light-EUC-H"); +pref("print.psnativecode.ko", "euc-kr"); +pref("print.psnativefont.ko", "Munhwa-Regular-KSC-EUC-H"); pref("print.psnativefont.th", ""); pref("print.psnativefont.tr", ""); pref("print.psnativefont.x-baltic", ""); @@ -246,7 +248,9 @@ pref("print.psnativefont.x-unicode", ""); pref("print.psnativefont.x-user-def", ""); pref("print.psnativefont.x-western", ""); -pref("print.psnativefont.zh-CN", ""); -pref("print.psnativefont.zh-TW", ""); +pref("print.psnativecode.zh-CN", "gb2312"); +pref("print.psnativefont.zh-CN", ""); +pref("print.psnativecode.zh-TW", "big5"); +pref("print.psnativefont.zh-TW", "MOESung-Regular-B5-H");

This patch was there until SuSE Linux 8.0 and it made Korean printing from Mozilla work if you installed Munhwa fonts from the FTP version of SuSE Linux 7.1 - 8.0:

ftp://ftp.suse.com/pub/suse/i386/8.1/suse/i586/CID-keyed-fonts-Munhwa-7.05.3-57.i586.rpm ftp://ftp.suse.com/pub/suse/i386/8.1/suse/i586/CMap-Adobe-Korea1-7.05.3-57.i586.rpm

Unfortunately these fonts were never on the CDs, only in the FTP version, because they are very big.

And, unfortunately the above patch was lost somehow in SuSE Linux 8.1.

One way to get Korean printing working in SuSE Linux 8.1 again is to edit /opt/mozilla/defaults/pref/unix.js and to replace the line

pref("print.postscript.nativefont.ko", "");

by

pref("print.psnativecode.ko", "euc-kr"); pref("print.psnativefont.ko", "Munhwa-Regular-KSC-EUC-H");

and install CID-keyed-fonts-Munhwa and CMap-Adobe-Korea1.

Another (better!) way is to edit the following two lines into /opt/mozilla/defaults/pref/unix.js instead

pref("print.postscript.nativecode.ko", "UTF-8"); pref("print.postscript.nativefont.ko", "Baekmuk-Gulim-UniKS-UTF8-H");

and install the updated ghostscript packages from my personal FTP directory:

ftp://ftp.suse.com/pub/people/mfabian/8.1-i586/ghostscript-fonts-other-7.05.3-99.i586.rpm ftp://ftp.suse.com/pub/people/mfabian/8.1-i586/ghostscript-fonts-rus-7.05.3-99.i586.rpm ftp://ftp.suse.com/pub/people/mfabian/8.1-i586/ghostscript-fonts-std-7.05.3-99.i586.rpm ftp://ftp.suse.com/pub/people/mfabian/8.1-i586/ghostscript-library-7.05.3-99.i586.rpm ftp://ftp.suse.com/pub/people/mfabian/8.1-i586/ghostscript-serv-7.05.3-99.i586.rpm ftp://ftp.suse.com/pub/people/mfabian/8.1-i586/ghostscript-x11-7.05.3-99.i586.rpm ftp://ftp.suse.com/pub/people/mfabian/8.1-noarch/ghostscript-cjk-20021119-9.noarch.rpm ftp://ftp.suse.com/pub/people/mfabian/8.1-nosrc/ghostscript-library-7.05.3-99.nosrc.rpm ftp://ftp.suse.com/pub/people/mfabian/8.1-src/ghostscript-cjk-20021119-9.src.rpm

don't forget the new ghostscript-cjk package!

These new ghostscript packages can print CJK using CJK TrueType fonts as CID-keyed fonts, therefore you can use the Baekmuk TrueType fonts for printing Korean with Ghostscript.

This has the advantage that you don't need to install the extra, huge CID-keyed-fonts-Munhwa package from FTP, you can use the Baekmuk TrueType fonts which are already on the CD set.

The above improved ghostscript packages are already in UnitedLinux 1.0 (which is based on SuSE Linux 8.1) but was published a few weeks later than SuSE Linux 8.1. SuSE Linux 8.2 will of course have these ghostscript packages as well, therefore I think it is best if you test these packages and give me feedback about problems to make sure Korean printing from Mozilla works out of the box on SuSE Linux 8.2.

Thank you very much,

Mike

Thanks a lot, Mike, Unfortunately, neither method did not work. Still the same square blocks everywhere. I have upgraded all those ghostscript rpms and I have had those Munhwa fonts all along. ANd then I did ldconfig -v. No use. By the way, I really cannot understand the position of UTF-8 in Korea. I am sure that you do not know about the situation either. Everyone uses eucKR, not UTF-8. Is UTF-8 somehow the encoding scheme recommended over the globe? I have known that eucKR and UTF-8 are definitely not compatible. I do not think that anyone in his right mind would ever switch to UTF-8 because she/he will immediately have trouble in reading her/his emails. Oh, What is UHC (unified hangul code)? What a mess! I am sure that those characters which just generated square blocks were coded by eucKR, not UTF-8. What a headache! Why should I bother with all this? I could gone to the MS Windows camp. Oh Well.. Best Regards, G. Hugh Song

Mike FABIAN

10:43

New subject: [m17n] Printing Korean from Mozilla

ghugh Song さんは書きました:

...

Unfortunately, neither method did not work. Still the same square blocks everywhere. I have upgraded all those ghostscript rpms and I have had those Munhwa fonts all along. ANd then I did ldconfig -v. No use.

I attache two korean example PostScript files for testing. Please try if you can display these with Ghostscript. Try with the 'gs' command, not 'gv' in order to see the messages which fonts are loaded. Should look like this if you have everything installed correctly: mfabian@gregory:~/test-texts$ gs korean-Baekmuk-Gulim-UniKS-UTF8-H.ps ESP Ghostscript 7.05 (2002-06-28) Copyright (C) 2002 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file COPYING for details. Loading Baekmuk-Gulim-UniKS-UTF8-H font from /usr/share/ghostscript/Resource/Font/Baekmuk-Gulim-UniKS-UTF8-H... 17136180 14436291 1662616 337756 0 done. >>showpage, press <return> to continue<< GS>quit mfabian@gregory:~/test-texts$ gs korean-Baekmuk-Gulim-KSC-EUC-H.ps ESP Ghostscript 7.05 (2002-06-28) Copyright (C) 2002 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file COPYING for details. Loading Baekmuk-Gulim-KSC-EUC-H font from /usr/share/ghostscript/Resource/Font/Baekmuk-Gulim-KSC-EUC-H... 15681640 14142029 1662616 337747 0 done. >>showpage, press <return> to continue<< GS>quit mfabian@gregory:~/test-texts$ -- Mike Fabian http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。

ghugh Song

15:08

New subject: [m17n] Printing Korean from Mozilla

Mike FABIAN wrote:

...

ghugh Song さんは書きました:

...
Unfortunately, neither method did not work. Still the same square blocks everywhere. I have upgraded all those ghostscript rpms and I have had those Munhwa fonts all along. ANd then I did ldconfig -v. No use.

I attache two korean example PostScript files for testing. Please try if you can display these with Ghostscript.

Try with the 'gs' command, not 'gv' in order to see the messages which fonts are loaded. Should look like this if you have everything installed correctly:

mfabian@gregory:~/test-texts$ gs korean-Baekmuk-Gulim-UniKS-UTF8-H.ps ESP Ghostscript 7.05 (2002-06-28) Copyright (C) 2002 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file COPYING for details. Loading Baekmuk-Gulim-UniKS-UTF8-H font from /usr/share/ghostscript/Resource/Font/Baekmuk-Gulim-UniKS-UTF8-H... 17136180 14436291 1662616 337756 0 done.

...
...
showpage, press <return> to continue<<

GS>quit mfabian@gregory:~/test-texts$ gs korean-Baekmuk-Gulim-KSC-EUC-H.ps ESP Ghostscript 7.05 (2002-06-28) Copyright (C) 2002 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file COPYING for details. Loading Baekmuk-Gulim-KSC-EUC-H font from /usr/share/ghostscript/Resource/Font/Baekmuk-Gulim-KSC-EUC-H... 15681640 14142029 1662616 337747 0 done.

...
...
showpage, press <return> to continue<<

GS>quit mfabian@gregory:~/test-texts$

------------------------------------------------------------------------

% -*- coding: euc-kr -*- /Baekmuk-Gulim-KSC-EUC-H findfont 30 scalefont setfont 50 200 moveto (Hangul ??) show showpage

------------------------------------------------------------------------

% -*- coding: utf-8 -*- /Baekmuk-Gulim-UniKS-UTF8-H findfont 30 scalefont setfont 50 200 moveto (Hangul ??) show showpage

------------------------------------------------------------------------

Thanks for the help. Unfortunately, there is still a trouble: I don't have anything inside /usr/share/ghostscript/Resource/Font/ What provides /usr/share/ghostscript/Resource/Font/Baekmuk-Gulim-KSC-EUC-H? This is the list of the ghostscript-related rpms installed. ghugh@bellini:/home/ghugh> rpm -qa | grep ghostscript ghostscript-x11-7.05.3-99 ghostscript-fonts-other-7.05.3-99 ghostscript-fonts-std-7.05.3-99 ghostscript-cjk-20021119-9 ghostscript-library-7.05.3-99 For this reason, "gs" showed the familiar error: ghugh@bellini:/home/ghugh> gs korean-Baekmuk-Gulim-UniKS-UTF8-H.ps ESP Ghostscript 7.05 (2002-06-28) Copyright (C) 2002 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file COPYING for details. Error: /undefinedfilename in (korean-Baekmuk-Gulim-UniKS-UTF8-H.ps) Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push --nostringval-- --nostringval-- Dictionary stack: --dict:1055/1417(ro)(G)-- --dict:0/20(G)-- --dict:68/200(L)-- Current allocation mode is local Last OS error: 2 ESP Ghostscript 7.05.3: Unrecoverable error, exit code 1 Incidently, the mozilla-1.3beta is out today. See http://www.mozilla.org In the release note, it is mentioned that only this new version has the xprint module which allows CJK language printout for the first time from mozilla. It is also mentioned those rpms provided for RedHat do not have this module enabled. This tells us something: Although whatever we do, it has been just obvious that we were not able to print CJK characters before mozilla-1.3beta. Am I right? Mike, would you please tell the guy in SuSE so that she/he specifically enable xprint for mozilla-1.3beta.suse.i586.rpm in the pub/project/mozilla directory? Please Mike, help me out. Thanks you very much. G. Hugh Song

Mike FABIAN

15:42

New subject: [m17n] Printing Korean from Mozilla

ghugh Song さんは書きました:

...

I don't have anything inside

/usr/share/ghostscript/Resource/Font/

You didn't run SuSEconfig?

...

What provides /usr/share/ghostscript/Resource/Font/Baekmuk-Gulim-KSC-EUC-H?

It's autogenerated by /sbin/conf.d/SuSEconfig.ghostscript-cjk What happens if you call SuSEconfig --module ghostscript-cjk or (same effect) directly /sbin/conf.d/SuSEconfig.ghostscript-cjk After that you should have the files and they should look like: mfabian@gregory:/usr/share/ghostscript/Resource$ rpm -qf CMap/KSC-EUC-H rpm -qf CMap/KSC-EUC-H ghostscript-cjk-20021119-2 mfabian@gregory:/usr/share/ghostscript/Resource$ cat CIDFont/Baekmuk-Gulim cat CIDFont/Baekmuk-Gulim %!PS-Adobe-3.0 Resource-CIDFont %%Creator: aliascid.ps by Taiji Yamada and gs-cjk project %%BeginResource: CIDFont (Baekmuk-Gulim) (Baekmuk-Gulim) (/usr/X11R6/lib/X11/fonts/truetype/gulim.ttf) .openttcidfont /CIDFont defineresource pop %%EndResource %%EOF mfabian@gregory:/usr/share/ghostscript/Resource$ cat Font/Baekmuk-Gulim-KSC-EUC-H cat Font/Baekmuk-Gulim-KSC-EUC-H %!PS-Adobe-3.0 Resource-Font %%Creator: aliascid.ps by Taiji Yamada and gs-cjk project %%DocumentNeededResources: KSC-EUC-H (CMap) %%IncludeResource: KSC-EUC-H (CMap) %%BeginResource: Font (Baekmuk-Gulim-KSC-EUC-H) (Baekmuk-Gulim-KSC-EUC-H) (KSC-EUC-H) /CMap findresource [(Baekmuk-Gulim) /CIDFont findresource] composefont pop %%EndResource %%EOF mfabian@gregory:/usr/share/ghostscript/Resource$

...

This is the list of the ghostscript-related rpms installed. ghugh@bellini:/home/ghugh> rpm -qa | grep ghostscript ghostscript-x11-7.05.3-99 ghostscript-fonts-other-7.05.3-99 ghostscript-fonts-std-7.05.3-99 ghostscript-cjk-20021119-9 ghostscript-library-7.05.3-99

That's OK.

...

For this reason, "gs" showed the familiar error:

Yes, the files are still missing on your system.

...

Incidently, the mozilla-1.3beta is out today. See http://www.mozilla.org In the release note, it is mentioned that only this new version has the xprint module which allows CJK language printout for the first time from mozilla.

It's not true that CJK printout is only possible with xprint.

...

It is also mentioned those rpms provided for RedHat do not have this module enabled. This tells us something: Although whatever we do, it has been just obvious that we were not able to print CJK characters before mozilla-1.3beta. Am I right?

No, it works for a *long* time already. It worked already in SuSE Linux 7.1.

...

Mike, would you please tell the guy in SuSE so that she/he specifically enable xprint for mozilla-1.3beta.suse.i586.rpm in the pub/project/mozilla directory?

I'm not yet sure whether xprint is a good idea or not. It has some advantages and some disadvantages. One of the advantages is that you can use different fonts for CJK in one printout whereas the PostScript output which is generated according to the configuration in /opt/mozilla/defaults/pref/unix.js can only use one font. But it's not true that CJK printout is only possible with xprint. -- Mike Fabian http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。

Mike FABIAN

15:46

New subject: [m17n] Printing Korean from Mozilla

Mike FABIAN さんは書きました:

...

What happens if you call

SuSEconfig --module ghostscript-cjk

or (same effect) directly

/sbin/conf.d/SuSEconfig.ghostscript-cjk

After that you should have the files and they should look like:

Of course you need to have the TrueType versions of the Baekmuk fonts installed (baekmuk-ttf.rpm). -- Mike Fabian http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。

ghugh Song

13 Feb 13 Feb

03:29

New subject: [m17n] Printing Korean from Mozilla

Mike FABIAN wrote:

...

ghugh Song さんは書きました:

...
I don't have anything inside

/usr/share/ghostscript/Resource/Font/

You didn't run SuSEconfig?

...
What provides /usr/share/ghostscript/Resource/Font/Baekmuk-Gulim-KSC-EUC-H?

It's autogenerated by /sbin/conf.d/SuSEconfig.ghostscript-cjk

What happens if you call

SuSEconfig --module ghostscript-cjk

or (same effect) directly

/sbin/conf.d/SuSEconfig.ghostscript-cjk

After that you should have the files and they should look like:

mfabian@gregory:/usr/share/ghostscript/Resource$ rpm -qf CMap/KSC-EUC-H rpm -qf CMap/KSC-EUC-H ghostscript-cjk-20021119-2 mfabian@gregory:/usr/share/ghostscript/Resource$ cat CIDFont/Baekmuk-Gulim cat CIDFont/Baekmuk-Gulim %!PS-Adobe-3.0 Resource-CIDFont %%Creator: aliascid.ps by Taiji Yamada and gs-cjk project %%BeginResource: CIDFont (Baekmuk-Gulim) (Baekmuk-Gulim) (/usr/X11R6/lib/X11/fonts/truetype/gulim.ttf) .openttcidfont /CIDFont defineresource pop %%EndResource %%EOF mfabian@gregory:/usr/share/ghostscript/Resource$ cat Font/Baekmuk-Gulim-KSC-EUC-H cat Font/Baekmuk-Gulim-KSC-EUC-H %!PS-Adobe-3.0 Resource-Font %%Creator: aliascid.ps by Taiji Yamada and gs-cjk project %%DocumentNeededResources: KSC-EUC-H (CMap) %%IncludeResource: KSC-EUC-H (CMap) %%BeginResource: Font (Baekmuk-Gulim-KSC-EUC-H) (Baekmuk-Gulim-KSC-EUC-H) (KSC-EUC-H) /CMap findresource [(Baekmuk-Gulim) /CIDFont findresource] composefont pop %%EndResource %%EOF mfabian@gregory:/usr/share/ghostscript/Resource$

Thanks a lot, Mike. Now, I issued "SuSEconfig" and I can see files in the directory. Guess what. gv shows the Korean character "??" correctly from the korean-Baekmuk-Gulim-KSC-EUC-H.ps file. But not from korean-Baekmuk-Gulim-UniKS-UTF8-H.ps The latter showd just "Hangul" and nothing. OK, now I tried to print from "gv" which uses "lpr". Again guess what. I got just the "cat"ed output from the hp6mp Postscript printer like this: % -*- coding: euc-kr -*- /Baekmuk-Gulim-KSC-EUC-H findfont 30 scalefont setfont 50 200 moveto (Hangul <Cryptic characters>) show showpage Incidently, I tested a printout from a sample web page containing Hangul characters. Well... Again the familiar square blocks from the printer. Oh. This is far from what I want. What did I miss? Thanks a lot. G. Hugh Song PS: I have not given up yet. So, please help me.

ghugh Song

05:57

New subject: [m17n] Printing Korean from Mozilla

ghugh Song wrote:

...

Incidently, I tested a printout from a sample web page containing Hangul characters. Well... Again the familiar square blocks from the printer.

Oh. This is far from what I want. What did I miss?

A miracle just happened to me. I was able to print one hangul web page correctly for the first time in my Linux history of seven years!!! But just briefly, unfortunately, because the printer HP2200 suddenly started throwing out blank page printouts forever after that one successful page. With Mozilla-1.2.1-1.i586.rpm, no matter what I do, it has been just square blocks at least on my HP6mp. (I cannot remember I tried a hangul page on HP2200.) With Mozilla-1.3b-0.i386.rpm, I got the correct printout from a hangul web page on a newer PS printer HP2200. Unfortunately, on my old personal printer HP6mp, I got an error printout like the following: ======================================== The PostScript interpreter in your printer is 2014.108 This printout requres at least version 2015 or greater. [ ...] ========================================= Isn't it normal? Do I have to throw out my old HP6mp? It appears that I have to update the firmware of the HP6mp. Of course, I have no idea how to flash the firmware of this printer. Mike, As you can imagine, I sorta think that mozilla-1.3b is essential in getting the corrent hangul page from the above experience. Thanks a lot. G. Hugh Song

Mike FABIAN

09:44

New subject: [m17n] Printing Korean from Mozilla

ghugh Song さんは書きました: [...]

...

Unfortunately, on my old personal printer HP6mp, I got an error printout like the following:

======================================== The PostScript interpreter in your printer is 2014.108 This printout requres at least version 2015 or greater.

[ ...] =========================================

Isn't it normal? Do I have to throw out my old HP6mp? It appears that I have to update the firmware of the HP6mp. Of course, I have no idea how to flash the firmware of this printer.

Just setup your HP6mp printer as a non-PostScript printer with YaST2 as already explained in my last mail. Then the Ghostscript will be used as the PostScript interpreter, the old PostScript interpreter in your HP6mp will not be used.

...

Mike, As you can imagine, I sorta think that mozilla-1.3b is essential in getting the corrent hangul page from the above experience.

Not true. You may have all sorts of nice new features with mozilla-1.3b, but just printing the correct hangul already works for a long, long time. -- Mike Fabian http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。

ghugh Song

15:18

New subject: [m17n] Printing Korean from Mozilla

Mike FABIAN wrote:

...

ghugh Song さんは書きました:

[...]

...
Unfortunately, on my old personal printer HP6mp, I got an error printout like the following:

======================================== The PostScript interpreter in your printer is 2014.108 This printout requres at least version 2015 or greater.

[ ...] =========================================

Isn't it normal? Do I have to throw out my old HP6mp?

I wanted to say "Is it normal?"

...

...
It appears that I have to update the firmware of the HP6mp. Of course, I have no idea how to flash the firmware of this printer.

Just setup your HP6mp printer as a non-PostScript printer with YaST2 as already explained in my last mail. Then the Ghostscript will be used as the PostScript interpreter, the old PostScript interpreter in your HP6mp will not be used.

With the newer RPM packages of ghostscript, when the printer is set up as a PCL printer HP6 series PCL from yast2 and CUPSlibrary, HP6MP gave me an endless output of empty blank sheets. Also, I reported already to you that my another printer HP LJ2200 configured by Ghostscript driver `stp': driver `stp' showed a similar symptom after generating a beautiful Hangul web page only once. I think that there is still some misconfigured setup in my ghostscript rpm setting even after SuSEconfig. When I choose Ghostscript from the choice of yast2 printer setup by choosing Postscript Distillery 'sDEVICE=pswrite', which is again different from using ghostscript by choosing a PCL printer, then the printer becomes unresponsive. No blinking at all. This last trouble seems to come from the use of CUPS. I say so because when I used lprng, 'pswrite' seemed to be working.

...

...
Mike, As you can imagine, I sorta think that mozilla-1.3b is essential in getting the corrent hangul page from the above experience.

Not true.

You may have all sorts of nice new features with mozilla-1.3b, but just printing the correct hangul already works for a long, long time.

All this experience tells me something. Printer setup appears to be the most basic thing in whatever OSes. Yet, I have had all sorts of trouble. That was the prime reason I switched to SuSE from RedHat about four years ago around the SuSE verseion 6.3. Now when I upgraded to SuSE-8.1 coming with CUPS by default, I almost thought of going back to RedHat. I sorted out all those trouble with CUPS by using those rpms in /pub/projects/. I would not understand SuSE if those rpms are still sitting only in /pub/projects rather than in /suse/update/8.1. Best regards, G. Hugh Song

Mike FABIAN

09:30

New subject: [m17n] Printing Korean from Mozilla

ghugh Song さんは書きました:

...

Now, I issued "SuSEconfig" and I can see files in the directory. Guess what. gv shows the Korean character "??" correctly from the korean-Baekmuk-Gulim-KSC-EUC-H.ps file. But not from korean-Baekmuk-Gulim-UniKS-UTF8-H.ps

The latter showd just "Hangul" and nothing.

Works for me. What are the messages when you try to display the file with 'gs'. Better use 'gs' for testing, not 'gv' because 'gs' shows you some messages on standard output which may help to understand what's wrong. Do you see the correct messages, like that: mfabian@gregory:~/test-texts$ LANG=C gs korean-Baekmuk-Gulim-UniKS-UTF8-H.ps ESP Ghostscript 7.05 (2002-06-28) Copyright (C) 2002 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file COPYING for details. Loading Baekmuk-Gulim-UniKS-UTF8-H font from /usr/share/ghostscript/Resource/Font/Baekmuk-Gulim-UniKS-UTF8-H... 17136180 14436291 1662616 337756 0 done. >>showpage, press <return> to continue<<

...

OK, now I tried to print from "gv" which uses "lpr". Again guess what. I got just the "cat"ed output from the hp6mp Postscript printer like this:

% -*- coding: euc-kr -*- /Baekmuk-Gulim-KSC-EUC-H findfont 30 scalefont setfont 50 200 moveto (Hangul <Cryptic characters>) show showpage

Of course. Your Ghostscript now has the /Baekmuk-Gulim-KSC-EUC-H font, but your printer doesn't have it. It looks like you have currently setup your printer as a PostScript printer. In that case, lpr sends the file without further processing directly to the printer without filtering through Ghostscript, because it is a PostScript printer and should be able handle the PostScript code. But of course this won't work when the PostScript code specifies fonts which the printer doesn't have. The solution is to setup the printer not as a PostScript printer but as something else. Setup your printer with YaST2 again and don't choose the PostScript printer driver but a different driver. Maybe the 'pcl3' driver of the 'ljet4' driver, I don't know your printer. But YaST2 will probably know and suggest something appropriate. You don't have to delete your PostScript printer queue, you can also create an additional, non-PostScript printer queue. Than use the non-PostScript queue for printing documents with fonts which your printer doesn't have. A PostScript file sent with lpr to a non-PostScript queue will be filtered through Ghostscript automatically and your Ghostscript now has the necessary fonts. Another possibility to do it manually is to filter the Postscript file manually through Ghostscript. For example: gs -dNOPAUSE -dBATCH -sPAPERSIZE=a4 -sDEVICE=pswrite -sOutputFile=korean-Baekmuk-Gulim-KSC-EUC-H.pswrite korean-Baekmuk-Gulim-KSC-EUC-H.ps then send the .pswrite file to a PostScript queue. The file processed this way by Ghostscript doesn't need the Baekmuk fonts anymore, all Korean glyphs are already included as outline graphics in this file, therefore any PostScript printer can print it. Instead of '-sDEVICE=pswrite' you can also use other devices like '-sDEVICE=ljet4' or whatever device is suitable for your printer, then send the filtered file to a raw printer queue which doesn't do any further processing. The manual example is just for better understanding what happens, all this works correctly automatically if you just setup your printer with YaST2 as a non-PostScript printer.

...

Incidently, I tested a printout from a sample web page containing Hangul characters. Well... Again the familiar square blocks from the printer.

Oh. This is far from what I want. What did I miss?

-- Mike Fabian http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。

ghugh Song

14 Feb 14 Feb

01:30

New subject: [m17n] Printing Korean from Mozilla

Mike FABIAN wrote:

...

ghugh Song さんは書きました:

...
Now, I issued "SuSEconfig" and I can see files in the directory. Guess what. gv shows the Korean character "??" correctly from the korean-Baekmuk-Gulim-KSC-EUC-H.ps file. But not from korean-Baekmuk-Gulim-UniKS-UTF8-H.ps

The latter showd just "Hangul" and nothing.

Works for me. What are the messages when you try to display the file with 'gs'. Better use 'gs' for testing, not 'gv' because 'gs' shows you some messages on standard output which may help to understand what's wrong. Do you see the correct messages, like that:

mfabian@gregory:~/test-texts$ LANG=C gs korean-Baekmuk-Gulim-UniKS-UTF8-H.ps ESP Ghostscript 7.05 (2002-06-28) Copyright (C) 2002 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file COPYING for details. Loading Baekmuk-Gulim-UniKS-UTF8-H font from /usr/share/ghostscript/Resource/Font/Baekmuk-Gulim-UniKS-UTF8-H... 17136180 14436291 1662616 337756 0 done.

...
...
showpage, press <return> to continue<<

This is what I got: ghugh@bellini:/home/ghugh> ls *.ps korean-Baekmuk-Gulim-KSC-EUC-H.ps korean-Baekmuk-Gulim-UniKS-UTF8-H.ps ghugh@bellini:/home/ghugh> gs korean-Baekmuk-Gulim-UniKS-UTF8-H.ps ESP Ghostscript 7.05 (2002-06-28) Copyright (C) 2002 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file COPYING for details. Loading Baekmuk-Gulim-UniKS-UTF8-H font from /usr/share/ghostscript/Resource/Font/Baekmuk-Gulim-UniKS-UTF8-H... 16849028 14226196 1662616 337756 0 done.

...

...
showpage, press <return> to continue<<

So, the message is exactly the same. But display windows does not show "??" unlike your case.

...

...
OK, now I tried to print from "gv" which uses "lpr". Again guess what. I got just the "cat"ed output from the hp6mp Postscript printer like this:

% -*- coding: euc-kr -*- /Baekmuk-Gulim-KSC-EUC-H findfont 30 scalefont setfont 50 200 moveto (Hangul <Cryptic characters>) show showpage

Of course. Your Ghostscript now has the /Baekmuk-Gulim-KSC-EUC-H font, but your printer doesn't have it.

It looks like you have currently setup your printer as a PostScript printer. In that case, lpr sends the file without further processing directly to the printer without filtering through Ghostscript, because it is a PostScript printer and should be able handle the PostScript code. But of course this won't work when the PostScript code specifies fonts which the printer doesn't have.

The solution is to setup the printer not as a PostScript printer but as something else. Setup your printer with YaST2 again and don't choose the PostScript printer driver but a different driver. Maybe the 'pcl3' driver of the 'ljet4' driver, I don't know your printer. But YaST2 will probably know and suggest something appropriate.

You don't have to delete your PostScript printer queue, you can also create an additional, non-PostScript printer queue. Than use the non-PostScript queue for printing documents with fonts which your printer doesn't have.

A PostScript file sent with lpr to a non-PostScript queue will be filtered through Ghostscript automatically and your Ghostscript now has the necessary fonts.

Unfortunately, although I did exactly what you just prescribed, the printer LaserJet 6MP did the same thing: those three "cat"ed output-lines only.

...

Another possibility to do it manually is to filter the Postscript file manually through Ghostscript. For example:

gs -dNOPAUSE -dBATCH -sPAPERSIZE=a4 -sDEVICE=pswrite -sOutputFile=korean-Baekmuk-Gulim-KSC-EUC-H.pswrite korean-Baekmuk-Gulim-KSC-EUC-H.ps

then send the .pswrite file to a PostScript queue. The file processed this way by Ghostscript doesn't need the Baekmuk fonts anymore, all Korean glyphs are already included as outline graphics in this file, therefore any PostScript printer can print it.

The above command worked OK, and produced the Korean characters properly.

...

Instead of '-sDEVICE=pswrite' you can also use other devices like '-sDEVICE=ljet4' or whatever device is suitable for your printer, then send the filtered file to a raw printer queue which doesn't do any further processing.

This method gave nothing. The /etc/printcap file configured by CUPS does not have such a rich list of printcap entries. Just putting the printer qname "lj6mp" in my case did not work.

...

The manual example is just for better understanding what happens, all this works correctly automatically if you just setup your printer with YaST2 as a non-PostScript printer.

Unfortunately, YaST2 configured setup did not produce the thing properly. Is CUPS intervening the process here? Thanks. G. Hugh Song

Mike FABIAN

15 Feb 15 Feb

01:55

New subject: [m17n] Printing Korean from Mozilla

ghugh Song さんは書きました:

...

...
...
Now, I issued "SuSEconfig" and I can see files in the directory. Guess what. gv shows the Korean character "??" correctly from the korean-Baekmuk-Gulim-KSC-EUC-H.ps file. But not from korean-Baekmuk-Gulim-UniKS-UTF8-H.ps

The latter showd just "Hangul" and nothing.

Works for me. What are the messages when you try to display the file with 'gs'. Better use 'gs' for testing, not 'gv' because 'gs' shows you some messages on standard output which may help to understand what's wrong. Do you see the correct messages, like that:

mfabian@gregory:~/test-texts$ LANG=C gs korean-Baekmuk-Gulim-UniKS-UTF8-H.ps ESP Ghostscript 7.05 (2002-06-28) Copyright (C) 2002 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file COPYING for details. Loading Baekmuk-Gulim-UniKS-UTF8-H font from /usr/share/ghostscript/Resource/Font/Baekmuk-Gulim-UniKS-UTF8-H... 17136180 14436291 1662616 337756 0 done.

...
...
showpage, press <return> to continue<<

This is what I got:

[...]

...

So, the message is exactly the same. But display windows does not show "??" unlike your case.

I see. The file korean-Baekmuk-Gulim-UniKS-UTF8-H.ps which was attached to my mail is not UTF-8 encoded, it is EUC-KR (!) encoded. This is my fault. It was caused because I did sent the attachment as type text/plain (because binary attachments will be stripped by the mailing list software because of bandwidth and security reasons). And my mail user agent (Gnus under XEmacs) did convert it to EUC-KR when sending the mail. If you convert the file to UTF-8, the above print command works. You can convert it to UTF-8 like this: iconv -f EUC-KR -t UTF-8 < korean-Baekmuk-Gulim-UniKS-UTF8-H.ps > tmp.ps mv tmp.ps korean-Baekmuk-Gulim-UniKS-UTF8-H.ps Now the display with 'gs' should work. -- Mike Fabian http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。

Mike FABIAN

12 Feb 12 Feb

11:20

New subject: UTF-8 (was: Printing Korean from Mozilla)

ghugh Song さんは書きました:

...

By the way, I really cannot understand the position of UTF-8 in Korea. I am sure that you do not know about the situation either. Everyone uses eucKR, not UTF-8.

Of course I know that currently more people use EUC-KR than UTF-8 in Korea. That doesn't mean this will never change. SuSE Linux tries to support both EUC-KR *and* UTF-8. The default locale for Korean is still ko_KR.eucKR. But ko_KR.UTF-8 is also supported and users should be able to use it if they want.

...

Is UTF-8 somehow the encoding scheme recommended over the globe?

Yes. It makes it possible to use many languages at the same time. For Linux like systems, UTF-8 is certainly the way to go in the future. For more information see also: http://www.cl.cam.ac.uk/~mgk25/unicode.html (UTF-8 and Unicode FAQ for Unix/Linuxd by Markus Kuhn) Also interesting is the linux-utf8@nl.linux.org mailing list. To subscribe, send a message to linux-utf8-request@nl.linux.org with the subject subscribe. The archive of this mailing list is here: http://mail.nl.linux.org/linux-utf8/.

...

I do not think that anyone in his right mind would ever switch to UTF-8 because she/he will immediately have trouble in reading her/his emails.

Most mail user agents support UTF-8 nowadays. According to the headers of you mail, you muse Mozilla: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021204 Mozilla supports UTF-8 as well, i.e. you should be able to see the following correctly: Hangul (한글) Japanese (日本語) German (Deutsch Süd) (This mail is in UTF-8!) -- Mike Fabian http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。

7743

Age (days ago)

7749

Last active (days ago)

List overview

Download

16 comments

3 participants

participants (3)

David Nettles
ghugh Song
Mike FABIAN