On 24 Oct 2001, Juliusz Chroboczek wrote:

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'?

JC> The XLFD provides a strict definition for `-c-' fonts.  This defi-
JC> nition is implemented by the freetype backend, which will do technic-
JC> ally correct but slightly unintuitive things if you lie to it about
JC> the nature of your fonts.

  Let me just make sure I understand your point. Are the following fonts
(-watanabe-mincho-....iso8859-1 and -watanabe-mincho-.....jisx0208.1983-0)
two separate fonts or a single font?

 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

Does the XLFD definition of '-c-' font prevent them from having two
different widths (*all* the glyphs in the second one are twice as wide
as *all* the glyphs in the first one) ? If yes, I have no more to say.
If not, I think my point still stands.


JC> If you desire a different behaviour, you should either try to get your
JC> applications to work with `-p-' fonts, or push for a ``biwidth'' `-b-'
JC> spacing type to be included in a future versions of the XLFD.

 If the answer to my two questions above is no, I don't think '-b-'
is necessary. '-b-' is only necessary for 'iso10646-1' fonts derived
from CJK TTFs, but I'm not talking about them (for them, I suggested
'subsetting' as a way around in my previous mesg.). Of course, if the
answer is yes, my point is moot.

  Jungshik Shin

_______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n

Reply via email to