Welcome to NeoOffice developer notes and announcements
NeoOffice
Developer notes and announcements
 
 

This website is an archive and is no longer active
NeoOffice announcements have moved to the NeoOffice News website


Support
· Forums
· NeoOffice Support
· NeoWiki


Announcements
· Twitter @NeoOffice


Downloads
· Download NeoOffice


  
NeoOffice :: View topic - Fix for non-ASCII Mac OS X file names bug
Fix for non-ASCII Mac OS X file names bug
 
   NeoOffice Forum Index -> NeoOffice/C Development
View previous topic :: View next topic  
Author Message
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: 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.

There is one tricky part to this fix: Mac OS X uses UTF-8's "normalization form D". This means that accented characters are decomposed into 2 separate characters. For example, if you have a file named "tésting", the actual file name is "te\314\201sting" where "\314\201" are the octal numbers that represent the "´" accent character.

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.

Hope you find the above info helpful.

Patrick
Back to top
OPENSTEP
The One
The One


Joined: May 25, 2003
Posts: 4752
Location: Santa Barbara, CA

PostPosted: 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? Wink

ed
Back to top
Max_Barel
Oracle


Joined: May 31, 2003
Posts: 219
Location: French Alps

PostPosted: 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?
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Tue Aug 19, 2003 7:29 am    Post subject:

Max,

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.

I quick way to test this out would be to tak the libsal.dylib.3.0.1 file in my http://www.planamesa.com/neojava/downloads/temp/printtest4.tar.gz NeoOffice/J download and put it in a NeoOffice installation. It will either work or it will cause layout problems.

Patrick
Back to top
Display posts from previous:   
   NeoOffice Forum Index -> NeoOffice/C Development All times are GMT - 7 Hours
Page 1 of 1

 
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

Powered by phpBB © 2001, 2005 phpBB Group

All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © Planamesa Inc.
NeoOffice is a registered trademark of Planamesa Inc. and may not be used without permission.
PHP-Nuke Copyright © 2005 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.