On Mon, 20 Mar 2000, Dmitry Timoshkov wrote:
> Ove Kaaven <[EMAIL PROTECTED]> wrote:
>
> >> >Can't data for X11 encodings just be internal to x11drv?
> >>
> >> Are the X11 encodings such specific and can not be replaced by the standard
> >> encodings? Having such common feature as support for various encodings in one
> >> place (kernel/ntdll) should help to minimize bugs in handling of encodings
> >> and help in providing additional drivers without excessive complications.
> >
> >Well, you can surely use RtlCustomCP routines even if the tables are in
> >the X11 module, and you can probably use the same tools to build the
> >tables no matter where they are? I can't see anything that should make the
> >solution any buggier.
>
> Don't forget about the future drivers that can be created on the base of
> x11drv. Then they should be forced to add theirs own encodings if needed
> instead of using existing infrastructure and Win32 API.
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?
> >And what "standard" encodings would you be talking about? Pretty much NONE
> >of the Microsoft codepages are standard encodings. Even CP1252 is a little
> >different from iso8859-1. And as far as I know, there is no codepage that
> >corresponds to any of the other major encodings... like koi8-r, for
> >example?
>
> The word "standard" I used just means publicly approved and widely used.
> I assume that publication at the unicode.org means exactly that.
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.
> >I think that since X11 encodings (which are standard) have nothing in
> >common with codepages (which is ordinary Microsoft non-standard), the
> >tables could just as well be linked into the X11 module.
>
> The X11 encodings could be easy used along with the code page stuff.
> I think also that having X11 encodings encapsuled in the nls-like files
> would help to use them not only inside of x11drv.
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.
