Closed Bug 226183 Opened 21 years ago Closed 21 years ago

add a note about Big5HKSCS fonts and the performance of X11core build

Categories

(Core Graveyard :: GFX: Gtk, defect)

Product:
Core Graveyard
Component:
GFX: Gtk
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: zero0w, Assigned: jshin1987)

References

(
URL
)

Details

(Keywords: intl, perf, relnote) 

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007

Note: CJK means Chinese/Japan/Korean.

For *some* CJK homepage, Mozilla will take unusually long time to render it (it
takes >10s while normal CJK page will be rendered in 1-3s). 

I have done some extensive testing: this bug exists only in GTK1.x build of
Linux Mozilla; GTK2 Linux and Win32 builds are not affected.

The bug persisted since Mozilla 1.0.x all the way up to 1.5 of GTK1.x build on
Linux.

I am not sure if I can produce more meaningful info, my guess is it has
something to do with the way GTK1.2 handles font encoding. But I have no idea
why it happens only on a few specific CJK page but not others. Many other forum
pages from the link I posted do not exhibit such behavior. I occassionally
encounter this problem but it's always the same page exhibits such behavior.

Curiously this problem is much more frequently encountered in some other Chinese
forum page such as HKEPC:

http://www.hkepc.com/phpBB-HK/

I suspect that certain text pattern triggered this long loading time.
Still I don't understand why GTK2 build has no such problem.

Reproducible: Always

Steps to Reproduce:
1.Launch the GTK1.x+ build of Mozilla on Linux
2.Go to the specific CJK homepage
3.You'll see how long it takes for the page to come up, now go to other CJK page
and you can compare the difference in loading time
Actual Results:  
An usually long loading time for certain page.

Expected Results:  
It should not take any longer to load that page; and GTK2 build has no such
behavior.
Are you sure it's a GTK1 vs GTK2 issue and not an xft vs. not issue?  Could you
try a GTK2 build without xft?
Boris Zbarsky:

1) Do you know where I can look for a non-Xft GTK2 build?

2) The disturbing matter still is: why only a few CJK page can't load properly
but the rest are okay? Also, Win32 build has no such problem; so it could be a
Unicode thing.
You can make an Xft-build of Mozilla behave like an X11core build by setting
GDK_USE_XFT=0. Be careful to reconfigure all your font preference settting in
the first Mozilla session with GDK_USE_XFT=0. Then, try problematic pages. 

