JS> However, if the last two fields of XLFD is something like iso8859-1,
JS> wouldn't it better to follow some kind of 'wcswidth convention' per
JS> 'character set+encoding' basis instead of 'ind. chars basis'?
[...]
JS> watanabe-mincho.ttf -watanabe-mincho-medium-r-normal--0-0-0-0-c-0-iso8859-1
JS> watanabe-mincho.ttf -watanabe-mincho-medium-r-normal--0-0-0-0-c-0-jisx0208.1983-0
JS> watanabe-mincho.ttf -watanabe-mincho-medium-r-normal--0-0-0-0-c-0-iso10646-1
[...]
JS> Wouldn't it be natural to expect Latin characters to have half the width
JS> of Japanese characters?
The XLFD provides a strict definition for `-c-' fonts. This defi-
nition is implemented by the freetype backend, which will do technic-
ally correct but slightly unintuitive things if you lie to it about
the nature of your fonts.
If you desire a different behaviour, you should either try to get your
applications to work with `-p-' fonts, or push for a ``biwidth'' `-b-'
spacing type to be included in a future versions of the XLFD.
My personal opinion is that core fonts should be deprecated, and
applications move to RENDER client-side fonts instead; thus, I think
that working on revising the XLFD is a loss of time. (In particular, I
do not intend to put any new code in the freetype backend myself,
although I'd be willing to include *correct* patches.)
(The word ``correct'' explains why the sbits patch has not yet been
included.)
Juliusz
_______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
