[HarfBuzz] Should MarkToBase attachment zero the mark advance?
moyogo at gmail.com
Mon Aug 23 13:17:09 PDT 2010
On Mon, Aug 23, 2010 at 7:46 PM, Jonathan Kew <jonathan at jfkew.plus.com> wrote:
> Hi Behdad,
> I notice that the code in MarkArray::apply() includes the following:
> hb_internal_glyph_position_t &o = c->buffer->pos[c->buffer->i];
> o.x_advance = 0;
> o.y_advance = 0;
> o.x_offset = base_x - mark_x;
> o.y_offset = base_y - mark_y;
> o.back = c->buffer->i - glyph_pos;
> i.e. in addition to setting x_offset and y_offset so as to position the mark glyph, it also explicitly overrides any existing x_advance and y_advance values for the glyph, settings them to zero. In many cases, this is harmless (though redundant), as mark glyphs are typically designed with zero advance anyway.
> However, I'm seeing problems in several monospaced fonts as a result of this; an example is DejaVuSansMono.ttf. Here, the mark glyphs have the same (non-zero) advance as the rest of the glyphs -- logical, I suppose, for a fixed-width font. There is a GPOS 'mark' feature that positions diacritics such as the U+03xx range. The trouble is that this feature actually executes TWO lookups for these glyphs: first, it does a MarkToBase Attachment (type 4), to place the diacritic over the base glyph, AND THEN it does a Single Adjustment that modifies the advance of the diacritic glyph by the negative of its original advance. This is clearly intended to make it become zero-width; but because harfbuzz has already zeroed the advance, it now ends up with a NEGATIVE advance, and the result is that the next glyph completely overprints the accented character.
> So unless you know of specific reasons why it is necessary to zero the x_advance and y_advance values here (are there examples of fonts where the rendering is incorrect without this?), I'd suggest removing those two lines, as in the attached patch.
> With that change, I'm getting the expected rendering with DejaVuSansMono. (The same issue occurs with the Consolas font on Windows7, for example.)
DejaVu SansMono uses this trick because renderers are'nt handling
zero-width characters in proper monowidth fonts. I guess Consolas
started doing it for the same reasons.
In a perfect world, this should be done in the renderer, and not by
using GPOS on marks.
Denis Moyogo Jacquerye --- http://home.sus.mcgill.ca/~moyogo
African Network for Localisation http://www.africanlocalisation.net/
Nkótá ya Kongó míbalé --- http://info-langues-congo.1sd.org/
DejaVu fonts --- http://www.dejavu-fonts.org/
More information about the HarfBuzz