Ilya Zakharevich <ilya(_at_)math(_dot_)ohio-state(_dot_)edu> writes:
Why would an extension want to do this? Most will not care about
encodings, since they have no way to use this info.
Tk would care. It needs to know encoding to map strings to fonts/indices.
However bitmaps are binary data.
(Tcl/Tk8.1 has gone the "everything is utf8" route - and added encoding
conversion to Tcl Channels. I suspect that "everything is utf8" is
just Tcl's "everyting is a string" re-asserting itself and will prove
to be a pain.)
Those few which *do* care will have a possibility to treat utf8 and
"narrow" SvPV's differently.
Exactly.
Note that the situation is not a tiny
bit worse than with the current nonsensical scheme, when the extension
is given an SV, and has no way to understand whether it is utf8 or narrow.
a) printing: all I/O goes via conversion [...]
Then it is as I suspected. :-(
IO is going to need to do encoding conversion in _some_ cases if all this
is to be any use. If I am displaying multi-lingual documents from
different files I need to convert iso-8859-X on input to (say) UTF8.
The inverse on output. But JPEG images etc. are not converted!
--
Nick Ing-Simmons <nik(_at_)tiuk(_dot_)ti(_dot_)com>
Via, but not speaking for: Texas Instruments Ltd.
