Fixing missing fonts in Collabora Online

Why Collabora Online fonts differ from Microsoft Office and when to fix them

Users who edit a Word or Excel file in the browser and see shifted text, different line breaks or boxes where glyphs should be are usually looking at a font problem, not a bug in the document. The short answer is that Collabora Online can only draw text with the fonts it can find on the server, and it substitutes other fonts when the original is missing. Fixing this means deciding which fonts your users need, installing them where the server looks for them, and confirming the result on documents your organization actually uses. Start by comparing one affected file on a Microsoft Office machine and on the Collabora Online server to see which font names differ.

Rendering depends on three things: the fonts installed in the server's systemplate, the substitution rules the server applies when a named font is absent, and any remote font configuration you set up. Each one can change how the same file looks. Substitution is the most common cause of visible drift, because a substituted face can have different metrics, so lines wrap differently and tables stretch even when the font looks similar. Before you change anything, confirm which fonts the affected documents embed or reference and which of those are present on the server. Fonts licensed for Microsoft products are a separate question that your legal and procurement teams should answer before you copy them onto a server, and the answer depends on your license terms, not on Collabora Online.

Font work belongs in the rollout plan, not only in the support queue. Fidelity testing with a representative set of documents, including templates, reports with complex tables and presentations with brand fonts, should happen before users move onto the service, and the same sample set should be rerun after each upgrade. The Collabora Online product page lists the formats the suite supports, including docx, xlsx and pptx, so your test set should cover those formats in the versions your users create. Ask your implementation team to document which fonts were installed, where they came from and how the sample results were recorded, so that a later difference can be traced to a specific change.

Which causes produce font differences

Font differences in browser-based editing usually come from one of a few sources: the server environment, the documents themselves, or the client. Each cause leaves a different trace, so matching the symptom to the cause tells you which layer to inspect first.

Fonts absent from the server image

The Collabora Online server renders documents using the fonts installed on the host or container. If a font named in a document is not present there, the text is drawn with a fallback. The usual symptom is that a whole document looks uniformly off, with headings or body text in a generic sans or serif face. Check which fonts the running server actually has before changing anything else, and compare the list against the fonts your documents use.

Microsoft core fonts not installed

Documents created in Microsoft Office often specify Calibri, Cambria, Arial, Times New Roman or similar core families. Many Linux base images do not ship these by default, and their metric-compatible substitutes may not be installed either. The symptom is line breaks and page breaks that move, so text that fits on one page in Word spills onto the next. Confirm whether the core font package is present on each server that renders documents.

Substitution with different metrics

When a font is missing, the renderer picks a replacement, and a replacement with different character widths changes wrapping, table column fit and pagination even if the glyphs look similar. The symptom is correct-looking text in the wrong places. Look at the font substitution table for the affected document and confirm which replacement was chosen. Metric-compatible fonts reduce this risk when they are available.

Embedded fonts not carried over

A .docx or .pptx file can embed its fonts, but embedding depends on the author's settings and on how the file was saved. If the embedded font data is absent or restricted, the editor cannot use it and falls back to installed fonts. The symptom appears in documents received from outside your organization and not in documents authored internally. Open the source file in Microsoft Office on a clean machine to see whether the font was truly embedded.

Container images lacking font packages

A custom image built from a minimal base often omits the font packages that the official image or a system package install includes. Rebuilding the image without them, or on a new base version, can change rendering after an upgrade with no change to your documents. The symptom starts on a specific date or deployment and affects every server built from that image. Compare the font inventory of the old and new images before assuming the document is at fault.

Differences from client-side display

The browser and the desktop application use different text rendering, hinting and zoom behavior, so a document can look slightly different on screen even when the server has the right fonts. The symptom is small spacing or weight differences that do not move content between pages. Separate these from server-side problems by checking whether the same document looks correct in a PDF export produced by the server and in the browser.

Options for adding fonts to a Collabora Online server

In a container deployment, fonts are usually added in one of two ways: by building a derived image that copies font files into the container's font directories, or by mounting a host directory with font files into the container at the path the server reads. A font placed inside a running container is lost when that container is recreated, so anything you depend on for document fidelity needs to live in the image build or in a mount you manage. The free CODE image is published as collabora/code, and the upgrade path is to rebuild your derived image on top of each new tag rather than edit a live container.

Derived image: Create a Dockerfile that starts from the Collabora tag you run and copies licensed font files into the system font path, then rebuild on every upgrade.
Read-only font mount: Mount a host directory of fonts into the container, which keeps font files outside the image and survives container replacement.
Font cache rebuild: After adding fonts, confirm the font cache is refreshed inside the container, since a missing cache can make new fonts invisible to the renderer.
Version pinning: Pin the image tag in your compose file or deployment so a font change is tested against one known Collabora release.
Licensing check: Confirm that you hold a license for every font you copy into an image, especially proprietary Microsoft faces.

