TableRecord.checksum for 'head' entry if in a TTC

[PeterConstable]

The spec isn't clear about how table checksums (TableRecord.checksum) should be calculated for certain tables when generating a TTC.

For the 'head' table, the question is really about what value to write as head.checksumAdjustment. It may be there's nothing that would really make sense, and so perhaps it could be left at zero. But the spec is silent.

Also, some tables may get modified as part of a TTC merge. In particular, loca and glyf or CFF/CFF2. Should table checksums for these get recalculated after merging data from the source TTFs/OTFs? Or should these just be ignored? Again, the spec currently doesn't say.

The spec shouldn't be silent on these details, leaving ambiguity about what tool developers should do. If it doesn't matter what is written, the spec should say that.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 6a1bda96-a268-b684-6cea-9b0c7be6f24e
• Version Independent ID: 36485fec-f05d-3984-6da8-ff2dd2799041
• Content: OpenType font file - Typography
• Content Source: typographydocs/opentype/spec/otff.md
• Product: typography
• GitHub Login: @PeterCon
• Microsoft Alias: PeterCon

[PeterCon]

Cf. #512

[HinTak]

The tables are still grouped by individual member fonts, so probably re-calculating the checksum if they do change, is in order.

In practice this is a non-issue, since AFAIK there are no tool for merging ttc at the level of merging table contents. Tables between member fonts are either identical (in which case, one copy is outputted) or different (in which case multiple ones are outputted). No attempts are made on reconciling differing member tables. There is also little incentive of doing so: the size benefit is not high, so the bulk of a font file is the glyf table, and if the glyf table is identical (with unused glyphs), anything that refers the glyf table tends to be identical.

Merging glyf tables across fonts is a big undertaking, but that will also merge loca, so that comes as a side-effect. But, merging glyf tables requires rewriting every other tables...

[PeterCon]

AFAIK there are no tool for merging ttc at the level of merging table contents...

Actually, I'm pretty sure the primary reason TTCs were invented was to de-dup common glyphs in CJK fonts (e.g., MingLiU vs. PMingLiU). So, I think merging of loca/glyf tables is common, in spite of domino-effect adjustments that might be needed in other (non-shared) tables.

[HinTak]

Yes, MingLiu and PMingLiu shares a common glyph table (by having some glyphs - a small fraction - not used in one vs the other). I assume that's a "pre-process" step though, by expanding each with extra glyphs first, until they are identical.The expansion reculculates the table checksums, as they are still individual fonts.

[behdad]

In practice this is a non-issue, since AFAIK there are no tool for merging ttc at the level of merging table contents.
...
Merging glyf tables across fonts is a big undertaking, but that will also merge loca, so that comes as a side-effect. But, merging glyf tables requires rewriting every other tables...

Why do you opine about things you don't know about?

[behdad]

My opinion:

1. Checksums are irrelevant and I suggest deprecating them,

2. Short of the above, is clear to me that the checksum for head table in each face within a TTC should be calculated as if this was NOT a TTC and just a single OTF.

[behdad]

I realize doing it that way is a waste of compute resources though, so I suggest we just deprecate them now instead of looking for an answer.

[behdad]

2. Short of the above, is clear to me that the checksum for head table in each face within a TTC should be calculated as if this was NOT a TTC and just a single OTF.

That seems to be what fonttools does in my reading.

[PeterCon]

Right now, the spec requires a checksum be calculated for every table, but is silent about what, if anything, needs to be done differently for a TTC. There is at least one ambiguity not made clear, which is what to do with head.checksumAdjustment. I've no particular objection to deprecating checksums, but that's a much more radical change that would require broad consensus. For now, I'm just trying to clarify what is currently expected.

Would it be fair to say the following?

• within a TTC, checksums in each TableRecord are calculated for the tables as they exist within the TTC (reflecting any merging that may have occurred)
• the head.checksumAdjustment is ignored and should be set to zero

Is that consistent with what fonttools does?

[PeterCon]

Why do you opine about things you don't know about?

Please be careful not to say things that may appear disrespectful of others.

[behdad]

• the head.checksumAdjustment is ignored and should be set to zero

The "should be set to zero" part is a new requirement, so I'd argue against doing that.

FontTools seems to calculate head table checksum according to the spec as if it was a non-collection font.

[PeterCon]

It's worded as a recommendation, not a requirement. It could be relaxed further: may be set to zero.

So, FontTools is calculating the head.checksumAdjustment(s) by summing across the entire TTC file? (If so, I wouldn't assume that's the case in all tools.)

[HinTak]

As I wrote earlier, current tools behave as if merging is done in two separate logical steps:

• expand the glyf table to accommodate extra and unused glyphs, until the individual fonts contain the exact same glyphs, in exact same order. And adjust checksums accordingly.

• then, de-duplicate identical tables, and replace with reference to common identical entries, when concatenating.

[behdad]

It's worded as a recommendation, not a requirement. It could be relaxed further: may be set to zero.

Sounds good to me.

So, FontTools is calculating the head.checksumAdjustment(s) by summing across the entire TTC file?

No.

Because of the way the checksum algorithm works (it just adds...), if you have a TableDirectory as well as a bunch of tables padded to four-byte padding, no matter how you order those, it results in the same "single-font checksum". That's what FontTools calculates.

[behdad]

As I wrote earlier, current tools behave as if merging is done in two separate logical steps:

You are wrong.

[behdad]

Please be careful not to say things that may appear disrespectful of others.

That's a slippery slope and is commonly used to thwart freedom of speech, which is widely considered a universal human right.
For example, some religious groups often use "getting offended" to shut down dissidents.

I, personally, feel disrespected and offended when others talk about things they are not qualified to talk about.

[HinTak]

How is what I wrote different from what you wrote, quote , it results in the same "single-font checksum". ?

[behdad]

How is what I wrote different from what you wrote, quote , it results in the same "single-font checksum". ?

Your "expand the glyf table to accommodate extra and unused glyphs" is wrong and doesn't make any sense.

[HinTak]

(sigh...)

[PeterCon]

Proposed change for next version: add the following at the end of the Checksum section:

Within a font collection file (see below), table checksums must reflect the tables in the collection file. The checksumAdjustment field in the 'head' table is not used for collection files and may be set to zero.

[HinTak]

Suggest small change: "table checksums must reflect the tables **as they are ** in the collection file"?

[PeterCon]

Thanks. Revised draft:

Within a font collection file (see below), table checksums must reflect the tables as they are in the collection file. The checksumAdjustment field in the 'head' table is not used for collection files and may be set to zero.