La trampa de los estándares

No pensamos demasiado en ellos, pero los formatos de archivo son una parte esencial de nuestra vida digital: en ellos guardamos imágenes, texto, bases de datos, confiamos en ellos para almacenar nuestra información importante, dependemos de ellos. Pero así como son una herramienta versátil y potente pueden también crear trampas difíciles de evitar.

Estas trampas pueden tomar varias formas. La más evidente es el infame «vendor lock-in»: un formato de archivo cuyo funcionamiento es secreto o está «protegido» por patentes en modo tal que solo pueda ser utilizado por un programa particular o, en el menor de los males, por «socios autorizados».

No creo que los lectores de este pingüino necesiten una lista de ejemplos de esta nefasta (al menos para el usuario) práctica.

Para luchar contra el «vendor lock-in» es que, en principio, nacen los estándares abiertos: contra los formatos cerrados que alguna vez utilizó MSOffice se creó el estándar ODF, para enfrentarse al ubicuo mp3 vorbis y compañía, etcétera.

La idea es que al ser un estándar abierto cualquiera puede implementar su uso y que por lo tanto un mismo archivo podrá ser abierto por cualquier programa en cualquier momento obteniendo siempre el mismo resultado.

La idea, digo.

Porque si bien es cierto que a veces esto se logra (png, PDF, vorbis, theora) la realidad es siempre más compleja.

Tomemos como ejemplo un archivo ODT creado en LibreOffice Writer en el que además de aplicar características OpenType avanzadas se tenga la fuente incrustada en el mismo.

Probemos ahora a abrir ese archivo en Apache OpenOffice o en Calligra Suite (en ambos se ve igual). ¿Resultado?

Y mejor no empezamos a hablar de los problemas que tiene Calligra Words para abrir documentos odt «normales»

Ahora bien, el formato ODF es un estándar ISO, ¿porqué tanta diferencia?, ¿no debería ser el resultado siempre el mismo?

Desafortunadamente no.

Pero antes de continuar debemos distinguir entre estándares «solo para almacenar y mostrar» y estándares «para ser manipulados». Ejemplo de estándar para «almacenar y mostrar» son los formatos de audio y vídeo o el magnífico PDF, mientras que para los formatos «a ser manipulados» tenemos el formato utilizado por LibreOffice y compañía, ODF. En este artículo estamos hablando mayormente de la segunda categoría, que nadie va a discutir la utilidad de un estándar como PDF. ¡Los PDF son magníficos! Solo no hay que tratar de modificarlos.

Veamos entonces el porqué un archivo «estándar para ser modificado» como el ODT puede fallar tanto.

Por una parte diferentes programas tienen distintos niveles de desarrollo por lo que el hecho de que algo esté definido en el estándar no implica que todos los «clientes» de ese estándar lo implementen. Por otro lado, y esto es aún más importante, los «estándares para ser modificados» no suelen ser las recetas rígidas exentas de ambigüedad que muchos creen: hasta donde comprendo el asunto ODF permite el uso de «extensiones» no definidas explícitamente en el estándar, extensiones que en realidad solo podrán ser utilizadas por una implementación particular que las reconozca… y LibreOffice hace uso de varias de esas extensiones, como incrustar fuentes, por ejemplo, o utilizar nombres extendidos para tener soporte OpenType.

¿Conclusión?, pues que ODF no resuelve el problema de la «interoperatividad». Y por si esto fuera poco agrega otro problema más sutil, pero no por eso menos grave. Veamos un ejemplo.

Writer ofrece la posibilidad de numerar las notas al pie de página «por capítulo». El problema es que define como «capítulo» solo títulos de nivel 1: si queremos agrupar nuestros capítulos en «partes» y nuestras notas al pie «por capítulo» tendremos problemas si tratamos de utilizar el nivel 1 para la parte y el 2 para el capítulo.

Existen «trucos» para superar este problema, es verdad, pero ninguno de ellos resulta perfecto. Por algo son trucos.

Ahora bien, ¿imaginas, lector, el motivo por el cual esta opción de usar «capítulos» que sean títulos de nivel 2 no está disponible en Writer? Sí, se debe al formato ODT: simplemente no lo permite.

Bug 112301 – Set outline level for chapters

(ver comentario 2)

LibreOffice ha sido capaz de aprovechar las ambigüedades de ODF para implementar características sumamente útiles y potentes como el soporte OpenType, el incrustar fuentes y vídeos en sus archivos, implementar firmas digitales y mucho más, pero al costo de perder interoperatividad con otros editores ODF. Y al mismo tiempo LibreOffice tiene las manos atadas a la hora de implementar características útiles cuando el estándar ODF decide ser explícito.

