On Sat, 2 Aug 2003, Chisato Yamauchi wrote:

>   Although the pliability of handling such special fonts is also important,
> non BMP plane in XLFD is now the most important problem.  Confusion is
> already seen such as linux-utf8 list.  An official definition should be
> indicated right now.  Why has XFree86 left this?

  That's because XFree86 is moving away from 15year-old XLFD-based
approach. As Owen wrote, we'd better let that poor thing rest in peace
and move along. With fontconfig/Xft, we don't need to worry about XLFD
any more except for the sake of backward compatibility.  For non-BMP
characters, there isn't much issue with back. comp.  to worry about.

If you take a look at Mozilla's gfx/src/gtk/nsFontMetricsGTK.cpp
and gfx/src/gtk/nsFontMetricsXft.cpp
(or gfx/src/windows/nsFontMetricsWin.cpp) at
<http://lxr.mozilla.org/seamonkey>, you'll know what I mean.
Mozilla developers have put tremendous amount of 'heroic' efforts to make
CSS-style font selection work with XLFD-based font names. However,
a much simpler and shorter fontconfig based code(in
nsFontMetricsXft.cpp) works better that nsFontMetricsGTK.cpp (for XLFD-based
font names).

Adding yet another field to make XLFD more complex doesn't help a bit
in this respect. Besides, in your example (GT fonts), I don't see why
you need to extend XLFD. Couldn't you just use different numbers in
the last field of XLFD?

 >   gt200001.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-0.1
 >   gt200002.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-0.2
 >   gt200003.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-0.3

Instead of the above, the following should work as well, shouldn't it?
Am I missing something?

 >   gt200001.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-1
 >   gt200002.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-2
 >   gt200003.ttf -gt-mincho-medium-r-normal--0-0-0-0-c-0-gt.2000-3


>   Why do we persist in X-TT?  The reason is that "libfreetype.a"
> does not useful at all in CJK.  Especially the following two points are fatal.

  Well, X-TT's 'competitor' is not freetype module, but fontconfig
(+FT2 + Xft)

>   - Handling a proportional multi-bytes fonts is too slow.
>     (The loading speed of libfreetype.a is 20 times slower than
>      that of X-TT 1.4; I show a benchmark in next email.)

>  For the "with TTCap option" case, the option has been set to
>  "fc=0x3400-0xe7ff:fm=0x5a00".  This particular option setting
>  indicates that "xtt" handles the glyphs that are within the CJK
>  region (in unicode) with constant spacing, whose metrics are
>  similar to that of "0x5a00".

  This is a nifty idea that can be utilized in Freetype2 and/or
fontconfig, but it seems to me that the fact that there's that much difference
in the perf.  between two cases is yet another indication that
X11 core fonts have to go away.


>   - The modification of a font(such as auto italic and double striking, etc.)
>     cannot be used at all.
>
>   That is, "libfreetype.a" should also have all options of "TTCap".
>

  Yeah, TTCap is useful, but it appears that we're trying to solve the
wrong problem turning away from the real issue. The real problem is
that we don't have quality CJK fonts in multiple styles.
Anyway, fontconfig offers 'artificial slanting' although it doesn't make
much sense to have 'italic' or 'slant' typefaces for CJK.

As for 'artificial bold',  there's a patch somewhere, but hasn't been
accepted because Freetype2 reportedly will come up with a better
solution for 'artificial bold'.

>   Have you seen CJK's *TYPICAL* fonts.dir of TrueType fonts?
> It is following:

 Not many people would be fond of tweaking fonts.dir/scale files
these days :-) Why would they when just dropping truetype fonts in
fontconfig in one of directories listed in the font search path
works like a charm?


  Jungshik

P.S. If merging X-TT and freetype module is not gonna happen soon,
it would be nice if X-TT makes use of fontenc library used by freetype
library. With fontenc library, freetype module doesn't have to hardcode
font encoding to Unicode mapping tables. Because font encodings are not
hard-coded, it's easy to add a new encoding although these days we don't
care much. Moreover, it'll cut down the size of X-TT significantly.
_______________________________________________
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Reply via email to