On Thu, Jun 17, 1999 at 09:20:16AM +0100, Nick Ing-Simmons wrote:
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.
I think you realize that this can only support my position: Tk should
be able to determine what the given SV contains, *and behave
accordingly*.
Note that the "according" behaviour when obtaining a bitmap given by a
string with chars > 255 is failure.
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!
Moreover, all that not marking "wide" strings as such does is it moves
the responsibility of bookkeeping to the user side.
Having Perl do bookkeeping *may* have some impact on speed, but my
guesstimates are that it will be circa 1% or below. Most OPs do not
care whether their arguments are narrow or wide, and for those which
care it is only a check of a bit of SvFLAGS to jump to a proper section.
Ilya
