Windows Update breaks WPF TrueType font subsetting (Calibri.ttf format specification error) KB5120708

Question

Windows Update breaks WPF TrueType font subsetting (Calibri.ttf format specification error) KB5120708

Reported

ISIMobile 36

When printing in .NET Framework 4.8 application WPF, it seems to have broken the XPS printing.

See stack trace below. If I uninstall the KB5120708 update, it works again. It has broken our printing functionality on our business application. Can any one else confirm the issue?


'file:///C:/WINDOWS/FONTS/CALIBRI.TTF' file does not conform to the expected file format specification.

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
ISIMobile 36 Reputation points

2026-08-13T14:01:16.4933333+00:00

I will try one more time to add a stack trace, it keep on getting deleted. I added text file with the stack trace.
Travis 10 Reputation points

2026-08-13T21:22:59.3933333+00:00
Can confirm this, and can add a few details that may help triage and give people a workaround short of uninstalling the update.

1. It isolates to a single GlyphTypeface.ComputeSubset call — no printing pipeline required. You don't need XPS, PrintDialog, or Crystal Reports to reproduce it. This two-liner throws on an affected machine:

var gt = new GlyphTypeface(new Uri(@"C:\Windows\Fonts\calibri.ttf")); gt.ComputeSubset(new ushort[] { 0 }); // FileFormatException after KB5120708

PowerShell equivalent for a quick check:

Add-Type -AssemblyName PresentationCore [System.Windows.Media.GlyphTypeface]::new([Uri]"$env:WINDIR\Fonts\calibri.ttf").ComputeSubset([uint16[]]@(0))

That should make it easy for anyone (and for Microsoft) to reproduce in isolation.

2. Constructing and reading the font still works — only subsetting fails. new GlyphTypeface(...) succeeds, and reading CharacterToGlyphMap, AdvanceWidths, GetFontStream(), etc. all succeed. Only ComputeSubset() throws. So the fonts are not corrupt (they open normally in Word and pass a plain load) — the regression is specifically in the native subsetting path (MS.Internal.TrueTypeSubsetter.ComputeSubset, which parses the raw font tables). This looks like tightened validation, consistent with the update being a security fix.

3. It's broader than Calibri — but not every font. On our machines the failing set is the Vista/Office ClearType families:

Fails: Calibri, Cambria, Constantia, Corbel (all weights/styles)

Passes: Consolas, Candara, and even Calibri Light — plus all the older TrueType fonts (Arial, Times New Roman, Verdana, Tahoma, Georgia, Courier New)

So it's not "all TrueType" and not simply "the C-fonts" — it's a specific internal table/outline structure that this subset of fonts shares. Calibri being the modern Office/WPF default is why it's biting the most documents.

You can enumerate the affected fonts on any machine with (fast — subsets a single glyph per face, and covers .ttc collections):

Add-Type -AssemblyName PresentationCore Get-ChildItem "$env:WINDIR\Fonts" -Include *.ttf,*.otf,*.ttc -Recurse | ForEach-Object { $file = $_.Name foreach ($tf in [System.Windows.Media.Fonts]::GetTypefaces((New-Object System.Uri($_.FullName)))) { $gt = $null if ($tf.TryGetGlyphTypeface([ref]$gt)) { try { [void]$gt.ComputeSubset([uint16[]]@(0)) } catch { [PSCustomObject]@{ File = $file; Face = @($tf.FaceNames.Values)[0] } } } } } | Sort-Object File | Format-Table -AutoSize

4. Workaround that keeps the security update. For anyone who can't uninstall KB5120708 (e.g. managed/security-locked machines), substituting the affected fonts in the documents/templates — switching body text from Calibri to a font that still subsets, such as Arial or Times New Roman — restores printing/XPS output without removing the patch.

5. Scope note. KB5120708 is the Windows 11 25H2 .NET Framework cumulative update, but the same August .NET Framework security fix ships for other Windows versions under different KB numbers, so machines that aren't on 25H2 can hit the identical failure under their equivalent update — worth checking if you're reproducing on a different OS build.

