Ove Kaaven <[EMAIL PROTECTED]> wrote:
[...]
>Why should they not use the existing infrastructure and Win32 API? Isn't
>it reasonable to expect them to use RtlCustomCP routines with whatever
>encoding tables they like?
[...]
>ISO issues standards, MS doesn't. Unicode publication is for convenience.
>But they point here is X11 encodings, which is more standard but pretty
>much do not correspond to existing MS codepages at all.
[...]
>Like I said, nothing else in Wine will use the X11 encodings, since
>Microsoft encodings have nothing in common with them, so why should the
>X11 encodings be accessible to the rest of Wine? As for future drivers,
>they can also link in the same encoding tables into their modules should
>they need it (but chances are they won't need the X11 encodings, since
>those underlying font systems would probably be Unicode-based). The
>encoding tables themselves don't need to be local to the x11drv, just
>linked into it, and since I expect only one display driver to be used at a
>time it won't be much of a loss to link the same source tables into more
>than one driver.
Ove, I am appreciating your ability to pass an opinion of well-founded belief.
Okay, you don't like an idea to have centralized place for all encodings.
But all, that I have in mind is to make things as simple as it can be.
Using RtlCustomCPToUnicodeN and RtlUnicodeToCustomCPN is anything but not an
intrusive intention at all.
I think that changing in registry
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Nls\Codepage]
"ACP"="1252"
"OEMCP"="437"
"MACCP"="1000"
to any appropriate values should be enough to make user happy without
recompilation.
Dmitry.
P.S.
What do you think about including of files with all possible encodings
from ftp.unocode.org in the same form to Wine tree?