Before you rely on either approach, confirm with Collabora's documentation for your exact image tag how font directories are read and whether any font configuration file is expected.

Font configuration options and when each fits

This table compares the four ways to close a font gap in Collabora Online: installing system font packages, adding custom font files, pointing the server at remote font locations, and accepting substitution. Read each row against your document set, since the right choice depends on which fonts your Word files use and who maintains the server image. The main takeaway is that the fix with the least effort is not always the one that keeps layout stable across rendering runs.

Option	When it fits	Effort and risk	What to verify
System font packages	The missing fonts are open or widely licensed families that your Linux distribution or package repository provides	Low effort on a package-based install, but package updates can change installed fonts without notice	Installed families with fc-list, and that the same set is present on every server in the pool
Custom font files in the server image	You hold a licence for proprietary fonts that Microsoft Office documents use, and you run Collabora from a container image you build	Moderate effort, with a rebuild for every font change; licence terms for redistribution must be checked before baking fonts into an image	Font files are licensed for this use, present in the built image, and render the same on sample documents after each rebuild
Remote font configuration	Fonts are kept in a central location that your organization already manages and serves over HTTP or HTTPS	Moderate effort, with added dependency on the font host and network path; a failed fetch can change rendering silently	The font host is reachable from the Collabora server, the configuration keys match your release, and fetch failures appear in logs
Accepting substitution	Only a few minor fonts are affected, or the documents are for reading and the layout tolerance is high	Lowest effort, but line breaks, pagination and table widths can shift, which matters for contracts and forms	Pagination and line breaks on representative documents compared against Microsoft Office output
Mixed approach	Some fonts are open and some are licensed, and documents differ by department	Combines the effort of two options and needs a clear record of which font came from where	A written font inventory that maps each font family to its source and the servers that hold it

How to diagnose and fix font issues step by step

This sequence turns a vague complaint that a document looks wrong into a measured comparison, a targeted font fix and a documented check that the rendering now matches what Microsoft Office produces for the same file.

Collect a sample document and its font list
Start with one representative file that shows the problem, ideally a .docx, .xlsx or .pptx the user saved in Microsoft Office. Record the file name, the Office version that saved it, and the font list reported by the source application or by unzipping the package and reading the font table. Ask the user to describe exactly what looks wrong, such as changed line breaks, shifted tables or different glyphs. Done when you have one file, its font list and a written description of the symptom that someone else could reproduce.
Compare output against Microsoft Office
Open the same file in Microsoft Office and in Collabora Online on the same machine or browser, then compare the first page, the page count, the line breaks of a fixed paragraph and the position of one table or chart. Keep PDF exports from both sides for reference. Note which fonts appear in each output. Done when you have a short table of differences, for example page count, line break position and substituted font name, that tells you whether the problem is font substitution, metric differences or a layout issue unrelated to fonts.
Check which fonts the server resolves
Determine which fonts the Collabora Online server actually has available, both in the system font directories and in the systemplate used for new documents. Confirm the installed package or container image and the font directory it reads, because the server does not use fonts from a user's desktop. Compare the list of resolved fonts with the list from step one. Done when you can name each missing font and the location the server searches, so the fix targets the correct path.
Add missing fonts and confirm their licenses
Install only the fonts your organization is licensed to use on the server, placing them in the font directory identified in the previous step, and check that the file permissions let the service read them. Record the source and license terms for each font in your change record. Where Microsoft fonts are needed, confirm with your licensing owner how they will be distributed to the server. Done when each missing font appears in the resolved list and the license record is complete.
Restart the service and clear cached renderings
Restart the Collabora Online service or container so it rescans the font directories, since fonts added while it runs may not be picked up. Close existing editing sessions and reopen the sample document, because open sessions keep their earlier state. If the file was previously loaded in the host application, reload it there as well. Done when the server log shows no font errors on startup and the reopened document is loaded in a fresh session.
Confirm rendering against the Office reference
Repeat the comparison from step two on the same file: check the first page, the page count, the line breaks of the fixed paragraph and the table position against your Microsoft Office output and PDF exports. Also check one spreadsheet cell width and one slide text box if those were affected. Record any remaining differences as known limitations rather than fixing them with unlicensed fonts. Done when the sample file matches the reference on the points you recorded, or the remaining differences are documented with a named owner.
Test a wider set of documents before sign-off
Repeat the same checks on a small set of representative files covering the document types your users open, including docx, xlsx, pptx and any PDFs with embedded fonts. Save the results next to the change record so a later font or version update can be re-tested against the same files. Confirm with the user who reported the issue that their document now behaves as expected. Done when the test set passes your agreed criteria and the results are stored for future upgrades.

