Jungshik Shin <jshin(_at_)jtan(_dot_)com> writes:
If you want, you can take a look at nsFontMetricsGTK.cpp file
of mozilla.
Can you pass on my admiration to the Mozilla team - its
handling of these issues in version 1.4 is so much better
than ye-olde Netscape.
You can view that huge file (over 6,000 lines of
code) by going to http://lxr.mozilla.org and typing in the
file name. Compare that with nsFontMetricsXft.cpp or
nsFontMetricsWin.cpp and you'll realize the enormous difficulty of the
problem you're trying to tackle. See, for example,
<http://bugzilla.mozilla.org/show_bug.cgi?id=152264>
Believe me I know the scope of the problem.
I started on porting the allegedly "Unicode aware" tk8.x from Tcl/Tk
back in 2000. The font problem has been plaguing me ever since.
Note my _personal_ care about is not CJK, nor correct rendering of
all the Russian SPAM I get, but IPA phonetics. These suffer particularly
badly as many of the glyphs are "borrowed" from various blocks.
But Tk's "loony" scheme means I get bold version of this, italic
version of that, re-scaled bitmap of the other - and then the
diacritics dumped in a heap on top.
Perhaps, your problem is of the limited scope, but still
it won't be a very pleasant experience ;-)
The scope is not limited - quite the reverse - this is a toolkit, so
I don't know what it is being used for. However that is also my "way out":
provided I can give the end-users a way to do something decent I can leave
the final compromises to them. What I don't like about current tk8
is that it forces some very dubious compromises on the end-user.
So my postings here (to perl-unicode) are to see if perl has the
mechanisms to help. The suggesions so far have been very useful.
Can Tk use Xft and fontconfig
(http://fontconfig.org) where/when available?
Using XLFD-based
fonts (15year old) is not such a good idea if you don't have to.
Not in the imminent release - that is too big a change to core-tk I inherit.
But as I had already more or less convinced my self that was way to
go and now Owen Taylor and you have both suggested it I will give
it serious consideration.
perl/Tk is notionaly a port of Tk from Tcl to perl, so I try not
to mess with the fundamentals, as that just creates more work.
But this is _such_ a mess, and font handling is relatively well
encapsulated that I really think a Xft type solution is worth a try.
What gets really painful is the Unicode fonts - one has to look at
which characters it has to decide if it
Japanese/Simplified Chinese/Traditional Chinese/Korean or just a grab-bag
of glyphs font designer had to hand.
Some Unicode fonts have a signature for 'lang'. For instance,
'misc-fixed-iso10646-1' fonts that come with XFree86 have 'ko' and
'ja' in add-style field.
But no Chinese? (I don't read any of these, but I am getting a feel for
what they should look like and I have co-workers that do read chinese.)
Other fonts have a 'lang signature' in
registry-encoding pairs (e.g. ucs2.korean-0)
Ah - I have not seen any of those yet.
http://bugzilla.mozilla.org/show_bug.cgi?id=215537). As you wrote,
most of them don't and it'll make some old system almost to a halt
for tens of seconds if you want to open Unicode X11 core fonts
and examine which char. is covered.
It is the freeze for 10s of seconds and then produce
a complete mess that I feel I must fix -
10s for beauty, or instant mess I could justify ;-)
The other irritant is that the more fonts one has the worse it gets.
The best results (for Tk) are obtained by deleting all but a selected
few fonts so it can't choose the wrong ones :-(
