Jungshik Shin <[EMAIL PROTECTED]> 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 :-(