Es decir, por una parte la ambigüedad de ODF ha dado lugar a una especie de «vendor lock-in soft» donde documentos medianamente complejos creados en versiones recientes de LibreOffice no funcionan correctamente en otros editores ODF, mientras que por otra parte la rigidez del estándar hace difícil el ir más allá de lo que ya tenemos, bloqueando efectivamente el progreso del programa.

En el pasado fui un furioso defensor de ODF, pero ahora ya no estoy tan seguro de su utilidad. Y es que el objetivo de limitar el poder de los formatos de MSOffice lo ha cumplido solo parcialmente (sigue siendo más sencillo manipular un .doc que un .docx), crea la ilusión de una interoperatividad en realidad inalcanzable y por si esto fuera poco dificulta la implementación de nuevas características.

Ahora creo que cada programa que crea documentos «para ser manipulados» debería utilizar su propio formato de archivo y que ese formato de archivo solo necesita estar bien documentado, con documentación accesible a todos así cualquiera puede implementar filtros para importar y exportar a ese formato. Nada más. ¿Ser un «estándar»? Para esta categoría de programas ya no creo en los estándares. Uno de los motivos por los que LaTeX sigue funcionando a través de los años es que no se preocupa de lo que hacen los demás y tiene un formato de archivo que le sirve solo a él. Comprensible por todos, sí, pero exclusivo.

Los estándares han resultado ser un mito pernicioso, lleno de trampas. Y es que solo funcionan (cuando lo hacen) para tareas bien definidas como un formato de imagen, audio o vídeo o cuando el contenido que llevan no debe ser modificado, como en un PDF. Para tareas más complejas como documentos que combinan texto e imagen (y audio y vídeo) en una página bien definida y que deben ser manipulados (documentos de texto, planillas de cálculo) los estándares resultan ser poco más que un cuento de hadas: algo bonito, incluso deseable, pero completamente alejado de la realidad.

Y sí, HTML es una más que bienvenida excepción, pero tiene su truco. O más bien tres trucos.

Primer truco: HTML es un estándar que nació antes que los programas que actualmente lo implementan mientras que ODF nació a partir del formato ya en uso por OpenOffice.org y por lo tanto los otros programas que lo implementan se adaptaron a ese formato, no les es nativo.

Segundo truco: el visor de HTML (el navegador) está separado del editor de HTML mientras que para ODF ambas funciones coinciden en el mismo programa. Esto hace que HTML sea más parecido a los estándares «para almacenar y mostrar» (como el PDF, que sí funciona) que a los estándares «para ser modificados» (como el ODF, que como estamos viendo en este artículo puede resultar un tanto problemático).

Tercer truco: los desarrolladores web necesitan comprobar todo varias veces y en varios navegadores diferentes para hacer «ajustes finos» antes de poder publicar por lo que… en fin, que se entiende.

Finalmente comprendo el porqué la gente de Abiword usa un formato propio y solo da soporte para importar o exportar ODT: atarse a un estándar puede complicarte la vida.

Para completar la lista de dificultades podríamos hablar también del asunto de la proliferación de estándares… pero ese es otro problema que me permitiré dejar pasar.

Anuncios

,

  1. #1 por Ondiz el 29 septiembre, 2017 - 9:55

    ¡Ay los formatos y los estándares, cuántos quebraderos de cabeza me han dado! Es especialmente horrible con los programas de CAD en los que cada programa usa uno y supuestamente hay un estándar para compartir que empezó siendo IGES, luego pasó a STEP… La cuestión final es que una acaba perdiendo horas y horas de vida corrigiendo la geometría de una pieza porque es imposible importarla bien por mucho estándar que haya.

    Es exactamente lo que comentas, la ilusión del “formato unificado” empeora el problema.

    Un saludo 🙂

    • #2 por elpinguinotolkiano el 29 septiembre, 2017 - 12:52

      Lo mejor de que cada uno use su propio formato sería la sinceridad: los líos seguirían existiendo, pero al menos todos estaríamos enterados y nadie pretendería que esos problemas no existen 😉

      Desafortunadamente en muchos casos ya es demasiado tarde, dudo mucho que LibO o Calligra Suite alguna vez cambien de formato a algo más útil 😦

  2. #3 por Anónimo el 29 septiembre, 2017 - 11:04

    Yo para CAD uso el «estándar» SVG que está en W3C. ¿En qué versión? En la de Inkscape, que es el programa que utilizo, y que añade a la norma capas y algo más.

    Saúdos,

Aquí puedes dejar un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: