Posted: Mon Aug 18, 2003 9:23 pm Post subject: Fix for non-ASCII Mac OS X file names bug
I just checked a fix into NeoOffice/J that may be of interest to NeoOffice. The bug I fixed, which is in the sal module, incorrectly encoded Mac OS X file names (which are UTF-8) into the user's current character set.
This bug causes any non-ASCII file names to be mangled in any of the OOo file dialogs. The fix that NeoOffice should be able to copy from NeoOffice/J without modification is the neojava/sal/osl/unx/file.c file. This file is the OOo file except that it redefines the osl_getThreadTextEncoding() function to the RTL_TEXTENCODING_UTF8 macro when dealing with file names.
Decomposed file names need to be handled in the NeoOffice implementation of the SalGraphics::DrawText() and the SalGraphics::DrawTextArray() methods. Basically, these methods need to recognize "non-spacing marks" (i.e. the accents) and draw at the same x coordinate as the preceding character. Also, the SalGraphics::GetCharWidth() method needs to return a width of 0 for these non-spacing marks.
I don't know how the above is done in Cocoa, but if it helps I have the above algorithm implemented in Java in the VCLGraphics.drawTextArray() method in the neojava/vcl/java/com/sun/star/vcl/VCLGraphics.java file.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Mon Aug 18, 2003 9:42 pm Post subject:
So that is the issue! I had thought eventually I'd see the "combining characters" style Unicode stuff crop up its ugly head. This info is *incredibly* useful.
Right now I'm thinking it's best to address this after I move over to 1.1 sources...the 1.0.1 based Neo has its own hacks into DrawTextArray() to allow it to do context sensitive text rendering and substitution and handle the non-combining marks, but I'm sure that 1.1 attempted to reinvent the wheel and do it all itself (judging from the fact they included all of ICU inside the source...never a good sign for allowing a platform to do its own Unicode substitution & rendering...).
Thanks for tracking this down and ifnding the encoding foible! I'll definitely hope to address it in the Neo VCL. Man, we really do need a better vcl bridge...anyone like the prospect of a Carbon/Cooca/Java/Qt amalgamation?
Joined: May 31, 2003 Posts: 219 Location: French Alps
Posted: Tue Aug 19, 2003 5:05 am Post subject: Re: Fix for non-ASCII Mac OS X file names bug
pluby wrote:
I don't know how the above is done in Cocoa, but if it helps I have the above algorithm implemented in Java in the VCLGraphics.drawTextArray() method in the neojava/vcl/java/com/sun/star/vcl/VCLGraphics.java file.
Once again I post with a doubt about usefulness of the post.
Anyway, when I first reported about the file name issue, in the beta time of OOo/X11, on OOodocs forum, I then made some browsing in the Cocoa doc, just in case I found something obvious, like environment parameter setting etc... I remember I saw several references to Cocoa methods/objects to deal with unicode string and specifically file names. Those methods are able to manage the diacritical (decomposed) unicode form. The Cocoa doc is clear about the fact that the finder/system use this kind of unicode, and so provide pointer to way to handle it.
Maybe should I had reported it. As I knew nothing about the code and the places where this should be used, and since we then were on a pure X11 code, I didn't. Is it useful now?
I would guess that Cocoa will handle decomposed characters OK. I just wanted to note that I did find problems in Java on 10.1. Most likely, it is a Java bug and hopefully not a 10.1 Cocoa bug.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
