Re: Re: [gui-dev] LimeWire 4.2.3 international font display patch
Philippe VERDY <[email protected]> Fri, 14 Jan 2005 20:08:10 +0100 (CET)
| Newsgroups | gmane.network.gnutella.limewire.gui.devel |
|---|---|
| Message-ID | <33128840.1105729690052.JavaMail.www@wwinf0603> |
I thought it was discussed many months ago, and fixed. This was a known caveat of Mac's HFS+ filesystem which uses some unique decomposed form (not really conforming to NFD, because it is based on a preliminary beta version of the NFD algorithm, and then it was frozen and never updated with new Unicode characters that have been added since HFS+ has been released; this HFS+ behavior was really a design error that will persist until MacOS adopts a newer filesystem that will not enforce a possibly broken normalization form; NTFS and Unix filexystems do not force the normalization form, however it's a common convention to use NFC, as the prefered form, including for the web, and alsmost all XML or HTML or SGML related standards). The idea of using some decomposed form was bad: it was used to simplify the implementation of what is really called "collation" in Unicode (and used in MacOS to search and sort files), but the scheme was broken as collation is locale-sensitive. HFS+ should not have enforce the normalization. Instead collation for sorting or searching files should be done in the user interface according to the user locale, but the filesystem should not do that. NTFS or FAT32 still perform similar transformations: notably case conversions and mappings to locate case-insensitive filenames, used as unique keys to open files. This is also broken, because this conversion does not follow exactly all the standard case mappings defined in Unicode. This was, however, fixed in newer versions of NTFS (but it creates some interoperability problems with older legacy systems, notably when sharing folders in a network, or mapping network drives). Unix does not have such difficulties in its filesystems: filenames are unique keys, with no aliases. It may look more difficult for users, but users can be helped by the user interface providing local-sensitive search algorithms for identying existing filenames. > Message du 14/01/05 00:26 > De : "Sam Berlin" > A : [email protected] > Copie à : "heavy_baby" > Objet : Re: [gui-dev] LimeWire 4.2.3 international font display patch > This is fixed and will be in LimeWire 4.3.3. Thanks for letting us > know about the problem, heavy. > > We're applying composition when: > a) Showing search results > b) Sending replies > c) Making a file on disk > > a) Should fix viewing search results from older LimeWires. > b) Should fix older LimeWires viewing newer LimeWire's results > c) Should fix saving downloads from older LimeWires > > Thanks, > Sam _______________________________________________ gui-dev mailing list [email protected] http://www.limewire.org/mailman/listinfo/gui-dev