Ilya Zakharevich <ilya(_at_)math(_dot_)ohio-state(_dot_)edu> writes:
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*.
That was exactly what I was trying to do - support your position.
Sorry if fact that I replied to _your_ message made that less obvious.
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.
Which is _only_ place that knows. Consider a JPEG image embeded in
say a XML page of text in an Indian script. Mostly UTF8 but between
these tags it is binary.
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.
Even if it is a little slower it may be _necessary_ to pay the price.
There is no point in a 100mph car if it cannot turn corners...
well not for general use anyway ;-)
--
Nick Ing-Simmons <nik(_at_)tiuk(_dot_)ti(_dot_)com>
Via, but not speaking for: Texas Instruments Ltd.
