QuickDraw GX

A medida que avanzaban los años 80, las limitaciones arquitectónicas de QuickDraw comenzaron a imponer restricciones a Apple y a los desarrolladores externos. ^{[ 3 ]}

• Todas las estructuras de datos públicas de QuickDraw asumen un espacio de coordenadas enteras de 16 bits, sin ninguna provisión para coordenadas fraccionarias. ^{[ 4 ]}
• Agregar nuevas funciones a QuickDraw era extremadamente difícil debido a la falta de ocultación de datos en la API. La estructura de datos central en QuickDraw era GrafPort, una estructura con todas las variables miembro expuestas. Peor aún, la estructura GrafPort estaba diseñada para integrarse directamente en estructuras de datos de desarrolladores externos, por lo que Apple no podía agregar nuevas variables. Color QuickDraw, introducido en 1987, fue una chapuza tremenda sobre el QuickDraw original en blanco y negro. Esto aumentó la complejidad del desarrollo de aplicaciones en color para Mac. ^{[ 4 ]} Por ejemplo, QuickDraw no podía admitir fácilmente transformaciones gráficas avanzadas como rotaciones y deformaciones, e introducir nuevos tipos de datos como curvas era imposible. ^{[ 5 ]}

GX parece haber comenzado de forma indirecta, originalmente como un sistema de fuentes de contorno que se añadiría a Mac OS. El motor de renderizado de fuentes incluía varias extensiones de utilidad general, en particular un sistema de coordenadas de punto fijo y diversos comandos para dibujar curvas. El sistema también incluía un mecanismo para "envolver" las fuentes PostScript Type 1 existentes en su propio formato interno, lo que añadía versiones de vista previa en mapa de bits para una rápida visualización en pantalla. Este proyecto adquirió posteriormente un papel más importante cuando Apple y Microsoft acordaron colaborar para crear una alternativa a las fuentes PostScript, que eran extremadamente caras, dando origen al proyecto TrueType, basado en los esfuerzos previos de Apple.

Another project, apparently unrelated at first, attempted to address problems with the conversion from QuickDraw into various printer output formats. Whereas developers had earlier been forced to write their own code to convert their QuickDraw on-screen display to PostScript for printing, under the new printer architecture such conversions would be provided by the OS. Additionally the new system was deliberately engineered to be as flexible as possible, supporting not only QD and PS printers, but potentially other standards such as Hewlett-Packard's PCL as well. The system also supported "desktop printers" (printers that appeared as icons on the user's desktop), a long sought-after feature missing from QD, and added improved printing dialogs and controls.

It is not clear when the projects merged, but this was a common theme in Apple at the time. Middle-managers were involved in an intense turf war for much of the late 1980s and early 1990s, gathering projects together into "über-projects" that contained enough important code to make them "unkillable". Sadly, this often delayed the projects dramatically; one component running behind schedule forced the entire collection to be delayed so they could be released "complete". QuickDraw GX was one such victim, and delays and changes of direction in TrueType and other problems greatly delayed the introduction of GX.

Discussions of GX technology started appearing in various trade magazines around 1992, notably Apple's own develop. At the time it appeared release was imminent, perhaps late 1992 or early 1993.

GX was initially released in about January 1994, as a separate package. Version 1.1.1 was bundled with System 7.5 later that year and it was not successful. The package was large enough to strain the memory of most existing Macintosh computers of the era, and arguments like "you can now print to PostScript" were less than impressive considering many existing programs had already added such support. Users and developers generally ignored GX, and a market for the system simply never appeared.

Existe una razón desconocida para el fracaso de GX en el mercado. Para empezar, GX era muy grande, requiriendo por sí solo tanta memoria como el resto del sistema operativo. ^{[ 6 ]} La velocidad también fue un problema, limitando su ejecución únicamente a Macs con un Motorola 68020 o superior. Dado que la base instalada de Macs en ese momento todavía incluía un gran número de máquinas con procesadores 68000 como el Mac Plus , estos requisitos restringieron la cantidad de máquinas en las que podía ejecutarse. Cuando se lanzó por primera vez, una reseña señaló: "QuickDraw GX no es para todos y requiere más RAM de la que muchas Macs tienen disponible". ^{[ 7 ]}