I'm almost sure it's X11core vs Xft. The example site given by you is a site at
Hong Kong that is likely to have some HKSAR specific characters not covered by
any of X11core fonts on your system. So, X11core build goes crazy looking for
glyphs for them in all available fonts. Some Korean sites can behave similarly
if they have characters not covered by KS X 1001 (KS C 5601) fonts but only
covered by only a few ISO10646-1 fonts (only one or none if you opted out of
installing Korean truetype fonts). The same can hold for some SC, TC and
Japanese sites with characters not covered by old standard charset based for SC,
TC and Japanese (that is, characters beyond the repertoire of GB2312, Big5 or
CNS11643p0 and JIS X 0208. JIS X 0212 didn't catch on and JIS X 0213 was issued).
Component: Embedding: GTK Widget → GFX: Gtk
Keywords: intl
Keywords: perf
Jungshik Shin:

You are right. It looks like it is locating for HKSAR Chinese fonts which are
not available in the Default Ming font-set.

So this problem cannot be solved without a change in the X11 core, am I correct?

I want to use non-AA font rendering when browsing web sites, is there a way to
workaround this problem?
By 'X11core', I didn't mean the core of X11 library/X server, but fonts 
supported by them and  the XLFD-based font referring system. 

To solve your problem, all you have to do is to install some pcf fonts
(with big5hkscs-0 XLFD registry-encoding) covering HKSAR extension of Big5
(Big5HKSCS) or truetype fonts with the coverage. XFree86 has two font
backends for rendering truetype fonts, freetype module and Xtt. Search
for 'truetype font Big5HKSCS) at google and you'll get, among the first
10 hits, Hong Kong SAR's font download page. Download and install them
(run mkfontscale in the directory) and add them to your fontpath (or
paths looked for by xfs).

As for disabling 'anti-aliasing' in Xft build, you can configure 
fontconfig not to anti-aliase for a certain pixel/point size range. Read the
man page of 'fontconfig' (or the document at http://freedesktop.org).
I haven't tried PCF font but the TTF font does not work quite right.....

I have downloaded the ISO-10461 font set from HKSAR gov site here:
http://www.info.gov.hk/digital21/eng/hkscs/reference_iso10646.html

(Check out NOTE 5 for a font-only download)

I installed "ming_uni.ttf" font by mkfontscale & mkfontdir + chkfontpath + xfs
restart.

Mozilla non-Xft Gtk1.2 build can locate it when I configured my Traditional
Chinese font setting, name as "misc-ming for ISO10646 big5-0" (that's what
mkfontdir generated).

Still when loading the problematic page, the long loading phenomenon continued.
It still cannot look up the new font installed by itself.

I forced the default font for Traditional Chinese to be "misc-ming for ISO10646
big5-0", yeah the HK specific character showed up, but it failed to show up if I
did't force this font as default (plus uncheck the box "Allow documents to use
other fonts).

So, what's the problem here? Should mkfontscale/mkfontdir get the font as
"-big5hkscs-0" instead of "-big5-0"?

Do I need to manual edit the font.dir/scale? Or PCF font is required?
Yes, you need to edit fonts.dir/fonts.scale so that it has big5hkscs-0
entry for the font you downloaded. Why doesn't mkfontscale generate
it? There are a few variants of 'mkfontscale' so that I'm not sure.

As for the font configuration setting, note that there is now a new
entry (TC : Hong Kong). Set the font there to Big5HKSCS font
and when viewing Hong Kong sites, make sure that Character Coding
is set to Big5HKSCS instead of Big5. 

As for the loading time of 10~20 seconds, it doesn't seem to be very
long (some people reported even a few minutes). Anyway, that's the
price of prefering 20-year old technology instead to a brand new Xft
(client-side font) ;-). You may want to figure out how to
turn off anti-aliasing for smaller pixel sizes with fontconfig
as I wrote before.
Jshin:
http://bugs.xfree86.org/show_bug.cgi?id=884 has a patch to add "big5hkscs-0"
support to "mkfontscale" ...
Jungshik Shin:

Well, I manually edited the fonts.scale/dir so that the font encoding is now
-big5hkscs-0- instead of -big5-0-.

I also installed Mozilla 1.6 Alpha which has a "Traditional Chinese (Hong Kong)"
font section as you have suggested:

The loading time seemed to be shortened (yet still longer than other big5 only
page...), but the HKSAR specific character still failed to show up in autodetect
by Mozilla :( .

Now I really wonder does XFree86 recognize -big5hkscs- in XLFD
registry-encoding? I am sure Xft can recogize it, but perhaps it's not yet in
XLFD? Also I found this discussion in XFree mailing list:

http://www.mail-archive.com/i18n@xfree86.org/msg00774.html

According to that discussion, Anthony Fok had a big5hkscs patch for XFree86 on
his site but I wonder if that has merged into the mainstream releases yet....

For reference here is another site with information regarding HKSCS:
http://cs-people.bu.edu/butta1/personal/hkscs/
Roland Mainz:

Thanks for the heads up on the mkfontscale patch. :)
What do you mean by 'auto detect in Mozilla'? Mozilla doesn't have any
auto-detector to tell Big5 from Big5HKSCS. Besides, most web pages in Big5HKSCS
are labelled simply as Big5 so that you have to select manually Big5HKSCS in
'View | Character Coding' menu.  We can't just regard Big5 as Big5HKSCS because
some extension of Big5 (Taiwan-specific) use code points used by HKSAR
extension. (we do this for ISO-8859-1 < Windows-1252 and EUC-KR <
x-windows-949/CP949 and TIS 620 < ISO-8859-11 < Windows-874, though) 

As for XFree86, the only thing you need is big5hkscs-0.encoding file installed
in /usr/X11R6/lib/X11/fonts/encoding/large (as far as freetype backend's Unicode
cmap to XLFD is concerned, nothing is hard-coded) I can't access the XFree86 bug
page (cited by Roland) at the moment so that I'm not sure whether it's only for
mkfontscale or also deals with adding big5hkscs-0.encoding file to the
distribution (I thought the encoding file had been already added to the XFree86,
but my memory is not usually reliable these days...). 

