55021 - RFE: Korean and Chinese fonts definitions for PostScript printing

Status: VERIFIED FIXED

(Core :: Printing: Output, defect, P3)

Description

[Masaki Katakai]

unix.js has now only japanese font definition for UNIX postscript printing.

// ps font
pref("print.psnativecode.ja", "euc-jp");
pref("print.psnativefont.ja", "Ryumin-Light-EUC-H");

We need to define Korean and Chinese fonts. I understand that PostScript
printers are not popular in Korea and China, also there is no standard
font name of PostScript for thoese locales, however, it would be better
we define *widely-used* fonts.

Comment 1

[Masaki Katakai]

 Munhwa font can be used for ko locale,

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

Comment 2

[dcone (gone)]

I don't know much about this.. do you know who could do this Frank?

Comment 3

[Masaki Katakai]

Frank,

I'd like to take this. If you agree, please assign to [e-mail].

Comment 4

[tao]

Hi, Erik:


Do we have resource in the group to fix this bug? If none, should we reassign to
Tajima-san?

Comment 5

[Katsuhiko Momoi]

Added teruko & ji and sending this to ji for QA for Chinese.
Will see about Korean later.

When you add PS font names, please also add the following
for Lexmark PS fonts. (Too bad we don't have generic
names for these.)

Simplified Chinese:

 CFangSong-Light
 MHei-Bold
 MKai-Medium
 MSung-Light

Traditional Chinese:

 MKai-Medium
 MingMT-Light
 MingMTP-Light

Comment 6

[Masaki Katakai]

Can anyone check fontname in ghostscript in Linux
of major chinese distributions?

Comment 7

[Masaki Katakai]

Here is an example for korean and chinese locale in Solaris DPS.

user_pref("print.psnativecode.zh-CN", "gb2312");
user_pref("print.psnativefont.zh-CN", "Song-Medium-EUC");

user_pref("print.psnativecode.zh-TW", "big5");
user_pref("print.psnativefont.zh-TW", "Ming-Light-B5");

user_pref("print.psnativecode.ko", "euc-kr");
user_pref("print.psnativefont.ko", "Myeongjo-Medium-EUC");

We should define more popular fonts in unix.js for Mozilla.
The fonts should be available on Linux ghostview for those
locales.

Comment 8

[nhottanscp]

Reassign to Katakai san.
Please contact i18n group if you need help (e.g. code review, cvs checkin).

Comment 9

[Linda Baliman]

Adding intl keyword

Comment 10

[Frank Tang]

Can anyone test Katakai's patch ? Does anyone have testing environment which can 
verify the fix ?

Comment 11

[Katsuhiko Momoi]

We should be able to. In addition to Japanese, we have
Trad. & Simplified Chinese and Korean printing capability.

Comment 12

[Masaki Katakai]

I got a info that Ming-Light-H is more popular than -Big5 font for zh-TW.

user_pref("print.psnativefont.zh-TW", "Ming-Light-H");
user_pref("print.psnativecode.zh-TW", "x-euc-tw");

Comment 13

[kill this account]

I found this:
http://picard.tamu.edu/doc/gs/Fonts.htm

Comment 14

[kill this account]

Katakai,

Do we know which printers (or ghostscript) support these fonts:
// ps font
pref("print.psnativecode.ja", "euc-jp");
pref("print.psnativefont.ja", "Ryumin-Light-EUC-H");
user_pref("print.psnativecode.ko", "euc-kr");
user_pref("print.psnativefont.ko", "Myeongjo-Medium-EUC");
user_pref("print.psnativecode.zh-CN", "gb2312");
user_pref("print.psnativefont.zh-CN", "Song-Medium-EUC");
user_pref("print.psnativefont.zh-TW", "Ming-Light-H");
user_pref("print.psnativecode.zh-TW", "x-euc-tw");

Comment 15

[kill this account]

I'd like to propose the following:

1) we implement the ps font names suggested by sun.

2) we open a new bug to have the code look for a per-printer "ps font name 
override" file and if found use the names in this file. 

The file would allow for multiple printers.

Printer vendors could supply a file with the font names in their printer on the 
web.  Users would copy it down, move it to a particular directory and then 
rename it. Mozilla would then use the file for that printer.





This would provide a relatively simple mechanism for users to setup 

Comment 16

[Masaki Katakai]

Hi Brian,

the examples are for Solaris Display PostScript system and
would not work properly on exact printers. We should define
more popular fontnames in Mozilla, which are used in ghostscript.
I have got info from Korean and the following is most popular
font,

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

Japanese font is OK. I'd like to ask chinese folks to find
popular fonts in Chinese Linux distributions.