Además, la API del sistema era muy extensa, ocupando varios libros. Implementar un programa GX no era tarea fácil, a pesar de que se suponía que el desarrollo sería más sencillo. Esto no era un problema de la arquitectura GX en sí, sino un efecto secundario de la naturaleza "integral" del sistema, un problema que afectaba a la mayoría de los productos de Apple de la época (véase PowerTalk, por ejemplo). Como resultado, su atractivo para los desarrolladores era limitado; se requería un gran esfuerzo para usar el sistema en los programas, y la aplicación resultante solo podía ejecutarse en un subconjunto de la base instalada. El número de programas basados ​​en GX (en contraposición a los compatibles con GX) era inferior a seis, entre ellos Typestry de Pixar ^{[ 8 ]} y UniQorn de Softpress ^{[ 9 ]} .

Además, el cambio en los sistemas de impresión planteó serios problemas en la práctica. Si bien la impresión PostScript nunca había sido sencilla, a lo largo de los años, desde el lanzamiento de la LaserWriter original , los desarrolladores habían acumulado una biblioteca de soluciones para problemas comunes. Con el cambio de arquitectura a GX, la mayoría de estas soluciones dejaron de funcionar. También se necesitaban nuevos controladores GX para las impresoras, y Apple no proporcionaba controladores para todas sus impresoras , y mucho menos para las de terceros. Los problemas de impresión eran generalizados y tan difíciles de solucionar que los usuarios a menudo abandonaban el sistema por frustración.

La adopción de GX por parte de los usuarios fue prácticamente nula, al igual que sucedió con la mayoría de las nuevas tecnologías que Apple lanzó a principios de la década de 1990. Podría haber tenido una mayor difusión como parte del proyecto Copland , pero este nunca se lanzó. Si bien Apple continuó afirmando que GX era el futuro de los gráficos en la Mac, para 1995 era evidente que ya no lo estaban promocionando, lo que frustró a sus seguidores.

Mac OS 8 dejó de ser compatible con la arquitectura de impresión GX, aunque las arquitecturas de gestión de texto y color se mantuvieron. Algunos elementos de la arquitectura de gestión de texto pasaron a formar parte de la especificación TrueType, mientras que otros, de la arquitectura de gestión de color, se integraron en la especificación del Consorcio Internacional del Color . Con la llegada de Mac OS X, algunas partes de GX siguen presentes en Apple Type Services for Unicode Imaging (ATSUI) y en ColorSync , cuyo formato de archivo es idéntico al formato original desarrollado para GX.

QuickDraw GX se basa en un modelo orientado a objetos en el que los objetos gráficos conocen y gestionan su propio estado. A diferencia de QuickDraw, no existe un "estado" universal; cada comando de dibujo puede reconstruir el estado a partir de los datos almacenados en él o en varios objetos "padre". Por ejemplo, un programador podría crear un redBoxobjeto que primero establezca el color en rojo y luego dibuje un cuadrado. A partir de ese momento, el programa ya no necesita establecer explícitamente el color antes de dibujar; el propio sistema GX siempre establecerá correctamente el color de dibujo cuando se le solicite dibujar un cuadrado redBoxy lo restablecerá al finalizar. Dado que este estado era privado y se enviaba a GX cuando era necesario, GX, en teoría, permitía que Mac OS admitiera memoria protegida, ya que el estado ya no se compartía directamente entre los programas y el sistema gráfico.

Esto contrasta notablemente con el QuickDraw original, donde el programador era responsable de todos los cambios de estado. Por ejemplo, si se dibujaba un cuadro rojo y luego una serie de líneas, estas también aparecerían en rojo a menos que el programador cambiara explícitamente el color previamente. La ventaja de este enfoque es que minimiza la cantidad de comandos necesarios para establecer el estado; el programador puede organizar el dibujo para dibujar grupos de objetos de estilo similar al mismo tiempo y, por lo tanto, ahorrar tiempo. La desventaja es que es fácil "olvidar" cambiar el estado y terminar causando problemas, tan fácil que los programadores a menudo guardaban y restauraban el estado completo antes de cada comando de dibujo, lo que potencialmente reducía el rendimiento.

El estado de dibujo en GX era jerárquico. Se creaba un modo de dibujo predeterminado para cada ventana, al igual que en QD, y los objetos de dibujo sin otros cambios de estado utilizaban estos valores predeterminados. El programador podía entonces cambiar el estado de los propios objetos, como en nuestro redBoxejemplo, o bien cambiar el estado de todo el dibujo estableciendo el estado en el objeto de ventana. Los objetos de GX se podían agrupar fácilmente, lo que permitía establecer el estado para un objeto complejo completo.

