All of lore.kernel.org
 help / color / mirror / Atom feed
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



  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.