Re: [ft-devel] Improved Arabic auto-hinting

[Werner LEMBERG]

Folks,


within the next months I'm going to add many scripts to the
auto-hinter (and eventually to ttfautohint), and I will report
progress here so that you can test the forthcoming changes, as
usual :-)

A few weeks ago Behdad pointed out a non-trivial issue in the current
implementation of Arabic auto-hinting support, to which I responded as
follows.

>>>> This effect:
>>>>
>>>>   https://www.flickr.com/photos/behdad/34769511/
>>>>
>>>> still happens in my limited testing.
>
> Thanks.  IMHO, this is not a bug in the autohinter; it's a font bug:
> The overlapping of glyphs isn't constructed correctly, which makes
> repeated drawing of the overlapping parts problematic, as described
> in your blog entry.

Meanwhile I think that calling this a `font bug' is too harsh, since...

> For comparison, here an image using a font by Titus with the same
> hb-view command.  Another image shows how the joining parts are
> designed to avoid (or to reduce the effects of) exactly this
> problem.

... even with Titus's solution you get similar effects at different
resolutions.  However, the overlaps are a bit shorter, which might be
still a good thing.

> What you envision, namely the cropping of the outline outside of the
> advance width so that there is no overlapping at all (as discussed
> during our meeting at ATypI) is a different topic – not sure how to
> achieve that reliably in an automated way...

The last few days I was thinking hard to find a solution to this
problem, since it is essential for good hinting of not only Arabic but
also of Devanagari, which exhibits exactly the same issue.

I came up with two possible solutions, and I would like to hear your
opinions to it.

A preliminary: Tag the `overlap blue zone' as special.  This should be
a safe thing for the two scripts since the overlap always happens at
the same vertical position.  [I have still to investigate how to make
this work for the Nastaliq style.]

  (1) Always enforce `strong' hinting for the overlap blue zone.  This
      means that the bottom and the top of the affected horizontal
      stem is aligned to the grid.  Overlapping such stems then don't
      produce additional ink.

      There are two possible disadvantages for rendering at small
      sizes.

      (a) The overlapping blue zone might appear `too black' at very
          small sizes, since the auto-hinter doesn't enforce alignment
          to the grid normally if there isn't enough vertical space.

      (b) Enforcing a single blue zone to the grid might also distort
          the shape more than necessary at small sizes, reducing its
          legibility.  Note, however, that you already get a similar
          effect with ttfautohint's `strong hinting' option (e.g.,
          using `-w gGD'), and it is not *that* bad :)

      The abovementioned disadvantages are only of importance for
      sizes below, say, 14ppem.  With modern high-DPI displays this is
      probably not an issue at all.

  (2) Crop the outline outside of the advance width as suggested by
      Behdad, but only between the top and the bottom of the overlap
      blue zone (to limit the cropping to the essential part of the
      glyph): This would ensure that there is no overlapping at all.

      While this algorithm avoids issues (a) and (b) of solution (1),
      there is a disadvantage also: Implementing this is far more
      complicated than (1); in particular, I have to compute the
      intersections of the lines x=0 and x=advance_width with the
      outline, which leads to third-order polynomials (cf. the
      attached image of an Arabic Noto glyph).[*] However, I guess
      that it won't add a lot of computational overhead since it
      should be straightforward to find good starting conditions for
      quickly and reliably iterating to a solution.

Please comment.  Personally, I tend to solution (2), but solution (1)
is probably the better one in practice, because it is what you have to
use to make a TrueType font render correctly on Windows, I guess.  Is
this assumption correct?  How does unhinted Noto look with recent
ClearType versions on Windows?  Do you also get the overlap artifacts
if horizontal stems are not aligned to the grid?


    Werner


[*] Basically, I consider it a bug that in all Arabic Noto glyphs
    there is no horizontal tangent at x=advance_width.  On the other
    hand, the difference is negligible, I reckon.