OpenType

OpenType
Desarrollador
Microsoft y Adobe Systems
Información general
Extensión de archivo	.otc, .otf, .ttc, .ttf
Tipo de MIME	application/font-sfnt y font/otf
Type code	OTTO
Uniform Type Identifier	public.opentype-font
Número mágico	4F54544F00
Lanzamiento inicial	1996
Última versión	OpenType 1.6
Tipo de formato	Formato tipográfico
Extendido de	TrueType, PostScript
Estándar(es)	ISO/IEC 14496-22:2015​
Formato abierto	?

OpenType es un formato de Tipos de letra escalables para computadora. Su arquitectura está basada en la de su antecesor, el formato TrueType, cuya estructura básica conserva y la cual complementa con tablas de datos que permiten incorporar a un tipo o familia tipográfica funciones tipográficas y lingüísticas avanzadas.

La especificación técnica se originó en Microsoft, y posteriormente fue desarrollada en colaboración con Adobe Systems, junto con quien Microsoft presentó públicamente el formato en 1996. La especificación continúa en desarrollo y en la actualidad se encuentra en proceso de convertirse en un estándar abierto.

Debido a su amplia disponibilidad en el mercado y a su versatilidad tipográfica —lo que incluye recursos para representar el comportamiento gráfico de muchos sistemas de escritura del mundo—, los tipos de letra en formato OpenType son muy utilizadas actualmente en las principales plataformas de cómputo.

Historia

OpenType fue expresamente diseñado por Microsoft y Adobe para suceder a los tradicionales formatos tipográficos TrueType y Tipo 1 (o “PostScript”), el primero de ellos desarrollado por Apple Computer y licenciado a Microsoft, y el segundo creado por Adobe, también autor del lenguaje PostScript. La necesidad de contar con un formato a la altura de las demandas de la tipografía de alta calidad y que fuera capaz de modelar el comportamiento complejo de muchos sistemas de escritura llevó a las dos compañías a combinar las tecnologías subyacentes en sus respectivos formatos originales y a incluir extensiones dirigidas a subsanar las limitaciones de ambos.

Los orígenes de OpenType se remontan al inicio de los noventa, cuando Microsoft intentó licenciar para su sistema operativo Windows la tecnología de tipografía avanzada de Apple, conocida entonces como “TrueType GX”. Tras el fracaso de las negociaciones, Microsoft determinó seguir adelante con su propia tecnología, la cual, basada también en la arquitectura TrueType, vio la luz en 1994 bajo la denominación “TrueType Open”. Adobe se unió al proyecto de Microsoft en 1996, añadiendo al formato la capacidad de usar las curvas matemáticas empleadas en sus tipografías Tipo 1 (curvas de Bézier de 3.^er. grado). La nueva tecnología, bautizada como “OpenType”, fue anunciada públicamente ese mismo año.

Adobe y Microsoft continuaron ampliando y refinando el formato OpenType a lo largo de la siguiente década, hasta que en 2005 se inició el proceso para oficializarlo como un estándar abierto de la Organización Internacional para la Estandarización (International Organization for Standardization, ISO), bajo los auspicios del grupo MPEG, que ya antes había adoptado el OpenType por referencia. El nuevo estándar consiste básicamente en la versión 1.4 de la especificación de OpenType, con adaptaciones lingüísticas requeridas por la ISO, y se denomina “Open Font Format”. La norma fue adoptada oficialmente en marzo de 2007 y declarada como el estándar ISO/IEC 14496-22,​ el cual está disponible de manera pública y gratuita.​

En 2001 ya existía un número significativo de tipos OpenType en el mercado. Adobe terminó la conversión de su catálogo tipográfico al formato OpenType a finales de 2002. A principios de 2005 había alrededor de 10,000 tipos de letra disponibles en el nuevo formato, un tercio de las cuales provenía del catálogo de Adobe. Hacia 2006 las principales casas tipográficas y muchas pequeñas fundiciones estaban produciendo sus tipos en formato OpenType.

Descripción

• 
  Los contornos TrueType se describen mediante curvas de Bézier cuadráticas.
