On Fri, 10 Nov 2000, ha shao wrote:
> On Fri, Nov 10, 2000 at 02:10:50PM +0400, [EMAIL PROTECTED] 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()
Yes, you are quite right. That was the reason.
All this is fixed in my patch I've posted a minute ago. Please test it.
> --
> best regard
> ha_shao
>
Best regards,
-Vlad
