All this CP mapping bothers me too. notepad won't display Hebrew text at
all (it puts spaces instead of Hebrew characters). It is still under
investigation. For now it seems that wine does set garbage data in the
font information ('fi' variables) for the Hebrew 1255 codepage fonts.
It seems to happen due to a different reason than the one stated in
previous mails, still it is in the same code area
(graphics/x11drv/text.c). This will take a while to learn this code and to
debug it, so for now there is not much information to give.
(Note that the problems are seen even in my local copy that contains
new NLS definitions for Hebrew)
Michael
On Wed, 23 Aug 2000, Albert den Haan wrote:
> Dmitry Timoshkov wrote:
>
> <snippage AdH>
>
> > Of course, I can :-). ExtTextOutA at wine/objects/text.c takes non-unicode
> > text and translates it to unicode using wrong code page. That's all.
> > The used code page will be always wrong, if currently selected font will have
> > another code page rather then current ANSI code page. Theoretically, the system
> > could have fonts with three different code pages: ANSI, OEM, MAC. I have even more
> > in addition to the mentioned ones: iso8859-1, iso8859-5, koi8-r, symbol. In my case
> > ANSI = 1251, OEM = 866, MAC = 10007. So, the question: Can the fonts with the
> > different code pages easy break everything?!
>
> Oh yes!Try using a symbol font like
>"-adobe-symbol-medium-r-normal--14-140-75-75-p-85-adobe-fontspecific" and scanning
>GetTextExtentPoint calls through it from FirstChar to LastChar.WordPerfect
> likes to do this every time the user selects a new font and wine crashes in
>X11DRV_GetTextExtentPoint on a pointer lookup of the "translated" character encoding
>determined by MultiByteToWideChar.
>
[snip]
