// TOM'S HARDWARE ITALIA — GAMING
Stampe e PDF possono bloccarsi con l’update .NET: le imprese italiane testino le app WPF
Per le imprese italiane che utilizzano applicazioni desktop gestionali, documentali o industriali basate su Windows Presentation Foundation, l’aggiornamento cumulativo di agosto 2026 per .NET Framework richiede un controllo supplementare prima della distribuzione generalizzata. Il problema può interrompere la stampa e la generazione di documenti PDF o XPS quando l’applicazione elabora alcuni caratteri tipografici molto diffusi.
Microsoft ha confermato che alcune applicazioni WPF possono terminare l’operazione con un errore System.IO.FileFormatException. Per i responsabili IT italiani la conseguenza pratica è inserire i flussi documentali nei test di pre-produzione: verificare soltanto l’avvio dell’applicazione non consente di individuare una regressione che emerge durante stampa, esportazione o serializzazione del documento.
La ricostruzione pubblicata da Wccftech riferisce che il malfunzionamento appare dopo l’installazione dell’aggiornamento .NET Framework di agosto. Il caso più immediato riguarda Calibri, ma l’errore può manifestarsi anche con Cambria, Constantia e Corbel durante la stampa o la produzione di contenuti PDF e XPS.
Il problema non indica necessariamente che il file del carattere sia danneggiato. Nella segnalazione tecnica su Microsoft Q&A, la regressione viene circoscritta all’operazione con cui WPF crea un sottoinsieme dei glifi del carattere. Il font può quindi continuare a essere visualizzato e letto correttamente, mentre la chiamata GlyphTypeface.ComputeSubset() genera l’eccezione.
Questo passaggio è parte del percorso usato da WPF per serializzare o stampare contenuti XPS. La documentazione Microsoft sulla stampa WPF spiega che il formato XPS può essere mantenuto lungo il flusso di stampa e che il sottoinsieme dei font serve a conservare nel documento soltanto i caratteri utilizzati, riducendo le dimensioni del file di spool.
I riscontri raccolti indicano come interessate le famiglie Calibri, Cambria, Constantia e Corbel. Altri caratteri, tra cui Arial, Times New Roman, Verdana, Tahoma, Segoe UI e Calibri Light, non hanno riprodotto lo stesso errore nei test citati. Si tratta tuttavia di risultati riferiti alle configurazioni provate, non di una certificazione generale per ogni versione del font o combinazione applicativa.
Microsoft descrive il difetto tra i problemi noti della KB5120710 per Windows 11 24H2. La scheda Microsoft dell’aggiornamento KB5120710 conferma che l’update dell’11 agosto riguarda .NET Framework 3.5 e 4.8.1 e che il problema può comparire sia nella stampa sia nella generazione di PDF o XPS.
La discussione tecnica segnala inoltre che il comportamento può essere riprodotto direttamente richiamando il metodo di creazione del sottoinsieme, senza utilizzare un’intera pipeline di stampa. Per i team di sviluppo questo permette di costruire un test automatizzato più rapido: una prova isolata su ComputeSubset() può affiancare i test completi su stampanti, code XPS e generatori PDF.
La stessa discussione contiene segnalazioni relative anche a versioni meno recenti di caratteri di terze parti. Questi riscontri rimangono contributi della comunità e Microsoft stava ancora indagando sulla causa definitiva; perciò l’inventario aziendale non dovrebbe fermarsi ai quattro font citati, soprattutto se le applicazioni incorporano template o pacchetti tipografici distribuiti dai clienti.
Microsoft propone un override temporaneo da inserire nel file di configurazione dell’applicazione, normalmente app.config o App.config. Il parametro è Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtection=true e consente di disattivare il controllo che provoca l’errore durante l’elaborazione dei font interessati.