On 11/20/2014 4:04 AM, Christian Gollwitzer wrote:
Tcl nor Tk support Unicode outside the BMP. Full Unicode support is a
big todo item on the wishlist for Tcl 9, for Tk nobody really knows. We
are lacking manpower and people with specialized knowledge.
Tcl/Tk currently use UCS-2, which only handles BMP chars. Alternatives
to support astral chars:
UTF-32 (Python's 3.2- wide build): Easy, especially starting from USC-2.
The main problem is the memory hit. However, most tk apps are not
text heavy, so this seems like a possibility. Does anyone ever try to
put a gigabyte text in a Text widget?
UTF-16 (Python's 3.2- narrow build): Easy but buggy when it comes to
indexing and slicing.
UTF-16+: I posted on the tracker a prototype of how to make indexing
correct by adding an auxiliary index of non-BMP chars. It makes
indexing O(k), where k is the number of astral chars.
UFT-8: Makes indexing O(n).
Python FSR (3.3+ Unicode): Handling variable byte width adds complexity,
but Python has already implemented this pretty efficiently. Python is
open source with a liberal licenc
To me, an important consideration for choosing is what the OSes require
to put characters on the screen. Are they all the same?
Apple is a
moving target, they pulled the rug from under Tk's feet twice over the
past 10 years. Nobody knows if Tk will continue to exist on the mac if
Cocoa is withdrawn some day and replaced by a new and completely
different windowing framework.
Python has largely replaced Tcl as the
first-choice scripting language, and that also does not help to attract
people working on Tcl/Tk.
A possible solution for Tk is to replace the non-C Tcl parts of TK with
Python (or the CPython API functions as needed for speed). I have no
idea how horrendous a project creating Py/Tk would be.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
