Re: [Fonts]Wrong CJK bitmap font size selected by fontconfig/Xft 2.1?

2003-01-02 Thread Anthony Fok
On Wed, Jan 01, 2003 at 07:32:48PM -0800, Keith Packard wrote:
 Around 11 o'clock on Jan 2, Anthony Fok wrote:
 
  I couldn't figure out why disproportionally large 24px zh-CN font was
  selected in place of the closest 16px when lang=en.  I have tried
  switching to all other languages, and it appears that only lang=en
  exhibits the problem.
 
 lang=en may force the 24px font because of coverage issues; it's possible 
 the 16px font is missing some glyphs needed for English but not needed 
 for German.
 
 You can check the language encoding supported by each font using fc-list, 
 I don't have a 24 pixel font with support for zh-CN, but you should be 
 able to see it with:
 
 $ fc-list :lang=zh-cn:pixelsize=24 family lang pixelsize

Hello Keith,

Thanks again for your quick and helpful response!  Yes, you have hit right
on the nail!  It turns out that fangsongti16.pcf is missing U+00EB (small
latin e with diaeresis), while fangsongti24.pcf does have it.  Manually
adding the glyph in fangsongti16.bdf solves the problem, at least fc-list
now shows fangsong ti 16 with lang=en support.  :-)

I was a little surprised to find that en.orth's coverage is greater than
that of say de.orth or fr.orth.  But then again, I guess English does use
more foreign words in daily use.  :-)

By the way, these fangsongti{16,24}.bdf fonts are created by Yu Shao and
Owen Taylor from existing XFree86 fonts (gb16fs.bdf, gb24st.bdf, 8x16,
12x24), re-encoded in Unicode.  If you are interested, you may get the font
here:

  BDF files:

http://mirror.mcs.anl.gov/redhat/linux/beta/phoebe/en/os/i386/SRPMS/bitmap-fonts-0.2-4.src.rpm

  PCF files:

http://mirror.mcs.anl.gov/redhat/linux/beta/phoebe/en/os/i386/RedHat/RPMS/bitmap-fonts-0.2-4.noarch.rpm

http://mirror.mcs.anl.gov/redhat/linux/beta/phoebe/en/os/i386/RedHat/RPMS/bitmap-fonts-cjk-0.2-4.noarch.rpm

Patch for fangsongti16.bdf attached.  (This is the least I can do.  :-)
I haven't tried it with an anaconda rebuild, but I guess the patch should
do the trick.  :-)

 You can watch the match process by enabling a couple of debugging levels 
 within fontconfig:
 
 $ export FC_DEBUG=3 
 $ some random pango app

 This will generate quite a bit of output, but should provide sufficient 
 information to see why one font is preferred to another, although you're 
 likely to need to look a the fontconfig source to make much sense of the 
 output.

Thanks for the helpful tips!  They'll come in handy.  :-)

Cheers,

Anthony

-- 
Anthony Fok Tung-Ling
ThizLinux Laboratory   [EMAIL PROTECTED] http://www.thizlinux.com/
Debian Chinese Project [EMAIL PROTECTED]   http://www.debian.org/intl/zh/
Come visit Our Lady of Victory Camp!   http://www.olvc.ab.ca/

--- bitmap-fonts-0.2~/fangsongti16.bdf  2002-08-29 01:55:55.0 +0800
+++ bitmap-fonts-0.2/fangsongti16.bdf   2003-01-02 17:22:16.0 +0800
@@ -81,7 +81,7 @@
 DEFAULT_CHAR 8481
 COPYRIGHT Copyright (c) 1988  The Institute of Software, Academia Sinica.
 ENDPROPERTIES
-CHARS 7814
+CHARS 7815
 STARTCHAR 0x3000
 ENCODING 12288
 SWIDTH 1000 0
@@ -179528,6 +179528,29 @@
 10
 20
 ENDCHAR
+STARTCHAR C353
+ENCODING 235
+SWIDTH 480 0
+DWIDTH 8 0
+BBX 8 16 0 -2
+BITMAP
+00
+44
+44
+00
+00
+38
+44
+82
+fe
+80
+80
+80
+44
+38
+00
+00
+ENDCHAR
 STARTCHAR C355
 ENCODING 238
 SWIDTH 480 0



[Fonts]Wrong CJK bitmap font size selected by fontconfig/Xft 2.1?

