From: "Yoshinori K. Okuji" <okuji@enbug.org>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: terminal enhancement
Date: Sun, 19 Sep 2004 16:35:19 +0200 [thread overview]
Message-ID: <200409191635.19746.okuji@enbug.org> (raw)
In-Reply-To: <87brg2ms9q.fsf@marco.marco-g.com>
On Sunday 19 September 2004 13:07, Marco Gerards wrote:
> First of all, why does the terminal has to determine the width?
Because it is dependent upon the implementation of a terminal. For
example, some Japanese characters can be shown both in one-column and
two-column. I think this problem has been discussed in a xfree86
mailing list.
Another problem is that not all Unicode characters may not be shown in a
given terminal. For example, some glyphs might be missing in a font.
Then, the font manager uses a default glyph. This glyph might use a
different width from real ones.
One way to solve this problem independently is to define standard widths
used in GRUB, and terminal drivers and the font manager follow them.
I'd like to avoid this, because I want to map some Unicode characters
to built-in glyphs in a ROM (for instance, in the PC console driver).
Another reason why I am willing to avoid this is that we need to create
our own font if any font does not follow our standard.
> Isn't that something generic and how the POSIX function wcwidth
> (which I could not find...) works?
I don't think it is very useful in reality, since Unicode does not
define how each character code is displayed.
> What I mean is that the character
> 'a' always has the same size, unless you are using some ttf-fonts.
> Do you have bigger characters in mind?
Surely. For example, look at this one:
http://yudit.org/images/yudit-2.4.8.gif
Even if you don't understand what the characters mean, you should be
able to distinguish characters.
> So basically, my question is why POSIX seems to implement it
> independent of a terminal while we need to integrate it there. I'm
> sure you are correct about this, but I want to understand this so I
> can implement the terminals for the PPC ports properly.
The SUSP v2 says that this function was removed from the final ISO C
Amendment 1. So probably they understand that this function is
meaningless.
http://www.opengroup.org/onlinepubs/007908799/xsh/wcwidth.html
When implementing a terminal, never assume (the number of bytes) == (the
number of columns) or (the number of characters) < (the number of
columns). A given character can be one-column or two-column in the
current implementation of GRUB. If we want to support Hindi, things
will be more complicated.
Okuji
next prev parent reply other threads:[~2004-09-19 14:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-18 14:32 terminal enhancement Yoshinori K. Okuji
2004-09-19 11:07 ` Marco Gerards
2004-09-19 14:35 ` Yoshinori K. Okuji [this message]
2004-09-19 14:51 ` Marco Gerards
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200409191635.19746.okuji@enbug.org \
--to=okuji@enbug.org \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.