• 
  Los contornos CFF se describen mediante curvas de Bézier cúbicas.

OpenType emplea la misma estructura de datos genérica (llamada “sfnt”) en la que se basan las tipografías TrueType, pero a ella agrega recursos que enriquecen la gama de prestaciones tipográficas de la familia tipográfica, así como sus capacidades de representación lingüística, por lo que se afirma que las OpenType pertenecen a la clase de los denominados “tipos de letra inteligentes” (smartfonts). La descripción de los contornos de los signos (o “glifos”) de un tipo OpenType puede almacenarse en una de dos posibles formas: como curvas de formato TrueType o como curvas de formato CFF (Compact Font Format). En el primer caso los contornos se guardan en la tabla denominada ‘glyf’; en el segundo, en la tabla ‘CFF ’ (nótese que el espacio al final es parte del nombre de la tabla, el cual siempre debe ser de 4 caracteres). El formato CFF, también conocido como Tipo 2 de Adobe, es una forma compacta de representar un tipo de letra de clase "Tipo 1".​ Es importante aclarar también que, según la especificación técnica, los tipos de letra OpenType del tipo “TrueType Collection” (.ttc) no pueden emplear curvas PostScript para describir sus glifos.

Para determinados usos, como sería la diagramación de páginas, no es indispensable saber cuál es el formato de las curvas en una tipografía, pero hay situaciones en las que la diferencia resulta significativa, como sería el control de la “rasterización” de los glifos, esto es, el proceso por el cual cada figura descrita en forma vectorial se convierte en un conjunto de pixeles o puntos para ser desplegados en un medio de salida digital (impresoras o pantallas). Cuando la resolución de salida es baja —pocos puntos para dibujar el objeto— dicho proceso suele requerir la asistencia de comandos o datos adicionales que instruyen al "rasterizador" para dibujar cada glifo haciendo ajustes de grosor, alineación y distancias, logrando así que aún en tamaños pequeños se conserve un grado aceptable de legibilidad. En tal situación, cada formato emplea técnicas muy diferentes: hints declarativos en CFF y un lenguaje completo para dirigir el ajuste (grid-fitting) en TrueType. Dado que el término “OpenType” no aclara por sí solo el formato en que se encuentran los contornos de los glifos, se emplean expresiones como “OpenType CFF” u “OpenType con curvas PostScript”, o bien “OpenType TT” u “OpenType con curvas TrueType”, para expresar dicha diferencia de variantes.

Las familias OpenType presentan las siguientes características distintivas:

• La codificación de los caracteres está basada en el estándar Unicode, por lo que los archivos de tipo de letra pueden cubrir uno o varios sistemas de escritura de manera simultánea.
• Pueden contener hasta 65,536 glifos (aunque todavía no es común hallar tipos OpenType que se acerquen a ese límite).
• Pueden incluir propiedades tipográficas avanzadas (features) que posibilitan el adecuado tratamiento tipográfico de sistemas de escritura complejos, así como la aplicación de transformaciones tipográficas para la composición de textos en sistemas más sencillos, como la escritura latina, usada en idiomas como el español o el inglés.
• Los archivos del tipo de letra son multiplataforma, por lo que pueden usarse sin modificación en sistemas operativos como Mac OS X, Windows y algunos sistemas Unix.
• Los tipos OpenType CFF pueden medir considerablemente menos que sus equivalentes en Tipo 1, siempre que no contengan glifos adicionales o una cantidad numerosa de propiedades tipográficas avanzadas.

Comparación con otros formatos

Comparado con la tecnología tipográfica GX de Apple —ahora llamada en:Apple Advanced Typography (“Tipografía Avanzada de Apple”) o AAT— OpenType es menos versátil en cuanto a su funcionamiento tipográfico, pero ofrece un esquema más acabado de vinculación de propiedades lingüísticas con reglas de transformación tipográfica.

