docs(toolbar): clarify how fonts work in SuperDoc#2848
Merged
caio-pizzol merged 2 commits intomainfrom Apr 16, 2026
Merged
Conversation
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.
|
Preview deployment for your docs. Learn more about Mintlify Previews.
π‘ 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`.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A
.docxcarries 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/fontswas an empty redirect stub, and the toolbarFont configurationsection had an Info callout claiming imported DOCX fonts auto-populate the dropdown (they don't).getting-started/fontsinto a real page: explains the.docxfont model, shows how to add a font, and points at the Office-font substitute pattern.Font configurationsection to separate two concerns cleanly: registration (selectability viafonts) vs. loading (real glyphs via@font-faceor<link>).@font-facealias 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-facealiasingCalibriβ Carlito andCambriaβ Tinos.document.fontsreports both asloaded, 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).