Re: RICHEDIT: RTF reader i18n (now with font charset support)

[Vitaly Lipatov]

В сообщении от 17 Март 2005 13:20 Phil Krylov написал(a):
> this patch replaces my precious patch "RICHEDIT: RTF reader i18n" and
> needs to be applied after Krzysztof Foltman's "RICHEDIT: RTF reader
> improvements and optimizations (TAB craziness fixed)" patch.
>
> ChangeLog:
>
> Replaced slow and outdated character set handling in RTF reader by
> Unicode/codepages support. Added charset->codepage conversion.
> Will we do this code in locale independent manner? Why we have 
> ansiCodePage=1252 by default?

-- 
Vitaly Lipatov, ALT Linux Team
Russia, Saint-Petersburg, www.etersoft.ru

RICHEDIT: RTF reader i18n (now with font charset support)

[Phil Krylov]

On Fri, 18 Mar 2005 15:12:01 +0300
Vitaly Lipatov <lav(a)etersoft.ru> wrote:
> В сообщении от 17 Март 2005 13:20 Phil Krylov написал(a):
> > this patch replaces my precious patch "RICHEDIT: RTF reader i18n" and
> > needs to be applied after Krzysztof Foltman's "RICHEDIT: RTF reader
> > improvements and optimizations (TAB craziness fixed)" patch.
> >
> > ChangeLog:
> >
> > Replaced slow and outdated character set handling in RTF reader by
> > Unicode/codepages support. Added charset->codepage conversion.
> > Will we do this code in locale independent manner? Why we have 
> > ansiCodePage=1252 by default?

It is locale independent. 1252 is the default value used if RTF does not
specify another codepage (which almost never happens). If I used
GetACP() here, the same RTF document would be differently imported
depending on user locale. RTF is not supposed to act like this. If RTF
does not specify any codepage it means that it uses CP1252.

How do you find this code is locale dependent? IMHO it's _in_dependent of
locale.

-- Ph.