Re: Call for I18N testers gnome-terminal/zvt + I18N patches

[HideToshi Tajima <hidetoshi tajima sun com>]

Hi Pablo,

Pablo Saratxaga wrote:

>Korean doesn't work.
>
>I wonder if that is because "KSC5601.1987-0" is missing from the
>list in xlfd_from_pango_font_description() from the libztv-18n sources.
>
>I'll add it and rebuild to see.
>
>... yes!
>
>Same problem for Thai in tis-620 mode, iso-8859-13 and cp1251, which are
>encodings still commonly used.
>
>So I propose adding:
>
>	"ksc5601.1987-0",
>	"tis620-0",
>	"iso8859-13",
>	"microsoft-cp1251"
>
>to the list.
>
Thanks. I'll either add them to the list or get a list of required
charsets of the
current locale, doing:

XOM om = XOpenOM(display, NULL, NULL, NULL);
if (om) {
XGetOMValues(om,
XNRequiredCharSet, &cslist,
NULL);
}

and pass this cslist.charset_list (after converting to the lower case)
to the pango function.

>
>Another problem is that when the width of a given char is "filled" to make
>a column, the "filled" portion isn't done using the background color but
>black. it is very ugly if background is not black.
>just go to edit->profile->colors and put black on white for example.
>The horizontal filling is wrong in UTF-8 mode.
>
I could reproduce this problem using "Green on black" on my Solaris box.

And this and other horizontal "filling" problems may be because I'm
getting a per-char width from
ascii digit characters. When the width of non-digit character is not the
same as that of
the digit character, there should cause these weird to be left - maybe
this is the case in ro_koi8,
I suspect. I could see this in Chinese EUC locale, when choosing "sans
13" for font.

I did not do anything for vertical filling, but now I understand how
weird it looks.

>
>also; there should be a similar filling mode for vertical size, as sometimes,
>in particular for CJK locales, the ascii font may be shorter in vertical size;
>when launching "mc" under Chinese for example half of the screen is blank
>due to that I suppose.
>here too, the vertical filling should follow the background color
>(and the background color can be redefined by some command sent to the
>terminal, eg with "mc" the background is blue in most of the screen, and
>amgenta (?) for menus, etc.)
>
>it would be nice too if the horizontal filling could follow the character
>column width; for example for Thai that uses zero width chars; I attach
>you a picture (it also shows the "black color filling" problem and the
>vertical alignment problem)
>
>gnome-terminal-th.png
>=====================
>
>uses "th" locale in TIS-620 encoding. -microsoft-tahoma-*-tis620-0
>as font (defined in pangox.aliases)
>
>The date of the ".netscape" file has the first colunm composed of two
>glyphs stacked; it is properly done, but then an empty column follows, instead
>of having the dot just after the first one, like in the other dates.
>
>note also how the empty filled column is black while it should be blue.
>
>in the higlited line (first at left, for "..") you can see for the date
>in Thai that the thai chars are aligned one pixel higher than the ascii (or
>maybe one pixel lower); the baseline is the same, but the upper and lower
>limits don't seem to be the same.
>ideally, the terminal should use a virtual "character box" which upepr bound
>is the one of the higher font, and the lower the one of the lower font;
>and vertically fill chars of fonts that are shorter.
>
>
>gnome-terminal-zh.png
>=====================
>
>zh_CN.GB2312 locale.
>
>Here you can see how the vertical filling problem can make the
>screen unreadable.
>Note that the chinese font is much bigger than the ascii one, so the problem
>has here more consequences.
>
>gnome-terminal-zh2.png
>======================
>
>the same as previous, after quitting "mc".
>you can see how the vertical filling problem leaves plenty of dirty lines.
>(that is a very old problem, that was present already in Gnome1; but as
>there was no real fontset support it was not that much visible (the dirty
>lines were only one pixel height) 
>
>gnome-terminal-ru_utf8.png
>==========================
>
>This shows how filling columns are incorrectly added in utf-8 mode.
>
>
>gnome-terminal-ru_koi8.png
>==========================
>
>Russian Cyrillic in 8bit mode is horrible.
>could it be because cyrillic letters are also present in CJK fonts
>and that width of cyrillic chars is wrongly guessed as double width ?
>
>gnome-terminal-uk_koi8u.png
>===========================
>
>Ukrainian (using koi8-u) is ok.
>You can see how the cyrillic output of "cal" should look like, the utf-8
>mode should look the same.
>maybe the difference with russian koi8-r is becase koi8-u needs letters
>not covered by the cyrillic portion in CJK encodings ? 
>
>
>
>
>That problems aside, the i18n patches work very well, it is a very good work,
>and still useful for a lot of people.
>The unpatched gnome-terminal for Gnome2 was in fact very deficient, as
>even the keyboard compose sequences didn't worked; which makes it impossible
>to write in most european languages.
>
>Thank you very much.
>
Many thanks for saying so!

Regards,
Toshi