>>>>> "David" == David Brownlee <abs@netbsd.org> writes:

  David> 	How feasible would it be to define a mapping to unicode (*) for
  David> 	all font/charsets, then use that to define a charset->font table
  David> 	for each font and charset when loaded into the kernel.

RFC1345 contains a pretty comprehensive set of such tables, so the
data mining should pose no problem.  Creating charset->font tables
from those tables is easy too.  Memory would still be an issue if you
make a cross product like this of course.  But maybe if the number of
font encodings is kept low (only ISO-8859-1 fonts in the dist as has
been suggested, rather than IBM and whatnot) then you probably won't
have more than three or four font encodings defined in the general
case, so it might not be so bad.  You'll want to be able to have many
input codesets enabled though, such as ISO-8859-* for European
systems.


  David> 	Cases such as EUC-JP to JIS X0208 could be handled with a NULL
  David> 	table.

This is actually not a case at all.  EUC is just a transport coding,
the actual codeset used in EUC-JP is already JISX0208.  Decoding of
EUC, ISO2022, UTF-8 etc should be handled algorithmically by an
earlier stage, before we have the (font_encoding, codepoint) pair.

Btw, I _did_ manage to think of a case where you _do_ want to make
remapping from <something else> to JISX0208:  VT100 has a box drawing
charset.  JISX0208 has box drawing characters.  So probably you want
to do remapping there.  Greek and Cyrillian(sp?) codesets might be an
issue to, as these are also present as glyphs in JISX0208, but that
might be less useful in practice.


  // Marcus