Subject: Re: wsfont encoding
To: None <email@example.com>
From: Noriyuki Soda <firstname.lastname@example.org>
Date: 02/03/2001 09:04:29
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.