Hoping Microsoft can confirm and issue a corrected update, since the workarounds are either removing a security update or re-fonting documents.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

3 answers

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
ISIMobile 36 Reputation points

2026-08-13T14:01:16.4933333+00:00

I will try one more time to add a stack trace, it keep on getting deleted. I added text file with the stack trace.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Answer 1

Hi @ISIMobile

This issue has been isolated to the WPF TrueType font-subsetting path. After installing KB5120708, GlyphTypeface.ComputeSubset() may throw a System.IO.FileFormatException when processing certain Windows fonts, including Calibri.

A minimal reproduction is:

var glyphTypeface = new GlyphTypeface(
    new Uri(@"C:\Windows\Fonts\calibri.ttf"));

glyphTypeface.ComputeSubset(new ushort[] { 0 });

On an affected system, the second line throws an exception similar to:

System.IO.FileFormatException:
'file:///C:/WINDOWS/FONTS/CALIBRI.TTF'
file does not conform to the expected file format specification.

This confirms that the issue does not require Crystal Reports, Infragistics, PrintDialog, or a complete XPS printing workflow. These components expose the problem because WPF uses font subsetting when serializing or printing XPS content.

The font itself is not necessarily corrupted. It can still be loaded, displayed, and read successfully. The failure occurs specifically during the ComputeSubset() operation in the following path:

MS.Internal.TrueTypeSubsetter.ComputeSubset
System.Windows.Media.GlyphTypeface.ComputeSubset
System.Windows.Xps.Serialization.FEMCacheItem.SubSetFont

Community testing indicates that the following font families may be affected: Calibri, Cambria, Constantia, Corbel.

Fonts reported as working include:

Arial, Segoe UI, Times New Roman, Verdana, Tahoma, Consolas, Candara, Calibri Light.

Testing also indicates a regression between WPF component versions 4.8.9340.0 and 4.8.9344.0, with version 4.8.9344.0 delivered by KB5120708. The same machine, document, and font file work before installing the update and fail after installing it.

Detailed community analysis suggests that the affected fonts contain a large legacy kern table whose stored subtable length cannot accurately represent its actual size. The updated WPF font-subsetting implementation appears to validate this structure more strictly and rejects the font. This analysis is consistent with the available reproduction results, but Microsoft engineering is still investigating, so it should not yet be considered the final official root cause.

As you might know, the only available temporary workarounds are:

Use an unaffected font Replacing Calibri or another affected font with Arial, Segoe UI, Times New Roman, or another font that subsets successfully may restore printing while keeping the security update installed. This may not be practical for applications with many customized forms or customer-managed templates, and it may affect document layout or pagination.
Disable font subsetting Developers who directly control XPS serialization may be able to disable font subsetting:

var packagingPolicy = new XpsPackagingPolicy(xpsDocument);
var serializationManager =
    new XpsSerializationManager(packagingPolicy, false);

serializationManager.SetFontSubsettingPolicy(
    FontSubsetterCommitPolicies.None);

serializationManager.SaveAsXaml(document);

This workaround should be tested carefully. Disabling subsetting may embed complete fonts, potentially multiple times, and can significantly increase XPS or PDF file size, memory usage, and processing time.

Remove KB5120708 Removing KB5120708 has been reported to restore functionality. However, KB5120708 is a security update, and uninstalling it may remove important security protections or conflict with organizational patching policies. Therefore, uninstalling the update is not recommended as a preferred or long-term solution.

Microsoft is actively investigating this regression. The available workarounds are temporary mitigations and may not be practical at scale. We will update this thread when an official resolution or additional guidance becomes available.

If this explanation and the diagnostic steps were helpful, I would appreciate it if you could follow the instructions here, so that others experiencing similar behavior can benefit from the answer as well.

Answer 2

I have the exact same problem, also with a .NET Framework 4.8 WPF application, when printing a report from Crystal Reports.

