We are using GroupDocs.Conversion to convert to HTML and PDF, but wherever the Symbol font is used in our docs, the output is an empty no-glyph-available box. The formulas with the Symbol chars in them are actually critical. Is there a way to get them working? Some more details follow.
- We are developing on MacOS, and our cloud containers most likely are Linux.
- I have set
EmbedFontResources = true in the conversion options for HTML, but it doesn’t help.
- There is no embed-fonts option available for PDFs to try out.
@FallinEAtMoodys
Summary
The missing Symbol characters in the generated HTML and PDF are caused by the Symbol font not being available in the Linux container where GroupDocs.Conversion runs. When the source document references that font, the converter cannot find it, so it substitutes a “missing‑glyph” box.
Why it happens
EmbedFontResources = true only embeds fonts that exist on the host at conversion time.- The default Linux images used for GroupDocs.Conversion include only generic fonts (e.g., Liberation) and do not contain Microsoft’s Symbol font.
- During conversion the library looks for the Symbol font in the system font cache. Because the font is absent, the converter falls back to the placeholder glyph, which appears in both HTML and PDF outputs.
What to do next
- Confirm the font is missing
fc-list | grep -i symbol
If the command returns no results, the Symbol font is not installed in the container.
- Add the Symbol font to the container – add the font file and refresh the font cache. Example Dockerfile fragment (adjust paths as needed):
FROM your-base-image
# Install font‑config utilities (if not already present)
RUN apt-get update && apt-get install -y fontconfig
# Copy a licensed Symbol.ttf into the system fonts directory
COPY Symbol.ttf /usr/share/fonts/truetype/custom/
# Refresh the font cache so the OS can see the new font
RUN fc-cache -f -v
Note: You must have the appropriate license to distribute the Symbol font. If you cannot use the Microsoft Symbol font, you can use any other font that contains the required glyphs.
- Re‑run the conversion (C# example)
var conversion = new GroupDocs.Conversion.Conversion(sourcePath);
var htmlOptions = new HtmlConvertOptions
{
EmbedFontResources = true // keep enabled so the font is embedded in HTML
};
conversion.Convert(outputHtmlPath, htmlOptions);
var pdfOptions = new PdfConvertOptions(); // no extra flag needed
conversion.Convert(outputPdfPath, pdfOptions);
With the Symbol font now present, the HTML output will include an @font-face rule for it, and the PDF will render the characters correctly.
- If the issue remains
- Enable detailed logging in the SDK (e.g., configure a
ConversionConfig with a logger) to capture font‑lookup messages.
- Look for log entries such as “Font Symbol not found” to verify whether the converter still cannot locate the font.
- Provide those log snippets along with your Docker base image and SDK version for further analysis.
- Gather additional information (if you need more help)
- The exact Linux distribution / base Docker image you are using.
- The GroupDocs.Conversion SDK version and the programming language (C#, Java, etc.).
- Any custom font‑substitution settings you have applied.
Providing this information will allow us to fine‑tune the container configuration or suggest alternative substitution strategies when installing the Symbol font is not feasible.
I could not fully verify this explanation against the retrieved sources. Please double-check the behaviour in your environment and confirm the exact SDK/version.
Hello @FallinEAtMoodys ,
We’re sorry to hear that you’ve encountered this issue when converting to HTML and PDF.
As our AI assistant mentioned above, such conversion issues are usually caused by missing fonts on the system. In this case, there are several ways to avoid the problem:
- Install the required fonts directly on your system.
You can find example installation commands in our documentation.
- If installing fonts is not an option, you can use the
ConverterSettings.FontDirectories property to specify a folder containing the required fonts.
Please note that the fonts still need to be available on the machine where the conversion takes place.
- If you’re converting DOCX to PDF, you can also replace missing fonts with available ones in the system using the
WordProcessingLoadOptions.FontSubstitutes property.
We can share a code example demonstrating how to apply these settings, but your message doesn’t specify which platform you’re using — .NET or Java.
Please also clarify which document formats you’re converting to PDF, as well as the platform and library version you’re using, so we can assist you further.
Hi there, thanks for your reply. Your comments were helpful, and so were the bot’s, though less. Please do send that applying-settings code, for .NET.
We are converting DOCX docs to PDF and to HTML using your .NET version. Right now the problem is seen in our dev environment, on MacOS. I’m assuming it may show up in Linux when we get there.
I’m pretty sure the basic diagnosis is right — missing font in MacOS. But the font missing is not Symbol itself, which is present. It’s an unknown different font, but I can’t tell which because the formulas were done in an unknown tool, and Words treats them like pictures. Trying to track that down.
@FallinEAtMoodys
Hi Ed,
Despite here is a GroupDocs.Conversion thread, while I’m responsible for GroupDocs.Viewer and GroupDocs.Editor, this issue is quite familiar and known for me. Let me help you.
- You have mentioned that input document is of DOCX format, and you want to convert it to the PDF and HTML. For DOCX document sthere is a mechanism called the font substitution — when original font is not found, GroupDocs.Conversion (and all other GroupDocs products) try to find the most appropriate replacement font for it, here is more info.
- Such font-related issues are complicated to reproduce because they are dependent on the list of actual fonts, installed on the machine. Even if you will share the DOCX with us, our machines have another fonts installed, and we probably will see another results.
- What you actually need to do is:
3.1. Define which fonts are actually used inside the content of the DOCX.
3.2. Detect which used fonts are available as system fonts.
3.3. Detect which used fonts are unavailable on system, and onto which fonts they are substituted.
- I can suggest you a little piece of source code which you should run on that exact machine where the issue occurs. This code uses not the GroupDocs.Conversion, but the GroupDocs.Viewer, but I’m sure that it will not be an issue for you. Here it is:
using (GroupDocs.Viewer.Viewer viewer = new Viewer("full-path-to-docx-or-stream.docx"))
{
Fonts.IFontInfo[] allFonts = viewer.GetAllFonts();
Console.WriteLine("{0} fonts are used in the '{1}' document", allFonts.Length, filename);
foreach (Fonts.IFontInfo font in allFonts)
{
if (font is Fonts.WordProcessingFontInfo)
{
Fonts.WordProcessingFontInfo actualFont = (Fonts.WordProcessingFontInfo)font;
Console.WriteLine("Original familty name: {0}; Style: {1}; Format: {2}; Charset: {3}; {4}; {5}",
actualFont.FamilyName,
actualFont.Style,
actualFont.Format,
actualFont.Charset,
actualFont.IsEmbedded ? "Embedded" : "System",
(actualFont.Content != null && actualFont.Content.Length > 0) ? (actualFont.Content.Length + " bytes") : "Font binary data is unavailable");
}
else if (font is Fonts.WordProcessingSubstitutedFontInfo)
{
Fonts.WordProcessingSubstitutedFontInfo substitutedFont = (Fonts.WordProcessingSubstitutedFontInfo)font;
Console.WriteLine("Substituted family name: {0}; Original family name: {1}; Style: {2}; Format: {3}; {4} bytes.",
substitutedFont.FamilyName,
substitutedFont.OriginalFamilyName,
substitutedFont.Style,
substitutedFont.Format,
substitutedFont.Content.Length);
}
else
{
throw new InvalidOperationException();
}
}
}
With this piece of code you will be able to find those “unknown different font”, that is used in formulas.
With best regards,
Denis Gvardionov