Considerando la mayor cantidad de tipos OpenType existentes y el número de aplicaciones que leen el formato, se puede afirmar que OpenType ha tenido más éxito que AAT aun cuando esta tecnología surgió antes que aquella. Dos factores que podrían explicar este hecho son que AAT funciona sólo en una plataforma y que, por otra parte, no ha recibido apoyo de los principales productores de software, excepto Apple mismo.

Desde la perspectiva de un desarrollador de tipografías, OpenType es un formato más fácil de producir que AAT en lo que toca a la funcionalidad básica. Primero, porque el lenguaje declarativo en el que se expresan las operaciones de sustitución y posicionamiento de glifos en OpenType es más sencillo que las tablas de transición de estados más complejas (aunque más poderosas) de AAT. En segundo lugar, la estrategia de Adobe de licenciar sin cargo el código fuente que utiliza en sus propias herramientas de producción —esto es, el Adobe Font Development Kit for OpenType (AFDKO)— permitió que otras aplicaciones de edición de tipos de letra, como en:FontLab y FontMaster, pudieran incorporar recursos de producción OpenType con relativa facilidad. Si bien el esquema de programación de propiedades OpenType de Adobe no cuenta con los medios de visualización que ofrece la utilidad VOLT (Visual OpenType Layout Tool) de Microsoft, su integración con los programas que actualmente se emplean para crear tipos ha sido bien acogida por los usuarios. Por su parte, las herramientas de producción para AAT también están disponibles de manera pública y gratuita,​ pero su uso requiere que el usuario esté familiarizado con las tablas de transición de estados.

Otra diferencia entre ambos formatos radica en el grado de procesamiento que se debe efectuar previo al momento en que se despliegan los caracteres (rendering) en pantalla. Los subsistemas de manejo de texto compatibles con OpenType (como el en:Uniscribe en Windows, el en:Core Text en Mac OS X o los incluidos en las propias aplicaciones) tienen que suministrar buena parte de la información sobre reglas especiales de procesamiento lingüístico requeridas para desplegar textos en escrituras de composición compleja, como el árabe. En contraste, quien desarrolla tipos AAT debe incorporar toda esa información experta en el propio tipo de letra. Lo anterior significa que AAT permite modelar en principio cualquier escritura, pero al costo de un mayor esfuerzo y conocimiento especializado por parte de los desarrolladores; por otro lado, las tipografías OpenType, aun siendo más fáciles de crear, pueden representar escrituras complejas solamente en la medida en que cuenten con apoyos externos que codifiquen el conocimiento lingüístico necesario.

Antes de OpenType, Adobe promovía las tipografías Multiple Master​ y las llamadas “expert fonts” ("tipos de letra expertos" o mal llamados "fuentes expertas") como soluciones para la tipografía de alta calidad. Las Multiple Master carecían de medios de selección de glifos alternativos o de los recursos lingüísticos con los que cuenta OpenType, pero ofrecían al usuario la posibilidad de generar pesos o estilos intermedios, compuestos a partir de la fusión o combinación graduada de dos o más matrices (masters) de diseño pertenecientes a una misma familia tipográfica. Por su parte, las "expert fonts" se ofrecían como complementarias a las Tipo 1 convencionales, cuyo repertorio de caracteres, basado en la codificación estándar de Adobe, estaba limitado a un máximo de 256 unidades. De esta manera, distintas especialidades —ligaduras, fracciones, versalitas, etc.— que no se hallaban en fuentes de codificación estándar podían encontrarse en los "tipos expertos" correspondientes. Sin embargo, y debido a las limitaciones de codificación de Tipo 1, para introducir tales glifos en un texto era preciso teclear caracteres que en general no estaban relacionados con ellos; por ejemplo, la ligadura “ffl” se obtenía tecleando una ‘Z’ en la fuente experta, con lo que se producía una desconexión entre el contenido lógico del documento y su representación gráfica. Los tipos OpenType modernos, en cambio, pueden contener en un mismo archivo tanto el repertorio estándar de glifos como las variantes especiales correspondientes, las cuales, gracias a su indización mediante Unicode y a las reglas de composición OpenType pueden introducirse en el texto sin afectar su integridad semántica.

---

