On 16 Jun 2003, Martin v. [iso-8859-15] L=F6wis wrote: > "Jeff Hobbs" <jeffh@ActiveState.com> writes: >=20 > > Right, and Unicode 4.0 is fresh out of diapers. You can't even get > > the regular code charts yet, you have to view the 4.0 beta ones. Wit= h > > 4.0 the non-BMP finally gets a notable amount of characters, but they > > are fairly weird ones that I'd be surprised to find a public font for. >=20 > Actually, Unicode 3.2 added most of them; Unicode 4.0 has only minor > additions. The biggest addition is the CJK unified ideographs in plane > 2, which is of significance to a fifth of the world population, > potentially - these are all current characters (instead of being only > of scientific interest). >=20 > I agree that it will take a while to have fonts for these > available. However, unavailability of fonts should not stop us from > supporting such characters in the libraries. Characters must pass > through many processing steps before being rendered, and all of these > steps must work flawlessly. So I think it is a good thing to start > today, to have the application software ready by the time fonts become > available. Hello, Here are the reasons Red Hat went for ucs4: - Red Hat 7.3 shipped python 2.2 (compiled in the python2 rpm). Not too=20 surprising that a number of configuration tools were already using it. Bu= t=20 no one saw tkinter was broken until too late - yes it was compiled with=20 ucs4. - Red Hat 8.0 went to --enable-unicode=3Ducs2: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D63965 - While shipping an erratum for 7.3 that updated python2 to 2.2.2, I=20 realized the compatibility mess we are in. 7.3 is UCS4, 8.0 is UCS2. Part= =20 of the reasons Red Hat 9 is called 9 and not 8.1 is to suggest there are=20 things that are incompatible with previous versions. There should be a=20 note in the release notes, stating python is now UCS4. The logic I tried=20 to apply was exactly what Martin said earlier - I would prefer to break=20 compatibility now rather than later when more people would notice :-)=20 Arguably, we should have beaten the heck out of tkinter at Red Hat 8 time= =20 and fix it then - almost 2 years ago, that is. > > > When I tested it, I found that it would break very easily. I was us= ing > > > the Redhat procedure, though, so I might have made something wrong. > >=20 > > Can you feed me some sample scripts offline to test with? >=20 > Will do, but it may take some time. It was so obvious to me that this > is not at all officially supported that I did not bother reporting it, > or taking notes. The patch for tcl that we came up with was, IIRC, posted somewhere on the= =20 tcl sites. I'll have to dig to find it again. So, I am willing to wear the brown paper bag for not letting the communit= y=20 know about the UCS4 change well in advance. I find it surprising to find=20 out _now_ that _tkinter.c was the one that was broken, I wish I knew that= =20 before poking at fixing tcl instead. I am surprised the tcl community was= =20 not aware of this either. Anyway, UCS4 is something I don't think we can change now - and after=20 reading Martin's post, it makes me feel it's the correct way to go. How=20 can we fix the tcl/python interaction? If you have suggestions, please le= t=20 me know (off-list would be fine too).=20 Cheers, Misa
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4