Pierre Sandboge wrote:
>When dropped in Finder, however, an error results on the console:
>java[1850] Couldn't convert path "/Users/sandboge/Pictures/pm/temp/a?
>a?o?.jpg" to an FSRef to put on the pasteboard.
>That's it. No stacktrace, no exception.
>
>I have no idea if there is an acceptable workaround. FSRef sounds
>like Cocoa, or at least not Java.
FSRef is the native API for working with long filenames and Unicode
characters. It's what I based the Mac OS X version of my MacBinary
Toolkit's I/O layer on.
The odd thing is that the FSRef API uses names with 16-bit Unicode chars,
not MacRoman bytes. However, there are some conversion functions to go
between FSRef and the older FSSpec API's. FSSpec DOES NOT support Unicode,
DOES use MacRoman (or other encodings, using script-codes), and is also
limited in the length of names it can handle. So it's possible that this
problem is coming from an obscure vestige of FSSpec code somewhere, and
it's unable to handle any of the accents, ligatures, etc.
One possible test is to try and trip it up with a long filename, which it
might also barf on. Any filename longer than 31 ASCII characters should
trigger the problem, if it's going to be a problem. Use just normal ASCII
chars, not anything with accents or symbols.
However, it might just work, because there's another trick for representing
long filenames to FSSpec, and that's to interject a file-number in the
middle of the long name. If you've run some Classic program and tried to
open a file with a long filename, you may have seen this trick happen. The
older MSIE and Adobe Acrobat Reader exhibit this, even in their non-Classic
Mac OS X versions, so if you want to see it happen, I'd try one of them.
One possible work-around is using my AccentComposer to precompose the
decomposed accents, and seeing if it works that way. I suspect it won't,
but it could still be interesting to try. See earlier post for URL.
This does seem rather like poking into a dark cave with a long stick to see
if a bear, a lion, or a swarm of bees comes out, but it does seem to be
producing good fail-cases, if not good work-arounds.
>Maybe the path is converted to MacRoman at some stage, if so I don't
>see how to get around the problem.
I think the data is getting mangled, not just converted to MacRoman. If
the text were only being converted to MacRoman, then bullet and ae-ligature
would work, because they have MacRoman code-points and should convert. The
fact they don't work either makes me think the problem is deeper than that.
Filing a bug-report with a good fail-case, which you seem to have, is
definitely worth doing. Especially if this happens in the latest J2SE 5.0
Release 4, which means it's a long-standing and deeply fundamental problem.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
