Clustering rules (was Re: Adding tis620.2533-0...)

[Owen Taylor <otaylor redhat com>]

Chookij Vanatham <chookij vanatham eng sun com> writes:

> K.Theppitak,
> 
> ] 
> ] Dear K.Chookij,
> ] 
> ] IMO, the code point assignments of both Windows and Solaris extensions are
> ] not different in the shaper engine's point of view. The difference is only
> ] the U+F71B glyph shape, not the different code tables as in the case of
> ] tis620-0, tis620-1 and tis620-2.
> ] 
> ] So, I don't think tis620-3 is necessary here.
> I think this is the good reason as well and I agree.
> 
> ] 
> ] However, let me guess that you mean to choose to handle tis620-3 with
> ] Wtt2.0 cell clustering engine. (Please excuse me if I'm wrong.)  But I
> ] think Wtt2.0 can be applied to other tis620 encodings as well.
> This is correct and that's why I have been trying to point out and hopefully,
> there is the flexibility in Pango engine design to have different rules of
> cell-clustering for the same font (charset-name) but seems to be that,
> it's not important issues to anybody. Unless, someone can tell me that,
> we can have this capability and they need to ship out their own Thai Pango
> engine to satify their own need. If that's the case, we wouldn't need
> to worry about this. Or, any other ideas are wellcome but making sure that
> don't force users to use what we provide but, at least, give the options
> to them.

I'm not very happy about any of the solutions that have been proposed
so far, because they involve separating the font from the clustering
rules that need to be used for the font.

This is going to present significant headaches for users, in having
to create configuration files that describe how each font should
be clustered and maintain them as they add new fonts.

I'm already concerned that the configuration for Pango with the
pangox-aliases file is not easy enough. I don't want to make this
worse.


I think we can do better than this, though it may cause backwards
compatibility problems with some existing fonts; we need to
either:

 - Standardize on one set of clustering rules per encoding

 - Represent the clustering rules in the encoding field of the
   XLFD:  (tis620-3.wtt20)

Or:

 - Store the appropriate clustering rules as an additional 
   property on the font.

   This could either be an atom representing one of a set 
   of standard clustering rules or a more complex rule set.


I think it would be useful if someone could enumerate the clustering
rules currently in use for Thai on X, so we can see:

 - How many different rules are in use
 - Which ones we need to support
 - How bad the problem is with legacy fonts without identified
   clustering rules.


I hope in the long term we'll be going to font formats like OpenType
that are rich enough to represent clustering rules natively.

Regards,
                                        Owen