> I am sure Xft can recogize it,

  Xft does not use 20-year old XLFD. It's one of innovations of Xft. 


 
Fixing bug 129387 should help you, here.
Depends on: 129387
Summary: Unusually long loading time for *some* CJK page on GTK1.2 build of Mozilla → X11core build takes unusually long to load Big5HKSCS (and some other CJK) pages
This is exactly the difference between Xft and XLFD.

The Xft build will auto replace Chinese characters with Big5-HKSCS encoding even
in Big5 page. That's what I meant in auto-detection.

And no, in _non-Xft_ build, even when I turned on Big5HKSCS by manually select 
View > Character Encoding > More > East Asian > Traditional Chinese (Big5-HKSCS)
the problematic page did not change one bit, nor the HKSAR character showed up.

>As for XFree86, the only thing you need is big5hkscs-0.encoding file 
>installed in /usr/X11R6/lib/X11/fonts/encoding/large (as far as freetype
>backend's Unicode cmap to XLFD is concerned, nothing is hard-coded)

There is no such file in that directory (btw I am on Mandrake 9.1);
A list of files in that directory:

$ cd /usr/X11R6/lib/X11/fonts/encodings/large/
$ ls

big5.eten-0.enc.gz      gb2312.1980-0.enc.gz    jisx0208.1990-0.enc.gz
encodings.dir           gbk-0.enc.gz            jisx0212.1990-0.enc.gz
fonts.cache-1           jisx0201.1976-0.enc.gz  ksc5601.1987-0.enc.gz
gb18030.2000-1.enc.gz   jisx0208.1983-0.enc.gz  ksc5601.1992-3.enc.gz

I don't know what big.eten-0.enc.gz will do but it doesn't look like it is for
big5hkscs I believe.
> The Xft build will auto replace Chinese characters with Big5-HKSCS encoding even
> in Big5 page. That's what I meant in auto-detection.

  Mozilla does understand Big5HKSCS encoding and knows how to convert Big5HKSCS
to Unicode. For Xft, that's the end of the story because Xft build does NOT use
XLFD. On the other hand, X11core build has to take another step. That is to
convert Unicode to the encoding of a font (specified in XLFD) which is where it
takes Mozilla a long time. 

> And no, in _non-Xft_ build, even when I turned on Big5HKSCS by manually select 
> View > Character Encoding > More > East Asian > Traditional Chinese (Big5-HKSCS)
> the problematic page did not change one bit, nor the HKSAR character showed up.

That's because you don't have big5hkscs-0 encoding file. Try 'xlsfs |grep
hkscs', pick one of fonts listed with the command (if there is any listed at
all) and do 'xfd -fn font_name'. HKSAR-extension positions would be all empty. 
Making one is easy. I'll put up one next week.


Thanks for the lengthy explanation and I understand the issue better now.

>That's because you don't have big5hkscs-0 encoding file. Try 'xlsfs |grep
>hkscs', pick one of fonts listed with the command (if there is any listed at
>all) and do 'xfd -fn font_name'. HKSAR-extension positions would be all empty. 
>Making one is easy. I'll put up one next week.

I tried this on HKSAR Ming-ISO 10461 font and here is the result:

# xfd -fn ming_uni.ttf

Warning: Cannot convert string "ming_uni.ttf" to type FontStruct
xfd:  no font to display

Thank you for making the big5hkscs-0 encoding file.
If this can solve the problem I am a happy man :) .

Also, Bug 183037 and 182089 also involve problem with zh-HK locale, I don't know
if they have anything to do with this problem but I am putting them here for
reference:

http://bugzilla.mozilla.org/show_bug.cgi?id=183037
http://bugzilla.mozilla.org/show_bug.cgi?id=182089
> xfd -fn ming_uni.ttf

I'm afraid you're still a bit confused (X11 font issues are complex and I
understand it takes time to get a full grasp of). Anyway, xfd doesn't know
anything about TTF. All it knows is XLFD. You have to provide
it with the 'XLFD' of a truetype font that is 'advertised' as X11core font
thanks to freetype font backend (or X-TT backend). 

That is, 

  $ xlsfonts | grep hkscs

   bblah-------big5hkscs-0

  $ xfd -fn 'bblah......big5hkscs-0'

