Re: RTF Text (contains Korean) Problem

[Fred Kiefer]

Sungjin Chun wrote:
> When I write RTF using TextEdit.app, the characters are like following;
>
> \u-10916 \u-20992 \u-16212 \u-18543
>
> But, I write RTF using OpenOffice.org or Microsoft Word, it has one more 
> character (the question mark):
>
> \u-10916 ?\u-20992 ?\u-16212 ?\u-18543 ?
>
> Because of this difference, the document created with TextEdit.app 
> cannot be read correctly with Word or
> OpenOffice.org if it contains Korean (I suspect Japanese or Chinese too)
>
> Which application is responsible for this problem, OpenOffice.org or 
> Word, or TextEdit.app?

It is not the application that is responcible for the problem, but the 
RTF converter in GNUstep GUI. In the RTF specification there is a 
command \uc which specifies, how many of the following characters are an 
ANSI representation of the Unicode character. The default for this is 1, 
so MS Word and OpenOffice are correct here and GNUstep should either try 
to output an ANSI character or reset \uc to 0. The later is what I did 
implement today in the RTF output code.

We are still reading the RTF from other sources incorrectly, as our RTF 
parser does not handle the command \uc. This is rather hard to implement 
in the current parser structure, as we need to skip characters. Perhaps 
it is time now to switch to a non-YACC parser as was suggested years ago.

Fred