Comment 17

[kill this account]

If we use a per-printer override file I'm not sure if it should be pref based or
properties based.

This kind of data looks like a property but the existing code is pref based.

If pref then might want to call GetFilePref()
If property then might want to call nsURLProperties::Get()
    (look for gInfo->Get in nsUNIXCharset.cpp)

Comment 18

[kill this account]

this Lexmark page indicated they emulate mswindows fonts
    http://www.lexmark.com/printers/fontdimms.html

Simplified Chinese Font Names p/n 13K0215
For PostScript 3        For PCL 6
CFangSong-Light         CFangSongGB
MHei-Bold               MHeiGB
MKai-Medium             MKaiGB
MSung-Light             MSungGB

Traditional Chinese Font Names p/n 13K0216
For PostScript 3        For PCL 6
MKai-Medium             MKai
MingMT-Light            MingMT
MingMTP-Light           MingMTP

Comment 19

[kill this account]

I looked at the ps printing code. If the user printed to a file they would
expect to be able to then send that file to the printer. In doing this the code
would not see the printer name and hence would not have been able to look in the
per-printer override file. Thus I think we should not do a per-printer override
but just do a single override file.

Comment 20

[kill this account]

Here is a sample file (unixpsfonts.properties) for Lexmark:

        # ps font mapping for Lexmark printer with a
        # Simplified Chinese font DIMM
        # Traditional Chinese font DIMM
        # Japanese font DIMM

        psnativecode.ja=euc-jp
        psnativefont.ja= HG-MinchoL

        #psnativecode.ko=euc-kr
        #psnativefont.ko=

        psnativecode.zh-CN=gb2312
        psnativefont.zh-CN=CFangSong-Light

        psnativefont.zh-TW=MKai-Medium
        psnativecode.zh-TW=x-euc-tw

Comment 21

[Katsuhiko Momoi]

For Wangsun (precomposing) encoding on Lexmark printer with
Korean PS fonts.

MD_Batang
MD_BatangChe
MD_Dodum
MD_DodumChe
MD_Gulim
MD_GulimChe
MD_Gungseo
MD_GungseoChe

For Johab encoding, add "_nt" to the end.

MD_Batang_nt
MD_BatangChe_nt
MD_Dodum_nt
MD_DodumChe_nt
MD_Gulim_nt
MD_GulimChe_nt
MD_Gungseo_nt
MD_GungseoChe_nt

Comment 22

[kill this account]

reassigning to bstell

Comment 23

[kill this account]

Attachment: patchs to Makefile.in, nsPostScriptObj.h, nsPostScriptObj.cpp to read a printer properties file

Comment 24

[kill this account]

Here is a working entry for a Lexmark Japanese fontdimm
(note the font name is "HG-MinchoL-EUC-H" not "HG-MinchoL")

##
# ps font mapping for Lexmark printer with a
#
# Japanese font DIMM
print.psnativecode.ja=euc-jp
print.psnativefont.ja=HG-MinchoL-EUC-H
#print.psnativefont.ja=HG-GothicB-EUC-H

Comment 25

[Linda Baliman]

Adding nsbeta1 keyword

Comment 26

[kill this account]

Attachment: updated patches to gfx/src/ps/ Makefile.in, nsPostScriptObj.cpp, and modules/libpref/src/unix/unix.js

Comment 27

[kill this account]

here is a working sample for Lexmark Optra 610:
(korean does not work yet)

        # ps font mapping for Lexmark printer with a
        #
        # Japanese font DIMM
        print.psnativefont.ja=HG-MinchoL-EUC-H
        print.psnativecode.ja=euc-jp

        #
        # Korean font DIMM
        print.psnativefont.ko=MD_Batang-KSC-EUC-H
        print.psnativecode.ko=EUC-KR

        #
        # Simplified Chinese font DIMM
        print.psnativefont.zh-CN=CFangSong-Light-GB-EUC-H
        print.psnativecode.zh-CN=gb2312

        #
        # Traditional Chinese font DIMM
        print.psnativefont.zh-TW=MingMT-Light-B5-H
        print.psnativecode.zh-TW=big5

Comment 28

[kill this account]

Katakai-san,

Would you:
    apply the patches
    build
    cd $TOP/mozilla/dist/bin/res/
    cp sample.unixpsfonts.properties unixpsfonts.properties
    edit the unixpsfonts.properties for the ja/tw/cn/ko postscript fonts you 
have

and try printing?

thanks

Comment 29

[Jungshik Shin]

PS printers with Korean PS fonts are extremly rare even in Korea.
I was surprised to find that Lexmark has the DIMM for Korean PS fonts.

