CJK fonts - xterm(235) - UTF-8.
Chris Jones
$ printf "abcdefgh\r\xE7\x89\xB9\xE5\x88\xA5XY\n"
.. should print:
特別XYgh¹
What happens on xterm(235) is that the second double-width character
overlays the first: the second character is shifted one and a half cell
widths to the left of where printf should have placed it, leaving part
of the 'c' and the entire 'd' visible.
Selecting the output of the printf with the mouse, or switching to
another X workspace or a linux console and back, fixes the display.
I was curious as to why this is happening and whether it may have been
addressed in more current versions of xterm.
Thanks,
CJ
¹ Not sure how that renders in your context. It may be necessary to run
the same test to see what I'm seeing.
Thomas Dickey
> $xterm-fn "-gnu-unifont-medium-r-normal-*-iso10646-1" -u8
>
> $ printf "abcdefgh\r\xE7\x89\xB9\xE5\x88\xA5XY\n"
>
> .. should print:
>
> 特別XYgh¹
>
> What happens on xterm(235) is that the second double-width character
> overlays the first: the second character is shifted one and a half cell
> widths to the left of where printf should have placed it, leaving part
> of the 'c' and the entire 'd' visible.
>
> Selecting the output of the printf with the mouse, or switching to
> another X workspace or a linux console and back, fixes the display.
>
> I was curious as to why this is happening and whether it may have been
> addressed in more current versions of xterm.
I don't recall this being reported before.
It is related to the specific font used: the same printf
applied to uxterm's normal set of fonts doesn't show the problem.
A quick look at the debugging trace shows me the basic issue.
The width of the special characters should be 2 (according to
the wcwidth function), but the font only provides a single-width
glyph. xterm is doing some adjustment for this, but it's not
done correctly in the initial drawing (a different path than that
used for repainting).
The chunk of code that's amiss was introduced in patch #229
to address a related issue.
--
Thomas E. Dickey <dic...@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net
Chris Jones
> On Sep 19, 8:11 pm, Chris Jones <cjns1...@optimum.net> wrote:
>> $xterm-fn "-gnu-unifont-medium-r-normal-*-iso10646-1" -u8
>>
>> $ printf "abcdefgh\r\xE7\x89\xB9\xE5\x88\xA5XY\n"
>>
>> .. should print:
>>
>> 特別XYgh¹
[..]
> I don't recall this being reported before.
>
> It is related to the specific font used: the same printf
> applied to uxterm's normal set of fonts doesn't show the problem.
What is the “normal set of fonts”?
I ran the test with:
xterm -fn "-Misc-Fixed-Medium-R-Normal–18-120-100-100-C-90-ISO10646-1”
-tn “xterm-256color" -u8
and indeed the two characters are correctly displayed.
Does this mean that the gnu/unifont is broken and that I should report
it to the maintainer?
FYi - I was not able to recreated this issue with rxvt-unicode.
> A quick look at the debugging trace shows me the basic issue.
> The width of the special characters should be 2 (according to
> the wcwidth function), but the font only provides a single-width
> glyph. xterm is doing some adjustment for this, but it's not
> done correctly in the initial drawing (a different path than that
> used for repainting).
>
> The chunk of code that's amiss was introduced in patch #229
> to address a related issue.
Or is this something that you feel xterm should handle more gracefully
and that you plan to address it?
The nice thing about gnu/unifont is/was that it is the only font I could
find that covers just about everything without headaches.
I have little knowledge of Eastern languages, my particular interest is
considerably more down to earth: if latin text for instance contains a
bit of CJK, RTL, or other, I’d rather see it than asterisks or question
marks.
Would you recommend specifying a wide font for xterm and point to a
different font that might (?) cover CJK?
If so, what font do you recommend?
I also tried the ttf approach, via -fa and presumably served by
fontconfig, but I must say that I wasn’t impressed by the result. The
truetype incarnation of gnu/unifont for instance appears to have been
automatically generated and what I saw was not only ugly, but barely
legible.
Another related issue appears to be RTL scripts such as Hebrew and
Arabic. Are they supported? I took a peek at the xterm FAQ but I didn’t
see anything.
I was able to display some English text RTL-wise in Vim by setting the
rightleft options, but I’m not sure this uses the underlying xterm’s
capabilities.
Thanks for your comments,
CJ
Thomas Dickey
> Does this mean that the gnu/unifont is broken and that I should report
> it to the maintainer?
Generally the fonts are unmaintained (ymmv)
> FYi - I was not able to recreated this issue with rxvt-unicode.
agree (though it's debatable whether it's doing what it "should").
It appears to be using the glyph-width (sometimes it follows the font,
and sometimes it doesn't).
> Or is this something that you feel xterm should handle more gracefully
> and that you plan to address it?
yes - at a minimum, it should fill in the second cell with a blank.
That's what I'm starting to work on at the moment.
Alternatively, it could be modified to use the font's notion of the
glyph
width rather than wcwidth. While that may seem "obvious", the problem
in following the font is that applications running in xterm don't know
what
the font is doing. So it helps to use the same or similar tables.
> Would you recommend specifying a wide font for xterm and point to a
> different font that might (?) cover CJK?
>
> If so, what font do you recommend?
That's hard - I mostly test ad hoc cases with various fonts,
but haven't found any that do good coverage, even for the
testcases I use frequently.
> I also tried the ttf approach, via -fa and presumably served by
> fontconfig, but I must say that I wasn’t impressed by the result. The
> truetype incarnation of gnu/unifont for instance appears to have been
> automatically generated and what I saw was not only ugly, but barely
> legible.
>
> Another related issue appears to be RTL scripts such as Hebrew and
> Arabic. Are they supported? I took a peek at the xterm FAQ but I didn’t
> see anything.
no - I've done nothing with RTL scripts.
> I was able to display some English text RTL-wise in Vim by setting the
> rightleft options, but I’m not sure this uses the underlying xterm’s
> capabilities.
From what I recall, vim doesn't try to use native RTL support because
the (few) implementations aren't reliable. (That may have changed).
Chris Jones
> On Sep 21, 3:22 pm, Chris Jones <cjns1...@optimum.net> wrote:
>> Does this mean that the gnu/unifont is broken and that I should report
>> it to the maintainer?
>
> Generally the fonts are unmaintained (ymmv)
What looks promising about this particular one is that it is rather well
documented - to say the least!
http://unifoundry.com/unifont.html
[..]
>> Or is this something that you feel xterm should handle more
>> gracefully and that you plan to address it?
>
> yes - at a minimum, it should fill in the second cell with a blank.
> That's what I'm starting to work on at the moment.
Thanks for the good news.
> Alternatively, it could be modified to use the font's notion of the
> glyph width rather than wcwidth. While that may seem "obvious", the
> problem in following the font is that applications running in xterm
> don't know what the font is doing. So it helps to use the same or
> similar tables.
[..]
>> Another related issue appears to be RTL scripts such as Hebrew and
>> Arabic. Are they supported? I took a peek at the xterm FAQ but I
>> didn’t see anything.
> no - I've done nothing with RTL scripts.
Until something is done in that area (?), does it mean that applications
that run such as mutt, slrn, or ELinks will not be able to render these
scripts?
Or is it something that you think falls outside the scope of what a
terminal should provide?
>> I was able to display some English text RTL-wise in Vim by setting
>> the rightleft options, but I’m not sure this uses the underlying
>> xterm’s capabilities.
>
> From what I recall, vim doesn't try to use native RTL support because
> the (few) implementations aren't reliable. (That may have changed).
The situation is probably still the same - :set rightleft on a linux
console and gets the same result - unless the linux console supports
such scripts, which I doubt.
CJ
Chris Jones
I was taking a look at the attached file and basically, the display is
totally garbled. All the double-width characters are basically shifted
to the left, which results in something illegible. I started
rxvt-unicode in another window, switched back to the xterm and the
display was fixed. So this appears to affect all double-width character.
I was wondering if you had made any progress with this issued?
Thanks,
CJ
# grub 软件包的简体中文翻译。
# Copyright (C) 2009 Free Software Foundation, Inc.
# This file is distributed under the same license as the grub package.
# Aron Xu <happya...@gmail.com>, 2009.
# Zhengyu Ji <zhen...@gmail.com>, 2009.
# Xin Ye <alye...@gmail.com>, 2009.
msgid ""
msgstr ""
"Project-Id-Version: grub 1.97+20091122\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2009-11-22 11:48+0100\n"
"PO-Revision-Date: 2009-12-17 22:48+0800\n"
"Last-Translator: Xin Ye <alye...@gmail.com>\n"
"Language-Team: Chinese (simplified) <i18...@googlegroups.com>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: util/i386/pc/grub-mkimage.c:65
msgid "the core image is too small"
msgstr "核心镜像太小"
#: util/i386/pc/grub-mkimage.c:77
msgid "cannot compress the kernel image"
msgstr "无法压缩内核镜像"
#: util/i386/pc/grub-mkimage.c:138
msgid "prefix is too long"
msgstr "所指定的目录太长"
#: util/i386/pc/grub-mkimage.c:206
msgid "the core image is too big"
msgstr "核心镜像太大"
#: util/i386/pc/grub-mkimage.c:211
#, c-format
msgid "diskboot.img size must be %u bytes"
msgstr "diskboot.img 的大小必须为 %u 字节"
#: util/i386/pc/grub-mkimage.c:284
#, c-format
msgid "Core image is too big (%p > %p)\n"
msgstr "核心镜像太大(%p > %p)\n"
[...]
Chris Jones
> I was wondering if you had made any progress with this issued?
s/issued/issue/
Or is the font the culprit, and should I take it up with its maintainer?
Thanks,
CJ
Thomas Dickey
> On 17 Dec 2009 18:53:45 GMT, Chris Jones <cjns1...@optimum.net> wrote:
>
> > I was wondering if you had made any progress with this issued?
>
> s/issued/issue/
>
> Or is the font the culprit, and should I take it up with its maintainer?
I added a new feature in #250 -
http://invisible-island.net/xterm/xterm.log.html#xterm_250
which addresses this. (It replaces the logic for handling
proportional fonts,
and is enabled by default - so it should "just work" with this fonts).
Chris Jones
> On Dec 17, 4:52 pm, Chris Jones <cjns1...@optimum.net> wrote:
>> On 17 Dec 2009 18:53:45 GMT, Chris Jones <cjns1...@optimum.net> wrote:
>>
>> > I was wondering if you had made any progress with this issued?
>>
>> s/issued/issue/
>>
>> Or is the font the culprit, and should I take it up with its maintainer?
>
> I added a new feature in #250 -
>
> http://invisible-island.net/xterm/xterm.log.html#xterm_250
> which addresses this. (It replaces the logic for handling
> proportional fonts, and is enabled by default - so it should "just
> work" with this fonts).
Indeed.
I just tested with xterm(253) and it appears to render GNU/unifont
correctly out of the box.
Thanks,
CJ