bug 183037 is a dupe of another bug(as far as zh-HK is concerned.  the patch in
bug 183037 is incomplete. Simply adding langGroup.properties file is not
sufficient) 

I fixed a couple of months ago (see bug 152264). As for bug 182089, I'm well
aware of that. Because that bug was fixed, you just need big5hkscs-0 encoding
file (i.e. Mozilla already does its part)
>That is,

>  $ xlsfonts | grep hkscs

>   bblah-------big5hkscs-0

>  $ xfd -fn 'bblah......big5hkscs-0'

1. This time I executed 

$ xfd -fn 'ming_uni.ttf -misc-Ming for ISO10646
-medium-r-normal--0-0-0-0-p-0-big5hkscs-0'

I see a GUI manual came up and the font charmap. So what to do next?

2. I have done a google search on the keyword "big5hkscs-0" and I found your
discussion :) here"

http://www.mail-archive.com/i18n@xfree86.org/msg01524.html
http://bugs.xfree86.org/show_bug.cgi?id=575

I downloaded the file "big5hkscs.enc" from the XFree bugzilla discussion and
gzip it, put the file big5hkscs.enc.gz into the directory
/usr/X11R6/lib/X11/fonts/encodings/large/

Now the long loading time is GONE! You got it right, thanks a ton!

Although the long loading time is gone, the HKSAR character still did not show
up (again I tried manually turned on View > Character Encoding >..).

Maybe something still needs to be done....

