On Tue, 3 Apr 2001, Hubert Figuiere wrote:
> Vlad Harchev �crit:
>
> >> How should I do for MacRoman as it does not have a codepage number but have
> >> an iconv() name ?
> >> I haven't found the method that does this.
> >
> > Hmm, how RTF header for files in MacRoman looks like? Does it include
> > \ansicpgXXXX or what?
>
> It is \mac
> BTW \ansicpg is an extension as originally it is \ansi, \pc, \pca.
>
> > What is the corresponding charset iconv should use?
>
> MACINTOSH or MAC
>
> > If \ansicpgXXXX is not included in the header of RTF file, then we should add
> > special support for that (new, I assume) keyword, and it should be something
> > like this, without the need to touch
>
> This is already for the 3 keywords above. This is NOT the problem
>
> > XAP_EncodingManager.cpp:MSCodepagename_to_charset_name_map:
> >
> > if (strcmp((char*)pKeyword, "SOMEKEYWORD") == 0)
> > {
> > m_mbtowc.setInCharset("CharsetNameForMacRoman");
> > }
> > break;
>
> OK. So I don't need to use the encoding manager class ? Good.
Yes, you don't need to use encoding manager class for \mac support.
> >> BTW how do we insure that we have support for this conversion ?
> >
> > You mean how do we insure that iconv() have support for this conversion or
> > what?
>
> yes. How can we make sure that iconv() can handle the conversion ?
The only safe way to check it is
iconv_open("charsetname","charsetname")
If return value is (iconv_t)(-1), then that charset is not supported.
I think UT_Wctomb and UT_Mbtowc are rather safe to use to the point that AW
won't crash if iconv doesn't support some encoding and it's selected as
destination or source charset for them - so I don't think you should worry
about availability of support for charset.
>
> Thanks for the help. If this works, I'm about to close bug 836 finally.
>
> Hub
>
Feel free to ask any i18n-related questions to me, guys.
Best regards,
-Vlad
