On 19 Oct 2001, Juliusz Chroboczek wrote: Hi Juliusz,
Thank you for your answer. > JS> When used under MS-Windows, glyphs for US-ASCII part (or ISO-8859-1 > JS> part) are about twice as narrow as glyphs for Japanese > JS> characters. However, the width of glyphs for US-ASCII part is the same > JS> as that of glyphs for Japanese characters when it is presented to X11 > JS> clients by freetype backend of XFree86 4.x. That is, the width of US-ASCII > JS> glyphs is abnormally wide making text rendered with them very ugly. JC> This is the expected behaviour. JC> If you put a `-c-' entry in your fonts.dir, the freetype backend will JC> forcibly cast all your glyphs to the same width. No doubt this is expected when the last two fields of XLFD is iso10646-1. That's why I wrote about subsetting support so that users can remove some code range in iso10646-1 fonts derived from CJK TTFs. However, if the last two fields of XLFD is something like iso8859-1, wouldn't it better to follow some kind of 'wcswidth convention' per 'character set+encoding' basis instead of 'ind. chars basis'? BTW, for this reason, I had to remove iso10646-1 entry in XLC_LOCALE definition of ko_KR.UTF-8. Otherwise, all the gnome applications requiring fixed-width fonts running under ko_KR.UTF-8 pick up iso10646-1 fonts with twice-as-wide-as-expected glyphs for Latin characters. However, this means that I cannot use Hangul precomposed syllables outside the repertoire of KS X 1001 (KS C 5601) *even* in ko_KR.UTF-8 locale unless ksc5601.1992-3 is supported by Xlib which will certainly bloat Xlib, which I don't think is desirable unless there's no way around. On the other hand, support for Big5 is already there so that adding ksc5601.1992-3 support might not be such a big deal... (I have little idea about this last point) JC> If you want to use a variable width font, you should be using `-p-' JC> instead. However, there are cases where '-c-' is necessary and users expect this dual-width convention. Of course, I'm not saying this has to be done *within* a single (as seen by X11 clients) font which is against the very definition of character cell font, but it appears to make sense that *two or more* 'logical' fonts with different values in the last two fields of XLFD presented to X11 clients derived from a *single* CJK TTF have *fixed* but different widths. Suppose we have the following entries in fonts.dir watanabe-mincho.ttf -watanabe-mincho-medium-r-normal--0-0-0-0-c-0-iso8859-1 watanabe-mincho.ttf -watanabe-mincho-medium-r-normal--0-0-0-0-c-0-jisx0208.1983-0 watanabe-mincho.ttf -watanabe-mincho-medium-r-normal--0-0-0-0-c-0-iso10646-1 Now there's a html rendering engine which uses '-c-' fonts to render <pre> or <tt> and a user feed it with the following html snippet. ------------ <div style="font-family: mincho" lang="ja"> <pre> Japanese and English mixed text </pre> </div> ---------- Wouldn't it be natural to expect Latin characters to have half the width of Japanese characters? One may ask: why don't I just remove the first entry above if I don't like the glyphs coming from that entry? I could, but more often than not, Latin glyphs included in CJK TTFs are designed to go along better with CJK glyphs in CJK TTFs than Latin glyphs in Latin-only TTFs (Times-Roman, Courier, Helvetica) and users may wish those glyphs to be used. Moreoever, users migrating from MS-Windows are used to this behavior (when they specify 'mincho', 'song', 'ming', 'batang' as a font to use, they get every letter/character rendered with glyphs drawn from that font) and expect the same from X11. Jungshik Shin _______________________________________________ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
