Subject: Re: final bits for CJK patch
From: ha shao (hashao@china.com)
Date: Fri Nov 10 2000 - 05:26:42 CST
On Fri, Nov 10, 2000 at 02:10:50PM +0400, hvv@hippo.ru wrote:
> On Fri, 10 Nov 2000, Chih-Wei Huang wrote:
>
> Hi,
>
> > Vlad Harchev ¼g¹D¡G
> > >
> > > In fact, I sent the same old version of that patch with this letter. Sorry.
> > > Here is a correct version (with those ut_*.cpp bits), and also it adds 136 as
> > > value \fcharset for BIG5 docs.
> >
> > Hmmm... I just test your p3 patch but no lucky!
> >
> > When I try to save document containing Chinese character(only one)
> > as RTF, AW crashed immediately and silently.
>
> Could you send me backtrace (or better, debug the problem and suggest a fix)?
> Most probably UT_Wctomb was using wrong charset name when opening icon_t. But
> which one?
>
I traced it but I am too confused by xap_EncodingManager.cpp to fix it. :)
So now, the function charsetFromCodepage() do the right thing. As a
result, the WindowsCharsetName() return bad result. The reason?
WinLanguageCode is not the codepage but the langage ID. language
ID of GB2312 is 0x804 or 2052 (It is somehow misplaced to 1028 which
is for BIG5). As a result, WindowsCharsetName() now return
CP1028 for GB2312. CP1028 is bad for wctomb.
What involved for wctomb is s_RTF_ListenerWriteDoc() in
ie_exp_RTF_listenerWriteDoc.cpp with the call:
m_wctomb.setOutCharset(XAP_EncodingManager::instance->WindowsCharsetName());
I don't know what to fix. Of course WindowsCharsetName should be fixed
but it doesn't matter. What the wctomb need is not windows' encoding
but its own encoding ID. We need a funciton call charsetFromWinLangageCode()
similar to charsetFromCodepage()
-- best regard ha_shao
This archive was generated by hypermail 2b25 : Fri Nov 10 2000 - 05:26:47 CST