Soporte OpenType

El soporte de OpenType puede estar dividido en varias categorías: virtualmente todas las aplicaciones y la mayoría de los sistemas operativos trabajan con tipografías OpenType tan bien como otros formatos antiguos. Lo que es de particular interés es:

• El soporte extendido de lenguajes en Unicode.
• El soporte para escrituras "complejas", como el lenguaje Árabe o el Hindú.
• El soporte tipográfico avanzado para lenguajes con alfabeto Latino como el inglés.

Los tipos TrueType TT (.TTF) son compatibles con todos los sistemas operativos de Microsoft. Los tipos OpenType PS (.OTF), sin embargo, son solamente soportadas por Windows 2000, Windows XP y Windows Vista. Para soporte Romano básico en Windows95/98/NT/Me se requiere instalar algún organizador de tipografías como Adobe Type Manager.

El soporte extendido del lenguaje a través de Unicode para OpenType y TrueType está presente en la mayoría de las aplicaciones de Windows (incluyendo Publisher, las aplicaciones de Adobe y Microsoft Office 2003) y muchas aplicaciones de Mac OS incluyendo TextEdit y Keynote. OpenType es soportado completamente en MacOS X por el procesador de texto Mellel.

El soporte de OpenType para escritura compleja en manuscrita ha aparecido en Microsoft Office on Publisher. Adobe InDesign provee capacidades extensivas de OpenType en Japonés pero no soporta directamente escrituras Medio Orientales o Indúes - aunque una versión separada soporta Árabe y Hebreo.

El soporte tipográfico avanzado para escritura Latina han aparecido hasta ahora en aplicaciones de Adobe como Adobe InDesign, Adobe Photoshop y Adobe Illustrator. CorelDRAW de Corel no soporta características tipográficas OpenType. QuarkXPress 6.5 y anteriores (Quark Inc.) no son compatibles con Unicode. Por lo tanto el texto que contiene otra cosa que no sean caracteres WinANSI/MacRoman no se mostrarán correctamente en una familia OpenType (ni en otros formatos de fuentes Unicode, para este caso). Sin embargo, Quark ofrece unsoporte similar al de Adobe en QuarkXPress 7, que lanzó en mayo del 2006. La "Windows Presentation Foundation", que es parte de Windows Vista y disponible para Windows XP soporta tipos OpenType CFF (Formato de Fuente Compacta) y características especiales avanzadas como ligaduras, numerales old-style, variantes de swash, fracciones, superíndice y subíndice, capitales pequeñas (small caps), sustitución de glifos, líneas base múltiples, alternativas contextuales y estilísticas (kerning), justificación a línea de nivel, caraceres rubí, etc. Adicionalmente las aplicaciones con soporte AT&T corriendo en Mac OS X, 10.4 y posteriores, incluyendo TexEdit y Keynote, tienen soporte OpenType considerable.

El soporte OpenType de Apple en Mac Os X 10.4 incluye la mayoría de las características tipográficas avanzadas necesarias para los lenguajes de escritura latina, como capitales pequeñas, figuras old-style, y varios tipos de ligaduras. Todavía no soporta alternativas contextuales, formas posicionales o reordenado de glifos como en la librería Microsoft Uniscribe en Windows.

En ambientes de software libre como Linux el soporte OpenType está provisto por el proyecto FreeType, incluido en implementaciones libres del Sistema de Ventanas X (X Window System) como X.Org.

La solución SING gaiji

En 2005 Adobe lanzó una nueva tecnología en su paquete de aplicaciones de la Suite Creativa que ofrece una solución para el problema gaiji (en japonés "carácter de afuera"). La escritura manual ideográfica como el chino y japonés no tienen colecciones fijas de caracteres. Usan miles de glifos cotidianamente y decenas de miles menos comúnmente. No todos los glifos jamás inventados y usados en la literatura oriental fueron catalogados. Un tipo normal puede contener de 8.000 a 15.000 glifos de uso común. De cuando en cuando un autor necesita un glifo que no está presente en el tipo elegido. Tales caracteres perdidos son conocidos en Japón como gaiji, y frecuentemente interrumpen el trabajo.

