Date:	Thu, 3 May 2007 02:17:34 -0400
From:	"Albert Cahalan" <acahalan@...il.com>
To:	"Jan Engelhardt" <jengelh@...ux01.gwdg.de>
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 5/2/07, Jan Engelhardt <jengelh@...ux01.gwdg.de> wrote:
> On May 1 2007 11:49, Albert Cahalan wrote:
> >>
> >> Well, I think the consensus is that anything beyond that should be done
> >> in userspace; the main such console daemon was Kon2 last I checked.
> >
> > Font size is not a sane place to draw the line. Features are.
> > The levels of support go something like this:
> >
> > 0. 7-bit ASCII
> > 1. Simple direct-to-font VGA characters.
> > 2. UTF-8 and large fonts, but no compositing or wide characters.
> > 3. Simple compositing and double-wide characters. (like xterm)
> > 4. Right-to-left. (like Kermit95)
> > 5. Complex shaping, glyph substitution, and vertical text.
> >
> > Without large fonts, UTF-8 is 90% pointless bloat.
>
> > Personally I don't even need #1, but I think anything less than #3 is
> > really rude toward people outside of Europe+Americas. I especially hate
> > to hear Europeans argue against this when they have 100% precomposed
> > characters for themselves and appear to have played a role (via ISO votes)
> > in denying stuff like the mere 12 precomposed characters needed to use
> > the Yoruba language with simple renderers.

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,
and kind of icky on some of the really big desktop displays
when in native (framebuffer) mode. 200 dpi may be in your future.
Even the 32-pixel height limit is starting to be a problem.

> 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.

> 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.

> 5. Vertical text - who else supports this please? Webpages in languages
>    that want to do TTB(top-to-bottom) scripting use html workarounds -
>    probably because TTB availability it's not even guaranteed in a
>    webbrowser.

I hope you didn't think I was suggesting this. It's quite absurd.
"Complex shaping, glyph substitution, and vertical text." was the
full item listed. Vertical is the least troublesome of those issues,
and as far as I know has never been implemented.

> 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.

I think one could make a reasonable argument that all the
internationalization is bloat, and that thus UTF-8 should go.
Given that we do support UTF-8 though, allowing a font with
more than 256 characters (with foreground intensity control)
is obviously sensible.
-
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/

Powered by blists - more mailing lists