Re: Adding tis620.2533-0 into Thai Pango engine
- From: Chookij Vanatham <chookij vanatham eng sun com>
- To: thep links nectec or th
- Cc: gtk-i18n-list gnome org, otaylor redhat com
- Subject: Re: Adding tis620.2533-0 into Thai Pango engine
- Date: Wed, 25 Oct 2000 13:18:43 -0700 (PDT)
Hi K.Theppitak,
I'm so glad to hear that Thai folks overthere are involving in these as well.
]
] According to our experience, there are three different practices of Thai
] fonts for rendering :
]
] 1. Plain tis620 : combining characters are placed at the safe positions to
] prevent collapsion. There are two practices of this kind :
] - negative-offset-zero-width diacritics (this makes the fonts apply to
] many applications, such as Netscape, which support Western fonts
] without knowing they are rendering Thai fonts)
] - real monospace fonts (used in mule/emacs; this requires the
] applications to combine characters into cells)
]
] 2. MacThai extension : an extended tis620 code set, by using codes in the
] range 0x80-0x9f and in some free slots to keep the prepositioned
] combining characters. This needs a shaping algorithm to produce
] elegant rendering.
]
] 3. WindowsThai extension : similar to MacThai extension, but used in
] Windows Thai Editions.
]
] The last two code sets are mapped to their own private area of Unicode and
] cannot be used together.
]
] So, we are now discussing about a convention on the encoding field on XLFD
] to distinguish the three code sets :-
]
] -tis620-0 for plain tis620
] -tis620-1 for MacThai extension
] -tis620-2 for WindowsThai extension
]
] Note that the years in the registry field are omitted, because tis620.2529
] and tis620.2533 do not differ in content. Both can be referred to as
] tis620 without confusion.
]
] However, Mr Chookij, could you please describe how Wtt2.0 is implemented
] in Solaris,
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.
There is no Wtt2.0 input checking implemented in Solaris.
] and which category the Thai fonts in Solaris could fall in?
] Or do we need a new category?
We use exact same font from Monotype which is used in Thai MS window.
Then, I would say it's WindowsThai extension.
But, we don't think that using U+F71B, which is the BLACK BOX, is the good
way to indicate the invalid sequence. So, we change this U+F71B glyph
from BLACK BOX which is zero-width glyph to BLANK which is non-zero width
glyph.
Again, with the SAME LOGIC to check invalid sequence, no matter what U+F71B
is going to look like, it will be always able to display those invalid
sequence of Thai characters as their own display cells. This is a lot better
to users not only Thai users but non-thai users.
]
] Please let me know your opinion on this categorization as well.
] Thank you.
I think if Thai industry can control these as the nation standard, it would
help us to have more software workable for Thai easier. I agree for this
categories defined. What ever name is going to be, it doesn't matter.
Regarding Pango, as I posted about adding tis620.2533-0 in Thai pango engine
before, I would like to point out that, even we come up with these categories,
there is the case where even different platforms use the same tis620-2,
the cell clustering rule can be different. That's why Pango shaper engine
shoule be able to distinquish these in order to pick up the proper/right
cell clustering rule to use for shaping.
Ex: In Thai MS window and Thai Solaris, even they are using the same fonts
which has tis620-2 but the clustering for cell is different.
]
] > ] Another possibilty, if we can identify some particular way of
] > ] doing it (perhaps the Solaris way), as definitely the _right_
] > ] way to do it, is just to standardize on that, and require the
] > ] fonts work in that fashion. This would have to be done in
] > ] coordination with the Thai Linux/open source community, of
] > ] course.
] > Well!!! I think this choice is a bit harder and don't know how long
] > it will take.
]
] It shouldn't be long if it is accepted here. :-)
] Another developer contributing to Qt is also in our local discussion list.
] So, the convention could be applied at both places consistently.
This is great.
Chookij V.
]
] Regards,
] -Thep.
] ____________________________________________________________________
] Theppitak Karoonboonyanan
] Software and Language Engineering Laboratory, NECTEC
] http://www.links.nectec.or.th/~thep/ mailto:theppitak nectec or th
]
]
] _______________________________________________
] gtk-i18n-list mailing list
] gtk-i18n-list gnome org
] http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]