Subject: Re: wsfont encoding
To: None <email@example.com>
From: Marcus Comstedt <firstname.lastname@example.org>
Date: 02/03/2001 01:21:45
>>>>> "Noriyuki" == Noriyuki Soda <email@example.com> writes:
Noriyuki> Probably you don't have to worry about this.
Noriyuki> The mapping table in (B) converts a font_encoding to another
Noriyuki> font_encoding. In other words, that is an attribute of font.
Noriyuki> The mapping table will be automatically shared between codesets
Noriyuki> which were broken to same font_encoding.
I'm still not convinced. What guarantees that (B) has a conversion
table/routine for any combination of input codeset and font
combination which I have enabled on my system?
>> 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.
Noriyuki> Codeset independent implementation is what X11 does.
Noriyuki> And we know that works.
X11 is a good example of something that doesn't solve the problem at
hand; If you have codeset/codepoint pair such as (iso_8559_4, 225) but
no iso_8859_4 font, X11 will offer you no help. X11 can not
substitute this for (iso_8851_1, 225) (which is the same glyph) for
you. So if there is something that we know "works" from looking at
X11, it's ignoring the problem.
Noriyuki> As probably you already understand, wscons driver will handle
Noriyuki> multiple font_encodings. Usually, the font_encodings are the
Noriyuki> real encodings in fonts.
For Japanese, this is not a problem. Either you have JISX0208, or you
don't. But for latin scripts, there are tons of different but
overlapping character encodings. So while the case that the
font_encoding and the real encoding is the same should be fairly
common, we must not disregard the case where they are not.
Noriyuki> But about (B), we will have virtual font_encoding.
Noriyuki> This can be done by adding an option to wsfontload. That adds
Noriyuki> mapping table which converts a (newly defined) virtual
Noriyuki> font_encoding to another (already existing) font_encoding.
Noriyuki> Thus, console driver will behave just like there is real
Noriyuki> font with such virtual font_encoding.
Again, it seems that there has to be one such table for each
combination of input codeset and font encoding (O(m*n)) and that you
have to add them manually. Yet you assure me that this is not the
case. How, then?