Una parte del estado general del dibujo era la matrizgxMapping de 3x3, que podía expresar transformaciones lineales arbitrarias en dos dimensiones, incluyendo distorsiones de perspectiva . Todos los objetos GX tenían una asignación asociada como parte de su estado de dibujo, lo que permitía rotaciones y traslaciones. Si bien todo este estado se almacenaba en la matriz de ese objeto, GX también proporcionaba comandos auxiliares como "rotar" para simplificar el uso de la API .gxMapping

A diferencia de QuickDraw, QuickDraw GX permitía el uso de coordenadas fraccionarias. Sin embargo, se trataba de valores de punto fijo , no de punto flotante . En la época en que se desarrollaba GX (finales de la década de 1980 y principios de la de 1990), el uso de aritmética de punto flotante aún suponía una importante penalización en el rendimiento.

La arquitectura gráfica GX se construyó en torno a varios tipos de objetos prefabricados, aunque se disponía de un conjunto completo de llamadas a la API para examinarlos y manipularlos:

• Un gxShape define la geometría básica de una forma (por ejemplo, las coordenadas de los puntos de control de una curva o el contenido de texto de un objeto de texto).
• gxStyle define elaboraciones de la geometría básica de la forma, como el grosor de la línea, los estilos de remate y unión, el patrón de relleno y la fuente del texto.
• gxInk especificaba cómo se debían calcular los valores de los píxeles al renderizar la forma: además de especificar un color básico para la forma, también incluía una elaborada estructura de modo de transferencia que podía definir una amplia variedad de funciones del valor del píxel de destino inicial y final.
• gxFont representaba una fuente, ya fuera una instalada para su uso en todo el sistema o una instalada sobre la marcha por la aplicación actual para su propio uso. Las llamadas a la API permitían consultar las propiedades de una fuente, incluida la determinación de las codificaciones (Unicode, específicas del idioma, etc.) que podía admitir.
• Un gxProfile era una representación de un perfil de color ColorSync, utilizado como parte de la especificación de un color para el dibujo. GX integraba compatibilidad total con la coincidencia de colores en todas las etapas del proceso de dibujo, así como compatibilidad con especificaciones de color distintas de RGB (como HSV , YUV y CIE XYZ).
• Un objeto gxTransform determinaba la relación entre la forma y el dispositivo de visualización. Además de la ruta de recorte y el mapeo gxMapping que transformaban la forma antes de mostrarla en el dispositivo de salida, este objeto también especificaba información de detección de clics que controlaba las respuestas a los clics del usuario dentro del área de la forma.
• Un gxViewDevice representaba un bloque de memoria de píxeles en el que se renderizaba el dibujo. Podía ser una pantalla real o un bloque de memoria fuera de pantalla. GX admitía todos los diseños de píxeles de QuickDraw ; esto permitía que tanto un dispositivo de vista GX como un GrafPort de QuickDraw apuntaran a los mismos píxeles, lo que permitía a las aplicaciones combinar ambos conjuntos de llamadas de dibujo.
• Un gxViewPort era un destino lógico para el dibujo. Un gxTransform podía especificar una lista de varios de estos; la forma se dibujaría en todos ellos en una sola GXDrawShapellamada.
• Un gxViewGroup representaba la conexión entre dispositivos de visualización y puertos de visualización. Cada puerto de visualización tenía un gxMapping que especificaba su relación con el sistema de coordenadas global del grupo de visualización; y cada dispositivo de visualización tenía un gxMapping que especificaba su ubicación y el tamaño de sus píxeles con respecto a las coordenadas del grupo de visualización. Existía un único grupo de visualización predefinido que contenía todos los dispositivos de visualización en pantalla (y cuyos puertos de visualización correspondían efectivamente a las ventanas en pantalla); las aplicaciones podían crear sus propios grupos de visualización para dispositivos y puertos de visualización fuera de pantalla.
• Una etiqueta gxTag permitía adjuntar información arbitraria definida por la aplicación a la mayoría de los tipos de objetos mencionados anteriormente. Cada etiqueta tenía un código de tipo OSType , pero se podían adjuntar varias etiquetas del mismo tipo al mismo objeto.

Las características tipográficas de GX se integraron en forma de 3 tipos de gxShape:

• Las formas de texto eran las más sencillas: contenían una única secuencia de texto representada con un solo estilo de fuente.
• Las formas de glifos eran una forma de utilizar las formas de los caracteres (" glifos ") como geometría pura, por ejemplo, como trazados de recorte .
• Las formas de diseño eran las más elaboradas. Podían dividirse en múltiples secuencias con diferentes estilos de fuente, incluso con distintas codificaciones de idioma y direcciones de texto. Así, era posible insertar una secuencia de texto árabe, de derecha a izquierda, dentro de una secuencia externa de texto romano de izquierda a derecha. Las formas de diseño desataban todo el potencial de las sustituciones contextuales, el espaciado entre caracteres, las variaciones y todas las demás capacidades de las fuentes TrueType GX. Su principal limitación era que se limitaban a una sola línea de texto.

La API de GX también proporcionaba funciones de detección de clics, de modo que, por ejemplo, si el usuario hacía clic en una forma de diseño en medio de una ligadura o en la región entre un cambio de dirección del texto, GX mismo proporcionaba la inteligencia necesaria para determinar qué posición de carácter en el texto original correspondía al clic.

En GX se estableció una distinción importante entre carácter y glifo , distinción que también se encuentra en el estándar Unicode. Un carácter era un símbolo abstracto del conjunto de caracteres de un sistema de escritura, como la letra "f" en los sistemas de escritura del alfabeto latino. En cambio, un glifo era una forma gráfica específica de una fuente particular, ya sea que representara un solo carácter o un conjunto de caracteres. Así, por ejemplo, la fuente Hoefler Text tenía glifos para representar las letras "f" y "l". También tenía otro glifo para representar la ligadura "fl" , que podía componerse automáticamente (en lugar de los glifos individuales) dondequiera que los dos caracteres abstractos "f" y "l" aparecieran en secuencia en el texto fuente.

Esta distinción era importante porque tales sustituciones contextuales ocurrían en el momento de la representación, sin ningún cambio en la cadena de caracteres de origen. Por lo tanto, no tenían ningún impacto en la edición o búsqueda del texto. Los archivos de fuente PostScript Tipo 1 tienen una correspondencia uno a uno, y como las ligaduras son correspondencias de muchos a uno, no se pueden insertar en la composición sin cambiar la cadena de caracteres de origen; por ejemplo, la ligadura ffi se coloca en la posición de la Y mayúscula en los productos de fuente de Adobe, y "Adobe Offices" se compone escribiendo "Adobe O" <cambiar fuente> "Y" <cambiar fuente> "ces". En el diseño, la cadena de caracteres se rompe, y en el PDF creado a partir de PostScript en flujo, los caracteres f+f+i solo se pueden reconstruir si el nombre del glifo sigue una lista de nombres de glifos.

Las sustituciones contextuales se pueden controlar habilitando o deshabilitando las opciones de composición de una fuente TrueType GX en WorldText del CD de Mac OS 9 o en TextEdit de Mac OS X. Las fuentes suelen tener características llamadas "ligaduras comunes" (como el ejemplo "fl"), "ligaduras raras" (como las ligaduras ME y MD de las inscripciones), "s arcaicas no terminales" (para sustituir automáticamente la letra "s" por la forma arcaica que se parecía más a una "f", excepto al final de las palabras) e incluso opciones entre conjuntos de diseños de glifos completamente separados, como formas más y menos ornamentadas.

Las reglas para realizar sustituciones contextuales se implementan como máquinas de estados integradas en la fuente y son interpretadas por el Administrador de Diseño de Líneas LLM, el equivalente al Módulo de Gestión de Color CMM para los servicios ColorSync. La gestión de texto en el sistema operativo permitió a QuickDraw GX aceptar cadenas de caracteres con cualquier combinación de sistemas de escritura y alfabetos, y componer las cadenas automáticamente, ya sea que la codificación fuera Unicode 1.0 o codificaciones de 8  y 8/16  bits.

Otra característica interesante eran las "variaciones" de fuente, que eran el equivalente en GX a las fuentes " múltiples maestras " de Adobe. Mientras que las fuentes de Adobe requerían que el usuario creara explícitamente una "instancia" de la fuente especificando valores para los ejes de variación antes de poder usarla, GX permitía al usuario especificar la fuente directamente para un estilo de diseño y luego variar dinámicamente los valores de los ejes y observar inmediatamente el efecto en el diseño del texto.

Esta tecnología se convirtió en la base de lo que Microsoft y Adobe adoptarían en 2016, con el desarrollo de las fuentes variables OpenType .

Dave G. Opstad fue el arquitecto del motor tipográfico y las tablas de forma de las fuentes de Apple. Posteriormente, se convirtió en líder técnico en Monotype Imaging. Otros que trabajaron en TrueType GX incluyen:

• Eric Mader
• Sampo Kaasila
• Mike Reed
• Arlo