Font licensing and remote font configuration

Before you install a commercial font on a Collabora Online server, confirm that your license allows it. Microsoft fonts such as Calibri, Cambria and Arial are commonly used in Office documents, but their terms of use are set by the rights holder and may not cover installation on a server that renders documents for many users. Ask the legal or procurement team to confirm whether the license permits server-side use, how many machines or users it covers, and whether a redistribution clause affects container images. Record the decision alongside the font list, because the answer determines whether the font can live in a shared image at all.

Remote font configuration moves font delivery out of the container image and into a location your deployment reads at runtime. This keeps licensed files out of images that may be copied to registries, mirrored to other environments or shared with partners, and it lets you change the font set without rebuilding the image. The trade-off is operational: someone must own the font store, control who can change it, check file integrity, and confirm that every replica loads the same set. Treat the font store like any other configuration dependency with access control and change records.

Confirm the supported remote font settings for your specific Collabora Online version in the vendor documentation before you change anything. Configuration keys, supported locations and reload behavior can differ between branches, and an unsupported setting may appear to work in testing but fail after an update. Once you have the supported option, test it on the same sample documents you use for font substitution checks, using a staging instance that matches production. Document the version, the font source, the license record and the test results together so that an upgrade review can repeat the check.

Security and operational considerations for font changes

Adding fonts changes what files the editing server reads, renders and logs, so it is a security and change event, not only a cosmetic fix. The cards below cover the controls to put in place before a font change reaches production, and how to back out one that breaks other documents.

Vet font files before installing

Font files are parsed by the rendering stack, so a malformed or hostile font is an attack surface on the server that opens documents for every user. Accept fonts only from the licensed source your organization has approved, record the origin and license of each file, and keep the set small. Check that each font loads and renders on a test document before it goes near production. Do not install fonts from unknown downloads or user uploads.

Keep font packages patched

Font packages come from the operating system or your own image build, so they receive updates through the same channel as other system packages. Decide who owns those updates and how quickly a security fix for the font stack is applied. Confirm that Collabora's own advisories for the release you run are reviewed, since a patched Collabora Online build does not patch a vulnerable system font package beneath it.

Keep document content out of logs

Troubleshooting font problems tempts teams to raise log levels and copy sample documents into tickets. Document text can contain personal or confidential data, so use log settings that record font names, paths and error messages without body content. Use a dedicated test document with fake content for reproduction, and remove any captured logs or files once the investigation closes.

Control image rebuild changes

When fonts ship inside a container image, every font change means a new image. Put that change through the same review as other image updates: a written change request, a named approver, a build from a pinned base image, and a rendering check on the sample set before rollout. Record the image tag and the font list in the change record so the exact state can be recreated later.

Roll back when other documents change

A new font can change line breaks, pagination or substitution for documents that never used it, especially where a font name is shared by two files. Keep the previous image tag available and keep a baseline set of documents with recorded expected output. If a regression appears, redeploy the previous tag, confirm the baseline again, and then investigate the fix in a separate environment.

Limit who can change fonts

Font changes alter how every user's documents render, so the people able to change them should be limited to the platform team that owns the image and the change process. Review access to the image registry, the build pipeline and the running containers. Confirm that changes made directly inside a running container are either blocked or detected, because they are lost on restart and bypass review.

Questions teams ask before fixing font rendering

How much effort does a font fix in Collabora Online take?

Effort depends on how many fonts are missing, how many document types are affected, and whether the fix is a single container change or a repeatable build. A small set of corporate fonts used in a few templates is a short task. A large archive with mixed Office versions, embedded fonts and charts needs a longer sample review because each mismatch has to be traced to a cause. Ask any partner to split the quote into font inventory, licensing review, packaging, and fidelity testing so you can see where the time goes.

What drives the cost of fixing fonts up or down?

The main drivers are the number of font families, whether they are licensed for server-side use, how many Collabora Online deployments need the same change, and how varied your documents are. Deployment shape matters too: a single Docker host is simpler than a Kubernetes cluster where every replica must carry identical fonts. Costs that recur include rebuilding images after updates and repeating sample tests. Ask for the one-time and recurring parts of the quote separately.

Can our in-house team fix font rendering without a partner?

Often yes, if you have someone comfortable with container images or system packages, the Collabora Online configuration, and a clear list of documents that look wrong. The work is mostly methodical: identify the substituted font, confirm you hold a license for the replacement, install it where the server reads it, and re-test. Teams usually struggle with the evidence side, meaning consistent sample sets and a record of what changed. A partner adds value when many documents need review or when the team lacks time for repeated testing.

