[Bug 16325] incorrect font rendering for CJK programs

http://bugs.winehq.org/show_bug.cgi?id=16325

Paul "TBBle" Hampson  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #88 from Paul "TBBle" Hampson   2009-05-12 11:15:01 ---
(In reply to comment #76)
> I think the patch step are:
> - Add the default FontAssoc/FontLink registry data updating code.

The FontLink part of that should be done now, as of 1.1.22.
> - Intruduce the smart fontlink fallback mechanism
> when the default font of the MS Windows does not exist in the system.
> Ex. winecfg approach, fontconfig approach,
>     "using first searched font" approach ...

Currently, if a font fails to find a charset, Wine implements Font fallback by
following the FontLinks for Microsoft Sans Serif, which now gets a default
FontLink setup as long as you have fonts that match the expected Font names or
FontReplacement entries to make chosen fonts appear as such.
> - GdiGetCodepage patch using the FontAssoc information.
>
> Or,
> 2a. tagGdiFont.codepage touch using the FontAssoc information.
> 2b. GdiGetCodepage patch using the step.2a change.

I guess this is the only remaining fix needed?

I grabbed SetupFTDB.NoHis.EXE from comment 31, and running under
LC_CTYPE=zh_CN.UTF-8 the initial dialog-sized "Wise installation is loading"
still has garbled characters, but the first screen of the actual installer
appeared correct (with the proviso that I don't read Chinese so am basically
going on the general lack of garbage characters and the 'next' button looking
like it means 'next')

I'm not totally clear on what "test program 2" (attachment 17825) is supposed
to be demonstrating, but I guess the idea is that the first line should look
like "Hello. 안녕하세요." if Font Association is enabled for ANSI_CHARSET
and you're in a Korean locale?

http://blogs.msdn.com/michkap/archive/2008/02/29/7945019.aspx is where I'm
getting my understanding of Font Association from.

I haven't been through all the patches in this bug yet, but I suspect some of
them at least have been obviated by the automatic FontLinks generation and the
fixing of the FontLink lookups for MS Shell Dlg.

Is attachment 17928 sufficient to fix Font Association? (ie does changing the
return value of GdiGetCodePage magically make Font Association work?)

I can't see how that would be the case because Font Association depends upon
the character being rendered, so probably needs to be handled down inside
get_glyph_index_linked, which suggests the Font Association registry keys
(which list the fonts to associate with, based on other attributes, from what I
saw in google) will need to be read and processed rather like FontLinks are
now.

Hopefully the FontAssociation keys can also be _generated_ automatically like
FontLinks are now, so it works out-of-the-box.