tdf#97171: Use DirectWrite for OpenGL glyph caching

A squash of several commits. Most important points mentioned below:

DirectWrite rendering for Graphite to work around ExtTextOut bug where
it incorrectly positions certain diacritics, using DirectWrite and
Direct2D fixes this. Implemented on-demand loading of the DLL so the
old ExTextOut based renderer will be used when drwite and d2d1 cannot
be found allowing this work on Windows XP (where this bug doesn't seem
to occur)

Make the new D2D Graphite rendering work also in the OpenGL case It
used to render just black boxes.

The change in DrawTextImpl() semantics from
61085083e4a5060ba7e2135818264d63c6da13c2 was not properly implemented
in the new Graphite code. The return value is not some kind of
"success" indicator, but tells the caller whether to continue the loop
at that level.

We do need to call FillRect() to fill the requested rectangle of the
HDC with white. On the other hand, the call to Clear() is not needed
and in fact makes no text show up.

(I now see that that same code snippet that calls FillRect() is used
in all the DrawTextImpl() implementations, so it should be factored
out to the call site in WinLayout::DrawText().)

Factor out the calls to FillRect in the DrawTextImpl()
implementations.  They were all in fact doing exactly the same, so do
it at the call site instead.

Fix what seems to have been off-by-one errors in glyph bounds
calculation. For some reason the error had a visible impact (as far as
I an see, anyway) only for Graphite fonts. The bottommost pixels were
cut off. (Also leftmost, but that was not so easily visible.)

<tools/gen.hxx> Rectangle type, I love you.

Refactor some previously private methods into public ones and
reimplement parts of D2DWriteTextOutRenderer to user them. Also apply
them to rendering the OpenGL glyph atlas, in an effort to workaround
some bugs in legacy Windows text rendering APIs.

I assume we want to initialise the rectangle with zero
left/right/top/bottom and not using the default constructor, which
sets the right and bottom coordinates to the magic value -32767. That
made the 'bound' rectangle end up with rather amusing boundaries, like
left=-32766, top=-16, right=-32576, bottom=6.

Try calculating a chunks ascent & height from the inkboxes rather than
using the font metrics which might not alway be correct when glyphs
inkboxes are tall than the ascent or lower than the descent.

Mark the mnAscent in the chunk bitmap debug output.

Fix several miscalulations in positioning glyph to be rendered into
that atlas.

Fix vertical alignment problems. Inkboxes are returned with all
co-ordinates relative to the glyphs not the fonts ascent.  Therefor
bounds.Top() is not the vertical overhang but the -ve height of the
inkbox above the baseline.  This fixes the calulation of the per Chunk
ascent.

Fix horizontal occsional alingment issues in OpenGL cached glyphs. The
left edge of the src location rectangle for the first glyph in a cache
chunk would set to extraspace and not zero, but all other rectangles
in the chunk would be set from the aEnds array. This produced a bug
where only certain letters would be mispositioned, proportional to the
fonts point size.

Rename OpenGLGlyphChunk::mnAscent to mnBaselineOffset to reflect curr
use.  Changed at Tor's stuggestion to better describe to it's use as
it's value would be per chunk and based on the maximum ink box bounds
of the glyphs in the chunk, rather than having anything to do with the
font's real ascent value.

Change-Id: I92ca17609022ae4af187e9a9f452a694fdd976ad
Reviewed-on: https://gerrit.libreoffice.org/23246
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>

0 files changed, 0 insertions, 0 deletions