[HarfBuzz] behavior of mark-width-zeroing

[Konstantin Ritt]

Hi,

Just wanted to mention I also encountered this issue with another
font(s)/script(s) (i.e. with monospaced variant of Liberation and DejaVu
fonts).
For instance, this old-and-already-fixed bug [1] has re-appeared once we
switched to HB-NG on Mac:
https://bugreports.qt-project.org/secure/attachment/18670/combiningmarks.txt
https://bugreports.qt-project.org/secure/attachment/20247/combining-bug.png

[1] https://bugreports.qt-project.org/browse/QTBUG-15675


Regards,
Konstantin


2014-06-09 17:12 GMT+03:00 Jonathan Kew <jfkthame at gmail.com>:

> Hi Behdad,
>
> Our current mark-zeroing code, in zero_mark_widths_by_gdef() and
> zero_mark_widths_by_unicode(), modifies only the advance of the glyphs, so
> that they no longer take up any space on the line.
>
> I'm wondering whether we should also adjust the offset, by subtracting the
> advance from it before we zero the advance. (Though perhaps only if there's
> no GPOS positioning?)
>
> In particular, this is required for correct rendering of old fonts such as
> MS Sans Serif codepage 874 (Thai), which has spacing glyphs for the Thai
> vowel/tone marks. AFAICT, what Uniscribe does with it is to zero their
> advance width *and* offset them to the left by their original advance, so
> that they overstrike the preceding glyph, even though the images in the
> font appear to the right of the origin.
>
> WDYT? Can you think of fonts where this would *not* be appropriate?
>
> _______________________________________________
> HarfBuzz mailing list
> HarfBuzz at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/harfbuzz
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/harfbuzz/attachments/20140609/11b9a82d/attachment.html>