I noticed the date of XFree Bugzilla discussion I take it that the big5hkscs-0
encoding file has not gone into the main tree of official XFree86 yet, am I right?
You'd better download big5hkscs-0.enc file from cvsweb.xfree86.org. It was
committed to XFree86 in August (http://bugs.xfree86.org/show_bug.cgi?id=575) I
filed the bug and made the file, but forgot about it. 

As I wrote, xfd does NOT know anything about ttf. You should just give

'foundry-family-...............big5hkscs-0' (as printed out by 'xlsfonts |grep
hkscs'

What you need to do is to check out HKSAR extension code points with 'xfd'. If
xfd shows visible glyphs at those positions, something is wrong with Mozilla. If
not, something is wrong with the font. I shouldn't be writing this right now.
This is the last message I'm gonna write on this bug this week. I'll take a look
next week.
OK. One lsat time. assigning to myself. 

As far as I can tell, this is not a Mozilla bug, but something that has to be
release-noted. That is, big5hkscs-0.enc file has to be added to Xfree86
/usr/X11R6/lib/fonts/encodings/large directory to avoid the slow rendering of
HKSCS pages. (and a new version of mkfontscale has to be used or
fonts.scale/fonts.dir file have to be hand-edited) The file was landed in
XFree86 trunk a few months ago and is not available on the majority of Linux
distributions. 

I'll make sure that this info. is added to 'International Known Issues' document
for 1.6b (and old releases as well).
Assignee: blizzard → jshin
Keywords: relnote
>As I wrote, xfd does NOT know anything about ttf. You should just give

>'foundry-family-...............big5hkscs-0' (as printed out by 'xlsfonts |grep
>hkscs'

Sorry I mistyped my #18 message.

I actually entered:

$ xfd -fn '-misc-ming for iso10646 -medium-r-normal--0-0-0-0-p-0-big5hkscs-0'

A GUI dfd menu came up. However, the [-16 / Prev / Next / +16] icons are all
greyed and unclickable...

> You'd better download big5hkscs-0.enc file from cvsweb.xfree86.org.

Got it from here:
http://cvsweb.xfree86.org/cvsweb/xc/fonts/encodings/large/

Perhaps there is someway to render a Big5HKSCS font among a Big5 page, but it is
not working for X11core at this moment. Or something is wrong with the font, but
I am not sure.

Once again, thanks for working on this issue.
I have done some testing with big5hkscs support on both Xft and non-Xft build of
Mozilla, with ming_uni.ttf installed from HKSAR ISO10646 page:

The page for testing are as follows:

1.Big5-HKSCS-2001 browser test pages
http://www.thizlinux.com/~anthony/hkscs/Big5-HKSCS-2001-test-81xx.html

2. HKSCS 2001 hex code with octet
http://cs-people.bu.edu/butta1/personal/hkscs/hkscs-oct.html

With Xft build, some errors of font display is found in the range (B5+8140 -
B5+81FE) on the test page from the first link above, probably it's not browser
related, but then I cannot tell the reason.

With non-Xft build, the error range is much greater, I suppose it has something
to do with the content of big5hkscs-0.enc....

But the most disturbing matter is on the second test page, because NO Chinese
font will display correctly in Big5-HKSCS encoding for non-Xft build, I
suspected that the font encoding is not working at all on that page, even after
I specified Character Encoding to Big5-HKSCS. Incidentally, Xft build works on
that page.

This is probably something to do with X11 and XFLD, but I believe the problem
should be reported.
Thanks for info. I had the same problem as you with big5hkscs encoding file and
'xfd'(comment #21). I think I tested big5hkscs encoding file before submitting
to XFree86. It was on my brother's computer which I cannot access now (I got
back my own computer since). Both have RH 9.0 installed and I have no idea
what's different between two (well, FT2 library version is slightly different,
but ....)  I'm adding jch for help here, but probably I have to report it
XFree86 bugzilla and XFree86 font and i18n mailing lists.
When searching for "Big5HKSCS" in Bugzilla database, I found that Bug 217733 is
related to this bug, report it here as reminder.
1. From my Comment #21:

>With Xft build, some errors of font display is found in the range (B5+8140 -
>B5+81FE) on the test page from the first link above, probably it's not browser
>related, but then I cannot tell the reason.

Please disregard this error; Anthony Fok has suggested this is normal behavior
as some of the characters in that range are supposed to be blank, or reserved
for PUA:

http://bugzilla.mozilla.org/show_bug.cgi?id=182089#c14

2. Ok I located a set of PCF font (for Big5HKSCS) partially working with Mozilla
non-Xft build:

http://cs-people.bu.edu/butta1/personal/hkscs/

From the page, I downloaded and installed the fonts: hku16hkscs.pcf.gz,
taipei16hkscs.pcf.gz, taipei24hkscs.pcf.gz; modifying fonts.alias to correct its
encoding scheme from "-big5.hkscs-0" back to "-big5hkscs-0" (no comma).

I proceeded to install by them

mkfontdir (+ modifying fonts.dir for "-big5hkscs-0" encoding) + chkfontpath +
xfs restart.

Now both test pages in Comment #22 render _much_ better. The result suggests
that the file big5hkscs-0.enc is not entirely to blame :). But some characters
are still missing, especially in the second test page.

I have emailed the author of that PCF font, to ask if he knew the font would
cover the entire range (from 8840 to FEFE) of Big5HKSCS in HKSCS 2001 spec. I
think we can assume that "big5hkscs-0.enc" works OK for now, but will need to
look further to see what caused the rest of missing characters.

3. Since another font works to some extent, allow me to go back to the problem:

Why X11core failed to render Big5HKSCS characters when accessing ming_uni.ttf?
Could there be any difference in the way X11core recognize PCF font vs TTF font?
(I heard Xtt and XFS handle fonts differently, could this be a factor too?)

Since Xft build works with ming_uni.ttf, and now we know non-Xft build works
with another PCF font, the logical conclusion is that X11core has some problem
talking to ming_uni.ttf in Big5HKSCS encoding scheme. Any ideas?
The way PCF is handled is very diffrent from the way TTF is handled. The former
doesn't rely on the external encoding file. So, the fact that pcf fonts work
fine doesn't prove anything.  Nonetheless, I'm pretty sure that big5hkscs-0.enc
file is fine.  Anyway, this is not a mozilla bug any more. I have to file a bug
in XFree86 asap.

I filed a bug at XF86 bugzilla. See http://bugs.xfree86.org/show_bug.cgi?id=917


 Juliusz, I couldn't add your address at Xfree86 bugzilla. What's your account
there? Anyway, could you take a look?
> The way PCF is handled is very diffrent from the way TTF is handled. The former
> doesn't rely on the external encoding file.

So this is why Mozilla can work with PCF but not TTF in this case.

But if this is true, then it cannot confirm nor deny "big5hkscs-0.enc" is
working in the case with Mozilla non-Xft. Anyway, as you have suggested, it is
now a XFree86 bug. Note that the font DFSongSd.ttf is not working either.

DFSongSd.ttf can located here:
http://www.iso10646hk.net/english/download_001.html
> But if this is true, then it cannot confirm nor deny "big5hkscs-0.enc" is
> working in the case with Mozilla non-Xft.

  Needless to say, it cannot. It doesn't even work with 'xfd'. If 'xfd' doesn't
work and see the font as we intended, Mozilla cannot, either, which is why this
is NOT a mozilla bug BUT an XFree86 bug (I suspect the encoding file parser has
a 'boundary value' error somewhere). 

Mozilla doesn't know anything about the encoding file.  The only thing it knows
about X11 core font is whatever it gets from the font server or X11 server (that
relies on encoding files to map TTF CMaps  to X11 font charsets specified in
encoding files)
As I wrote in Xfree86 bugzilla (http://bugs.xfree86.org/show_bug.cgi?id=917),
you have to add big5hkscs-0 entry to encoding.dir files in
/usr/X11R6/lib/X11/fonts/encodings and /usr/X11R6/lib/X11/fonts/encodings/large
(the latter is perhaps not necessary). I don't know how I could forget that
(which I did several months ago). My memory really sucks !

So, I'll keep this open only as a reminder that I have to add a note on this in
the release note.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Summary: X11core build takes unusually long to load Big5HKSCS (and some other CJK) pages → add a note about Big5HKSCS fonts and the performance of X11core build
I've just updated the 1.6a int'l known issues. It'll show up about an hour or so
later(?). And it'll be propagated to 1.6beta notes (when it comes out)

Because I refered to this bug in the release notes, here's what to do:

1. download big5hkscs-0.enc file from the XFree86 CVS 

    http://cvsweb.xfree86.org/cvsweb/xc/fonts/encodings/large/big5hkscs-0.enc

2. Compress it with gzip and install big5hkscs-0.enc.gz in
/usr/X11R6/lib/X11/fonts/encodings/large
    Make sure it's world readable (do 'chmod a+r big5hkscs-0.enc.gz as root)

3. Edit /usr/X11R6/lib/X11/fonts/encodings/encoding.dir and 
          /usr/X11R6/lib/X11/fonts/encodidngs/large/encoding.dir

    to add the followling line :

    big5hkscs-0 /usr/X11R6/lib/X11/fonts/encodings/large/big5hkscs-0.enc.gz

   Bump up the number of entries at the beginning of two files by one. 

4. download fonts supporting Hong Kong SAR extension (such as ming-uni) 
    
    http://www.info.gov.hk/digital21/eng/hkscs/reference_iso10646.html

5. The installation program will put it in /usr/share/fonts/zh-TW/Truetype on RedHat

6.  Edit fonts.scale and fonts.dir so that they have the following entry [1]

  -misc-ming(for iso10646)-medium-r-normal--0-0-0-0-c-0-big5hkscs-0

   (you have to change the number of entries at the beginning of files accordingly)

7. Restart your X font server ('service xfs restart' should work on Red Hat,
Mandrake and Suse).
    If not, figure out the pid of 'xfs' by 'ps -ef | grep xfs' and give it HUP
signal by 'kill -HUP Pid_of_xfs'

8.  Check that everything goes well by doing the following:

     $   xlsfs |  grep big5hkscs
     $   xfd -fn '-misc-ming(for iso10646)-medium-r-normal--0-0-0-0-c-0-big5hkscs-0'

    Make sure that you can move around and see a lot of Chinese characters.

9. If you feel like, write to the HKSAR government to update their Linux
pacakage so that you don't have to go  
    through all these steps :-)


     
