Re: Dealing with different character map formats when mapping glyph indicies to character codes

[Craig White]

Would you mind addressing the other approaches given, and why yours will work the best?

To me, simply looking up the characters that need adjustments beforehand to get their glyph indices makes the most sense.

On Wed, May 24, 2023 at 12:29 AM Werner LEMBERG <wl@gnu.org> wrote:

> Will it be necessary to implement the reverse mapping separately for
> every cmap format?

No.  The idea is rather to use HarfBuzz as much as possible, see
`afshaper.c`, and in particular `af_shaper_get_cluster` and
`af_shaper_get_coverage`.

Every OpenType feature consists of one or more lookups.  Using
`hb_ot_layout_collect_lookups` and
`hb_ot_layout_lookup_collect_glyphs`, it collects the glyph coverage
for every feature.

These functions should help you set up a one-to-many mapping from
glyph index to input (Unicode) character codes.  Some glyphs won't
have such a mapping; however, I think it is not necessary to exclude
GPOS lookups (contrary to blue zone handling); see big comment
starting at line 307 in file `afshaper.c`.

Setting up the one-one mapping cases from glyph index to a single
input character code should be straightforward.  However, you also
have to take care of ligatures – I think it makes sense to support
them in the forthcoming database.  Assuming that the 'fi' ligature is
in the database, you can use `hb_shape` to check whether input
characters 'f' + 'i' map to a single glyph.  This test should be done
for all features handled specially by the auto-hinter (see file
`afstyles.h`, macro `META_STYLE_LATIN`; names like 'c2cp' are OpenType
feature names).

For consistency you should add one or more `af_shaper_*` functions to
create this mapping.


    Werner