Re: Adding tis620.2533-0 into Thai Pango engine

[Chookij Vanatham <chookij vanatham eng sun com>]

Hi Robert,

] 
] On Wed, 1 Nov 2000, Chookij Vanatham wrote:
] 
] > Let me know what you think and if you agree, please let me know
] > how this convention on encoding field on XLFD will be maintained
] > and well-known to anybody as the standard.
] 
] > ] In Solaris, we have Wtt2.0 rule for the display. Wtt2.0 provides the table
] > ] to check whether the current Thai character can be combined with the 
previous
] > ] character. If it can't be combined like those invalid Thai sequences such 
as,
] > ] U+0E48 + U+0E34 --> this is invalid sequence, then U+0E34 will be 
displayed
] > ] as its own cell.
] 
] This is not a platform-dependent or even font-dependent setting.  This
] should be a user preference.
] 
] Any other way is mad.
] 
] (Sure, you may want to ship this with a different default).

First of all, I think I would have used the wrong word and that would be
because I don't understand all the issues clearly.

I think, I would say that the cell-clustering behavior which is tied to
font layout shouldn't be said 100% to platform-dependent.

Absolutely right that font-dependent setting should be just the shipment
of the different default. I just want to point out that, with Thai pango
engine now, the cell clustering is not the same as what we follow Wtt2.0
cell clustering. So, even shiping with a different default font, it wouldn't
be enough, unless, shipping with different Thai pango engine, then, this
issue shouldn't be the concern. 

Please clearify me if shiping with different Pango engines would be
the way we would like to do it as well in pango design. Then, I wouldn't bother
keeping talking about this, please.

Thanks,

Chookij V.


] 
] -- 
] Robert Brady
] robert suse co uk
] 
] 
] _______________________________________________
] gtk-i18n-list mailing list
] gtk-i18n-list gnome org
] http://mail.gnome.org/mailman/listinfo/gtk-i18n-list