[1] With XFree86 bug  884 fixed (http://bugs.xfree86.org/show_bug.cgi?id=884),
'mkfontscale; mkfontdir; chkfontpath' should also work. Juliuscz' replacement
for mkfontscale should also work. 
> If you feel like, write to the HKSAR government to update their Linux
> pacakage so that you don't have to go through all these steps :-)

It's a good idea!

But all those changes will go into XFree86 4.4 release, right?
So I think most people will be able to enjoy it without tinkering around like us
when they upgrade in the next Linux distro release cycle :) .

>'mkfontscale; mkfontdir; chkfontpath' should also work. Juliuscz' replacement
>for mkfontscale should also work. 

I just wonder if mkfontscale would detect ming_uni.ttf as -big5hkscs-0 only, or
 also will include -big5-0?

Anyway, thanks very much. Your hard work is appreciated!
I believe I located a missing character mapping in big5hkscs-0.enc, please see
my attachment in XFree86 bug 917 for detail:

http://bugs.xfree86.org/show_bug.cgi?id=917#c4
Thanks for catching the glitch. I uploaded a patch to the XFree86 bugzilla. 

> I just wonder if mkfontscale would detect ming_uni.ttf as -big5hkscs-0 only, or
>  also will include -big5-0?
  
  Both if the character repertoire of both are covered by a foint.

