>>>>> "Noriyuki" == Noriyuki Soda <soda@sra.co.jp> 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?


  // Marcus