QuickDraw GX fue un reemplazo para el motor de gráficos 2D QuickDraw (QD) y el Administrador de impresión dentro del sistema operativo Mac OS clásico . [1] Su plataforma de dibujo subyacente era un sistema de modo retenido , independiente de la resolución y orientado a objetos , lo que hacía mucho más fácil para los programadores realizar tareas comunes (en comparación con el QuickDraw original). Además, GX agregó varios comandos de dibujo de curvas que faltaban en QD, además de introducir TrueType como su sistema de fuentes básico. [2]
Si bien GX solucionó muchos de los problemas que tenía QD, cuando estuvo disponible, la mayoría de los desarrolladores ya habían desarrollado sus propias soluciones a estos problemas. GX también sufrió por causar una serie de incompatibilidades en los programas existentes, en particular aquellos que habían desarrollado sus propias extensiones QD. Esto, junto con la oposición de una fracción importante del mercado de desarrolladores, especialmente el propietario de PostScript , Adobe, y la falta de comunicación por parte de Apple sobre los beneficios de GX y por qué los usuarios deberían adoptarlo, llevó a que la tecnología quedara relegada.
QuickDraw GX tuvo poco desarrollo después de su lanzamiento inicial y fue "eliminado" formalmente con la compra de NeXT y la eventual adopción del modelo de imágenes Quartz en Mac OS X. Muchas de las características de sus componentes sobrevivieron y ahora son estándar en la plataforma Macintosh actual; TrueType GX en particular se ha convertido en un estándar moderno ampliamente utilizado en forma de fuentes variables OpenType .
A medida que avanzaba la década de 1980, las limitaciones arquitectónicas de QuickDraw comenzaron a imponer límites a Apple y a los desarrolladores externos. [3]
Parece que GX comenzó de forma indirecta, originalmente como un sistema de fuentes de contorno que se añadiría al sistema operativo Mac. El motor de renderizado de fuentes incluía una serie de extensiones útiles en general, en particular un sistema de coordenadas de punto fijo y una variedad de comandos de dibujo de curvas. El sistema también incluía un sistema para "envolver" las fuentes PostScript Type 1 existentes en su propio formato interno, que añadía versiones de vista previa de mapa de bits para una rápida renderización en pantalla. Este proyecto adquirió más adelante un papel más amplio cuando Apple y Microsoft acordaron trabajar juntos para formar una alternativa a las fuentes PostScript, que eran extremadamente caras, creando el proyecto TrueType basado en los proyectos existentes de Apple.
Otro proyecto, aparentemente no relacionado al principio, intentó solucionar los problemas con la conversión de QuickDraw a varios formatos de salida de impresora. Mientras que antes los desarrolladores se habían visto obligados a escribir su propio código para convertir la presentación en pantalla de QuickDraw a PostScript para imprimir, bajo la nueva arquitectura de impresoras dichas conversiones serían proporcionadas por el sistema operativo. Además, el nuevo sistema fue diseñado deliberadamente para ser lo más flexible posible, admitiendo no sólo impresoras QD y PS, sino también potencialmente otros estándares como PCL de Hewlett-Packard . El sistema también admitía "impresoras de escritorio" (impresoras que aparecían como iconos en el escritorio del usuario), una característica muy buscada que faltaba en QD, y agregó cuadros de diálogo y controles de impresión mejorados.
No está claro cuándo se fusionaron los proyectos, pero este era un tema común en Apple en ese momento. Los gerentes intermedios estuvieron involucrados en una intensa guerra territorial durante gran parte de finales de los años 1980 y principios de los años 1990, reuniendo proyectos en "superproyectos" que contenían suficiente código importante para hacerlos "imposibles de eliminar". Lamentablemente, esto a menudo retrasaba drásticamente los proyectos; un componente que funcionaba con retraso obligó a retrasar toda la colección para que pudieran lanzarse "completos". QuickDraw GX fue una de esas víctimas, y los retrasos y cambios de dirección en TrueType y otros problemas retrasaron enormemente la introducción de GX.
En 1992, comenzaron a aparecer debates sobre la tecnología GX en varias revistas especializadas, en particular en la propia Apple . En ese momento, parecía que el lanzamiento era inminente, tal vez a fines de 1992 o principios de 1993.
GX se lanzó inicialmente en enero de 1994, aproximadamente, como un paquete independiente. La versión 1.1.1 se incluyó con System 7.5 más tarde ese año y no tuvo éxito. El paquete era lo suficientemente grande como para agotar la memoria de la mayoría de las computadoras Macintosh existentes de la época, y argumentos como "ahora puede imprimir en PostScript" no eran muy impresionantes considerando que muchos programas existentes ya habían agregado ese soporte. Los usuarios y desarrolladores generalmente ignoraron GX, y simplemente nunca apareció un mercado para el sistema.
Existe una razón desconocida para el fracaso de GX en el mercado. Por un lado, GX era muy grande y requería tanta memoria como el resto del sistema operativo. [6] La velocidad también era un problema, ya que lo limitaba a funcionar solo en Mac con un Motorola 68020 o superior. Dado que la base de Mac instalada en ese momento todavía contenía una gran cantidad de máquinas basadas en 68000 como Mac Plus , estos requisitos restringían la cantidad de máquinas en las que podía ejecutarse. Cuando se lanzó por primera vez, una revisión señaló: "QuickDraw GX no es para todos y requiere más RAM de la que muchos Mac tienen de sobra". [7] [ enlace muerto ]
Además, la API del sistema era muy grande y llenaba varios libros. Implementar un programa GX no era una tarea fácil, aunque se suponía que el desarrollo sería más fácil. Esto no era un problema de la arquitectura GX en sí, sino un efecto secundario de la naturaleza "todo incluido" del sistema, un problema que adolecía la mayoría de los productos Apple de la época (véase PowerTalk , por ejemplo). Como resultado, el atractivo para los desarrolladores era limitado; se requeriría mucho esfuerzo para usar el sistema en programas, y la aplicación resultante solo podría ejecutarse en un subconjunto de la base instalada. El número de programas basados en GX (a diferencia de los compatibles con GX ) era inferior a seis, incluidos Typestry de Pixar [8] y UniQorn de Softpress [9] .
Además, el cambio en los sistemas de impresión planteó serios problemas en el mundo real. Si bien la impresión PostScript nunca había sido fácil, a lo largo de los años desde el lanzamiento del LaserWriter original , los desarrolladores habían creado una biblioteca de soluciones a problemas comunes. Con el cambio en la arquitectura de GX, la mayoría de estas dejaron de funcionar. También se necesitaban nuevos "controladores GX" para las impresoras, y Apple no proporcionaba controladores para todas sus propias impresoras, y mucho menos para las de terceros. Los problemas de impresión eran endémicos y tan difíciles de solucionar que los usuarios a menudo abandonaban el sistema por frustración.
La aceptación de GX por parte de los usuarios fue casi nula, como sucedió con la mayoría de las nuevas tecnologías que Apple lanzó a principios de los años 90. Es posible que se haya utilizado ampliamente como parte del proyecto Copland , pero Copland nunca se lanzó. Aunque Apple siguió afirmando que GX era el futuro de los gráficos en Mac, en 1995 quedó claro que ya no lo "promovían", lo que frustró a sus partidarios.
Mac OS 8 dejó de ofrecer compatibilidad con la arquitectura de impresión GX, aunque las arquitecturas de gestión de texto y de gestión de color sobrevivieron. Algunos elementos de la arquitectura de gestión de texto pasaron a formar parte de la especificación TrueType y algunos elementos de la arquitectura de gestión de color pasaron a formar parte de la especificación del International Color Consortium . Con la llegada de Mac OS X, partes de GX siguen vivas 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 son responsables de 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 de varios objetos "principales". 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 tiene que establecer explícitamente el color antes de dibujar; el propio sistema GX siempre establecerá correctamente el color de dibujo cuando se le solicite que dibuje un cuadrado redBoxy lo restablecerá cuando termine. Dado que este estado era privado y se enviaba a GX cuando era necesario, GX teóricamente 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 fuertemente con el QuickDraw original, donde el programador era responsable de todos los cambios de estado. Por ejemplo, si uno dibujara un cuadro rojo y luego una serie de líneas, las líneas también aparecerían en rojo a menos que el programador cambiara explícitamente el color primero. 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 de este enfoque es que es fácil "olvidarse" de 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 con cada ventana, como 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 todos los dibujos estableciendo el estado en el objeto de ventana. Los objetos GX se podían agrupar fácilmente en grupos, que eran en sí mismos objetos, lo que permitía establecer el estado de un objeto complejo completo.
Una parte del estado general del dibujo era el . Se trataba de una matrizgxMapping de 3 por 3 que podía expresar transformaciones lineales arbitrarias en dos dimensiones, incluidas distorsiones de perspectiva . Todos los objetos GX tenían una asignación asociada como parte de su estado de dibujo, que permitía cosas como rotaciones y traslaciones. Aunque todo este estado se guardaba en el para ese objeto, GX también proporcionaba comandos "envoltorios" como "rotar" para que la API fuera más sencilla de usar.gxMapping
A diferencia de QuickDraw, QuickDraw GX permitía el uso de coordenadas fraccionarias. Sin embargo, se trataba de valores de punto fijo , en lugar de de punto flotante . En el momento en que se estaba desarrollando GX (finales de los años 1980 y principios de los años 1990), el uso de aritmética de punto flotante aún suponía una pérdida de rendimiento significativa.
La arquitectura gráfica de GX se construyó en torno a una serie de tipos de objetos que estaban prefabricados, aunque había disponible un conjunto completo de llamadas API para examinarlos y manipularlos:
GXDrawShapellamada.Las formas GX pueden ser de varios tipos:
Las características tipográficas de GX se integraron en forma de 3 tipos de gxShape:
La API de GX también proporciona funciones de prueba de impacto, de modo que, por ejemplo, si el usuario hacía clic en una forma de diseño en el medio de una ligadura , o en la región entre un cambio de dirección del texto, GX mismo proporcionaría la inteligencia 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 un carácter y un 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 de la escritura latina. Mientras que un glifo era una forma gráfica específica de una fuente en particular, ya sea que la forma 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 dichas sustituciones contextuales se producí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 la búsqueda del texto. Los archivos de fuentes PostScript Tipo 1 tienen una asignación de uno a uno solamente, y como las ligaduras son asignaciones 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 fuentes de Adobe, y "Adobe Offices" se compone escribiendo "Adobe O" <cambiar fuente> "Y" <cambiar fuente> "ces". En el diseño, la cadena de caracteres está rota, y en PDF creado a partir de PostScript transmitido en tiempo real, 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 en el CD de Mac OS 9 o en TextEdit en Mac OS X. Las fuentes comúnmente tienen características llamadas "ligaduras comunes" (como el ejemplo "fl"), "ligaduras raras" (como las ligaduras inscripcionales ME y MD), "s no terminal arcaica" (para sustituir automáticamente la letra "s" con la forma arcaica que se parecía más a una "f", excepto al final de las palabras), e incluso opciones entre conjuntos completamente separados de diseños de glifos, 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ínea LLM, la contraparte del módulo de administración de color CMM para los servicios ColorSync. La administración de texto en el sistema operativo permitió que QuickDraw GX aceptara cadenas de caracteres con cualquier combinación de sistemas de escritura y scripts, y compusiera las cadenas automáticamente, ya sea que la codificación fuera Unicode 1.0 o de 8 bits y 8/16 bits.
Otra característica interesante eran las "variaciones" de fuentes, que eran el equivalente en GX de 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 el núcleo de lo que Microsoft y Adobe adoptarían en 2016, con su desarrollo de OpenType Variable Fonts .
Cary Clark fue el arquitecto y el líder técnico de QuickDraw GX. Había trabajado en Color QuickDraw y luego se convirtió en uno de los primeros miembros de Rocket Science Games y WebTV. Keith McGreggor fue el gerente del grupo de gráficos y el desarrollador principal de la arquitectura de color para QuickDraw GX, y Robert Johnson fue el matemático residente. [ se necesita más explicación ]
Otros desarrolladores del proyecto incluyen:
Dave G. Opstad fue el arquitecto del motor tipográfico y de las tablas de formas de las fuentes de Apple. Luego se convirtió en el director técnico de Monotype Imaging. Otros que trabajaron en TrueType GX son: