Hace más de un lustro, publiqué Mejorar presentaciones. Después de ese tiempo, Vídeo vectorial. Un método para presentaciones es la explicación actualizada.

En cinco años, he podido comprobar varias cosas. Tengo la impresión en que puedo resumir ese período como que nada ha cambiado. Pero es mejor que cuente cuál ha sido el desarrollo y qué elementos pueden influir en el futuro.

No hay otro modo de hacerlo

Hace cinco años pensaba que sería un gran avance que las presentaciones vídeo vectorial debían ser PDF, en vez de SWF. La documentación sobre JavaScript para Acrobat hacía prometer esa capacidad1. Pensaba también que así, al existir Acrobat Reader para plataformas móviles, podría llegar a lo que Flash no llegaba.

En ambas cosas estaba equivocado. Primero, lo audiovisual en PDF necesita de Flash para integrar archivos de sonido y vídeo. Hay un método anterior, que no permitiría el vídeo vectorial que expongo aquí, pero es obsoleto. Con lo que las plataformas móviles siguen fuera. En segundo lugar, PDF no funciona porque el sistema apenas responde2. Una orden de reproducción sencillla3 no siempre funciona, o tarda al menos cinco segundos en comenzar ejecutarse. Así es imposible pretender el método que busco.

Mucho me temo PDF no está en condiciones de asumir aquello para que lo debería valer. Por tanto, Flash es la única solución como formato. También es una buena solución, porque está precisamente pensada para animaciones vectoriales. Es bueno no olvidar que el vídeo vectorial no deja de ser una animación.

Desde ahora será más difícil

Desgraciadamente, me temo que para los usuarios la adopción de PDF como estándar ISO no es necesariamente una mejora. Desde luego, la publicidad del formato se vuelve perfectamente opaca. Porque ahora, la propietaria del formato y de su especificación es la Organización Internacional de Estandarización. En concreto, del ISO/TC 171 —su Comité Técnico 171—.

La mayoría de los documentos relacionados con PDF —desde que es un estándar— están pendientes de publicación. De momento, sólo son accesibles a socios. Entre esos documentos está ECMAScript for PDF —esto es, JavaScript para PDF—.

De este modo, supongo que se querrá vender que PDF ahora tienen un desarrollo abierto. No es abierto, ha pasado a la opacidad. No sólo en su desarrollo, sino en que luego otras personas puedan incorporarlo a sus aplicaciones.

Cuando pertenecía a Adobe, PDF estaba en un escaparate. Era una especificación pública, aunque no abierta. Ahora que pertenece a la ISO, se ha quitado de la vista del público —ni pública, ni mucho menos abierta4—.

Prometo que me gustaría que fuera de otra manera, pero me temo que van a conseguir desconectar a la mayoría. El riesgo para el formato mismo es que habrá muchos que se queden en la versión antigua, desechando las presuntas mejoras de la nueva. No creo que Adobe pretendiera eso cuando se decidió a estandarizarlo. Una pena.

Dos lecciones de la historia

Quizá no lo entendamos, pero la informática no es una actividad industrial. No es fabricación de productos. Una clave dentro del sistema es la protección de los programas por derechos de autor. Sólo secundariamente se ha permitido la existencia de patentes de métodos de programación. Estandarizar en informática es esencialmente distinto.

Veamos un ejemplo, por lo que muchos piensan que Flash es inseguro: internet. Más en concreto, los sitios y páginas de internet. Existe un consorcio, el W3C o World Wide Web Consortium, que publica las especificaciones correspondientes. ¿Creemos realmente que internet sería hoy lo que es si fueran de pago? ¿Se habría ganado algo? Es fácil entender la universalidad de internet tiene mucho que enseñarnos aquí.