Anyway, if we can restrict (I guess we can't) ourselves to  supporting
Linux only, Munhwa-Regular (I gave last year to ould be a lot better for
Korean than one for Lexmark or Sun's DPS. However, the situation might
change as a couple of patches  to support truetype fonts in ghostscript
6.5 have been around for a while (one from Korean and the other from
Japan) and there are some truetype fonts with pseudo-standardized
names like Batang, Gulim, Dotum available for Linux/FreeBSD.  I really
hate these names (which are the established standard under MS-Windows)
because it's all but impossible to tell what style of fonts - serif or
sans-serif -   these are from their names.)

Comment 30

[kill this account]

The corrected Korean spec for a Lexmark printer is:

        #
        # Korean font DIMM
        print.psnativefont.ko=MD_Batang
        print.psnativecode.ko=EUC-KR

Comment 31

[kill this account]

added [e-mail] to cc:

Comment 32

[kill this account]

The release notes should look something like this:

To configure Netscape/Mozilla postscript printing get the font info file
from the vendor and copy it to 
$MOZILLA_FIVE_HOME/defaults/prefs/unixpsfonts.properties
 and restart Netscape/Mozilla.

Comment 33

[kill this account]

I changed the FREE_IF macro in nsPostScriptObj.cpp to:

  #define FREE_IF(x) do {if(x) {nsMemory::Free(x); (x)=nsnull;}} while(0)

this makes the semi-colon in the typical usage "FREE_IF(ptr);" associate with
the macro instead of being a separate statement.

Comment 34

[Masaki Katakai]

I've verified Brian's patch works well in the following conditions,

 - user's prefs.js and unixpsfonts.properties both exist
 - only unixpsfonts.properties exist
 - only user's prefs.js exist
 - both prefs.js and unixpsfonts.properties does not exist

Btw, Brian, you mentioned about the locale of unixpsfonts.properties
in your comment of 2001-02-19 but I believe defaults/prefs is not correct,
res/ is correct location, right?

Comment 35

[kill this account]

Attachment: patches to nsPostScriptObj.cpp to use a vendor supplied file listing the font names

Comment 36

[kill this account]

Attachment: the sample font info file

Comment 37

[kill this account]

Attachment: a "typical" vendor supplied font info file (Lexmark)

Comment 38

[kill this account]

yes, Katakai-san, /res is correct.
The release notes should look something like this:

To configure Netscape/Mozilla postscript printing get the font 
info file from the vendor and copy it to:

  $MOZILLA_FIVE_HOME/res/unixpsfonts.properties

and restart Netscape/Mozilla. A sample version of
this file is supplied to simplify the the process
of creating a new version:

  $MOZILLA_FIVE_HOME/res/sample.unixpsfonts.properties

Comment 39

[kill this account]

dcone: can you review the patch?

  http://bugzilla.mozilla.org/show_bug.cgi?id=61108

thanks

Comment 40

[kill this account]

Don, I meant this attachment:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=26276

Comment 41

[dcone (gone)]

The code looks good.  Make sure you run printing tests with the samples and a 
few top 100 sites.

One question:  the following line.. 
#define FREE_IF(x) do {if(x) {nsMemory::Free(x); (x)=nsnull;}} while(0)

would 
#define FREE_IF(x) {if(x) {nsMemory::Free(x); (x)=nsnull;}}

be simplier or is there a reason for the do{}while loop I am missing..

r=dcone

Comment 42

[kill this account]

I struggled with the "do {} while(0)" as well.

The "do {} while(0)" is slightly different from "{}".
Consider a typical usage: 

  FREE_IF(p);

The "{if(x) {...}}" version gets translated as:

  {if(x) {...}};

which equals:
  {
    if(x) {
      ...
    }
  }
  ;

Note tht the ";" becomes a separate statement from the "{if(x) {...}}".

By adding the "do {} while(0)" the semi-colon gets associated with the macro
instead of being a separate "statement".

This "do {} while(0)" shows up in other similar macros; eg:
http://lxr.mozilla.org/seamonkey/source/include/xp_mem.h#37
 36 /* global free routine */
 37 #define XP_FREEIF(obj) do { if(obj) { XP_FREE(obj); obj = 0; }} while(0)

for more examples see: 
http://lxr.mozilla.org/seamonkey/search?string=while%280%29 

Comment 43

[kill this account]

Here is an example of a place where the "do {} while(0)" would be required:

if (condition)
  FREE_IF(p);
else
  other_statement;

Without the "do {} while(0)" this would not compile.

Comment 44

[Brendan Eich [:brendan]]

do{ and }while(0) are codified and de-uglified by PR_BEGIN_MACRO and
PR_END_MACRO, from prtypes.h, and have been for almost six years.  Please use
them even if it makes the macro body multi-line, just to inform others of their
existence and spread the meme.

Lack of nsCOMPtr makes for leak on error here:

+  NS_ENSURE_SUCCESS(nsComponentManager::CreateInstance(
+    NS_PERSISTENTPROPERTIES_CONTRACTID, nsnull,
+    NS_GET_IID(nsIPersistentProperties), (void**)&printerprops_tmp),
+    PR_FALSE);
+  NS_ENSURE_SUCCESS(printerprops_tmp->Load(in), PR_FALSE);
+  gPrinterProps = printerprops_tmp;

If the load fails, printerprops_tmp is not released.  Use an nsCOMPtr locally,
or (better, not sure you can do this on all platforms -- dbaron?) just make
gPrinterProps a static nsCOMPtr.

These should be nsAutoStrings, no?

+  nsString key;
+  key.AssignWithConversion(aKey.GetBuffer());
+  nsString oValue;

These (and psnativefont, I think) really should be nsXPIDLCStrings, and then you
don't need the FREE_IF macro, and the FREE_IF calls on every exit path from the
function:

   char *psnativecode = nsnull;
   char *psunicodefont = nsnull;

How about a patch that uses these XPCOM auto-helper classes?

/be

Comment 45

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm not a big fan of static nsCOMPtrs -- they've been known to cause shutdown
problems when they release something after XPCOM shutdown after things needed to
release them are already shut down, although that's not a problem if you can
guarantee that they're set to null before or during XPCOM shutdown (even if
something else leaks).  If they're global scope, they also (I think) cause
problems on OpenBSD, and if they're function scope they cause problems with gcc
if we try to unload the shared library they're in before exit (unless we use
-fuse-cxa-atexit, which would force users to use a reasonably (?) recent glibc).

