Skip to content

docs(toolbar): clarify how fonts work in SuperDoc#2848

Merged
caio-pizzol merged 2 commits intomainfrom
caio-pizzol/docs-fonts-guide
Apr 16, 2026
Merged

docs(toolbar): clarify how fonts work in SuperDoc#2848
caio-pizzol merged 2 commits intomainfrom
caio-pizzol/docs-fonts-guide

Conversation

@caio-pizzol
Copy link
Copy Markdown
Contributor

A .docx carries font names, not font data. Consumers hit this constantly β€” most commonly when a document uses Cambria/Calibri/Aptos and the rendered text falls back to Helvetica in the browser because those fonts ship with Office, not with the docx or with browsers. The existing docs made this worse: getting-started/fonts was an empty redirect stub, and the toolbar Font configuration section had an Info callout claiming imported DOCX fonts auto-populate the dropdown (they don't).

  • Rewrites getting-started/fonts into a real page: explains the .docx font model, shows how to add a font, and points at the Office-font substitute pattern.
  • Rewrites the toolbar Font configuration section to separate two concerns cleanly: registration (selectability via fonts) vs. loading (real glyphs via @font-face or <link>).
  • Adds a working @font-face alias example and a table of free metric-compatible substitutes (Carlito for Calibri, Tinos/Gelasio for Cambria, Carlito/Inter for Aptos).

Verified in practice: instrumented the dev app to load Carlito + Tinos via @font-face aliasing Calibri β†’ Carlito and Cambria β†’ Tinos. document.fonts reports both as loaded, and canvas-measurement confirms the aliased names now resolve to real glyphs instead of the sans-serif fallback.

Rejected: recommending consumers license Cambria/Calibri directly from Microsoft (possible but restricted and rarely worth it); recommending SuperDoc ship its own font library (against the existing "you control what fonts are available" philosophy).

Review: confirm the Office-font substitute table is accurate, especially the Aptos row (no free metric-identical match exists β€” I list Carlito/Inter as reasonable stand-ins).

A .docx carries font names, not font data. Consumers often hit this
when a document uses Cambria/Calibri/Aptos and the rendered text
falls back to Helvetica in the browser. The existing docs were an
empty redirect stub plus an inaccurate Info callout that claimed
imported DOCX fonts auto-populate the toolbar dropdown (they don't).

Rewrites the Font support getting-started page and the toolbar
Font configuration section to separate two concerns cleanly:
registration (selectability via `fonts`) vs. loading (real glyphs
via `@font-face`). Adds a working alias example and a table of
metric-compatible free substitutes for Office fonts.
@mintlify
Copy link
Copy Markdown

mintlify Bot commented Apr 16, 2026

Preview deployment for your docs. Learn more about Mintlify Previews.

Project Status Preview Updated (UTC)
SuperDoc 🟒 Ready View Preview Apr 16, 2026, 4:44 PM

πŸ’‘ Tip: Enable Workflows to automatically generate PRs for you.

Revert the expanded font-support page back to the one-line redirect
stub. The real content already lives in the toolbar Font configuration
section β€” the stub only needs the redirect target corrected from
`/modules/toolbar#font-configuration` (which bounces to overview and
has no matching anchor) to `/modules/toolbar/built-in#font-configuration`.
@caio-pizzol caio-pizzol merged commit f4a845a into main Apr 16, 2026
4 checks passed
@caio-pizzol caio-pizzol deleted the caio-pizzol/docs-fonts-guide branch April 16, 2026 16:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant