por Italo Vignoli
A cualquiera que elija el formato estándar en lugar del privativo le surge naturalmente la siguiente pregunta: ¿por qué las suites ofimáticas que utilizan OOXML como formato nativo manejan el ODF de maneras que van desde deficientes hasta espantosas?
Las dos respuestas más obvias son estas: los proveedores han descuidado el formato, tratándolo como algo secundario, o bien están trabajando discretamente para desacreditar la idea misma de la interoperabilidad transparente, mediante un soporte tan deficiente que demuestra que el formato «no funciona».
Ambas respuestas son demasiado simplistas. La realidad es que hay tres mecanismos distintos en juego, que se aplican a diferentes proveedores en proporciones distintas y que, en última instancia, convergen en el mismo resultado.
Un reto que no es un reto
Leer y escribir ODF fielmente, de manera aislada, es realmente factible: el formato está especificado de manera completa y abierta, y no existe un equivalente a los notorios indicadores de compatibilidad con versiones anteriores de OOXML, que hacen referencia a comportamientos no documentados de antiguos productos de Microsoft que solo Microsoft puede reproducir.
Un equipo de desarrollo competente es capaz de implementar ODF correctamente basándose únicamente en la especificación de ODF.
Sin embargo, una suite ofimática no implementa un formato de manera aislada: cuenta con una representación interna del documento en memoria. Cargar un documento consiste en mapearlo hacia esa representación, y guardarlo consiste en mapearlo desde ella.
La fidelidad es máxima cuando el modelo interno es congruente con el formato del documento. El modelo de LibreOffice es esencialmente ODF, por lo que, en este contexto, ODF es verdaderamente nativo.
Cuando el modelo interno de una suite tiene la estructura de OOXML, ODF deja de ser nativo y se convierte en una importación externa que debe convertirse hacia y desde una representación diseñada para un formato diferente.
Tomemos una característica de ODF de la que carece OOXML: el campo ODP que muestra el número total de diapositivas. Lo revelador es que la información en sí misma no falta en un archivo PPTX. El paquete enumera cada diapositiva, y el recuento está disponible para cualquier programa que lo abra. Lo que OOXML no ofrece es una forma de expresar que este número es el total. Hay un campo para el número de diapositiva actual y ninguno para el recuento, y la propia guía de Microsoft recomienda escribir la cifra en un cuadro de texto y mantenerla actualizada manualmente, lo cual es una descripción precisa de no tener ningún campo en absoluto. Todas las soluciones alternativas publicadas consisten en una macro o un complemento que calcula el número una sola vez y lo escribe como texto fijo.
Así que cuando se abre un archivo ODP que contiene ese campo en un editor basado en OOXML, lo que se pierde no son los datos, sino la instrucción. El número se conserva. El hecho de que se haya calculado, no, y a partir de ese momento el documento ya no sabe cuán largo es.
La conversión en sentido contrario falla de manera más discreta y, por lo tanto, es peor. El recuento de diapositivas exportado de Impress a PPTX debe escribirse como texto fijo, por lo que la presentación es correcta el día de la conversión, pero se vuelve incorrecta la primera vez que se agrega o elimina una diapositiva. Un número que ha dejado de calcularse pero que aún parece plausible es más perjudicial que una discrepancia visible, ya que nada en el documento indica que sea necesario revisarlo.
Un editor basado en ODF maneja el caso inverso de una manera totalmente diferente. Cuando encuentra una característica presente en un formato y ausente en el otro, deja los datos a un lado en lugar de descartarlos, y los restaura cuando el documento vuelve a OOXML. En LibreOffice, este mecanismo tiene un nombre, el «grab bag», y es una parte documentada de los filtros de importación, en lugar de un comportamiento incidental.
La diferencia no radica en la calidad del filtro de importación, sino en el hecho de que la arquitectura fue diseñada para conservar el significado del otro formato.
Esto es importante, porque significa que el deficiente soporte a ODF en las suites basadas en OOXML está en gran medida predeterminado incluso antes de que surja la cuestión del motivo. La dificultad no es absoluta, sino relativa a la arquitectura que ha elegido el proveedor.
Tres mecanismos
Primero: la apuesta por un formato de referencia. Algunas suites ni siquiera toman en cuenta el ODF, ya que han construido su propuesta de valor en torno al otro formato.
OnlyOffice es el caso más evidente, ya que se desarrolló en torno a OOXML y convierte todos los demás formatos a ese modelo, por lo que ODF es, por diseño, un formato de importación y exportación de segunda clase.
WPS Office es un software creado para abrir archivos docx, xlsx y pptx de manera fiel. Su funcionalidad ODF proviene del complemento del propio proyecto OpenXML de Microsoft y se integró en la aplicación recién en mayo de 2022, como una capa de conversión escrita para ODF 1.1, es decir, para la revisión de 2007 del estándar. Desde el día de su lanzamiento, ya llevaba incorporados quince años de retraso.
Google Workspace es una variante de la misma lógica, más que una excepción a ella. Su modelo interno no es ni ODF ni OOXML, sino una representación web privativa, y ambos formatos llegan a él a través de una capa de conversión. Para una administración pública, la consecuencia es idéntica: el estándar abierto es un destino de exportación, no el sustrato en el que piensa el software.
Para estos proveedores, ODF nunca formó parte de la estrategia. Su propuesta consiste en abrir documentos de Microsoft en algo distinto a Microsoft Office y hacer que se vean bien; por lo tanto, el deficiente soporte al ODF es la consecuencia directa de esa estrategia.
Segundo: la falta de inversión deliberada. Esta es probablemente una causa que afecta a todo el sector de las suites ofimáticas. Aunque ODF es más fácil y económico de implementar correctamente, el proceso sigue implicando costos y plazos de desarrollo, control de calidad y mantenimiento, a fin de mantenerse al día con un estándar en constante evolución.
Si los usuarios de un proveedor intercambian principalmente archivos docx, el valor comercial marginal de una compatibilidad excelente con ODF es casi nulo, por lo que ODF se implementa primero al nivel mínimo y luego se deja de lado sin más.
La percepción de que la compatibilidad con ODF no importa es, en sí misma, una consecuencia del dominio del mercado por parte de una sola empresa, y su efecto es doble. El «lock-in» se convierte en una característica del software que el mercado considera totalmente normal, y ODF adquiere una reputación de fragilidad que no requirió ninguna campaña deliberada para generarse.
Tercero: la descalificación deliberada. Este mecanismo es real y concierne a la propia Microsoft, con el Service Pack 2 para Office 2007. La compatibilidad con ODF que incluyó falló en dos aspectos opuestos al mismo tiempo.
Al leer una hoja de cálculo ODF generada por otra aplicación, Excel eliminaba silenciosamente las fórmulas y conservaba únicamente el último valor que había tenido cada celda, reduciendo el documento, según la evaluación de Rob Weir en ese momento, a una mera «tabla de números» sin la lógica de cálculo. Al escribir, Excel colocaba las fórmulas en un espacio de nombres de Excel que no era ni el utilizado por OpenOffice y las demás aplicaciones ODF, ni el de OOXML. Las aplicaciones que verificaban el espacio de nombres rechazaban el documento de inmediato; aquellas que no lo verificaban mostraban un archivo dañado en el que ni la fórmula ni el valor se veían correctamente.
Este es un mecanismo clásico para desacreditar la interoperabilidad: cumplir con un requisito de formato mediante una implementación que solo cumple en teoría y produce archivos visiblemente dañados, lo que demuestra a todo observador que el ODF en realidad no funciona.
En ese momento, Microsoft argumentó que el estándar ODF no definía las fórmulas de hojas de cálculo -que recién se incorporaron con ODF 1.2- y que, por lo tanto, no había ninguna referencia que seguir. El argumento no resiste la propia respuesta de Microsoft. Al responder públicamente a Weir, el evangelista de Microsoft, Doug Mahugh, comparó los dos comportamientos: ante la misma sintaxis de fórmula no reconocida, IBM Lotus Symphony conservó el marcado de la fórmula, mientras que Excel conservó los valores almacenados en caché. Ninguna de las dos aplicaciones contaba con una especificación que seguir. Solo una tenía una arquitectura con un lugar donde colocar lo que no entendía.
Vale la pena señalar lo que Excel conservó. No la fórmula, sino su último resultado, lo cual es la misma reducción que vimos con el recuento de diapositivas, en una aplicación diferente. Un modelo moldeado por OOXML conserva el valor y pierde el cálculo que lo produjo, y un documento reducido a sus últimos resultados es un documento que ha dejado de poder corregirse a sí mismo.
Ese episodio ocurrió hace diecisiete años, y sería fácil dejarlo de lado como algo del pasado. Hoy en día, Microsoft Office declara que es compatible con ODF 1.4. Pero lo que ha mejorado es la conformidad nominal, no la arquitectura. El modelo interno sigue siendo OOXML, y cada documento ODF que pasa por él sigue siendo una traducción.
La síntesis
La deficiente compatibilidad con ODF no es un veredicto técnico sobre el formato, sino la manifestación visible de un mercado organizado en torno al dominio de un único proveedor, y esa situación no surgió por casualidad.
Para las administraciones públicas europeas, esto redefine la cuestión práctica, ya que los problemas de interoperabilidad que enfrentan al intentar migrar al estándar abierto ODF no son causados por ODF, que está completamente listo. Son evidencia de que la mayoría de las herramientas disponibles fueron diseñadas para ser nativas del formato de otra empresa, y de que el único proveedor con el poder de cambiar esta situación ha optado repetidamente por no hacerlo.
El precario estado de la compatibilidad con ODF en el mercado no es una razón para dudar en adoptar el estándar, sino la razón más sólida posible para exigirlo, y exigirlo con precisión.
La cuestión que protege los documentos de un organismo público, y su soberanía sobre ellos, no es si se es compatible con ODF, sino si esa compatibilidad es nativa; es decir, si el modelo interno del software es el estándar abierto, o si el estándar es simplemente un elemento externo dentro de un motor creado para otra cosa.
El formato de los documentos es la base de la continuidad administrativa y la memoria pública. Elegir herramientas que utilicen de forma nativa un estándar abierto no es una cuestión de preferencia entre opciones equivalentes, sino la diferencia entre ser dueño de tus documentos y tener que pagar por el acceso a ellos a quien controla el formato en el que están escritos.
Artículo original (en inglés)
Ilustración: Sebastián Acosta Nieto (Colombia)
