Hi!
I am writing to report an issue with font rendering encountered in Aspose.Words version 25.1.0.
Problem description: When converting a .docx document containing text in the regular “Baskerville” font to PDF (or PNG), the font incorrectly renders as semi-bold. The Baskerville font family is installed system-wide for all users on my machine.
Expected behavior: The font weight should be preserved (regular) in the output PDF, matching the source DOCX.
Source file: Sample.docx (22.3 KB)
Converted file: Result.pdf (37.7 KB)
Font files used, contains original .ttc: Baskerville.zip (693.7 KB)
Code sample to reproduce:
var document = new Aspose.Words.Document(SourcePath);
document.LayoutOptions.TextShaperFactory = Aspose.Words.Shaping.HarfBuzz.HarfBuzzTextShaperFactory.Instance;
document.WarningCallback = new WordDocumentSubstitutionWarnings();
var saveOptions = Aspose.Words.Saving.SaveOptions.CreateSaveOptions(Aspose.Words.SaveFormat.Pdf);
saveOptions.UpdateFields = false;
document.Save(TargetPath, saveOptions);
The issue appears to be related to TrueType Collections (.ttc). When I split the Baskerville.ttc file into individual .ttf files (e.g., Baskerville.ttf , Baskerville-Bold.ttf ) and install those instead, the conversion works correctly, and the font weight is preserved.
This leads me to suspect that Aspose.Words might have difficulty correctly parsing or selecting the correct font weight from within a .ttc container.
Is there a way to resolve this issue while keeping the font in its original .ttc format, or is splitting the collection the only recommended workaround at this time?
@directum
The behavior you describe is consistent with a known limitation in the TTC handling of Aspose.Words 25.1.0. To confirm whether the issue has already been addressed and to gather the information needed for a reproducible report, please provide the following:
- Operating system (including version) and the .NET runtime you are using (e.g., .NET 6, .NET Framework 4.8).
- Full output from the
WordDocumentSubstitutionWarnings callback – it will show which font file Aspose.Words actually selected for the regular style.
- If you are using any custom
FontSettings (e.g., FontSettings.SetFontsFolder(...)), include that code; otherwise confirm you rely on the system‑wide font installation only.
In the meantime, try the same conversion with the latest Aspose.Words build (e.g., 25.2.x or newer). TTC support was improved in later releases, and the issue may already be resolved.
If the problem persists after testing the newer version, please attach:
- The original
Sample.docx.
- The original
Baskerville.ttc (or the extracted .ttf files you used as a workaround).
- A minimal console program that reproduces the semi‑bold rendering, including the warning callback output.
With those details we can log an internal defect and work on a fix.
@directum
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.
Issue ID(s): WORDSNET-28908
You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.
1 Like
This issue occurs for both operating systems, Window or Linux, and also for both .NET Standard 2.0 and .NET Core 3.1.
Full output from WordDocumentSubstitutionWarnings callback: Warning: type=FontSubstitution, description=Font ‘NTTimes/Cyrillic’ has not been found. Using ‘Cambria’ font instead. Reason: alternative name from document., source=Layout.
Yes, we rely on the system-wide font installation. We tried to use SetFontsFolder with original .ttc file, but it didn’t help.
@directum
I understand that you are converting a DOCX to PDF with Aspose.Words (both .NET Standard 2.0 and .NET Core 3.1, on Windows and Linux) and you receive the following warning:
Warning: type=FontSubstitution, description=Font 'NTTimes/Cyrillic' has not been found. Using 'Cambria' font instead.
Even though the required font is installed system‑wide, the output PDF shows the regular style rendered as semi‑bold. You have already tried FontSettings.SetFontsFolder(...) with the original .ttc file, but the substitution still occurs.
What is happening
- In Aspose.Words 25.1.0 the handling of TrueType Collections (.ttc) has a known limitation that can cause the library to select the wrong face from the collection, resulting in a semi‑bold rendering of a regular‑weight font [1][3][4].
- When the exact font cannot be resolved, Aspose.Words raises a FontSubstitution warning and falls back to the next available font (Cambria in your case) [1][4].
- Supplying the .ttc file via
SetFontsFolder does not change this behaviour in the 25.1.0 build [1][4].
Recommended next steps
-
Upgrade to the latest Aspose.Words build (25.2.x or newer). TTC support was improved in later releases, and the issue may already be fixed [2].
-
Run the conversion again with the same code, keeping the WordDocumentSubstitutionWarnings callback attached so you can capture the full warning output.
-
If the problem persists after the upgrade, please provide:
- The original DOCX file that uses the TTC‑based font.
- The original .ttc file (or the extracted .ttf files you used as a workaround).
- A minimal console program reproducing the issue, including the warning‑callback code.
With these artifacts we can log a reproducible defect and work on a fix.
Current defect tracking
An internal defect ticket has already been created for this scenario: WORDSNET‑28908 [3]. Once you confirm whether the latest build resolves the problem, we will either close the ticket or continue investigation.
Action items for you
var doc = new Aspose.Words.Document(sourcePath);
doc.LayoutOptions.TextShaperFactory = Aspose.Words.Shaping.HarfBuzz.HarfBuzzTextShaperFactory.Instance;
doc.WarningCallback = new WordDocumentSubstitutionWarnings(); // captures substitution info
var saveOpts = Aspose.Words.Saving.SaveOptions.CreateSaveOptions(Aspose.Words.SaveFormat.Pdf);
doc.Save(targetPath, saveOpts);
- Test with the newest NuGet package (
Aspose.Words 25.2.x or later).
- Review the console/log output of
WordDocumentSubstitutionWarnings.
If the warning still shows “Font ‘NTTimes/Cyrillic’ has not been found” and the PDF renders semi‑bold, please share the files mentioned above so we can reproduce the issue and advance the fix under ticket WORDSNET‑28908.
@directum The issue you have encountered has already been resolved in the current codebase. The fix will be included in the upcoming 26.1 version of Aspose.Words. We will be sure to let you know once it is published.
1 Like
The issues you have found earlier (filed as WORDSNET-28908) have been fixed in this Aspose.Words for .NET 26.1 update also available on NuGet.
1 Like