2003-01-01 Thread Anthony Fok
Hello,

First of all, Happy New Year!  :-)

While testing the latest Red Hat 8.1 beta (Phoebe), during installation,
fontconfig/Xft 2.1 appears to be selecting the wrong CJK bitmap font size
when lang=en, as shown in the following screen capture:

   http://foka.homelinux.net/~foka/xft/phoebe-anaconda-en-chinese-24px.jpg

switching to other languages, e.g. lang=de, seem to fix the problem:

   http://foka.homelinux.net/~foka/xft/phoebe-anaconda-de-chinese-16px.jpg

Hanzi fonts available in the system:
  zh-CN: 16px and 24px PCF fonts
  zh-TW: AR PL Mingti2L Big5 (TrueType)
  ja: Kochi Gothic (TrueType)
  ko: (I forgot which one, probably Baekmuk Batang or Dotum; also TrueType)

I couldn't figure out why disproportionally large 24px zh-CN font was
selected in place of the closest 16px when lang=en.  I have tried switching
to all other languages, and it appears that only lang=en exhibits the
problem.

In the previous version (Red Hat 8.0, fontconfig 2.0, Xft 2.0), a more
correct bitmap font size (16px instead of 24px) was selected even when
lang=en.  (I.e., it looks like phoebe-anaconda-de-chinese-16px.jpg)

Is this issue the domain of fontconfig or Xft?  Or Pango?  Or something else
altogether?  I apologize for my ignorance, as I am not yet sure of the exact
division of work among the three libraries.  :-)

Many thanks,

Anthony

-- 
Anthony Fok Tung-Ling
ThizLinux Laboratory   [EMAIL PROTECTED] http://www.thizlinux.com/
Debian Chinese Project [EMAIL PROTECTED]   http://www.debian.org/intl/zh/
Come visit Our Lady of Victory Camp!   http://www.olvc.ab.ca/
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts



[Fonts]Xft patch for halfwidth glyphs in monospace CJK fonts

2002-12-09 Thread Anthony Fok
Hello,

I was assigned with the task of dealing with s p a c e d - o u t  CJK
fixedPitch font issue in konsole.  There are quite a few modern CJK
TrueType fonts with the fixedPitch flag set to true to mean that:

   * All CJK glyphs have the same fullwidth
   * The ASCII glyphs and other special glyphs have the same halfwidth

I have submitted a small patch to the FreeType mailing list to deal with the
halfwidth monospace font issue, and it turns out that Xft has the same
issue.  It took me a while to figure out that it was not konsole or Qt.  :-)

Anyhow, to demonstrate the issue, the following screenshot was taken after
patching FreeType and before patching Xft:

http://anthony.homelinux.net/~foka/xft/halfwidth-rendered-as-fullwidth.png

The font therein is a popular fixedPitch Chinese TrueType font.

After applying the patch to Xft, it looks much nicer:

http://anthony.homelinux.net/~foka/xft/halfwidth-even-advance.png

Note that this is the case when the fullwidth (or full advance width) is
an *even* number, say 16, so that the halfwidth would be 8.

How, when the fullwidth is an *odd* number, say 15, the halfwidth would be
rounded off to 7, but 7 + 7 = 14.  And as you can see from the following
screenshot, the text aren't as nicely aligned:

http://anthony.homelinux.net/~foka/xft/halfwidth-odd-advance.png

(but of course, still much better than before.  :-)

Any idea on how to deal with the 15 / 2 = 7;  7 + 7 = 14 issue?  :-)

Oh yes, please let me know if the attached patch is okay.  Many thanks!

Cheer,

Anthony

-- 
Anthony Fok Tung-Ling
ThizLinux Laboratory   [EMAIL PROTECTED] http://www.thizlinux.com/
Debian Chinese Project [EMAIL PROTECTED]   http://www.debian.org/intl/zh/
Come visit Our Lady of Victory Camp!   http://www.olvc.ab.ca/

