From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.33) id 1C92t2-0002Fw-7H for mharc-grub-devel@gnu.org; Sun, 19 Sep 2004 10:41:56 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C92t0-0002Fr-RS for grub-devel@gnu.org; Sun, 19 Sep 2004 10:41:54 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C92sy-0002Ff-TG for grub-devel@gnu.org; Sun, 19 Sep 2004 10:41:54 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C92sy-0002FV-PH for grub-devel@gnu.org; Sun, 19 Sep 2004 10:41:52 -0400 Received: from [212.43.237.68] (helo=kotoba.storever.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1C92mf-0004dZ-PG for grub-devel@gnu.org; Sun, 19 Sep 2004 10:35:22 -0400 Received: from localhost (localhost [127.0.0.1]) by kotoba.storever.com (Postfix) with ESMTP id 721A3F54FF44 for ; Sun, 19 Sep 2004 16:35:19 +0200 (CEST) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Sun, 19 Sep 2004 16:35:19 +0200 User-Agent: KMail/1.6.1 References: <200409181632.21893.okuji@enbug.org> <87brg2ms9q.fsf@marco.marco-g.com> In-Reply-To: <87brg2ms9q.fsf@marco.marco-g.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409191635.19746.okuji@enbug.org> Subject: Re: terminal enhancement X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Sep 2004 14:41:55 -0000 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