Re: Progress update on adjustment database

[Werner LEMBERG]

>> A mapping from input Unicode characters to glyph indices based on
>> the GSUB + cmap tables and not on cmap alone.
>
> Right now, the only cases where the GSUB table is helpful that I am
> aware of, for the purposes of this project, are for handling glyph
> alternates and combining characters.  Those would be one-to-one
> mappings and many-to-one mappings, respectively.

Yes.

> Would this general solution involve other kinds of GSUB mappings?

Yes, but it won't affect your database format, which always contains
single Unicode input characters (or glyph names, see below).

> If so, it opens up edge cases such as: if a glyph on the "many" side
> of a many-to-one mapping needs a vertical separation adjustment,
> does the resulting glyph need it too?  This could be answered
> quickly by looking at the specific characters involved, but how
> would I answer this question in general?
>
> Even sticking to just many-to-one and one-to-one mappings, the
> adjustment database must make assumptions specific to the characters
> it's dealing with.

Yes, I think some kind of topological tests are needed.  For example,
the following assumptions should be checked for an 'i'-like shape:

(1) There are two contours A and B.
(2) Both contours have the same direction.
(3) All points of A are lower than all points of B (or vice versa).
(4) There is some horizontal overlap between A and B.

> In the case of combining characters, a separate database table is
> required because the existing table is a list of unicode characters
> and the actions that should be applied to them, while a glyph
> resulting from a combining character might not be a unicode
> character.

I don't think you need another database.  Let's discuss an 'fi'
ligature example.

* Analyzing the GSUB table shows that it is the result of two input
  characters, 'f' and i'.
* 'f' doesn't occur in your database and can be thus ignored if it is
  about to be queried.
* 'i' appears in your database, so check whether glyph 'fi' satisfies
  the constraints for an 'i'-like shape (as described above): No, it
  doesn't, since it either is a single contour, failing condition (1),
  or if there are two contours, failing condition (3).

It would be beneficial if your database could accept also glyph names
in addition to Unicode input character codes – glyph names, if
present, follow the Adobe Glyph List conventions today, which means
that they are standardized to a certain extent.  For example, there
might be an entry for glyph name 'fi' that ensures that on the right
side of the glyph there is vertical separation between the bottom and
top shape (i.e., the merged 'i').

Another example, this time a one-to-many mapping: Let's assume that
glyph U+2173, SMALL ROMAN NUMERAL FOUR, gets mapped in the GSUB table
to two glyphs, 'v.numeral' and 'i.numeral' (but 'i' is not mapped to
'i.numeral' or vice versa because of incompatible horizontal metrics).
Let's further assume that glyph 'i.numeral' is about to be queried.

* According to the GSUB table, 'i.numeral' is part of U+2173.
* U+2173 is in your database, and the constraints for considering it
  are the same as for the 'i' entry, which are met here.

> As for the tilde correction, I'll try doing it after the grid
> fitting like you recommended.

OK.


    Werner