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

Hi Philippe,

Performing the normalization will indeed fix things for the future.
Unfortunately, there's a ton of existing clients out there that aren't
sending correctly formatted results.  To display those properly,
normalization would indeed need to be done on every incoming result.

Thanks,
 Sam

> -----Original Message-----
> From: [email protected] [mailto:gui-dev-
> [email protected]] On Behalf Of Philippe Verdy
> Sent: Saturday, November 27, 2004 3:54 PM
> To: [email protected]
> Subject: Re: [gui-dev] LimeWire 4.2.3 international font display patch
> 
> 
> ----- Original Message -----
> From: "Sam Berlin" <[email protected]>
> To: <[email protected]>
> Sent: Saturday, November 27, 2004 5:10 PM
> Subject: RE: [gui-dev] LimeWire 4.2.3 international font display patch
> 
> 
> > Hi heavy,
> >
> > Do you recall if you saw this problem with earlier LimeWire versions?
> > Nothing has changed with normalization that should have affected this,
> so
> > we're hesitant to make a change for the 4.2 series.  Your two
> suggestions
> > are indeed the correct places to add the normalization.  We're just
> > hesitant
> > to add it to all incoming search results because it may be a very
> > time-consuming process.
> 
> No Sam, you just need to add normalized composition when reading
> directories
> on Mac filesystems (which are not consistant, depending on the filesystem
> type and version effectively used on MacOSX).
> MacOS or MacOSX will accept to create files with precomposed filenames in
> NFC form, but the HFS+ filesystem driver will remap these names to the
> Apple-specific decomposed form (a variant of NFD, based on preliminary
> versions of Unicode canonical decompositions, but which is incomplete and
> not fully conforming to the normalized NFD). However you can be sure that
> the Apple-decompositions created by HFS+ are canonically equivalent to a
> NFC
> form, and that all filenames given to HFS+ that are canonically equivalent
> to the Apple decomposition will be stored on HFS+ with the same
> Apple-decomposition.
> 
> What this means is that it is always safe on MacOS filesystems to force
> the
> recomposition to NFC, when reading directory entries. I just wonder why
> the
> java.io.* packages ported on MacOS or MacOSX do not perform that
> normalized
> composition by default, so that Java programs would not have to worry
> about
> these details, and could safely create files with names in NFC forms, and
> then parsing directories to find the same names.
> 
> The FAT32 or NTFS filesystems on Windows, or Linux filesystems do not
> perform such forced composition or decompositions, so an application that
> creates a file using any valid form will be able to retreive the same form
> when reading directory entries.
> 
> On all these filesystems however, whever the FS driver performs some
> normalization or not, you can create a file with any form, and then open
> that file for reading using the same form, even if the file was created
> with
> a different form (it only affects the case where we read directory
> entries).
> 
> So the correct place to do that normalization is only when parsing shared
> directory contents...
> 
> _______________________________________________
> 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