Noriyuki> Just add the conversion table.

> This is what I was worried about, that each conversion table would
> have to be added manually.  That's what I asked about and which you
> then replied with "no".  But if conversion tables have to be added for
> each combination of input codeset and font encoding, then you _will_
> have to add 7 tables if you have 7 font encodings enabled and want a
> new input encoding you add to work with all of them.  To be required
> to manually add 7 tables just to get one more input codeset sounds
> unmanageble to me.

Probably you don't have to worry about this.
The mapping table in (B) converts a font_encoding to another 
font_encoding. In other words, that is an attribute of font.
The mapping table will be automatically shared between codesets
which were broken to same font_encoding.

Noriyuki> As I already said, all thing which can be supported by Unicode based
Noriyuki> interface can be supported by codeset independent interface.
Noriyuki> Because the latter is more general.

> General often ends up meaning half-implemented, in my experience.
> That's why I'm a little sceptical.  A Turing Machine is general as
> hell, but it's not much use in everyday life, as it lacks the bits
> that gets it anywhere close to real problems.  Therefore, less general
> devices are used to perform actual work.

Codeset independent implementation is what X11 does.
And we know that works.

> We have mapchar before my changes, which really didn't do anything,
> and thus didn't solve (B).  Then we have mapchar after my changes,
> which solves (B) if the first font_encoding is Unicode.  You have
> still to show how generalizing this into allowing any font_encoding
> will allow implementation to be "easy" while still not putting an
> unreasonable burden on the user to configure the system.

As probably you already understand, wscons driver will handle
multiple font_encodings. Usually, the font_encodings are the
real encodings in fonts.

But about (B), we will have virtual font_encoding.
This can be done by adding an option to wsfontload. That adds 
mapping table which converts a (newly defined) virtual 
font_encoding to another (already existing) font_encoding.
Thus, console driver will behave just like there is real
font with such virtual font_encoding.
--
soda