--- Xft~/xftglyphs.c2002-10-12 01:53:02.0 +0800
+++ Xft/xftglyphs.c 2002-12-09 01:42:56.0 +0800
@@ -298,6 +298,13 @@
xftg-metrics.yOff = 0;
}
}
+
+   /*
+* Halfwidth characters in fixed-width CJK fonts
+*/
+   if (TRUNC(ROUND(glyphslot-advance.x)) = (font-public.max_advance_width 
+ 1) + 1
+xftg-metrics.xOff  1)
+   xftg-metrics.xOff = xftg-metrics.xOff  1;
}
else
{



Re: [Fonts]zh-hk font support/priority in Xft

2002-12-04 Thread Anthony Fok
Hello Keith,

Wow, you are really fast!  I didn't expect to receive a reply within
minutes, but yes, I am really grateful that you have been so responsive and
helpful.  :-)

On Wed, Dec 04, 2002 at 11:39:05AM -0800, Keith Packard wrote:
 
 Around 2 o'clock on Dec 5, Anthony Fok wrote:
 
  The PUA mapping is a distinguishing feature of a HKSCS font.
 
 Hmm.  I removed these hoping that the remaining standard codepoints would
 serve to correctly identify HKSCS fonts.  I'm not entirely sanguine about
 using PUA codepoints in this way, but it appears we don't have a better 
 option.

I see your point.  I guess the reason using PUA is safe in this case
because nearly all HKSCS fonts, at least within these few years, will
provide mapping to PUA as a fallback, especially for the 1650+
characters above U+2.  There are still too many software limited
within the BMP, especially for legacy systems like Windows 98.  ;-)

On the other hand, in the future, if a large CJK + CJK A + CJK B font
(without HKSCS compatibility PUA) comes along... Hmm... do the *.orth
support either or, say F308|2010C?  grin, duck, run  ;-)

Thanks again, and cheers,

Anthony

-- 
Anthony Fok Tung-Ling
ThizLinux Laboratory   [EMAIL PROTECTED] http://www.thizlinux.com/
Debian Chinese Project [EMAIL PROTECTED]   http://www.debian.org/intl/zh/
Come visit Our Lady of Victory Camp!   http://www.olvc.ab.ca/
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts



[Fonts]zh-hk font support/priority in Xft/Pango

2002-12-02 Thread Anthony Fok
Hello Keith and all,

I was trying to run a Gtk2 application built with Xft/Fontconfig (2.0)
and Pango under the zh_HK locale, on a system with only zh_CN (GB2312)
and zh_TW (Big5) fonts installed.  Under zh_CN and zh_TW locales, the
correct fonts are chosen.  Under zh_HK locale, however, since no zh_HK
fonts were found on the system, the zh_CN font appears to have a
higher priority over the zh_TW one, resulting in a funny-looking mosaic
of text rendered with about 1/3 zh_CN and 2/3 zh_TW.  This is my first
problem.

