Bounding Box not kept in conversion about woff2 HOT 9 CLOSED

This happens because:

1. The font has wrong bounding box info in the glyf table (ie, claims xmin=0 while it's clearly not the case),
2. Reference implementation always throws away the bounding box. That has been a known issue. Ie, check sbbox_ in transform.cc; it's never set to true.

from woff2.

Interesting. This whole library is a bit over my head, or I would try to do a pull request (not even sure where to start).

WOFF2 Spec on Bounding Box

By the way I think this is the only open source WOFF2 converter, so hopefully someone that runs into it can solve it.

from woff2.

There's also this:
fonttools/fonttools#222

I haven't merged it yet.

from woff2.

Setting sbox_ to true is not enough since the bounding box is already normalized (i.e. recalculated) at this point. To fix this one needs to drop NormalizeSimpleGlyphBoundingBox() and instead use similar code in WriteSimpleGlyph() to calculate the bounding box, compare it with the original and if it is different call WriteBbox(). The sbbox_ as well as cbbox_ member variables should just be dropped.

from woff2.

Have you seen a conformance test that would cover this? If not, I suppose
we should add one.

On Fri, Apr 10, 2015 at 12:33 PM, Khaled Hosny [email protected]
wrote:

Setting sbox_ to true is not enough since the bounding box is already
normalized (i.e. recalculated) at this point. To fix this one needs to drop
NormalizeSimpleGlyphBoundingBox() and instead use similar code in
WriteSimpleGlyph() to calculate the bounding box, compare it with the
original and if it is different call WriteBbox(). The sbbox_ as well as
cbbox_ member variables should just be dropped.

—
Reply to this email directly or view it on GitHub
#12 (comment).

from woff2.

Yes, there is http://dev.w3.org/webfonts/WOFF2/spec/#conform-mustCalculateOmitBBoxValues and http://dev.w3.org/webfonts/WOFF2/spec/#conform-mustHaveCompositeBBox.

from woff2.

Just for the record, an alternative, more filesize-friendly, way to fix it is: if the incoming bounding box of a glyph is wrong, fix it (ie. normalize it), but adjust the lsb in hmtx to offset the change, so the glyph doesn't shift.

from woff2.

But this would work only for this particular case, not for the general case of setting a bounding box different from what the font actually has.

(Playing with the bounding box is not something I have seen in the wild, but for a while I wanted to explore it in math fonts to control glyph stacking to be uniform for some glyphs that have different “natural” bounding boxes, a trick used by some traditional TeX math fonts).

from woff2.

I just got around to testing the patch that @khaledhosny has suggested and it solves the issue for me.

Comparison vs Third Party

My test font has 1035 glyphs. This is an odd comparison obviously, but thought I would share it to illustrate that a third party tool does have a smaller size.

from woff2.