RdB> Well, Juliusz it's probably "just" a "little" change to luit so
RdB> it can be anti-luit too. :-)
It's trivial to make work. But it won't be efficient without some
changes to the data structures used. (That's why the `-c' flag to
luit doesn't implement reverse conversion.)
While luit does implement Unicode->ISO 2022 conversion, the
functionality is designed for keyboard input only. The implementation
therefore is as simple as probing each of the available mappings in
turn.
You might argue that this should be fast enough for your needs, but as
I've gone to quite a bit of trouble to make luit efficient, I'm not
very keen on making it benchmark-unfriendly. (Luit in the direct
direction is I/O bound on my machine; in other words, I couldn't
measure a difference in speed between ``luit -c'' and ``cat''.)
An efficient implementation would consist in keeping a lazily
maintained table of mappings from codepoints to ISO 2022 charsets,
probably represented as a lazily unrolled tree. How many pints is
such functionality worth to you?
Juliusz
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
