Mostrar PostScript

Display PostScript (o DPS ) es un sistema de motor gráfico 2D para ordenadores que utiliza el modelo y lenguaje de imágenes PostScript (PS) para generar gráficos en pantalla. PS se desarrolló originalmente para la impresión de ordenadores , al que DPS añade una serie de funciones destinadas a facilitar el trabajo con pantallas de mapa de bits y mejorar el rendimiento de algunas tareas comunes.

Las primeras versiones de los sistemas de visualización PostScript fueron desarrolladas en Adobe Systems . Durante el desarrollo de las computadoras NeXT , NeXT y Adobe colaboraron para producir el sistema DPS oficial, que se lanzó en 1987. NeXT utilizó DPS a lo largo de su historia, mientras que las versiones de Adobe fueron populares en las estaciones de trabajo Unix durante un tiempo en las décadas de 1980 y 1990.

El PostScript original fue escrito para impresión, con el modelo de que solo se podía imprimir un documento a la vez, y que este se dividía en secciones lógicas que se aproximaban a una página. Por esta razón, el modelo subyacente de PS se basaba en una máquina de pila similar al lenguaje de programación Forth , lo que reducía la complejidad del código de la impresora y la cantidad de memoria necesaria para almacenar gráficos individuales. El sistema acumulaba instrucciones hasta que showpagese emitía el comando, momento en el que se ejecutaban todas las instrucciones recibidas desde la última showpageo el inicio de la sesión y se liberaba la memoria utilizada por dichas instrucciones. ^{[ 1 ]}

En contraste, un motor de visualización funciona en un entorno muy diferente. No existe un análogo showpageque permita ejecutar instrucciones en cola; generalmente, se espera que cualquier dibujo se realice de inmediato. Además, mientras que una impresora PS solo podía imprimir un documento a la vez, en una computadora moderna con múltiples ventanas de visualización , todas las ventanas podrían actualizarse simultáneamente con diferentes configuraciones. Esto se solucionó con la introducción de múltiples contextos de ejecución , cada uno de los cuales se aproximaba al modelo visto en una impresora; es decir, cada ventana tenía efectivamente su propio contexto PS y pila de instrucciones, y cada ventana podía producir una salida con diferentes configuraciones, como si la siguiente línea debía ser punteada o continua. El sistema DPS proporcionaba llamadas a la biblioteca para crear los contextos, que podían ser completamente independientes o compartidos. ^{[ 2 ]} Los contextos compartidos eran útiles en los sistemas de ventanas porque permitían que todas las ventanas dentro de una aplicación, o incluso entre varias aplicaciones, compartieran configuraciones y, especialmente, procedimientos predefinidos almacenados en userdicty globaldict. Un uso particularmente importante del contexto compartido globaldictera almacenar fuentes de todo el sistema. ^{[ 3 ]}

El propio sistema de fuentes también tuvo que ser modificado. PS tiene un sistema potente que produce fuentes de alta calidad a partir de descripciones de contorno que incluyen "sugerencias" que mejoran la calidad en tamaños más pequeños. Todo esto depende de que la resolución de salida sea bastante alta, normalmente 300 ppp o más. Para monitores de resolución mucho menor (normalmente 72 ppp en ese momento), los resultados no habrían sido satisfactorios. DPS añadió un sistema para permitir que los mapas de bits dibujados a mano se almacenaran en caché en los diccionarios, lo que se utilizó para proporcionar fuentes que podían ser transferidas directamente a la pantalla. ^{[ 4 ]} Los mapas de bits prerrenderizados cayeron en desuso a medida que el suavizado de bordes , que resuelve muchos de estos problemas, se generalizó. Del mismo modo, DPS añadió soporte para la fase de semitonos para asegurar que los objetos recién dibujados tuvieran el mismo semitono que los objetos anteriores, ^{[ 5 ]} pero esto también ha perdido importancia en los sistemas modernos.  

PS almacenaba objetos y código en los diccionarios mediante identificadores de cadena. Esto hacía que encontrar la definición fuera costoso a medida que aumentaba el tamaño de las colecciones, lo cual era un efecto secundario de muchas de estas nuevas características. DPS solucionó esto añadiendo la capacidad de almacenar objetos en el diccionario usando números enteros en lugar de cadenas. Este concepto de "nombres de sistema codificados" podría mejorar considerablemente el rendimiento de diversas tareas, como encontrar una fuente del sistema o buscar una rutina común como "dibujar la barra de título". Estos nombres codificados se almacenaban por contexto. ^{[ 6 ]}

