linux-kernel - Re: console font limits

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.61.0705030902430.18504@yvahk01.tjqt.qr>
Date:	Thu, 3 May 2007 09:12:29 +0200 (MEST)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	Albert Cahalan <acahalan@...il.com>
cc:	"H. Peter Anvin" <hpa@...or.com>,
	"Antonino A. Daplas" <adaplas@...il.com>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	linux-kernel <linux-kernel@...r.kernel.org>, aeb@....nl
Subject: Re: console font limits


On May 3 2007 02:17, Albert Cahalan wrote:
> Note: I never suggested going beyond #3.
>
>> 0. yes we want that
>> 
>> 1. can't tell
>> 
>> 2. utf8 yes, many text files are in that encoding.
>> large fonts - can't tell, I am fine with the regular vga
>> font infrastructure (8x16, 8x8)
>
> Those sizes are unreadable on the 200 dpi OLPC XO screen,

Hm that should have read, for you:
I don't object implementing support for larger sizes.
(But I wonder how that should work without FB/CVIDIX/SVGA/VESA extensions.)

Note that I was assuming that no FB is used:

>> 3. compositing - no, don't need that,
>> wide characters - does not even work in vga. just display a '??'
>> and everything is fine.
>
> It's been shown to be workable, and it allows support for
> some additional languages.

What benefits does it actually bring? Your standard VGA knows 256/512
glyphs, and trying to display combined characters needs a
precomposed glyph.

>> 4. I do not really think this has a future on VC.
>> You would also 'need' kerning and that serif combiner thing (complex
>> shaping?) for Arabic. At best, Arabic would look as horrible on VC
>> as it does in xterm today (no RTL, no serif combiner)
>
> I agree. Hebrew is more doable, but probably not worth the effort
> because of the rarity and because of the general lack of support
> in text mode apps for such odd behavior. Very few emulators
> support this; kermit95 is one of the few.

For everything beyond Latin, fbiterm should work a lot better.

>> In short, the current console is very much OK.
>
> I wouldn't say that. We suffer the bloat of all this UTF-8 stuff
> without being able to load a decent-sized font to go with it.
> We're stuck at 256 characters really, with the very lame option
> of trading foreground color intensity control for an extra 256.

Making VC use a 16x32 font may be possible, but then you will also
need 4 glyph positions in a 4096 byte font to create a character.
Or the hardware needs to support 'non-standard' (that would be
8x8,12,14,16) fonts.


Jan
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/