Goals and Motivations/es
From GNUpdf
Contents |
Introducción
El objetivo del proyecto GNU PDF es desarrollar y proporcionar al público una implementación libre, de calidad y completa del formato PDF y sus tecnologías asociadas.
Estamos trabajando para implementar las siguientes tecnologías y especificaciones:
- PDF 1.7
- PDF/A-1 (ISO 19005-1:2005)
- Extensible Metadata Platform (XMP)
- XML Forms Architecture v2.4 (XFA)
Uso del formato PDF en la industria
El formato PDF se ha convertido en el estándar de facto para compartir documentación en el entorno industrial.
La mayoría de las empresas y corporaciones utilizan documentos PDF para transmitir todo tipo de información: manuales, documentos de proyecto, presentaciones, etc. Esto ocurre incluso si el documento ha sido compuesto originalmente con otros programas, en muchos casos libres, como OpenOffice, LaTeX o algún otro procesador de textos.
Desgraciadamente es muy habitual que estas empresas utilicen software privativo para componer, leer y manipular ficheros PDF. La consecuencia es que los trabajadores y clientes de dichas empersas se ven forzados a utilizar programas privativos.
Uso del PDF en los gobiernos
La utilización de documentos PDF por parte de muchos gobiernos y organismos públicos como un medio para comunicarse con los ciudadanos reviste de especial importancia. Por ejempo, actualmente no existe software libre que implemente formularios PDF en su totalidad. Como consecuencia millones de ciudadanos son forzados a utilizar software privativo (que vulnera sus derechos) para realizar tareas como petición de subvenciones públicas, acceso a los servicios de la seguridad social, pago de impuestos y muchas otras que requieren comunicación con las agencias públicas.
Esto resulta muy peligroso, ya que las empresas que proporcionan ese software privativo pueden obtener fácilmente acceso a nuestra información privada.
En el estado actual de las cosas, la realidad es que el software privativo (impredecible, inseguro y quizá malicioso) es un intermediario obligado entre nosotros y nuestros gobiernos e instituciones.
El formato PDF será un estándar internacional
PDF 1.7 será ISO 32000
Actualmente (Junio del 2007) la empresa que mantiene el formato PDF está trabajando junto con la ISO (Organización internacional de estandarización) para declarar la versión 1.7 de la especificación del formato PDF como un formato internacional denominado ISO 32000.
De esta forma, parece que el formato PDF será pronto un estándar internacional para intercambio de información en la forma de documentos. Se espera que tanto los gobiernos como las agencias públicas utilizarán el nuevo formato estandarizado. Después de todo, ya es el estándar de facto.
La consecuencia es que debemos disponer de software libre para manipular documentos ISO 32000. Esto implica que realmente necesitamos software libre que sea capaz de operar de forma completa en los documentos PDF 1.7.
Archivado a largo plazo y ISO 19005 (PDF/A)
El estándar ISO 32000 no está todavía terminado. Pero el estándar denominado ISO 19005 fué aprobado por la ISO en Noviembre del 2005.
Este estándar define un formato de documentación denominado PDF/A, orientado a ser utilizado para archivado y preservación a largo plazo de la información. El PDF/A es un subconjunto de la especificación 1.4 del formato PDF.
De la sección titulada "¿Por qué PDF/A?" de la FAQ oficial de iso ISO 19005-1:
Tremendas cantidades de información valiosa están siendo actualmente creadas y almacenadas como documentos PDF, en todo el mundo. Se requiere una especificación-solución para asegurar que todo ese matierial digital en forma de PDF permanezca siendo legible y accesible a largo plazo. PDF/A es dicha especificación.
Muchas organizaciones están introduciendo PDF/A en sus procesos de archivado:
- The US National Archives and Records Administration (NARA)
- The Swedish National Archives
- ...
Por otra parte, todos los fabricantes que ofrecen de forma oficial soporte para PDF/A-1 son compañías que ofrecen productos privativos.
Gráficos y ISO 15930 (PDF/X)
El PDF/X es otro subconjunto ISO de la especificación PDF. Su campo de aplicación es el intercambio de gráficos conservando una gran independencia de los dispositivos concretos.
Varias compañías implementan este futuro estándar. Todas ellas ofrecen soluciones privativas.
¿Por qué estamos escribiendo una nueva implementación del formato PDF?
El objetivo principal del proyecto GNU PDF es proporcionar una solución completa y de gran calidad para gestionar contenido PDF. Debido a todos los motivos expuestos en las secciones previas, realmente necesitamos acceso libre a la tecnología PDF. El proyecto figura en la lista de proyectos de alta prioridad de la Free Software Fundation. Además estamos trabajando para conseguir fondos para pagar a desarrolladores y así alcanzar nuestros objetivos lo antes posible.
Bajo nuestro punto de vista, se trata de un asunto urgente.
Actualmente existe software libre que puede proporcionar algo como lo descrito anteriormente, pero hemos decidido comenzar un nuevo proyecto desde cero debido a algunos requerimientos que tenemos en mente:
- Completitud
- Portabilidad
- Eficiencia
- Robustez con respecto a asuntos legales
Antes de comenzar el proyecto realizamos un extensivo estudio de los paquetes de software libre existentes que implementan el formato PDF. Por una razón u otra, segun el caso, decidimos no reutilizar dicho software.
¿Cuáles han sido esos motivos?
Ghostscript es una maravillosa pieza de software. Su cobertura de la especificación postscript es excelente y su capacidad de ejecutarse incluso en una tostadora es impresionante. Pero el código de Ghostscript es gigantesco y extremadamente complejo. No estamos criticando este hecho. Pensamos que no es innecesariamente complejo para las tarea que implementa: interpretar postscript. Como dice Peter Deutsch (autor de Ghostscript) utilizar los allocators ghostscript en el nivel C (principal fuente de complejidad del código) no es divertido, pero hasta ahora no conocemos una forma mejor que hacerlo. Estamos totalmente de acuerdo: Ghostscript es complejo simplemente porque implementa cosas muy complejas.
Pero la complejidad asociada a la interpretación de postscript no es en absoluto necesaria para interpretar PDF. Preferimos trabajar en un intérprete PDF ligero.
Del mismo modo también pensamos en otras consideraciones menores que nos llevaron a no reutilizar Ghostscript. El intérprete PDF distribuido con Ghostscript está escrito en postscript. No resulta fácil encontrar hackers capaces de (o dispuestos a) escribir postscript. Además, este hecho dificulta mucho la interacción con otras herramientas que puedan necesitar manipular ficheros PDF.
También consideramos en su momento utilizar xpdf o la biblioteca poppler. Al fin y al cabo, casi todos los visores libres de PDF utilizan dicha biblioteca. Funciona y está mantenida de forma activa. Sin embargo en este caso también encontramos motivos para no reutilizarla. Tiene importancia el asunto de la portabilidad. poppler está escrita en C++. Si es difícil escribir C portable, utilizar C++ es clamar por problemas de portabilidad. Alguien podría querer empotrar la librería gnu en un dispositivo embarcado, por ejemplo. Además, hay que tener en cuenta que la mayoria del sistema GNU está escrito en C, y uno de los objetivos de la librería PDF es proporcionar soporte para manipular PDF a los demás paquetes GNU.
Estamos utilizando un método aburrido (pero esperamos efectivo) para obtener la mayor completitud posible: diseñar e implementar a lo "ancho" en lugar de a lo "largo". Antes de pensar en implementar el lexer o el parser, por ejemplo, queremos tener listo el soporte completo para todos los filtros (incluidos los más raramente utilizados, e incluyendo los relativos a encriptación), todos los objetos estructurados PDF (incluyendo las funciones, en todos sus tipos), etc. No queremos pasar al siguiente capítulo de la especificación PDF hasta tener completado el soporte para los capítulos anteriores, en su totalidad. Desde este punto de vista, el objetivo de GNU PDF difiere lo suficiente del de Ghostscript y poppler como para considerar una nueva implementación. Tal y como lo vemos, los objetivos de ghostscript están más orientados a proporcionar buen soporte para postscript en lugar de buen soporte para PDF. De forma similar, el objetivo del proyecto poppler también parece más orientado a la visualización que a proporcionar buenas interfaces para edición de PDF.
Finalmente, también consideramos MuPDF+Fitz. De nuevo, detectamos el suficiente grado de divergencia en objetivos como para decidir no utilizarlo: el autor de mupdf y fitz parece más interesado en obtener una fantástica biblioteca gráfica (Fitz) más que en su interfaz con PDF (MuPDF). Es una gran tarea la suya y pensamos que está haciendo un gran trabajo soportando distintos imaging models en Fitz (como el soporte de Metro).
Sin embargo, no necesitamos escribir absolutamente todo desde cero. Estamos considerando utilizar alguna librería de gráficos capaz de gestionar el Adobe imaging model (Fitz sería una gran opción). La implementación de fuentes Tipo1 y truetype de ghostscript es realmente excelente. Y otras muchas cosas.
Por último, destacar que las cuestiones legales también representan algo a tener en cuenta. Queremos una biblioteca PDF cubierta bajo la licencia GPL versión 3. El código de xpdf (utilizado por poppler) se distribuye bajo GPL versión 2 solamente. Lo mismo aplica al código de ghostscript.
