|
From: | Fred Kiefer |
Subject: | Re: RTF Text (contains Korean) Problem |
Date: | Sun, 16 Jan 2005 16:56:48 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040906 |
Sungjin Chun wrote:
When I write RTF using TextEdit.app, the characters are like following; \u-10916 \u-20992 \u-16212 \u-18543But, 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 orOpenOffice.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
[Prev in Thread] | Current Thread | [Next in Thread] |