Search code examples
fontstruetypefile-format

Number of font tables in TrueType Font files?

According to Apple's Reference manual for TrueType font files, there are 45 different types of font tables. Checking those ttf I have installed on my system, I have acertained that the number of tables actually present in those files ranges from 12 to maximum 22 font tables per file.

Looking further at the structure of a true type font file, it start with this information:

uint32 scaler type A tag to indicate the OFA scaler to be used to rasterize this font; see the note on the scaler type below for more information.
uint16 numTables number of tables
uint16 searchRange (maximum power of 2 <= numTables)*16
uint16 entrySelector log2(maximum power of 2 <= numTables)
uint16 rangeShift numTables*16-searchRange

which gives reason to believe there would be a common need for the precalculated, but yet totally imho redudant fields rangeShift, entrySelector, searchRange. It even states them to be employed for binary searching of the list of font tables:

The entries for searchRange, entrySelector and rangeShift are used to facilitate quick binary searches of the table directory that follows (source https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6.html)

A valid reason to even consider adding those fields, which could anyway be calculated on the fly from numTables would be indeed that there is a large number of font tables.

My question is therefore, if despite my testing there exist indeed occasions in which true type fonts are reasonably to be expected to have a larger (e.g. >1000) number of tables, which would imply the question if it is at all possible that any of the 45 different type of font tables can occure multiple times?

The tables it listed are the following.

  1. The 'acnt' (accent attachment) table
  2. The 'ankr' (anchor point) table
  3. The 'avar' (axis variation) table
  4. The 'bdat' (bitmap data) table
  5. The 'bhed' (bitmap font header) table
  6. The 'bloc' (bitmap location) table
  7. The 'bsln' (baseline) table
  8. The 'cmap' (character code mapping) table
  9. The 'cvar' (CVT variation) table
  10. The 'cvt ' (control value) table
  11. The 'EBSC' (embedded bitmap scaling control) table
  12. The 'fdsc' (font descriptor) table
  13. The 'feat' (layout feature) table
  14. The 'fmtx' (font metrics) table
  15. The 'fond' (font family compatibility) table
  16. The 'fpgm' (font program) table
  17. The 'fvar' (font variation) table
  18. The 'gasp' (grid-fitting and scan-conversion procedure) table
  19. The 'glyf' (glyph outline) table
  20. The 'gvar' (glyph variation) table
  21. The 'hdmx' (horizontal device metrics) table
  22. The 'head' (font header) table
  23. The 'hhea' (horizontal header) table
  24. The 'hmtx' (horizontal metrics) table
  25. The 'just' (justification) table
  26. The 'kern' (kerning) table
  27. The 'kerx' (extended kerning) table
  28. The 'lcar' (ligature caret) table
  29. The 'loca' (glyph location) table
  30. The 'ltag' (language tag) table
  31. The 'maxp' (maximum profile) table
  32. The 'meta' (metadata) table
  33. The 'morx' (extended metamorphosis) table
  34. The 'name' (name) table
  35. The 'opbd' (optical bounds) table
  36. The 'OS/2' (compatibility) table
  37. The 'post' (glyph name and PostScript compatibility) table
  38. The 'prep' (control value program) table
  39. The 'prop' (properties) table
  40. The 'sbix' (extended bitmaps) table
  41. The 'trak' (tracking) table
  42. The 'vhea' (vertical header) table
  43. The 'vmtx' (vertical metrics) table
  44. The 'xref' (cross-reference) table
  45. The 'Zapf' (glyph reference) table

It seems that the "font tables" allow any random "extension" among them, as for instance there is a font table labeled FFTM, which

"[...] is unique to FontForge. It contains three timestamps: First FontForge's version date, then when the font was generated, and when the font was created. I describe its format here."

https://fontforge.github.io/TrueOpenTables.html

Still even those occasional added tables like FFTM would not seem to merit the fields searchRange etc.

Solution

  • When TrueType was invented in the late 1980s/early 1990s, the developers were not certain how things would evolve as the format was adopted. Also remember that processor speeds were considerably slower then.

    As it turns out, indeed, few fonts have more than about 25 tables, and probably none that approach the number where a binary search and the use of the pre-calculated fields would make much difference in locating a table (versus just iterating through the sorted list).

    Nevertheless, the fields are part of the specification and can’t be “omitted”. Many implementations ignore the fields, and they are frequently filled with wrong values, but be aware that many font checkers/validators/sanitizers DO check them and might flag wrong values as an invalid font. So if you’re asking this question as regards creating a font, I would advise filling in the fields with correct data.