Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


Hi Khaled,

On Wed, 2011-01-05 at 15:54 +0200, Khaled Hosny wrote:
This my first message to the list, hopping it will be a fruitful
experience :)

        Drat; we took ages to reply. I suspect Thorsten might be able to help,
but failing that the best text expert I'm aware of is Tim (CC'd) who may
be able to give some advice. SIL's Graphite integration would
undoubtedly have fallen over the same sort of problems, and no doubt he
can give some pointers to how to work around it - Tim ? :-)

        HTH,

                Michael.

I was trying to debug fdo#31016[1] since it breaks almost all my fonts,
it toke me few months but I think I finally got the root of it (I
started working on it few weeks before libreoffice was announced, what a
nice code base ;).

Anyway, it turned out that the issue is not specific to kerning nor
Arabic, but affects all horizontal glyph positioning in the ICU layout
path; the problem does not show on Windows nor with Graphite fonts and
of course not with con-CTL.

The X adjustment of glyph widths is simply ignored, and glyphs are drawn
stacked after each other baased on their original width, which results in
kerning being ignored as well as other forms of glyph positioning like
cursive anchors, however vertical glyph positions (in the Y access) are
OK.

In source/glyphs/gcach_layout.cxx, ICU's layoutChars() is called and new
glyph indices and positions are returned, which is then fed into
SalLayout in the form of GlyphItem's. Though GlyphItem has maLinearPos
which holds its absolute position, many places in the code re-calculate
glyph position from its mnOrigWidth (original glyph width) and mnNewWidth
(width after adjustments), but the ICU path simply sets mnNewWidth to
mnOrigWidth since ICU layout engine does not return individual glyph
widths, resulting in failure of glyph position re-calculation which
manifests in this bug.

As a prove of concept, the attached patch trays to set mnNewWidth in a
very hackish way by subtracting current glyph position from the of next
non-diacritic (+ve) glyph. It does indeed fix the problem (see the
attached screenshots), but it looks very unreliable to me. May be a
cleaner solution is to re-implement all the broken virtual methods to
eliminate the re-calculation part.

Hope this helps, and sorry for the broken terminology as I'm not really
a developer and less of C++ one (I can only do much of C++ that looks
like C, which I don't really "speak" either).

[1] https://bugs.freedesktop.org/show_bug.cgi?id=31016

-- 
 michael.meeks@novell.com  <><, Pseudo Engineer, itinerant idiot



Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.