I have checked the release notes of Mozilla 1.6 Alpha, it refers to the bug
205387 instead of this one, it needs to be fixed.
Thanks. I fixed it.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
I noticed the C6A1-C8D3 range which includes Russian alphabet and Japanese kana
in hkscs is blank when I tested the pcf font from
http://cs-people.bu.edu/butta1/personal/hkscs/hku16hkscs.pcf.gz to display
http://cs-people.bu.edu/butta1/personal/hkscs/hkscs-oct.html

Should C6A1-C8D3 range which includes Russian alphabet and Japanese kana be
displayed as part of the hkscs? Microsoft defines that range in hkscs display
page at http://www.microsoft.com/hk/hkscs/code/HKSCS.htm
Note to Mozilla developers, it is not bug related. 

Re: Mitrophan Chin

I think that range (C6A1-C8D3) should be added, if you check the Microsoft page
those characters are among the charmap encoding for big5hkscs:

Starting from C6A1
http://www.microsoft.com/hk/hkscs/code/HKSCS_C6.htm

btw, thanks for keeping an eye on it, I am using your pcf font (Nov 26 update)
and many sites look fine now on X11core Mozilla. But it will be great if the
whole range of HKSCS 2001 spec (from 8840 to FEFE) can be added into the PCF font.

If you have installed ming_uni.ttf according to the procedure described in
Comment #31, the whole range of U+8840-FEFE characters in fact can be displayed
in your testing page here:

http://cs-people.bu.edu/butta1/personal/hkscs/hkscs-oct.html

Although under X11core ming_uni.ttf looks ugly. I wonder if converting to pcf
format will make it look better.

If you want to install ming_uni.ttf ONLY without the input method for Red Hat,
here are the steps:

1. Go to the <Ming for ISO10646> font download page (Note 5 from the site) :
http://www.info.gov.hk/digital21/eng/hkscs/terms/terms34.html

2. Download, ungzipped it, install in a directory in the fontpath list.

3. Comment #31's procedures still apply, except for step 4 & 5, where

Continued from Step 4:

(1) You need to generate fonts.scale & fonts.dir yourself:

In the directory where the font is copied to, enter

# mkfontscale
# mkfontdir

(2) If you install the font in a new directory created inside /usr/share/fonts/
or /usr/X11R6/lib/X11/fonts/, you need to add the new directory to fontpath, by

# chkfontpath -a {path for the new font, ming_uni.ttf}

If you install the font in an existing directory in the fontpath list
(chkfontpath -l) then the above is not needed.

(3) On system with freetype2 AND fontconfig, you need to update the font info by

# fc-cache -f -v

Then you can go back to Step 6 in Comment #31 and continue the installation of
the font.
Obviously (as you all agree), it's not MS but HKSAR that has the final say about
Big5HKSCS. In this case, they're in agreement (how can't they? MS just
implemented the specification by HKSAR). 
Just want to report that the information about this bug-fix did not make it into
Mozilla 1.6 final Release Notes:

http://www.mozilla.org/releases/mozilla1.6/known-issues-int.html
(Although it is in there for 1.6a)

It will be nice if release note for 1.6 final is updated too.
Thanks for the reminder. I've just fixed it.

What happened is that I updated 1.6a release notes about a week before 1.6b
release. However, 1.6b release note was copied from 1.6a release notes well
before the actual release of 1.6a (but was not available for me to update) and
more importantly before I updated 1.6a release notes. Then, 1.6 final release
notes was copied from 1.6b release notes without my change made to 1.6a release
notes included.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.