La actualización de .NET de Microsoft rompió las impresiones. Esta es la verdadera lección.

WPF (Windows Presentation Foundation) es un marco de trabajo desarrollado por Microsoft para crear aplicaciones de escritorio de Windows, construido sobre el Microsoft .NET Framework. Las aplicaciones WPF típicas incluyen sistemas ERP, de contabilidad, logística, ingeniería, administración y otras aplicaciones empresariales basadas en Windows. WPF es especialmente común en el software empresarial que se ha desarrollado en el Microsoft .NET Framework durante muchos años.

Las aplicaciones que generan informes, etiquetas, facturas u otros documentos imprimibles, especialmente los sistemas ERP, POS y de almacén que imprimen a través de Windowsson las que vale la pena revisar primero. La actualización acumulativa de agosto de 2026 de Microsoft para .NET Framework está provocando que algunas aplicaciones WPF fallen al imprimir o generar archivos PDF/XPS con ciertas fuentes, incluida Calibri, como informó The Register por primera vez. como informó The Register por primera vezSi tu equipo instaló esta actualización y la impresión de repente empezó a dar errores, es probable que esta sea la razón.

Qué falló en realidad

Las actualizaciones de Microsoft del 11 de agosto para .NET Framework provocan que algunas aplicaciones WPF lancen una System.IO.FileFormatException Ocurre al imprimir o al generar archivos PDF/XPS y está relacionado con la forma en que se procesan ciertas fuentes, incluida Calibri, la fuente predeterminada de Word desde 2007. El fallo afecta a Windows 10, Windows 11 y a todas las versiones compatibles de Windows Server desde 2012 hasta 2025, lo que supone una amplia superficie de exposición para un problema de renderizado de fuentes.

La solución de Microsoft es un interruptor en el archivo de configuración: Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtectionDicha protección se añadió en la misma actualización de agosto para cerrar una brecha de seguridad. Desactivarla para arreglar la impresión significa deshacer una corrección que se había aplicado a propósito días antes. Microsoft lo reconoce en su propia guía, presentando el interruptor como una medida temporal y advirtiendo que vuelve a exponer los sistemas a las vulnerabilidades que la actualización había parcheado.

Microsoft afirma que sigue investigando. Aún no hay un plazo para una solución definitiva.

Qué significa esto si estás aplicando parches

Si tus usuarios se topan con esto, activar el interruptor de configuración de Microsoft (indicado más abajo) les permitirá volver a imprimir al desactivar la nueva protección de procesamiento de fuentes. Es un paso atrás en materia de seguridad, según la propia descripción de Microsoft, y está pensado como temporal. Si optas por esta vía, lleva un registro de los equipos en los que la apliques para poder retirarla en cuanto se publique una solución definitiva.

Solución rápida. Añade esto al archivo de configuración de la aplicación afectada, en la sección <runtime>Es una configuración por aplicación, no para todo el equipo, así que si la aplicación ya tiene una <runtime> En la sección, añade esta línea en lugar de reemplazar el archivo:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.MS.Internal.TtfDelta.DisableCmapAndSbitOverflowProtection=true"/>
  </runtime>
</configuration>

La cuestión a largo plazo no es tanto este error en particular, sino el lugar que ocupan las impresiones en tu entorno. Cada vez que la impresión depende de toda la pila de Windows (los controladores, el Print spooler, .NET, WPF y cualquier otra cosa que incorpore una aplicación determinada), hereda todos los riesgos asociados a los parches de esa pila, ya tenga o no algo que ver con la impresión.

Construye un sistema de impresiones que no dependa de Windows

Este error reside en la propia aplicación WPF, antes de que un trabajo de impresión llegue a cualquier sistema posterior, incluido ezeep. Esto es cierto incluso con más de 25 años de experiencia en impresión empresarial a sus espaldas. Es un ejemplo dentro del patrón más amplio de cambios en la pila de impresión de Windows que Microsoft ha estado impulsando desde Windows Protected Print. Es una razón para evaluar qué se está imprimiendo en tu organización y cómo, y luego eliminar las dependencias del sistema Windows allí donde la aplicación lo permita.

En el caso específico de las aplicaciones WPF, este error señala exactamente dónde reside el riesgo. WPF incluye su propia canalización de impresión (PrintDialog, FixedDocument, XpsDocument) que representa el contenido y genera la salida de impresión o PDF en el mismo paso. Es la opción de menor resistencia para un desarrollador. No hay que añadir ninguna biblioteca extra y funciona de inmediato. También es exactamente el código que falló.

Lograr eso con una biblioteca de PDF independiente —una que nunca toque la creación de subconjuntos de fuentes ni la renderización propias de WPF— elimina la dependencia de ese código específico. Combínalo con la API de ezeep (o su servidor MCP, para aplicaciones desarrolladas con herramientas de desarrollo asistidas por IA) para gestionar las impresiones, y la aplicación deja de depender de la pila de impresión de Windows en general, no solo de este error: las etiquetas de almacén pueden imprimirse directamente desde los eventos de pedido, las facturas desde el software de contabilidad, los informes de forma programada, todo ello sin que haya un usuario con la sesión iniciada ni un cuadro de diálogo de impresión de por medio.

Esto no arreglará los equipos que ya ejecutan la actualización defectuosa. Es un argumento para desarrollar la próxima versión de la aplicación para que el próximo error de la pila de impresión de Windows tampoco sea tu problema.