test Coverage object if it has a Format attr about compositor

[behdad]

Correct.

(Didn't know anyone relies on it. I'm open to reconsidering that. But basically the reason was that the "Format" is not needed to use the coverage data, and best format is automatically chosen when compiling the font and the Format set on the object is ignored. The only use it can possibly have is informational.

[typesupply]

FontTools is very frequently used to inspect the data inside of a font, not just to modify it and recompile it. CoverageFormat is an official part of the spec.

Is there a change list somewhere of all the things that you've done since forking from the original FontTools? We're running into lots of things so it would be good to have something to review.

[benkiel]

+1 on @typesupply's request

There are several things that I use/have written over the past decade that rely on FontTools working in a stable way. A change list would be very helpful.

[behdad]

This can be closed now.

[adrientetar]

This can be closed now.

I am still experiencing this bug.

[behdad]

This can be closed now.

I am still experiencing this bug.

Humm. Even after this commit:
fonttools/fonttools@6851f66

[adrientetar]

Humm. Even after this commit:
fonttools/fonttools@6851f66

Yea.

[behdad]

Humm. Even after this commit:
fonttools/fonttools@6851f66

Yea.

Can you please debug it then?

[adrientetar]

@behdad Should buildCoverage in otlLib set the Format attribute? Currently in feaLib neither preWrite() nor postRead() methods of Coverage are called so no Format attribute is set.

[behdad]

Ah, ok, so you are not actually loading from binary. Then that's a separate issue...

Tal, would be nice if you can merge the original suggestion. Or better, just remove the CoverageFormat member completely. There is no use for the Format of a Coverage table as the FontTools layer hides the different formats.

I'm hesitant to add a hack in otlLib to add Format, which would be wrong. Just told me today that he has updated his code that relied on the Coverage.Format to avoid it. Perhaps it's time to accept that my fork of fonttools is what everyone is using?

[adrientetar]

would be nice if you can merge the original suggestion.

I don't know what you are hinting at here but actually, yeah, CoverageFormat isn't internally used in the code so presumably there's no reason to keep it.
I'm submitting a PR for that (I assume if it gets merged, then you are free to revert your patch that keeps the Format attribute around).

[typesupply]

I'll remove CoverageFormat. No big deal. Compositor abstracts the different formats as well.

[adrientetar]

@typesupply Put you a PR up for it.

[typesupply]

Done. Thanks!

[behdad]

Thanks Tal.