Does ScopeStack Support a Specific Font?
Short answer: ScopeStack supports whatever fonts your Word template uses. It does not maintain a list of “supported fonts,” because it does not render fonts itself — it fills your template with data and leaves the template’s own formatting in place. The font questions that come up almost always trace to one of the three points below.
Fonts are referenced by name, not embedded
A Word document stores fonts by name (for example, “Avenir Book” or “Calibri”), not by embedding the actual font file. Font embedding is off by default in Word. When ScopeStack generates a document, it produces a file that references the same font names your template uses.
This matters for one reason: a document displays a font correctly only on a machine where that font is installed.
An uninstalled font substitutes silently
If a document references a font that is not installed on the machine viewing it, Word does not warn anyone — it silently substitutes a different font. So a template built on a designer’s Mac using a Mac-only font (Avenir is the classic example) will look right on that Mac and quietly fall back to something else on a Windows machine that doesn’t have it.
If a generated document is coming out in the wrong font, the first thing to check is whether the intended font is actually installed on the machine where you’re viewing it. No change inside ScopeStack can make a document show a font the viewer’s computer doesn’t have.
PDF output is a separate, server-side conversion step
When you request PDF output, ScopeStack first merges your data into the Word template, then converts that finished Word file to PDF on the server (see How Document Generation Works). The conversion happens on ScopeStack’s servers, not on your machine, and it preserves the layout and formatting of the merged Word document.
Because the PDF is produced server-side, the fonts available during that conversion are the ones on the conversion server, not the ones on your laptop. A brand or custom font that renders fine when you open the Word output on your own machine can substitute during PDF conversion. If a font renders correctly in the Word output but not in the PDF, that difference is the reason — it is a conversion-environment font question, not a data or template-tag problem.
If rich-text content (service descriptions, language fields) comes out in the wrong font
There is one more case specific to Markdown-formatted fields — service descriptions, language fields, and similar rich-text content. These fields are converted from Markdown into brand-new Word paragraphs at generation time, and how those paragraphs pick up a font depends on which template engine you use:
- Tag Templates (V2): the rendered content takes the paragraph style of the line where the tag sits in your template. Control the font by applying a paragraph style to that line — see Styling rich text and lists. (The
ListBullet/ListNumbernamed styles from V1 have no effect in a Tag Template.) - Mail Merge Legacy templates (V1): the rendered content takes its font from named paragraph styles (
Paragraph,ListBullet,ListNumber,Heading1–Heading6), not from the surrounding text — see How markdown content is styled.
If your body text is correct but your rendered service descriptions come out in a different (usually the theme default) font, that is a template-styles issue — apply the fix above for your template type. If it still doesn’t resolve, reach out to support.