Re: Design idea for capabilities databse

[Werner LEMBERG]

> context:
> https://summerofcode.withgoogle.com/proposals/details/6CaOVRhz

I can't access this.  I get an 'Access denied' error.

> I am assuming that the list of character adjustments is small enough
> to store in-memory without issues.  This changes completely if a
> file was needed instead.

Yes, I think that in-memory is the way to go.  Compare this to
`afblue.dat`.

> The database would consist of an array of records, where each record
> contains a unicode code point and a value for each kind of
> adjustment.

Yes.  The question is whether more fields are necessary or useful.

* For example, the character 'ä' might be rendered differently for
  English ('letter a with trema') and for German ('umlaut a'): In the
  latter case, the two dots are sometimes positioned a bit lower.

* Bear in mind that in the normal case FreeType only sees the glyph
  index as an argument.  It thus have to map it back to an input
  character using the current cmap – this can be tricky, because it is
  also necessary to revert further mappings done by the 'GSUB' table.

* Another complication is that some scripts like Devanagari map
  multiple input characters to a single glyph, usually a ligature.
  Other scripts like Arabic map multiple glyphs to a single input
  character (not counting ligatures, you have an initial, medial,
  final, and isolated representation form for every character).

I don't ask to add support for these scripts, but whatever you are
coming up with, it must be easy to extend it.  My conclusion from the
above is that you need to keep track of OpenType features.

  https://learn.microsoft.com/en-us/typography/opentype/spec/featurelist

> To reduce memory footprint and take advantage of the fact that most
> characters will not have adjustments, unused entries can be left
> out, at a cost of lookup time.  The increased lookup time could be
> mitigated by sorting the code points in order and using a binary
> search.

Yes.

> Also, I have a question for Werner specifically: The Google Summer
> of Code proposal page called this database the capabilities
> database.  Why that name?  I consider "actions" or "instructions" to
> be the appropriate word the thing stored in the database, not
> "capabilities".

I guess I selected it because 'instructions' smells like 'TrueType
instructions', which is something completely different.  Similarly,
'actions' is also already taken for the auto-hinter.  However, given
that in the end you are going to map glyph indices to auto-hinter
actions (just follow the variable `num_actions` in `aflatin.c` to see
what I mean), an 'action database' might be a better term.  I'm also
not a native English speaker :-)

Please call it whatever you think fits best.


    Werner