Different BBox in head and CFF table

I checked my final fonts with the comparefamily command, and it tells me: “The font bounding box in the hhea table differs from that in the CFF table”. I never got this message when I generated the fonts directly in AFDKO. Is there any reason for the different values?

Both tables are written by makeOTF. Can you send me the .glyphs file that I can have a look?

It is happening the same thing to me.

The font bounding box in the hhea table ‘(-403, -248, 1193, 947)’ differs from that in the CFF table ‘[-146, -248, 1193, 947]’. Plural-Regular.

Only the first number in the array differs. any way to fix this?

Are your combining marks made of spacing-mark components?

what is spacing-mark components? I think this is happening because the width of commaaccentcomb is changed to zero on the final fonts,

can I change commaaccentcomb to spacing-mark component? It doesn’t seem to let me do that,

Only if you change the respective glyph info. But I would not recommend it. It is supposed to be zero (no advance width), because the cursor is not supposed to move.

Ok, I’ll turn to width of my marks to zero then. Thanks

I have noticed that this happens only when Glyphs changes the widths of certain characters when generating the fonts.

For example: I have a glyph called commaaccent, which has a certain (positive) width. Now Glyphs changes the width to zero (when exporting the font). It seems that one value for the BBox is the one from the production file (so my values), the other one the values from the final font (so Glyphs’ values). This might be the reason for the different values. Not sure, if this is a problem though.

I assume the CFF table value is then directly from the /FontBBox statement in the font.ps file, which is written by Glyphs, while the one in the head table is actually calculated by makeotf. I compared with app versions 956 and 954, and the .ps file (and therefore, the CFF table values) are the same across all three versions.

Me neither. Have you encountered any rendering problems, presumably occurring, if at all, when combining accents are used?

I never used combining accents.

I don’t use combining accents either. I jus made all my marks width = zero, both spacing-marks and nonspacing-marks. Now both tables are the same, since none of the withs change at export.

Would it be better if in the combining marks, only the width changed to zero at export leaving the outlines coordinates unchanged?

I’ll fix the calculation of the bbox.
The none combining accents should have a width. Otherwise the dead key input of accented letters will not work properly.

ok, great. Thanks!

That is almost what happens now already. The left sidebearing is retracted onto the right sidebearing. That usually means that the x coordinates change.

Fixed it.

2 Likes