The second problem is that fontconfig 2.0 does not seem to recognize a
zh_HK (HKSCS-2001) font as such.  (This is on a different system where
a full set of Chinese fonts is installed.)  I have with me AR Mingti
Light B5 v2.50 with HKSCS-2001, and here is roughly what fc-list tells
me (from memory; I don't have access to that machine now):

$ fc-list :lang=zh-cn
FZShuSong\-Z01:style=Regular
FZHei\-B01:style=Regular

$ fc-list :lang=zh-tw
AR Mingti Light B5:style=Regular
AR PL Mingti2L Big5:style=Reguler [sic]
AR PL KaitiM Big5:style=Regular

$ fc-list :lang=zh-hk
[no output]

AR Mingti Light B5 should be complete, but just to make sure, I chdir
to fontconfig/fc-lang, modified zh-hk.orth and kept only the first code
(4E04?), ran 'xmkmf -a; make' etc., and fc-list :lang=zh-hk still
showed no font.  Now, I changed zh-hk.orth to just include
zh-tw.orth, and finally fc-list :lang=zh-hk works, just as
fc-list :lang=zh-mo does.

So yes, there appears to be two related but separate issues:

  1. When no zh_HK font is found, fontconfig (or is it Pango?) looks
 for zh_CN before zh_TW, but the right thing is to go to zh_TW
 first because zh_TW is 98% of the time adequate for zh_HK.
 (Yes, there are some 4800+ HKSCS characters, but their use is rare
 compared to the core Big-5 in a zh_TW font.

  2. When a zh_HK font is available, fontconfig does actually
 recognize it.  Could it have something to do with the algorithm
 where fontconfig decides a font to be either zh_CN or zh_TW (and
 not both?)

And, hereby I admit my inadequacy, and I am no advanced programmer. 
I am not quite sure where to look.  In fontconfig?  Or in Pango?
Any pointers would be helpful.  Thanks in advance!  :-)

Cheers,

Anthony

-- 
Anthony Fok Tung-Ling
ThizLinux Laboratory   [EMAIL PROTECTED] http://www.thizlinux.com/
Debian Chinese Project [EMAIL PROTECTED]   http://www.debian.org/intl/zh/
Come visit Our Lady of Victory Camp!   http://www.olvc.ab.ca/
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts



Re: [Fonts]zh-hk font support/priority in Xft/Pango

2002-12-02 Thread Anthony Fok
Hello Keith,

On Mon, Dec 02, 2002 at 10:17:58AM -0800, Keith Packard wrote:
 
 Around 0 o'clock on Dec 3, Anthony Fok wrote:
 
  Under zh_HK locale, however, since no zh_HK fonts were found on the system,
  the zh_CN font appears to have a higher priority over the zh_TW one,
  resulting in a funny-looking mosaic of text rendered with about 1/3 zh_CN
  and 2/3 zh_TW.  This is my first problem.
 
 We can solve this with a configuration change:
 
   match target=pattern
   test qual=any name=lang
   stringzh-hk/string
   /test
   edit name=lang mode=append
   stringzh-tw/string
   /edit
   /match

Great!  Thanks!  I'll give it a try.  :-)

 This says that when asking for a font which supports 'zh-hk', accept as a 
 reasonable substitute a font which supports 'zh-tw'.
 
  The second problem is that fontconfig 2.0 does not seem to recognize a
  zh_HK (HKSCS-2001) font as such.
 
 It's quite possible that the hk orthography is too selective; the HKSCS 
 includes a lot of codepoints which may not be in the fonts you're 
 interested in.  You can check which codepoints are supported in that font 
 using 'xfd'.  If you can, send as many HKSCS fonts as you can along to me 
 and I'll modify the orthography to fit them.  The trick is to make sure 
 that only fonts with reasonable HKSCS support are matched.

That's true.  Yes, for starters, I suppose zh-hk.orth only need to cover
HKSCS-1999 (with 116 less characters).  Nevertheless, I reduced zh-hk.orth
to only one single line (just the code 4E04) and fontconfig still wouldn't
recognize any font as such, so I suspect the problem lies somewhere else. 
But yes, I shall do more experiment and let you know of the result.  :-)

Thanks again,

Anthony

-- 
Anthony Fok Tung-Ling
ThizLinux Laboratory   [EMAIL PROTECTED] http://www.thizlinux.com/
Debian Chinese Project [EMAIL PROTECTED]   http://www.debian.org/intl/zh/
Come visit Our Lady of Victory Camp!   http://www.olvc.ab.ca/
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts



[Fonts]Re: [Freetype] A problem on using fonttootf problem

2002-10-08 Thread Anthony Fok

Hello Zenith,

First of all, thank you for your interests in improving Chinese fonts
support.  :-)  I have not heard of fonttootf before, but it certainly sounds
interesting.

There are probably three methods to embed a bitmap Chinese font into a
TrueType/OpenType font:

  1. Use Microsoft's free (zero-cost) tools available at
http://www.microsoft.com/typography/

 Of course, the BDF/PCF font needs to be converted to a proper format
 first.

  2. Use George William's PfaEdit tool to import the bitmap data into
 the TTF/OTF.  A downside to this is that there may be some quality loss
 to the vector glyph data (because PfaEdit converts the quadratic bezier
 curves to cubic bezier curves upon opening, and back upon saving.

  3. Use fonttools (fonttools.sourceforge.net).  The BDF data also needs
 to be converted to a format (some kind of XML) that fonttools can read
 for merging.

  4. Use a commercial font tool. 

I like #3, and may get around doing something about it when I have the time. 
:-)  By the way, where did you find the 12pt public-domain Big5-HKSCS
bitmap font?  I didn't know that any existed!

Hope this helps,

Anthony

-- 
Anthony Fok Tung-Ling
ThizLinux Laboratory   [EMAIL PROTECTED] http://www.thizlinux.com/
Debian Chinese Project [EMAIL PROTECTED]   http://www.debian.org/intl/zh/
Come visit Our Lady of Victory Camp!   http://www.olvc.ab.ca/
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts