Display PostScript (o DPS) es un sistema de representación en pantalla. Como el nombre sugiere, DPS emplea el lenguaje PostScript (PS) para generar gráficos en pantalla.

NeXT Computer Inc. diseñó DPS como sistema de representación para su empleo en las computadoras personales basadas en Unix en 1987. Mientras que las versiones anteriores de PostScript habían sido desarrolladas por Adobe, la implementación de Display PostScript fue desarrollada por NeXT en cooperación con Adobe Systems, e hicieron un producto oficial Adobe con sus propios estándares, documentos y requisitos de licencias.

Contenido 1 Modificaciones 2 Uso en la industria 3 Véase también 4 Enlaces externoss 5 Referencias

Modificaciones

Para conseguir el uso interactivo en pantalla con un rendimiento razonable tuvieron que realizar algunos cambios:

• Contextos de ejecución múltiple: A diferencia de los entornos de impresión donde los intérpretes PostScript procesan una tarea cada vez, DPS podría emplearse en varias ventanas a la vez, cada una con sus propia configuración (color, brochas, escala, etc.). Esto requería una modificación del sistema para permitir el almacenamiento de muchos “contextos” (conjuntos de datos de estado) activos, uno para cada proceso o ventana.

• Nombres codificados: Muchos de los procesos y estructuras de datos de PostScript se obtenían al buscar por su nombre. En DPS estos nombres podían reemplazarse por números pequeños, mucho más fáciles de encontrar por una computadora.

• Apoyo a la interacción: Se difinieron varios procedimientos para manejar la interacción, incluyendo la detección de hits.

• Fase de semitono: Para mejorar el rendimiento al desplazar el texto, DPS sólo dibujaba la pequeña porción de la ventana que se volvía visible, desplazando el resto de la imagen en lugar de recalcularla. Sin embargo, esto significaba que los semitonos no se alineaban, produciendo líneas y rectángulos visibles en la representación. DPS incluía código adicional para solucionar estos casos. Los sistemas de representación modernos a color sin semitonos han hecho que esta idea quede obsoleta.

• Actualizaciones incrementales: En las aplicaciones con capacidad de impresión el código PostScript se interpreta hasta que se obtiene una showpage, punto en el que se imprime realmente. Esto no es apropiado para situaciones donde se necesita mostrar un gran número de actualizaciones menores. DPS incluía modos para permitir representaciones casi en tiempo real a medida que las instrucciones de los programas de usuario se recibían.

• Soporte de tipos Bitmap: DPS añadió la capacidad de mapear fuentes PostScript en tipos de mapa de bits dibujados a mano y cambiar de unos a otros rápidamente. Mientras que la capacidad de PostScript de representar tipos en dispositivos de “baja resolución” era buenta, “baja resolución” significaba representacionoes del orden de los 300dpi, no los 96dpi que empleaba la pantalla del NeXT. Esto hacía más conveniente el uso de fuentes de mapa de bits para obtener un rendimiento razonable.

• Soporte a programadores: DPS introdujo el concepto de “pswrap”, que permitía a los desarrolladores encapsular código PostScript en una función en lenguaje C que podía llamarse desde una aplicación.

Uso en la industria

Sin embargo, DPS no definía un sistema de ventanas. Se dejaba a la implementación que proporcionase uno, que DPS usaría. Normalmente fue el X Window System hasta que más tarde Display PostScript fue adoptado por compañías como IBM y Silicon Graphics para sus estaciones de trabajo. A menudo el código necesitado para obtener un contexto DPS a partir de una ventana de X era mucho más complicado que el resto de la interfaz DPS. Esto limitó gravemente la popularidad de DPS en cuanto apareció una alternativa.

Los desarrolladores de NeXT escribieron un motor de ventanas completamente nuevo para sacar todo el partido posible al sistema operativo totalmente orientado a objetos de que disponían. Su API facilitaba mucho la programación de alto nivel, lo que provocó que NeXT fuera uno de los pocos sistemas que usaba intensamente DPS. La biblioteca de sistema de ventanas NeXTSTep usaba PostScript para dibujar elementos como barras de títulos y deslizadores. Esto, al final, hacía un uso intenso de pswraps, que a su vez estaban encapsulados en objetos que se presentaban al programador.

El Mac OS X de Apple actualmente emplea un modelo de representación similar a Display PostScript, pero no tiene el mismo nivel de programabilidad. El nuevo sistema, conocido como Quartz está basado en el modelo de PDF, en el que el código fuente de la imagen no es el propio código PostScript, sino el resultado de su interpretación. Sigue teniendo las mismas primitivas básicas, el manejo de tipos y medidas, y en muchos casos parece DPS. El formato PDF también tiene varias mejoras sobre PostScript, incluyendo el manejo del color mejorado, compresión y manejo de tipos. No está totalmente claro por qué se dio este cambio, se dice que Adobe pedía grandes sumas por su licencia. Las estipulaciones del copyright de Adobe respecto a su estándar PDF son mucho menos restrictivas, lo que garantiza permisos condicionales de uso a cualquiera que emplea el formato en aplicaciones software sin tener que desembolsar nada.

Véase también

• QuickDraw

Enlaces externoss

En inglés

• Descripción en la Wiki C2
• GNU/BackBone

Referencias

• La especificación más reciente de PDF, versión 1.6
• PostScript Language Reference, Segunda Edición, que incluye información sobre DPS.
• Documentos de referencia de Display PostScript