Re: Progress update on adjustments database branch.

[Werner LEMBERG]

Hello Craig (and Ahmet),


sorry for the very late reply, but right now there is soon the end of
the semester here in Austria, which means a lot of extra exams and
meetings.

> To implement this adjustment, I inserted a step after all other
> alignment steps in af_latin_hints_apply, which corrects the results
> of the previous steps to ensure proper separation.

I think this is the right solution.

> The function implementing that step looks up the glyph index to
> determine what type of vertical separation is needed, or if it
> doesn't apply.  To do this, it uses a reverse character map that was
> calculated by looking up every unicode code point referenced in the
> adjustment database in the font's cmap and stored with the global
> metrics.

As mentioned earlier, if everything works fine, this must be
eventually expanded to also cover glyphs only accessible via the
'GSUB' table.

> I have also learned that fonts using multiple contours where a
> single one would do isn't an unusual case, so a mode that does not
> need to assume the bottom shape is 1 contour will be the next thing
> I do.

Yes, this can happen especially in Variation Fonts.

> Here are some pictures demonstrating the changes:
> https://imgur.com/a/HXGY2oJ

Very nice!  Please also post some images with text paragraphs at
different sizes so we get a feeling for the whole thing (see below
also).

BTW, please attach images directly to your e-mails so that they get
stored in the e-mail list archive, too.

> Here are my main concerns about this approach:
>
> - Because vertical separation adjustments are a step after all other
>   steps, they have the potential to clash with assumptions made by
>   the previous steps, or to violate constraints.  Does anyone know
>   of issues I should watch out for?

I'm not aware of any.  I consider the adjustments database as
something similar to the family of DELTA instructions in TrueType
bytecode, which are used for last-moment fixes to adjust certain glyph
points at certain PPEM values to ensure good rendering.  This is
always done as the very last thing, right before rendering.

> - To determine which contours are higher or lower, and to adjust
>   their position, the algorithm makes multiple passes through all
>   points in the glyph.  Could this be a performance issue?

Ahmet, this would be a nice cooperation – can you test Craig's branch
with your code to check that?

> - When the assumptions the algorithm makes are broken, it can do
>   extreme modifications to the glyph's shape.  For example, this is
>   what happens when you tell it that the double quotes character
>   should be adjusted with the "one glyph stacked on another" mode:
>
>     https://imgur.com/a/JrUTMrQ
>
>   The algorithm arbitrarily chose one of the quotes as being higher,
>   and pushed it until it cleared the other one by a pixel.  This
>   would happen in practice if someone mapped codepoint i to double
>   quotes in their font.  How much of an issue is this?  Do any fonts
>   do this?

FreeType always assumes that fonts do not cheat.  In other words, the
mapping from the input character to the output character *must* be
correct.  It was common practice in the days of very old Windows
versions (more than 20 years ago) that some fonts abuse the ASCII
range for, say, Hebrew glyphs because correct support was lacking.
Today, this is no longer an issue.  So: no, this isn't an issue at
all.

> I could prevent it by limiting the distance it can push something up
> by a pixel or two.

This might be a good idea in general since sometimes glyphs are
designed in weird ways: For example, the two vertical strokes of the
doublequote character might have different vertical positions, and
such 'inaccuracies' (in the broadest sense) must not lead to bad
results.

> - Werner previously suggested that a gap of less than one pixel,
>   instead of one full pixel as I'm currently doing, might be better
>   in some cases.  Does anyone know of such a case?

'Waterfall images' of short paragraphs can answer this, I think, so
please post them for some selected fonts.  BTW, I can also imagine the
opposite, namely that a separation of one pixel might not be
sufficiently large for some PPEM values to produce good-looking
output.


    Werner