Pamela,
Thanks for the sympathy, I have not yet come up with a workable solution either. I have decided to try a similar approach on the Mac that you describe with using markers in my english text pointing to the chinese/asian which I can then keep as just chinese instead of being mixed. I also think that filter doesn't work so I will have to rewrite using a find structure. I haven't tested my stuff on windows yet since I couldn't even get it to work on the Mac.
Please keep me informed to what you discover.
Thank you
Tom
On May 9, 2005, at 10:44 PM, pkc wrote:
Many thanks to Devin for his wonderful site. I am still hung up on a problem very closely related to Thomas McGrath's, however. Like him, I am working on a project that calls for mixing Asian (in my case, Chinese) characters with English text. Both the English and the Chinese elements are fixed, so I hit on the strategy of downloading the English text as an English text with markers for Chinese characters, then getting the client to feed characters from the Chinese text into the English text; then the client identifies the imported elements through reference to the list they came from and setting the textFont of the foundChunk to ",chinese."
This works extremely well on my machine (OS X). In fact, it works perfectly. However, nobody using it on a Windows machine gets the right characters (they get about 40% correct characters and the rest is junk). this is very perplexing, since the whole point of Unicode is supposed to be that the characters are unique and will render correctly in either Mac or Windows. But they don't.
One thing I discovered in experimentation was that if I moved a Chinese file line by line into a new field I could get the same junk that Windows users are getting (the boxes --light or dark-- and random character elements in a meaningless string). (this was not a paste, which reproduces the textFont perfectly, as previously noted). It seemed to me that I was transferring not only the characters but also carriage-returns (is this possible??). When I manually removed the spaces between characters, everything straightened up. The problem was that I was left with a field that the computer thinks has one character in it. That won't work with my strategy --all the characters will go into the marker for the first character.
I think that could have been a blind alley, and now I am interested in the idea that Mac and Windows systems reverse the placement of the null character when dealing with UTF-16. That could be why Windows users are picking up the carriage returns and Mac users are not. The problem is I don't see a way in Revolution to tell the computer to put the null characters where WIndows expects it to be. Oh, one thing I just thought of experimenting with... I have so far been making the editing software remove all empty spaces (they produce those weird cross things in Unicode). But maybe it would be healthier to make sure the empty spaces are there, in order to keep the character returns out of the WIndows character renderings? No idea, will experiment and see if the results are any better.
If there is no Revolution trick that will fix this, I would like to know if there is a setting Windows users can use to get their Unicode to work the way Mac works.
A bit frustrating. I have the basis for a research portal that works very pleasantly on the Mac and looks insane on Windows. Despite it all being in Unicode!
I'm still reading and still experimenting, but have sort of plateaued here. Quite a while since I had a breakthrough.
Anyway, Tom, I sympathize.
Pamela Crossley _______________________________________________ use-revolution mailing list [email protected] http://lists.runrev.com/mailman/listinfo/use-revolution
Thomas J. McGrath III SCS 1000 Killarney Dr. Pittsburgh, PA 15234 412-885-8541
_______________________________________________ use-revolution mailing list [email protected] http://lists.runrev.com/mailman/listinfo/use-revolution
