Re: Thai/Devanagari in GNOME Terminal

[Chookij Vanatham <chookij vanatham eng sun com>]

Ralph, Robert,

] 
] Chookij, please correct me, but here's what I understood about
] compensation:
] 
] These Thai terminals have two character widths, one and zero. Zero-width
] characters (like vowels and tonemarks) combine with the previous cell,
] modifying the glyph there displayed.
I think yes but let me put more detail to prevent other mis-interpretation.
The width of vowel/tonemark glyphs will be zero. Tty-based applications
will not care about it. They know only Thai character set and deal with
Thai character set and still assumming one character is one cursor position
as is conventional. The terminal emulator itself will take care how to
put the right cursor on the screen (x,y position).


] Whenever two spaces are sent in a
] row, the terminal automagically advances the cursor to the position it
] would have occupied if there were no combining characters. That way
] applications can calculate line lengths and appropriate cursor positions
] assuming one character is one cursor position as is conventional, and
] generate correct results 80% of the time.
yes. I think, terminal would need to redisplay the whole line as long as
that line has been changed and recalculate how many spaces those need to
be inserted after trigger string. I guess that terminal doesn't need to
check if there are two spaces sent by escape sequence.
Simply, it's the piece of work on the display side of terminal.

] Additionally, applications can
] trigger the compensation behavior directly by sending a special character
] (should be an escape sequence?) to take care of the remaining 20% of the
] cases.
As long as terminal itself redisplay the line based on trigger string
and compensate character correctly, tty-based application doesn't know
about this but if those tty-based applications know about this feature,
tty-based applications can be designed to expect to use trigger string
and compensation character to help them to display as they want.

Trigger string and compensation can be different for various tty-based appls
and should be able to be changed/configurable by any parties.

] 
] For example, consider the following table. Forgive the english--I'm not
] familiar with thai script.
] 
] -1-    -2-
] brown  fox
] gray   cat
] yellow partridge
] 
] If we imagine writing this with zero-width vowels we get:
] 
] -1-    -2-
] brwn  fx
] gry   ct
] yllw prtrdg
] 
] The columns no longer align. If we apply the two-space compensation
] trigger:
] 
] -1-    -2-
] brwn   fx
] gry    ct
] yllow prtrdg
] 
Yes, it's correct.

] Except for the case where only a single space separates the columns, the
] spacing is correct.
Then, the tty-based applications should have 2 spaces between the data
of these 2 columns and they should be already done that because, even,
in english, you still need 2 spaces between columns to have them aligned,
right ?


Hi robert,
] This is highly icky.  The correct solution is to honour wcwidth() and
] wcswidth().
Well. As we know, in order to know if those vowels/tonemarks would have
the width zero or not, we need to check the previous character. wcwidth()
and wcswidth() does accept only one character as the argument. This's not
enough to say if those vowels/tonemarks should be displayed with zero width
glyph or not. Just like to point out that the same vowel/tonemark can be
displayed either zero-width or non-zero-width based on the type of previous
characters, here is sample.

	Sequence 1:	C1 + V1
	Sequence 2:	C2 + V1
	
	V1 of sequence 1 can be displayed as Zero width
	V1 of sequence 2 can be displayed as Non-Zero width
	
	How would wcwidth() and wcswidth() be able to help ?
	
Chookij V.