The font that gives the exception is not CALIBRI.TTF, but CALIBRIB.TTF (it's the bold version).

Tried updating Crystal Reports to the last version but didn't solved anything.

Uninstalling the Windows update solved the issue.

Here is part of the stack trace:

Line number: 0
Message: O ficheiro 'file:///C:/WINDOWS/FONTS/CALIBRIB.TTF' não está em conformidade com a especificação de formato de ficheiro esperada.
   em MS.Internal.TrueTypeSubsetter.ComputeSubset(Void* fontData, Int32 fileSize, Uri sourceUri, Int32 directoryOffset, UInt16[] glyphArray)
   em MS.Internal.FontFace.TrueTypeFontDriver.ComputeFontSubset(ICollection`1 glyphs)
   em System.Windows.Media.GlyphTypeface.ComputeSubset(ICollection`1 glyphs)
   em System.Windows.Xps.Serialization.FEMCacheItem.SubSetFont(ICollection`1 glyphs, Stream stream)
   em System.Windows.Xps.Serialization.FEMCacheItem.Commit()
   em System.Windows.Xps.Serialization.XpsFontSubsetter.CommitFontSubsetsSignal(FontSubsetterCommitPolicies signal)
   em System.Windows.Xps.Serialization.XpsFontSerializationService.SignalCommit(Type type)
   em System.Windows.Xps.Serialization.XpsOMSerializationManager.signalReleaseToFontService(Type writerType)
   em System.Windows.Xps.Serialization.XpsOMSerializationManager.ReleaseXpsOMWriterForFixedDocument()
   em System.Windows.Xps.Serialization.XpsOMDocumentPaginatorSerializer.EndPersistObjectData()
   em System.Windows.Xps.Serialization.XpsOMDocumentPaginatorSerializer.PersistObjectData(SerializableObjectContext serializableObjectContext)
   em System.Windows.Xps.Serialization.XpsOMDocumentPaginatorSerializer.SerializeObject(Object serializedObject)
   em System.Windows.Xps.Serialization.XpsOMSerializationManager.SaveAsXaml(Object serializedObject)
   em System.Windows.Xps.XpsDocumentWriter.SaveAsXaml(Object serializedObject, Boolean isSync)
   em System.Windows.Xps.XpsDocumentWriter.Write(DocumentPaginator documentPaginator, PrintTicket printTicket)
   em System.Windows.Controls.PrintDialog.PrintDocument(DocumentPaginator documentPaginator, String description)
   em SAPBusinessObjects.WPF.Viewer.PrintControl.Print()
   em SAPBusinessObjects.WPF.Viewer.ReportAlbum.PrintReport()

Answer 3

Tony Thach (WICLOUD CORPORATION) 340 Microsoft External Staff Moderator

We are actively investigating this issue and will share updates as soon as they become available. Thank you for your patience and understanding.

Tore Østergaard Jensen (TORE) 0 Reputation points

2026-08-15T13:55:24.0766667+00:00

We are seeing the same issue with .Net Framework 4.8 + .Net 8 + .Net 10 (different versions of our application) and an older version of Open Sans (1.10). If upgraded to Open Sans 3.003 it works again.
Tony Thach (WICLOUD CORPORATION) 340 Reputation points Microsoft External Staff Moderator

2026-08-17T05:04:20.5866667+00:00

Hi @Tore Østergaard Jensen (TORE) ,

Thank you for sharing your findings. The fact that the issue also occurs with Open Sans 1.10 across applications targeting .NET Framework 4.8, .NET 8, and .NET 10—and no longer occurs after upgrading to Open Sans 3.003—is a helpful data point for the ongoing investigation.

This suggests that the issue may also affect certain older versions of third-party fonts and is not limited to the Windows font families reported earlier.

If you continue to experience the issue or need further assistance, please create a new Microsoft Q&A question and include your Windows version, installed update KB, application target framework, font version, and relevant exception details so the scenario can be investigated separately.

Thank you again for providing this information.