Re: (unknown)

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

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

>> Loadable fonts worked just fine on real vt220.  I still have
>> collection of koi8 fonts for various fonts sizes somewhere (real dec
>> vt220, tatungs that emulated vt220 but had taller glyphs, etc).
> 
> Yes a real vt220... The wscons_vt100 emulation doesn't claim vt220
> compatibility, and this is for a reason.  There is just too much
> graphics stuff involved, which doesn't map to the wsdisplay
> abstraction, and can't be emulated on eg standard PC character cell
> displays.

I'm not saying we should support DECDLD command.  The specific
mechanism used to make a loadable font available to the terminal is
not important (ROM fonts, DECDLD sequence for real vt220 or wsfont
with either compiled-in or dynamically loaded fonts).

My point is that once the font is available, you can select it and use
it and the terminal doesn't care what the glyphs are.  It just uses
whatever was selected to GR to display the 8-bit chars.


>> wsemul doesn't provide the G0..G3 distinction

Sorry, I was not clear.  I meant emulops and the fact that it has
single mapchar method.  More on that below.


> It does, as much as the vt100 did. One can map them to the various
> DEC defined charsets, including the "national character replacement"
> or so things.  It is just that no eastern languages were on DEC's
> radar at that time.

NCRs are 7bit national ASCII replacements which I hope everybody has
happily forgotten about couple of decades ago. :)

Loadable vt220 fonts made national 8-bit charset support completely
solved - you just loaded what you needed and didn't have to depend on
fonts being present in the terminal ROM (the national charset had to
be compatible with C0/GL/C1/GR structure, so you wouldn't be able to
use e.g. DOS and Windows "codepage" charsets that have parts of
national chars encoded in C1 zone).

Note that wsemul_vt100 does support G2 and G3 which, iirc, were not
supported by the real vt100 and appeared only in later models.  This
is why I feel it's appropriate to drag vt220 into this discussion,
even though the emulation is named after vt100. :)


>> While the idea of the char mapping as used by vt100 emul is nice, the
>> actual implementation is quite impractical, and evidence of 15+ years
>> without properly localized console
> 
> The vt100 emul just tries to emulate a vt100 as good as practical.
> (My initial motivation was to telnet into a DEC box or an embedded
> system which doesn't know much more than a VT100. This works well,
> including bus analyzers with waveform displays made of DEC graphics
> characters.)
>
> As said, if you want localization beyond what the original offered,
> add another emulation to wscons.

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?

As Eddie Izzard put it in one of his brilliant sketches

- Cake or death?
- Cake please.

:)


Actually, the two scenarios are not even conflicting (esp. given that
different wsscreens can use different fonts)!  As I mentioned in my
previous mail (on the "lie to the kernel the font is ISO" topic), the
issue is not DEC $obscure charsets, the issue is that wsmul_vt100
effectively hardcodes the assumption that your "normal" GR is latin1.

So, we want to be able to display supplemental graphics charset.  It's
a fixed, known in advance charset, so we use unicode code points to
name them and do:

    for (i = 0; i < 128; i++)
            (*edp->emulops->mapchar)(edp->emulcookie, decspcgr2uni[i],
                                     &edp->decgraphtab[i]);

The the same for DEC tech:

    for (i = 0; i < 128; i++)
            (*edp->emulops->mapchar)(edp->emulcookie, dectech2uni[i],
                                     &edp->dectechtab[i]);

No problems so far.  But then

    for (i = 0; i < 128; i++)
            (*edp->emulops->mapchar)(edp->emulcookie, 128 + i,
                                     &edp->isolatin1tab[i]);

and, importantly, elsewhere

   edp->chartab_G[2] = edp->isolatin1tab;
   edp->chartab_G[3] = edp->isolatin1tab;

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

In reality, here you don't want to ask emulops how to map latin1, you
want to ask how to map 160..255 part of the national 8-bit charset
whatever it is (e.g. whatever font is loaded into G2 or G3 on your
vt220).  For most raster wsdisplays that gonna be a trivial 1:1
mapping since you would use "naturally-encoded" fonts.  It gonna be
non-trivial mapping for text-mode vga where you want to use DOS
codepage fonts (to get smooth line-drawing) but still work in ISO
8859-* encodings (or koi8).

This is what I meant by my comment that emulops don't let this to be
expressed naturally.  You need to be able to map known DEC chars on
one hand and unknown 160..255 range on the other.

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