OpenType字体报错咨询：无支持字形表等多问题排查

Hey there, let's tackle your font validation issues and questions one by one—this looks like a mix of metadata misalignment, structural table problems, and compliance with Google Fonts standards.

Absolutely—CFF2 is the modern PostScript table format built specifically for variable fonts, and it’s supported by most modern browsers, operating systems, and font tools. The errors you’re seeing (Mac validator saying "no recognizable glyph data" and ots-sanitize failing with no supported glyph shapes table(s) present) aren’t because CFF2 is invalid, but likely because your CFF2 table is misstructured or not properly linked to other required tables in the font.

Since you confirmed the CharStrings INDEX in CFF2 has glyph data, the problem is probably tied to:

• Unordered table directory or unsorted name records (as noted in the ots-sanitize error)
• Missing or incorrect references between the CFF2 table and core tables like head or maxp
• Corrupted offset data in the CFF2 INDEX (which might also be causing the repeated "offSize too large: 185" assertion error)

Fix these structural issues first, and CFF2 should work as intended.

It depends on your use case:

• TTF: Offers the broadest compatibility, especially with older operating systems (pre-2019 macOS/Windows versions) and legacy tools. If you’re targeting a wide range of devices without needing variable font features, TTF is a safe bet.
• CFF (CFF1): The original PostScript table format, ideal for print workflows and non-variable fonts where file size efficiency is a priority. It’s well-supported but not optimized for variable fonts.
• CFF2: The only PostScript format for variable fonts, and it’s more efficient than TTF for variable font data. If you’re building a variable font, stick with CFF2 and fix the structural issues. If you don’t need variable features, switching to TTF/CFF1 might simplify compatibility, but it’s not mandatory—you can get CFF2 working with proper fixes.

The question about hhea.advanceWidthMax matching every glyph’s advanceWidth is a critical check for monospace fonts. Here’s the breakdown:
For a font to be truly monospace, every glyph must have the exact same advance width—this ensures consistent spacing between characters, which is essential for code, terminals, and any use case where alignment matters.

hhea.advanceWidthMax is a metadata field that stores the largest advance width value in the font. For a valid monospace font, this value must equal the advance width of every single glyph (since all widths are identical, the "maximum" is just that shared width). If they don’t match, it means some glyphs have different widths, so the font doesn’t meet monospace standards.

Based on your fontbakery check-googlefonts results, here’s the checklist of requirements your font needs to meet:

Mandatory Fixes #

• Version Consistency: The head table version (currently ('1', '000')) must match the version string in platform 1, encoding 0 of the name table (currently ('0', '000')). Update both to the same value (e.g., 1.000).
• Glyph Coverage:
  • The first glyph in the font must be .notdef (required for fallback when an unsupported character is requested).
  • Include blank glyphs for Unicode code points 0x0020 (space) and 0x00A0 (non-breaking space).
  • Add the Euro symbol (0x20AC)—this is a requirement for Google Fonts.
• Metric Alignment:
  • Ensure OS/2 sTypoAscender equals hhea ascent (these metrics need to be consistent for cross-platform rendering).
  • Set OS/2.usWinAscent to a value ≥200 (your current value is 0, which will break rendering on Windows).
• Table Structure:
  • Fix the CFF2 table issues: resolve the "offSize too large" error, sort the table directory and name records, and ensure the system can recognize glyph data in CFF2 (this will fix both the ots-sanitize failure and the Mac validator error).
  • Use a valid, registered OS/2 VendorID (replace XXXX with an ID registered via Microsoft’s portal).
• Naming: Rebuild the font to use a规范的样式名称 (e.g., "Regular" must follow Google Fonts naming conventions—avoid custom or non-standard labels).

Recommended Improvements #

• If you’re building a variable font, change unitsPerEm from 1000 to 2000—this provides more precision for interpolating glyph shapes, resulting in higher-quality variable font output.

内容的提问来源于stack exchange，提问作者user10869858