Re: Industry Thai Cell-Clustering Rules



Chookij Vanatham <chookij vanatham eng sun com> writes:

> This is the point. WTT2.0 isn't dependent on font encoding but, for sure,
> it talks about Cell-Clustering. Whether Cell-clustering is specific to
> font or not, again, I don't know what to say. 
> 
> Let me show you then, you might help to answer me if
> Cell-clustering is font-specific or not.
> 
> Here is the piece of Thai pango engine codes which are for determining,
> the Thai cell cluster.
> 
>     while (p < text + length)
>      {
>         ...
> 
> 	if (wc >= 0xe30 && wc < 0xe50)
> 	   group = groups[wc - 0xe30];
> 	else
>            group = 0;
> 
> 	switch (group)
> 	{
>         case 0:
> 	  if (base)
>             {
>               add_cluster (font_info, glyphs, cluster_start, base,
>               			group1, group2);
> 		group1 = 0;
> 		group2 = 0;
>             }
>           cluster_start = p - text;
> 	  base = wc;
> 	  break;
> 	case 1:
> 	  group1 = wc;
> 	  break;
> 	case 2:
> 	  group2 = wc;
> 	  break;
> 	}
> 
>       p = g_utf8_next_char (p);
>  
>       ....
> 
>     }
> 
> 
> This piece of code determines Cell-Clustering for Thai and, of couse,
> it doesn't use Wtt2.0 Cell-clustering logic.
>
> Now, if users want to have Thai displayed as Wtt2.0 Cell-clustering,
> what will you do ?
>
> That's why, we put Cell-clustering to XLFD name, so that, the engine
> can determine which cell-clustering rule should be used. Then, users
> would be able to choose what they want.
> 
> It's not really clear cut to say that Cell-clustering is not specific to
> font. Unfortunately, in the industry, there are more than 1 cell-clustering
> rule.

I have to disagree here (and, I think, agree with K. Theppitak) - 

 - I wrote that code basically to give a simple example of how a
   shaper can work in Pango, not to say that is how Thai shaping
   should definitively work in Pango. In fact, I'd be very happy if
   somebody replaced the code with something more standard and
   better.

 - Changing .pangox-aliases to use a different font name is not
   a good way for users to configure their preferred clustering
   rules.

 - I'm not sure if we need to support multiple cell clustering
   rules in Pango is even necessary. Can't we just say that 
   we always use wtt-2.0?

 - It is important in Pango that clustering (in the Pango sense -
   I'm not sure I quite understand the sense that you mean), is
   independent of the font.

   I can have a GtkTextBuffer object with multiple views of the same
   text with different. Moving one cursor position to the right 
   should have an unambiguous meaning in this case.

> ] Let me say:
> ] - tis620-1 and tis620-2 are proper supersets of tis620-0.
> ] - So, any rendering engine that works with plain TIS 620 (i.e. tis620-0)
> ]   can be applied to all above categories of tis620 registry. And WTT 2.0
> ]   provides one of such engines.
> ] - So, it's rather a matter of preference to choose the rendering engine
> ]   than a matter of font encoding.
> 
> K.Theppitak, let me make sure that we are not mixing between Cell-clustering
> and font-shapping. As you mentioned that it's a matter of preference to
> choose the rendering engine to have either Wtt2.0 cell-clustering or
> (let's say) non-Wtt2.0 cell-clustering, how would you be able to do that
> with Pango ?

What would be the reasons why a user would want to choose one
clustering rule or another?
 
> For the long term, we hope to have the new font technology to put this
> cell-clustering information into the font and if that is possible, then,
> we don't need to put .wtt2.0 into XLFD. Now, we are talking about short-term
> and in order for Thai Pango engine to be able to provide the right
> cell-clustering to what the users need.

I don't think I still quite understand the concept of cell-clustering.

Can you maybe explain how the shapes and/or metrics of a font depend
on the clustering rule for which it was designed?

If we can use any clustering rule with any font, then there is no
reason that they should be tied together.


Still a bit confused...
                                        Owen




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]