Otro aspecto del problema gaiji son los glifos que varían en ciertos caracteres. A menudo ciertos caracteres fueron escritos diferente en distintos periodos de tiempo. Es usual para nombres de lugares o nombres personales de familias usar una forma histórica del carácter. Así, es posible para un usuario final usando tipos estándar no poder deletrear correctamente su nombre o el nombre del lugar donde vive.

Se han ideado varias maneras para lidiar con el problema gaiji. Las soluciones que los tratan como caracteres usualmente le asignan valores Unicode en el Área de Usuario Privada (Private User Area, PUA). Tales caracteres no pueden ser usados fuera del medio en la cual la asociación del Unicode privado con la forma del glifo es conocida. Los documentos basados en ellas no son portables. Otras instalaciones tratan los gaiji como gráficos. Esto puede ser incómodo porque la disposición y composición del texto no puede ser aplicada a los gráficos. Tampoco pueden ser buscados. A menudo su representación luce diferente de los caracteres que lo rodean porque la maquinaria para representar gráficos usualmente es diferente de la maquinaria para representar glifos de tipografía.

La tecnología SING que hizo su debut con la Creative Suite 2 de Adobe permite la creación de glifos, cada uno empaquetado como una "fuente" separada, después de una moda. Tal glifo empaquetado es llamado glyphet (glifete). El formato, que Adobe hizo público, está basado en OpenType. El paquete consiste en un contorno de un glifo en forma TrueType o CFF (estilo de contornos PostScript); tablas OpenType estándar declarando las métricas y comportamiento del glifo en la composición; y metadatos, información extra incluida para identificar el glifete, su propietario, y tal vez, pronunciación o categorización lingüística. Los glifetes SING pueden ser creados usando la aplicación SigMaker3 de Fontlab.

La especificación SING (Smart INdependent Glyphlets) declara que los glifetes deben viajar con el documento en el que son usadas. De esa manera los documentos son portables, sin dejar en peligro al documento en el que ciertos caracteres pueden no ser mostrados. Ya que los glifetes son esencialmente tipos de letra OpenType, la maquinaria estándar de tipografías puede representarlos. La especificación SING también describe un formato XML que incluye todos los datos necesarios para reconstruir el glifete en forma biaria. Un glifete típico puede requerir de 1 a 2 kilobytes para ser representado.

Disposición de las etiquetas

Las etiquetas de disposición de OpenType son secuencias de caracteres de 4 bytes que identifican la escritura, el sistema de lenguaje, características y líneas de fondo en una Disposición OpenType del tipo. El registro de etiquetas de la disposición OpenType de Microsoft establece convenciones para nombrar y usar las etiquetas. Las características OpenType son creadas usando las etiquetas para crear escrituras con características que describen como los caracteres van a ser manipulados para lograr la característica deseada. Estas escrituras con características pueden ser creadas e incorporadas en archivos OpenType por editores de tipografía avanzados como FontLab Studio y Asian Studio.

Etiquetas de escritura

Las etiquetas de escritura identifican las escrituras representadas en una tipografía OpenType. Cada etiqueta corresponde a un rango de código de carácter contiguo en Unicode. Una etiqueta de escritura puede consistir d 4 o menos letras minúsculas. Los ejemplos incluyen arab para el Alfabeto Árabe, cyrl para el Alfabeto Cirílico, latn para el Alfabeto Latino, etc.

Etiquetas de idioma

Las etiquetas del sistema de idioma identifica los sistemas de idioma soportados en una tipografía OpenType. Los ejemplos incluyen ARA para el idioma árabe, HYE para el idioma armenio, etc. Los códigos son similares pero no idénticos al ISO 639-2.

Etiquetas de Características

Las etiquetas de características identifican los glifos que representan cierta característica tipográfica.

