Hello Thomas, here is my strategy, which on the basis of my experience so far I
believe won't render all correct characters on Windows. But, see what you can
make of it.
This is the critical part of the script:
put the number of words in fld "chinese" into charCount
put 1 into lineCount
repeat
find string "= " in fld "window"
if the result is "not found" then exit repeat
put the foundChunk into thisInsert
put (word lineCount of fld "chinese") into the foundChunk
set the textFont of thisInsert to "Taipei,Chinese"
add 1 to lineCount
end repeat
I suppose it is self-explanatory. The field "chinese" contains a series of
characters, one on each line, that are fed in order into the English text. I
tried various markers, but for some reason this one (not very intuitive) works
best.
I found by trial and error that not using a variable like "thisInsert" and just
relying on floating foundChunks produced a lot of errors. With this script, I
have NO errors on the Macintosh that cannot be traced to Unicode ambiguities.
However, in Windows there is more junk than sense in the characters. I still
think that Windows is picking up the carriage returns in the "chinese" source
file and feeding them into the English file, which with the font change at the
foundChunk renders a lot of nonsense. I don't know how to get the program to
stop it.
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution
