[Mono-winforms-list] Combining characters in libgdiplus strings

[Sebastien Pouliot]

Le 2011-09-09 à 10:39, Dick Porter <dporter at codicesoftware.com> a écrit :

> Hi all
>
> I've been tracking down a display bug with winforms.  Basically, any
> string drawn that has combining chars (eg accents) doesn't come out
> right.  I've attached a screenshot and a sample test.
>
> In the screenshot the two buttons should look identical.  The only
> difference is that the one on the left has text using a combining
> accent, and the one on the right has the same text but using
> pre-combined chars.  They're both valid utf-16; that is, it's not an
> encoding issue.
>
> It's caused by libgdiplus using the cairo 'toy' text api to render
> strings.  This API takes each character in turn, draws the glyph from
> the font, and advances the drawing point by the width of the character
> in the font.  The combining accent has a zero width, but by the time it
> has come to be drawn the drawing point has already been moved so it
> misses the character it's supposed to be combining with.
>
> I've tried enabling the "experimental and unsupported" pango text
> rendering support (see attached patch to get around the failed
> assertion: (process:27402): Pango-CRITICAL **: pango_fc_font_lock_face:
> assertion `PANGO_IS_FC_FONT (font)' failed) but am having font loading
> issues when using the 'system' cairo (with or without pango), which the
> pango support depends on.
>
> Is there any reason why the pango support can't be enabled by default?

Yes, it (presently, as is "the last few years" ;-) only support a
subset* of the features available with cairo so most applications will
regress if a switch was made.

* but it do support a few things that the cairo-based rendered does
not support (since the prototype was made to ensure it fixed those
things :-).

FWIW parts of the pango renderer needed to be re-written to use the
lower-level API to be able to totally replace (and augment) the
current (cairo) one.

Sebastien