What does the work need from our team?

Plan to provide a set of representative sample documents from the templates and sources people actually use, including Word, Excel and PowerPoint files that look wrong today. You also need a font inventory from the workstations and templates, showing which families are in use and where they came from. Licence records matter: know which fonts your organization is entitled to install on servers, because some fonts are licensed only for desktop use. Name an owner who can approve font packages and sign off on the test results.

Do font fixes survive Collabora Online upgrades?

They survive only if the fonts are kept outside the packages or images that get replaced during an upgrade. Fonts placed in the system or in a Collabora template directory can be overwritten when the base image is rebuilt, so record the exact path and the method used. Keep the font packages in your own build pipeline or configuration management, and re-run the sample documents after every upgrade. Confirm the current location for the release you run in the Collabora Online documentation and your deployment notes.

How do we verify that rendering now matches Microsoft Office?

Verify with a fixed test set rather than a visual spot check. Open each sample in Microsoft Office and in Collabora Online, then compare pagination, line breaks, table widths, chart labels and header or footer positions. Record the result for each file, and note which differences are accepted, such as small kerning changes, and which block sign-off. Repeat the same set after each font change and after each Collabora Online update. Independent compliance assessors do not certify rendering, so keep these records as your own evidence.

Do we need license records for fonts we install on the server?

Yes. Server-side installation can fall under different license terms than desktop installation, and many commercial fonts restrict use on shared servers or in hosted services. Before installing anything, check the license for each family and keep the written terms with the font package. Open-source font families are usually easier to document, but still confirm the license file that ships with them. Your legal or procurement team should approve the list before it is deployed.

How to verify fixes on sample documents

Verification means proving that a font change fixed the document users actually open, so start by building a sample set that mirrors real traffic rather than a handful of files chosen for convenience. Pull representative documents from the shares and repositories your users work in, and group them by type: Writer documents with dense headers and footers, Calc workbooks with wide tables and number formats, and Impress decks that rely on specific brand typefaces. Include the formats your environment handles, such as docx, xlsx and pptx, alongside OpenDocument originals. Where documents contain confidential content, use anonymized copies or ask the document owners to approve a test copy, and keep the set in a location with the same access controls as the source data.

For each file, open the same document in Microsoft Office and in Collabora Online, then compare page count, line breaks, table column widths, and header and footer placement. Record each difference in a simple log with the file name, the Collabora Online version, the font the document requests, the font that was substituted, and a screenshot or PDF export of both renderings. Treat a page count change or a moved line break in a contract or form as a defect, and treat a small kerning shift in a marketing deck as a lower priority item. Run the same checks on documents with embedded fonts and documents that depend on fonts installed on the server, because the two cases fail differently.

Repeat the full set after every font installation, every change to the font configuration, and every move to a new Collabora Online branch or container image, since any of these can change layout without touching the documents themselves. Confirm the current release and branch with your vendor before you start, and keep the results with the change record so that auditors and support staff can see what was tested. Once the set passes, use the Collabora Online file format compatibility guidance as the next step for wider fidelity testing across formats.

How DeployOpen scopes and delivers font and rendering fixes

DeployOpen approaches font and rendering work as a scoped change to your own Collabora Online installation, inside your infrastructure. We start from a written list of the documents and fonts that matter to your organization, then fix, test and document each change so your team can repeat it.

How we scope

Engagements are fixed-scope, with the sample documents, fonts and server environments agreed in writing before work starts.
The written scope lists which Microsoft Office templates and file types are in view for fidelity comparison.
We confirm which Collabora Online version and deployment method you run, since font handling depends on the installed build.
Ongoing support for font changes after handover is available as a retainer if your template library keeps changing.

How we build

We inventory the fonts your documents request and compare them with what the server actually has installed.
We install or map approved fonts in the server environment you control, following the procedure agreed in scope.
We test each change against the agreed sample documents in both Collabora Online and Microsoft Office, recording pagination and line-break differences.
We keep configuration changes in version-controlled files so they can be reviewed and reapplied after updates.

How we hand over

You receive a written record of fonts installed, substitutions accepted and the reasons for each decision.
Runbooks explain how to add a font, check that it loads and roll back a change on your own servers.
Test documents and expected results are handed over so your team can rerun the checks after each Collabora Online update.

How we support

Support after handover covers font and rendering questions raised by your team, scoped in a separate written agreement.
Ongoing support and continuous testing are available as retainers for organizations that update Collabora Online regularly.
Confirm with your licensing and font vendors which typefaces you are permitted to install on servers before the engagement starts.

Fixing missing fonts and rendering differences in Collabora Online