[subset] MATH: don't serialize coverage table when iterator is empty

[qxliu76]

when iterator is empty, just set coverage offset to 0.
serialize() in coverage will at least write out a 16-bit format header.

I didn't change serialize() method to return early, since I noticed sometimes fonttools keeps this header for other tables.
This minor cosmetic change mainly aims to match fonttools's result for MATH table, so that we have less diff noise during ttx comparison.

[behdad]

I didn't change serialize() method to return early, since I noticed sometimes fonttools keeps this header for other tables.
This minor cosmetic change mainly aims to match fonttools's result for MATH table, so that we have less diff noise during ttx comparison.

Well, then find a software engineer to do the thinking for you to see if we can change fonttools as well to remove that header. Then come back.

[behdad]

I didn't change serialize() method to return early

The real reason probably has to do with this: serialize returning false means "failed". It's only subset returning false that means "not needed".

[behdad]

sometimes fonttools keeps this header for other tables

Can you point to examples? I have a hard time imagining that.

[qxliu76]

sometimes fonttools keeps this header for other tables

Can you point to examples? I have a hard time imagining that.

Here's an example:
pyftsubset test/subset/data/fonts/Roboto-Regular.abc.ttf --text=abc --output-file=test.ttf

In output GDEF table, there're non-zero coverage offsets for empty coverage tables in MarkGlyphSetsDef

I found some comments in harfbuzz code explaining this:
//not using o->serialize_subset (c, offset, this, out) here because
//OTS doesn't allow null offset.
//See issue: khaledhosny/ots#172

[behdad]

In output GDEF table, there're non-zero coverage offsets for empty coverage tables in MarkGlyphSetsDef

Okay, thanks. Next time please include all your findings such that the reviewer can make an informed decision. FontTools is not impeccable, so "to match fonttools" is not enough reason to write code in HarfBuzz. Thanks.

[qxliu76]

In output GDEF table, there're non-zero coverage offsets for empty coverage tables in MarkGlyphSetsDef

Okay, thanks. Next time please include all your findings such that the reviewer can make an informed decision. FontTools is not impeccable, so "to match fonttools" is not enough reason to write code in HarfBuzz. Thanks.

sure!

[khaledhosny]

FWIW, both Chrome and Firefox release builds don't pass the three G* layout tables to OTS, so you might want to ignore it's illuminations regarding these tables.

[behdad]

FWIW, both Chrome and Firefox release builds don't pass the three G* layout tables to OTS, so you might want to ignore it's illuminations regarding these tables.

Yeah I was thinking it might be time we should relax that limitation in fonttools subsetter as well, as I think OTS was fixed a while back. Khaled, do you remember?

[khaledhosny]

I think we fixed some of these null offsets long ago, it is worth retesting if OTS still rejects them

[behdad]

I think we fixed some of these null offsets long ago, it is worth retesting if OTS still rejects them

Yeah that's also my recollection.

[behdad]

Yeah that's also my recollection.

@qxliu76 Is that something you can look into?

[qxliu76]

Yeah that's also my recollection.

@qxliu76 Is that something you can look into?
yeah, I can try to do some testing