Gurusamy Sarathy <gsar(_at_)ActiveState(_dot_)com> writes:
On Wed, 15 Mar 2000 21:04:07 GMT, Nick Ing-Simmons wrote:
The Tk code needs several things in this area - the two most fundamental
being:
"Give me a pointer to the UTF8 encoded chars in this SV" - which
would seem to be SvPVutf8()
and its inverse:
"Set this SV to contain these UTF8 encoded chars".
Which seems to be
sv_setpvn(sv)
+ SvUTF8_on(sv)
There not being any special setting function(s).
I assume at least a sentence or two for perlguts.pod is appropriate?
I'm not comfortable about setting either of the above in stone yet.
(My fear being that we may have a better/different API when we support
I/O disciplines.)
But strictly for experimental purposes, the above look right. :-)
Well if this is ever going to stop being experimental we need to try
using it - the question is (A) should we document it at all or
restrict experiments to those that can read the source. (B) if we
document it should it be in the perlguts.pod next to its "peers",
or in perlunicode.pod where it is more obviously tagged as experimental.
I am leaning towards the latter.
Tk would also _like_ (but can provide by importing more of Tcl than I would
like) "convert this UTF8 string to encoding yyyy" where yyyy is a "name"
of an encoding used by a particular font - it may be a single byte encoding
or wide char encoding.
There was talk of bundling one or more encoding converters -
did it ever happen?
No. :-(
I think the conversion stuff has to be braindead easy--it needs built-in
support (via tr/// or maybe pack/unpack). Or perhaps even with a
"discipline" mechanism that can get tied to variables.
Agreed - but Tk (as ever) is going to be awkward and want to access it from the
C side. But I assume that if the perl core has a "braindead easy" way of doing
it the routines that implement it will be available for calling.
So who's up for an (e-mail) brainstorming session on what the easy way
should look like?
--
Nick Ing-Simmons