El pago sólo es una parte del problema. Se trata de la mayor disfusión posible de un formato. Aunque a la ISO le cueste entenderlo, la informática no es fabricación industrial. Cualquiera podemos programar. Limitar la entrada no es buena idea. Porque este estándar es de un formato, no de un producto final. Comparémoslo con el estándar ISO 216, que define los tamaños de papel. La hoja A4 en ese estándar son 210 × 297 mm. Una especificación informática necesita estudio o consulta. Si no es pública, muchas personas nos quedaremos en el camino —o sencillamente fuera—. El fin de un formato electrónico es su uso universal, o a eso debería apuntar su normalización. Están persiguiendo lo contrario a lo que deberían buscar.

Con es un mal modelo de distribución lo que están consiguiendo, es un pésimo modelo de difusión lo que están logrando. A diferencia del papel, es esencial que haya nuevas versiones que cambien los estándares. Lo importante es que llegue a todo el mundo, como entiendió perfectamente Adobe. Si la ISO entiende que lo importante es que la gente pague, creo que tiene un problema grave.

Lo que está en juego no es la gratuidad de un libro. Imaginemos las leyes, que suelen compararse con el código de la sociedad. Pensemos en nuestro diario oficial el Boletín Oficial del Estado. Seguro que cuesta dinero producirlo, pero es mucho mejor que esté abierto que no lo esté. Las normas jurídicas deben ser públicas para que sean efectivas y eficaces. Con la normalización informática, en la práctica pasa algo parecido.

El león de la Metro Goldwyn Mayer tiene encima de la cabeza aquello de ars gratia artis. No es que precisamente lo hagan ellos, pero significa «por amor al arte». De muchas actividades podemos no tenemos que sacar beneficio monetario directo. Muchas pueden estar relacionadas con nuestro trabajo. Trabajar no es calcular cuántos billetes nos aporta cada cosa que hacemos. Bien, teniendo disponibles las referencias, podemos hacer mejor nuestro trabajo. Si hasta hace no mucho nos quejábamos que no había buenos visores PDF, exceptuando Adobe Acrobat Reader, ¿cómo pretendemos que sea ahora? Incluso aunque demos ejemplares a los desarrolladores de proyectos abiertos5. ¿No ven que dejan fuera a colaboradores ocasionales, o usuarios que quieren dar informes detallados de fallos? De tanto insistir, pierden a una buena parte su público quienes exigen entrada.

Pensemos en cuánta creatividad —a pesar de que ahora esté muy denostado— ha permitido Flash. Es importante que la especificación de su formato sea pública para que pueda haber visores que permitan acceder a su contenido. Aunque sólo sea para poderlo pasar al formato que sustituya a Flash. Hasta donde yo sé está por desarrollar. Pero si los archivos Flash no los entendemos, habremos perdido todas las creaciones que contienen y que ese formato ha hecho posible.

Notas

  1. Son las anotaciones /RichMedia, según el código PDF. La documentación es doble: especificación en el formato y tratamiento en JavaScript

  2. Es muy revelador que Developing Acrobat® Applications Using JavaScript™ ni mencione las anotaciones de las que estoy tratando en ese documento. 

  3. Mi prueba consistía en reproducir directamente archivo de sonido MP3 incluido en el documento. Habitualmente no respondía a la primera y no pocas veces había que reiniciar Acrobat Reader DC. Me quedé sorprendido de lo extraordinariamente mal que funcionaba. 

  4. Sólo para sugerir el uso de LZMA como formato de comprensión, es necesario asociarse —con su correspondiente cuota—. Incluso lo sería para pedir la corección de errores arrastrados desde la versión 1.7 y reconocidos por Adobe. En cuanto a la sugerencia, SWF incluye compresión LZMA desde octubre de 2012. 

  5. Se ha arbitrado un método para que sean gratuitos los ejemplares electrónicos para cinco desarrolladores por proyecto, se ha visto en algún caso. Con unas reglas bastante complicadas de uso por persona y como haciéndoles un favor, todo hay que decirlo. En todo caso, el favor es mutuo.