Otros cambios abordaron la necesidad de interactividad directa. Esto incluyó la capacidad de realizar actualizaciones incrementales para que los comandos de PS que producían resultados pudieran ejecutarse inmediatamente. ^{[ 7 ]} También existían sistemas para realizar detección de colisiones , de modo que se pudiera ver si una ubicación particular impactaba alguno de los objetos dibujados. Esto se utilizaba, por ejemplo, para comprobar qué objetos de la vista se impactaban en la ubicación de un clic del ratón. ^{[ 8 ]}

Finalmente, DPS añadió el concepto de una pswrapfunción en lenguaje C que tomaba comandos de DPS en forma de cadenas y los enviaba al contexto de DPS para su salida. Esto permitía, por ejemplo, escribir una función en lenguaje C que produjera un rectángulo en la pantalla. ^{[ 9 ]}

Sin embargo, DPS no incorporaba un sistema de ventanas. Esta función recaía en la implementación, y DPS estaba diseñado para usarse junto con un motor de ventanas existente. Este solía ser el Sistema de Ventanas X , y en esta forma Display PostScript fue posteriormente adoptado por empresas como IBM y SGI para sus estaciones de trabajo. A menudo, el código necesario para pasar de una ventana X a un contexto DPS era mucho más complejo que el resto de la interfaz DPS. Esto limitó considerablemente la popularidad de DPS cuando existía alguna alternativa disponible.

En septiembre de 1987, NeXT se convirtió en la primera empresa en licenciar Display Postscript. ^{[ 10 ]} Los desarrolladores de NeXT escribieron un motor de ventanas completamente nuevo para aprovechar al máximo el sistema operativo orientado a objetos de NeXT . Se agregaron varios comandos a DPS para crear las ventanas y reaccionar a eventos, similares a NeWS pero más simples . La API única hizo que la programación en niveles superiores fuera mucho más fácil y convirtió a NeXT en uno de los pocos sistemas que usaban DPS extensamente. La biblioteca del sistema de ventanas en espacio de usuario NeXTSTEP usaba PostScript para dibujar elementos como barras de título y barras de desplazamiento. Esto, a su vez, hacía un uso extensivo de pswrap, que a su vez estaban envueltos en objetos y se presentaban al programador en forma de objeto.

A principios de 1988, Digital Equipment Corporation obtuvo la licencia de Display PostScript para DECwindows . Adobe expresó su esperanza de que IBM y Microsoft , para OS/2 Presentation Manager , y Apple Computer también utilizaran la tecnología. ^{[ 10 ]}

En noviembre de 1993, Sun Microsystems lanzó OpenWindows 3.3, que dejó de dar soporte a NeWS y sus extensiones no estándar para PostScript, sustituyéndolas por DPS.

Tras adquirir NeXT, el sistema operativo Mac OS X de Apple utiliza un servidor de ventanas central (creado íntegramente por Apple) que almacena en caché los gráficos de las ventanas como mapas de bits, en lugar de almacenar y ejecutar código PostScript. Una biblioteca gráfica llamada Quartz 2D proporciona imágenes al estilo PostScript mediante el modelo de renderizado PDF (un subconjunto, con algunas modificaciones, del modelo PostScript), pero este es utilizado por los marcos de las aplicaciones; no hay PostScript presente en el servidor de ventanas de Mac OS X. Apple optó por este modelo por diversas razones, entre ellas, evitar las tarifas de licencia de DPS y ofrecer una compatibilidad más eficiente con el código heredado de Carbon y Classic ; las aplicaciones basadas en QuickDraw utilizan exclusivamente el dibujo mediante mapas de bits.

• NeWS , un sistema de ventanas similar que utilizaba el modelo gráfico PostScript, pero con extensiones para concurrencia, eventos y programación orientada a objetos.
• Codificación estándar PostScript (conjunto de caracteres PostScript)
• Conjunto de caracteres NeXT

• Adobe Systems Incorporated (1990) [1985]. Manual de referencia del lenguaje PostScript (2.ª  ed.). Addison-Wesley Publishing Company .(Nota: Esta edición también incluye una descripción de Display PostScript, que ya no se trata en la tercera edición).

• Descripción en la Wiki de C2
• GNU/BackBone
• La especificación PDF más reciente, versión 1.7
• Referencia del lenguaje PostScript, segunda edición
• Mostrar documentos de referencia de PostScript
• Comparación entre Display PostScript y NeWS