• 'aalt' Access All Alternates
• 'abvf' Above-base Forms
• 'abvm' Above-base Mark Positioning
• 'abvs' Above-base Substitutions
• 'afrc' Fracciones alternativas
• 'akhn' Akhands
• 'blwf' Below-base Forms
• 'blwm' Below-base Mark Positioning
• 'blws' Below-base Substitutions
• 'calt' Alternativas contextuales
• 'case' Case-Sensitive Forms
• 'ccmp' Glyph Composition / Decomposition
• 'clig' Contextual Ligatures
• 'cpsp' Capital Spacing
• 'cswh' Contextual Swash
• 'curs' Cursive Positioning
• 'c2sc' Small Capitals From Capitals(probablemente, versalitas)
• 'c2pc' Petite Capitals From Capitals
• 'dist' Distances
• 'dlig' Discretionary Ligatures
• 'dnom' Denominadores
• 'expt' Expert Forms
• 'falt' Final Glyph on Line Alternates
• 'fin2' Terminal Forms #2
• 'fin3' Terminal Forms #3
• 'fina' Terminal Forms
• 'frac' Fracciones
• 'fwid' Full Widths
• 'half' Half Forms
• 'haln' Halant Forms
• 'halt' Alternate Half Widths
• 'hist' Historical Forms
• 'hkna' Horizontal Kana Alternates
• 'hlig' Historical Ligatures
• 'hngl' Hangul
• 'hojo' Hojo Kanji Forms
• 'hwid' Half Widths
• 'init' Initial Forms
• 'isol' Isolated Forms
• 'ital' Italics
• 'jalt' Justification Alternates
• 'jp04' JIS2004 Forms
• 'jp78' JIS78 Forms
• 'jp83' JIS83 Forms
• 'jp90' JIS90 Forms
• 'kern' Kerning
• 'lfbd' Left Bounds
• 'liga' Standard Ligatures
• 'ljmo' Leading Jamo Forms
• 'lnum' Lining Figures
• 'locl' Localized Forms
• 'mark' Mark Positioning
• 'med2' Medial Forms #2
• 'medi' Medial Forms
• 'mgrk' Mathematical Greek
• 'mkmk' Mark to Mark Positioning
• 'mset' Mark Positioning via Substitution
• 'nalt' Alternate Annotation Forms
• 'nlck' NLC Kanji Forms
• 'nukt' Nukta Forms
• 'numr' Numeradores
• 'onum' Oldstyle Figures
• 'opbd' Optical Bounds
• 'ordn' Ordinales
• 'ornm' Adornos
• 'palt' Proportional Alternate Widths
• 'pcap' Petite Capitals
• 'pnum' Proportional Figures
• 'pres' Pre-Base Substitutions
• 'pstf' Post-base Forms
• 'psts' Post-base Substitutions
• 'pwid' Proportional Widths
• 'qwid' Quarter Widths
• 'rand' Randomize
• 'rlig' Required Ligatures
• 'rphf' Reph Forms
• 'rtbd' Right Bounds
• 'rtla' Right-to-left Alternates
• 'ruby' Ruby Notation Forms
• 'salt' Variaciones de estilo
• 'sinf' Subíndices científicos
• 'size' Optical size
• 'smcp' Small Capitals
• 'smpl' Simplified Forms
• 'ss01' to 'ss20' Stylistic Set 1 to 20
• 'subs' Subscript
• 'sups' Superscript
• 'swsh' Swash
• 'titl' Titling
• 'tjmo' Trailing Jamo Forms
• 'tnam' Traditional Name Forms
• 'tnum' Tabular Figures
• 'trad' Traditional Forms
• 'twid' Third Widths
• 'unic' Unicase
• 'valt' Alternate Vertical Metrics
• 'vatu' Vattu Variants
• 'vert' Escritura vertical
• 'vhal' Alternate Vertical Half Metrics
• 'vjmo' Vowel Jamo Forms
• 'vkna' Vertical Kana Alternates
• 'vkrn' Vertical Kerning
• 'vpal' Proportional Alternate Vertical Metrics
• 'vrt2' Vertical Alternates and Rotation
• 'zero' Slashed Zero

Referencias

• Datos: Q260180
• Multimedia: OpenType / Q260180