Re: FreeBSD i18n fonts for wscons

[uwe%stderr.spb.ru@localhost (Valeriy E. Ushakov)]

Matthias Drochner <M.Drochner%fz-juelich.de@localhost> wrote:

>> wsemul_vt100 is our primary emulation.  Do we want to optimize our
>> primary emulation for the scenario where it is used to display output
>> from programs/devices that use ASCII (or NCR) plus DEC technical and
>> DEC supplemental graphics charsets or do we want to optimize it for
>> people who use charsets other than latin1 and use termcap/curses apps?
> 
> It is the primary emulation because it is the most powerful atm,
> but that's not set in stone. It is easy to add another one (it has
> taken me one or two hours to derive "ucons" from "vt100"), and the
> rest is some changes to etc/wscons.conf.
> So I'd prefer to leave "vt100" as an emulation which is conservative
> in its features, but works if one logs into a legacy/embedded/3rtparty
> system from it, no matter which fonts are loaded locally.
> For modern uses, there are plenty of names available, just not "vt100".

So if we were to clone wsemul_vt100 under a different name and fix
G2/G3 handling - how is that different from fixing it directly in
wsemul_vt100 without cloning it?  There's still the mapping issue to
address regardless of whether we want to fix it in the old code or in
the cloned code.


>> and given the unicode semantic of the second argument to mapchar (as
>> used for fun and profit by the two DEC charset above) *this is why*
>> people have to lie about their national fonts being "ISO".
> 
> Well, in an ideal world it shouldn't be necessary to lie...
> I think I understood what you mean. My idea is that the encoding
> between userland and tty is completely independent of any downloaded
> font. The visible result is always similar, to a varying degree of
> perfection. Which means that characters are replaced by some replacement
> sign if the fonts available to the display can't represent it, or some
> less perfect approximation.
>
> In any case, it is the wsdisplay emulation which defines which
> glyph is to be displayed in which input.

But this is not exactly how a real vt does it.  I tried to explain
that in my previous email.  Do I need to make a 3rd attempt at that?

For ASCII, NCRs, DEC technical and other DEC charsets a real terminal
would use a ROM font.  In that case terminal "knows" what it displays
by construction.  In wsemul case we need to build an equivalent of
that ROM (so that wsemul has the same "knowledge") by asking the
wsdisplay (via emulops): "Hey, what should I pass to putchar to draw a
lower left corner line-drawing glyph?".

But when a loadable font is used you absolutely don't want to know
anything about "encoding" of data coming to the tty from the system.
That's how real vt220 and later version were.  You load something, you
designate it into, say, G2, then you map G2 into GR.  Then you just
send bytes to the terminal and it displays them obediently.

This is why people are forced to use "ISO" currently - because due to
unicode and latin1 numerology they will get from the current code the
"leave me alone" 1:1 mapping for their 160-255 range.

You really want wsemul to ask wsdisplay a different kind of quesion
here, a companion of mapchar with the semantic of the second "int c"
argument changed.  For most 8-bit fonts the mapping gonna be 1:1, but
a non-trivial mapping gonna be needed for text-mode vga dos codepages
fonts used to display some other charset.  We can clone wsemul_vt100,
but this mapping problem - how to properly express the kind of quesion
like the above - is *not* in wsemul.

Speaking about legacy systems, if you get the loadable fonts right,
you not just solve the national 8-bit charset problem, you actually
*improve* support for legacy systems, because then you can do stuff
like this (just what are unicode codepoints for some of the glyphs
used there?):

    http://vt100.net/dec/vt320/snap-animacp-large.png
    http://vt100.net/dec/vt320/soft_characters

using wscons on your jornada 620lx (that is too underpowered to run
X11) that just happened to be in your pocket when you need it.  (perl
script to convert donloadable vt font to a wsfont is left as an
exercise to the user).

Continuing with the legacy theme, let's say for the sake of argument
that I want to use a charset like CSX+ (for sanskrit transliteration).
Unicode mapping for some of the codepoints may contain 4 unicode
characters.  Somehow I seriously doubt we gonna have *that* level of
unicode support in our kernel any time soon.  Yet it's *trivial* with
the proper semantic - you can just make a font that matches your
custom esoteric encoding, load it and it just works.


I've been trying to start a technical discussion on this topic because
I belive that I'm correctly outlining the way real terminals work, the
way wsemul_vt100 is lacking in this area and that fixing this problem
gonna improve support for both legacy systems and for users of
national 8-bit charsets.

I'm NOT interested in "write a different wsemul" answer - b/c it's not
even an answer in the first place, as it ignores the mapping problem.

wscons is not the most easy to read code and I haven't touched it in
years, so it's quite possible that I misunderstand some of the design
decisions; I haven't worked with a real terminal in more than a decade
so I may misremember/misinterpret some details.  I'd really appreciate
any on-topic replies.


SY, Uwe
-- 
uwe%stderr.spb.ru@localhost                       |       Zu Grunde kommen
http://snark.ptc.spbu.ru/~uwe/          |       Ist zu Grunde gehen