Comment 46

[kill this account]

Attachment: revised patches to nsPostScriptObj.h, nsPostScriptObj.cpp, and nsPostScriptObj.cpp

Comment 47

[kill this account]

the attachement comment above should read:
  revised patches to nsPostScriptObj.h, nsPostScriptObj.cpp, and
  gfx/src/ps/Makefile.in

Use of the very cool nsXPIDLCStrings removed the need for the FREE_IF macro 
(thanks Brendan) and thus no need for the (cool) PR_BEGIN_MACRO and 
PR_END_MACRO.

Used a nsCOMPtr with NS_ENSURE_SUCCESS to avoid leak (thanks Brendan).

Modified the pref/enum callback to take the nsPostScriptObj object and thus 
removed the need for a global gPrinterProps. Added printer props to the 
nsPostScriptObj (using nsCOMPtr).

Comment 48

[kill this account]

Attachment: patch using getter_Copies when calling GetUnixPrinterFallbackSetting() and GetUnixPrinterSetting()

Comment 49

[Frank Tang]

r=ftang

Comment 50

[Erik van der Poel]

Please use consistent upper/lowercasing for the method names.

Please consider removing the empty prefs in unix.js.

sr=[e-mail]

Comment 51

[Masaki Katakai]

Brian,

It seems that the changes have been checked in to Trunk, but I found
it does not work because we don't have entries in unix.js,
PrefEnumCallback() is called for unix.js so your codes are not called.
We need to check mPrinterProps entries as well.
I'll attach the patch and could you evaluate?

Comment 52

[Masaki Katakai]

Attachment: check predefined setting and mPrinterProps if no prefs

Comment 53

[kill this account]

we need a way to enumerate the language groups so we can tell the postscript
the font mappings.

Comment 54

[kill this account]

Attachment: patch with the font langGroups so the postscript code will fill in the font info (see bug 75054)

Comment 55

[Frank Tang]

r=ftang

Comment 56

[Erik van der Poel]

sr=[e-mail]

Comment 57

[kill this account]

should be working now
Except for Japanese international text will require a vendor font file such as 
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=26278

Comment 58

[ji]

QA contact to Yuying, since she is looking into this area now.

Comment 59

[Yuying Long]

I can not get the right print out on Chinese and Korean pages, even Japanese 
pages are display fine.  Re-open this bug.

Comment 60

[kill this account]

we need to document how to enable intl printing; see bug 76433

Comment 61

[Yuying Long]

The problem was Chinese and Korean don't have common font that works on e.g. 
Lexmark printer, but Japanese does has some common font.  That's why Japanese 
was displayed OK and Chinese / Korean were not.
After I copy the file that Brain's attached on 02/27/01 09:00, Chinese and 
Korean now works fine.  I'll mark this bug as fixed.

Comment 62

[Yuying Long]

Mark as verified.