[DMAP] Fleshing out

[behdad]

The DMAP proposal has been around. It's supposed to be a "delta map" on top of cmap, such that collections can share cmap and encode their differences in a separate DMAP table per font.

I suggested copying the cmap table exactly as DMAP. It was suggested that only a few formats (4, 12, 13, 14) be allowed. I don't see why disallow other formats, since I expect implementations to share the code for cmap and DMAP processing. Hence my suggestion.

The next, unresolved, issue with DMAP was what to do when a variation-sequence in format 14 maps to the "default" glyph for the character. Ie. should it take the default from DMAP, or cmap. The situation can arise with both DMAP and cmap table format 14 subtables.

Here's my proposal: the default is looked up in DMAP and if not found, in cmap. Ie. a regular lookup for that character happens. This simple way allows for both possibly desired behaviors, of getting the default from DMAP, or from cmap.

In pseudo-code (and very likely how it will be implemented in HarfBuzz):

unsigned get_nominal_glyph(font_t *font, unsigned u)
{
  unsigned g;
  g = font->dmap.get_nominal_glyph(u);
  if (g == 0) 
    g = font->cmap.get_nominal_glyph(u);
  return g;
}

#define USE_DEFAULT ((unsigned) -1)

unsigned get_glyph_variation(font_t *, unsigned u, unsigned vs)
{
  unsigned g;
  g = font->dmap.get_glyph_variation(u, vs);
  if (g == 0)
    g = font->cmap.get_glyph_variation(u, vs);
  if (g == USE_DEFAULT)
    g = get_nominal_glyph(font, u, vs);
  return g;
}

[skef]

Seems like the main question that's been raised on the email lists but not here is whether DMAP should have some means of negative mapping -- a means of ignoring a mapping in the underlying cmap.

[behdad]

Seems like the main question that's been raised on the email lists but not here is whether DMAP should have some means of negative mapping -- a means of ignoring a mapping in the underlying cmap.

It can always override it. No?

[skef]

It can always override it. No?

You might want the mapping to go away so that a code point falls back to the next font in the resolution list.

[skef]

(An alternative, discussed in that same thread, is to only have the intersection of the codepoints in the cmap and then have a dmap for every sub-font, rather than having a cmap only for one sub-font and dmaps for the others. It's not clear to me that that isn't the correct solution for this.)

[Lorp]

The same issue occurred to me. Mapping to glyph 0, by current definitions, means "look in cmap for fallback" so cannot act as an override to declare a subfont must not render a particular character. A workaround would be to encode the null mapping in cmap, and ensure all subfonts that need a non-zero glyphId for that character to encode it in DMAP (this may be more efficient than giving any of the subfonts their own cmap).

[liamquin]

This thread is now sounding like a usage possibility rather than a change to the dmap draft, right?

[skef]

@liamquin It depends. If the group is happy with the cmap only containing the intersection, and dmap having all the "extras", then nothing needs to change in the spec. If they want to be able to have the cmap be for one sub-font, and then have dmaps with the differences with the other sub-font, then you need some way of cancelling mappings in the cmap via the dmap, which would be a change.

[liamquin]

I’ve posted a dmap draft that tries to address Format 14 (thanks, Behdad!) but doesn’t reflect this topic; i took @Lorp to be suggesting a way the same result could be accomplished. For the use cases we have for dmap right now, with large fonts, especially CJK, it seems to me there’s got to be a font compiler doing the work here, so indeed cmap having an intersection would make sense, and likely even that could be shared. Well, the new draft should appear some time in the next few hours, and i'll send it around by email tomorrow night if not.

So far, this is where the group would say they wanted something different, and they haven't (or i missed it). Although i’m not sure there’s a whole lot of attention being given to dmap right now, so maybe it'll wake up, or maybe people will decide it’s not worth it, i’m not sure. Me, i wondered at Portland whether TTC could be extended to do hybrid fonts instead of all these uppercase/lowercase table names, but it was not a popular suggestion :-)

[behdad]

Yeah I think dmap completely removing a codepoint from the font is out of scope.

[nedley]

Straw proposal: dmap mapping to 0 (whether due to explicit mapping or no entry) means “use cmap”, and dmap mapping to a value greater than or equal to the number of glyphs (determined by parsing mode) means “remove this code point or UVS”.