Re: [gui-dev] LimeWire 4.2.3 international font display patch

It was discussed a while ago, but was not fixed because we were very 
late in the release cycle for LimeWire 4.2.  Now that we are starting a 
new cycle, it is fixed.

Thanks,
  Sam

On Jan 14, 2005, at 2:08 PM, Philippe VERDY wrote:

> 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
>


_______________________________________________
gui-dev mailing list
[email protected]
http://www.limewire.org/mailman/listinfo/gui-dev