Skip to content

Name a registered font's /BaseFont by its PostScript name - #102

Merged
bobsingor merged 1 commit into
embedpdf/mainfrom
embedpdf/fix/postscript-base-font
Nov 3, 2026
Merged

bobsingor merged 1 commit into
embedpdf/mainfrom
embedpdf/fix/postscript-base-font

Conversation

@bobsingor

Copy link
Copy Markdown
Contributor

A registered font's /BaseFont was the family it was registered under, with the spaces removed, so every weight of a family was written under one name: Noto Sans Hebrew Regular and Bold were both NotoSansHebrew. ISO 32000-2 9.6.3 and 9.7.4 make /BaseFont the font's PostScript name, and every other writer gives each weight its own (Acrobat's MinionPro-Regular, Word's Calibri-Bold, Chrome's Inter-SemiBold, WeasyPrint, pdfTeX, Quartz, PDFTron).

Readers that name fonts by it saw one font for two:

  • Acrobat's Document Properties > Fonts lists one NotoSansHebrew (Embedded Subset) for a file with both weights; with the bold one renamed, it lists both.
  • The engine's font list merged them into one 400-weight entry, so a bold box read back under the regular font's name in an engine that doesn't have the font registered.

The drawing was never wrong: each box points at its own embedded program.

What changes

  • /BaseFont is the program's own name: its PostScript name, else Family,Style as a TrueType font without one is named. The family stays the descriptor's /FontFamily, which is what reopening resolves a registered font by, so finding it again doesn't change. EPDFFont_GetPostScriptName() reports the same name, as its header already promised.
  • A variable-font instance is named as the font names that instance. Registration instances a variable font and keeps its name table, whose name 6 is the default instance's: a bold Roboto was named Roboto-Regular. Following Adobe Technical Note #5902, an instance takes its named instance's own PostScript name (RobotoRoman-Bold); else the family prefix and the instance's style (NotoSans-Bold); else the prefix and the weight (NotoSans_450wght).
  • The subset tag hashes the program as well as its glyphs. Two weights number their glyphs alike, so the same text gave them the same tag; different subsets in one file now get different tags (9.6.4).

Files written before this keep their names until a box is edited and its appearance rewritten; nothing that finds fonts depends on the old names.

Tests

  • TwoWeightsOfOneFamilyAreTwoFontsByName: Arimo Regular and Bold registered under one family give two names, two tags and one /FontFamily.
  • VariableFontInstanceWithoutItsOwnName: a Noto Sans instance at 700 is NotoSans-Bold, one at 450 NotoSans_450wght.
  • VariableFontIsInstancedAtRegistration checks the instance names; NoSubsettingFontEmbedsWholeProgram and RegisteredCffFontEmitsCidFontType0 now expect the PostScript name rather than the registered family.
  • Each mutation fails its tests: the family name back, instances keeping name 6, a tag of the glyphs alone.
  • Full macOS embedder suite: 1750 pass; the 12 failures are render and golden tests that fail the same way on embedpdf/main.
  • Layer mode: the new test that writes is in the writers list; check-fork-tags --strict passes (the fork's own files).

With #101 merged in locally, both engines pass the font and mixed-script suites, and a file reopened without the fonts reads the bold box as NotoSansHebrew-Bold and lists two fonts. Meant to be released together with #101, so embedpdf pins once.

A registered font's /BaseFont was the family it was registered under, spaces removed, so every weight of a family was written under one name: Noto Sans Hebrew Regular and Bold were both NotoSansHebrew. ISO 32000-2 9.6.3 and 9.7.4 make /BaseFont the font's PostScript name, which every other writer gives each weight (Acrobat's MinionPro-Regular, Word's Calibri-Bold, Chrome's Inter-SemiBold). Readers that name fonts by it saw one font for two: Acrobat's Document Properties listed one NotoSansHebrew for both weights, and the engine's font list merged them into one 400 entry, so a bold box read back under the regular font's name where the font isn't registered.

The name is now the program's own: its PostScript name, else Family,Style as a TrueType without one is named. The family stays the descriptor's /FontFamily, which is what reopening resolves a registered font by, so finding it again doesn't change. EPDFFont_GetPostScriptName() reports the same name.

A variable font is instanced at registration and keeps its name table, whose name 6 is the default instance's: a bold instance of Roboto was named Roboto-Regular. An instance is now named as Adobe Technical Note #5902 names instances: the named instance's own PostScript name (RobotoRoman-Bold); else the family prefix and the instance's style (NotoSans-Bold); else the prefix and the weight (NotoSans_450wght).

The subset tag hashed only the glyphs a subset holds, and two weights number their glyphs alike, so they also shared a tag. It now hashes the program too, so different subsets in one file get different tags (9.6.4).

Tests: TwoWeightsOfOneFamilyAreTwoFontsByName (Arimo Regular and Bold under one family: two names, two tags, one /FontFamily), VariableFontInstanceWithoutItsOwnName, and the instance names in VariableFontIsInstancedAtRegistration; NoSubsettingFontEmbedsWholeProgram and RegisteredCffFontEmitsCidFontType0 now expect the PostScript name. Three mutations (the family name back, instances keeping name 6, a tag of the glyphs alone) each fail their tests. Full macOS embedder suite: 1750 pass, the same 12 render and golden failures as embedpdf/main. Layer mode: the new writing test is in the writers list.
@bobsingor
bobsingor merged commit e9b936d into embedpdf/main Nov 3, 2026
1 check passed
@bobsingor
bobsingor deleted the embedpdf/fix/postscript-base-font branch November 3, 2026 19:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant