Suscribirse a Entradas ó Comentarios

Por minombresbond 15 Oct 2008 02:00 am

Diseño Web | Diseño Gráfico | Licencias | Tipografía

¿Se viene el estándar EOT (embebido de fuentes para la web) impulsado por Microsoft?

webfonts

El tema Web Fonts es un asunto que venimos siguiendo de cerca, esta entrada de hace unos meses puede servir de introduccion al tema.

Recientemente la W3C (el organismo que define los estándares de la web) publicó un artículo, ‘For & against - Standardizing font embedding’ dando cuenta del actual debate sobre Web Fonts:

  • En un rincón, ‘font linking’, o la posibilidad de enlazar transparentemente un archivo de fuente tipográfica remoto con un formato estándar.
  • En el otro rincón, la propuesta de Microsoft (y de la industria): Embedded OpenType (EOT), o la posibilidad de embeber una fuente, y la consiguiente presentación a la W3C de las especificaciones para promover el estándar del formato EOT, en marzo de este año.

‘Font linking’ está incluído dentro de las recomendaciones para CSS2 desde hace una década!, describe como pueden referenciarse fuentes remotas, por ejemplo, truetype, opentype ó type-1, sólo hace falta especificar la url en la hoja de estilo:

@font-face {
font-family: “Mi Familia”;
src: url(”http://site/fonts/miarchivo”)
}

Pero esto casi no funciona, porque los navegadores web nunca lo implementaron (hasta el 2006, que empezó Webkit/Safari). EOT tambien lleva muchos años —olvidado— como una tecnología cerrada de Microsoft, y también está entre las referencias para @font-face (que sólo podía usarse en IE, al mantener Microsoft cerrada la especificación de su formato EOT).

Los estándares abiertos impulsados por Microsoft

La reciente novedad de que Mozilla se está sumando a Safari en la implementación de ‘font linking’, seguramente forzó a Microsoft (y la industria tipográfica detrás), a impulsar un estándar más acorde a sus intereses, liberando las especificaciones de EOT para que pueda ser adoptado por los otros navegadores.

El motivo de este post es la traducción al castellano el articulo publicado por la WC3. Si bien es algo extensa aconsejo leerla a todo aquel a quien los ‘estandares abiertos impulsados por Microsoft’, no dejan de provocarle cierta suspicacia.

Si los usuarios no defendemos nuestros intereses, la industria no lo hará por nosotros, recordemos que detrás de cada traba impuesta ‘para evitar la posibilidad de copias indebidas’ se esconden nuestros viejos conocidos, los monopolios artificiales.

¿El documento de la W3C parece favorable a EOT? a estar atentos…


Artículo original (en inglés) de la W3C:
‘For & against - Standardizing font embedding’ por Bert Bos

A favor y en contra: Estandarizando embebido de fuentes

Todo lo que he oído acerca embebido de fuentes en la web…
… hasta Septiembre de 2008

W3C esta estudiando si debería conformar un WG para hacer una versión estándar de EOT. No hay estándar para embebido de fuentes en documentos para la Web aún, pero EOT con algunas mejoras, puede volverse uno. Microsoft y Monotype presentaron su tecnología a la W3C con ese propósito. El equipo WC3 preguntó a muchas compañías y gente por sus opiniones. Este es el resúmen.

índice

  1. Los hechos
  2. La controversia
  3. La posición de los interesados

1. Los hechos

La Primer Recomendación de la W3C para CSS level 2 (1998) incluye una característica llamada ‘Web Fonts’, para considerar la situación donde desde una hoja de estilo se hace referencia a una fuente que no está presente en el equipo local del usuario. Una de las cosas que permite es enlazar a un archivo remoto de una fuente tipográfica para que pueda ser descargada. Sólo Microsoft decidió implementarlo.

El navegador Netscape 4 añadió una capacidad similar, usando la tecnología ‘TrueDoc PFR’ de Bitstream, pero como una extensión propietaria del HTML, en vez de ir a través de los CSS. La extensión generó controversia, porque no se limitaba a fuentes ‘embebibles’. En este momento, ningún navegador web soporta PFR.

Mas recientemente, SVG adoptó las propiedades CSS y por tanto es posible enlazar fuentes desde un SVG, sin ir a traves del CSS. Hay planes de incluir las mismas propiedades en el XSL2

No hay duda que la razón por la cual las Web Fonts no se volvieron masivas, fue la falta de una buena implementación en su momento. No había ninguna fuente para descargar.

La razón por la cual Microsoft lo implementó, era que desde su punto de vista ‘font embebing’ (fuente embebida) es un caso especial de ‘font linking’ (fuente enlazada). La fuente embebida tiene doble referencia, del documento a la fuente y de la fuente al documento, mientras que la fuente enlazada tiene una sola referencia: del documento a la fuente. Entonces Microsoft desarrolló EOT (Embedded OpenType), para añadir ese doble camino que OpenType por si solo no ofrecia. Pero lo mantuvieron propietario.

Crear un formato separado de OpenType tenía la ventaja agregada de que una fuente embebida era fácilmente distingible de una fuente original, por la extensión del archivo y porque los contenidos no lucen como los de Opentype.

Esta situación duró cerca de 8 años. Entonces, en 2006, Håkon Wium Lie inició la campaña por las Web Fonts y en 2007 el grupo de trabajo de CSS dió mayor prioridad al módulo CSS para fuentes.

Aquel grupo ya venía discutiendo la cuestión a causa del aumento de popularidad de técnicas de reemplazo con imágenes (image-replacement), donde los diseñadores reemplazan un encabezado con una imagen (usando algunas propiedades CSS), para conseguir que las tipografías se vean exactamente como ellos desean.

Håkon ademas convencio a YesLogic (en 2007) y a Apple (en 2008) para implementar enlazado de fuentes directo (sin embebido), en Prince y Safari, respectivamente.

En esa misma época, Microsoft decidió ofrecer EOT a los demás: con la ayuda de Monotype (dueño de parte de esa tecnología) lo presentaron ante la W3C en el final de 2007.

2. La controversia

Aqui es donde la discusión realmente inicia, para empezar, con los argumentos que estamos esperando: EOT es DRM y por lo tanto malo, ‘font linking’ hace robar fuentes a la gente sin saberlo, etc. Parece una cuestión de juntar a los expertos y buscar el consenso, como W3C ha hecho tantas veces antes. Desafortunadamente parece que las posiciones se han alejado más en los pasados meses.

Veamos los argumentos:

EOT no es escalable

El argumento afirma que el mejor camino para compartir una fuente es compartir su URL. EOT tal como se describe en su presentación sólo considera fuentes embebidas, por ej. cada documento o grupo de documentos necesita su propio recurso tipográfico que va unido a esos documentos. Pero cuando la licencia de la fuente lo permite, seria bueno tener sólo un archivo EOT que sea enlazado desde cualquier lado.

De echo, la implementación de Microsoft ya incluye esto y debe ser facil añadirlo a la especificación.

Subsetting y compresión sin embebido

EOT se hace conveniente para ’subset’ y comprimir una fuente sin confundir la version ’subsetted’ con la original. Esto también debería estar disponible para fuentes libres, en tanto pueden ser enlazadas en vez de embebidas. El argumento es básicamente el mismo que el anterior: debería ser posible usar EOT con su propio conjunto de vinculacioness vacío.

Conformidad con EOT implica responsabilidad legal

Algunos implementadores expresaron su temor que EOT requeriria al navegador web verificar los URLs en un recurso tipográfico no sólo para conformar la especificación, sino por obligación legal.

Este es ciertamente un aspecto a discutir, pero, acorde a algunos abogados, el riesgo no es lo suficientemente serio para suspender el inicio de un grupo de trabajo.

La discusión no es únicamente para fuentes. Igual que más y más metadata de recursos en línea se vuelven legibles-para-máquinas, la pregunta que debemos hacernos es si el hecho que los datos sean legibles por máquinas implica que las máquinas deban leerlos

Licencia legible para humanos

Otra crítica para EOT era que EOT hace de la licencia legible-para-máquinas un dato de fácil acceso, pero esconde la que es legible-para-humanos. Hay también un camino no estándar para incluir una URL, la licencia es sólo texto plano.

Si esto es aceptado como requerimiento, no parece dificultoso agregar una URL al formato EOT.

Limitaciones especificas de Windows

EOT tiene al menos una limitación que hace de ciertas fuentes no adecuadas para embeber como EOT: EOT parece limitar el tipo de letra a no más de cuatro variantes.

Opentype soporta extensas familias tipográficas. No parece dificultoso extender EOT para usar el mismo mecanismo que OpenType.

Extensibilidad

EOT es específico para OpenType. OpenType es ampliamente soportado, pero en el futuro puede haber nuevos formatos de fuentes.

El grupo de trabajo debe examinar si EOT debería ser extensible. Sin mas discusión, no está claro cuáles son los requisitos.

Facilidad de uso

Si Ud. tiene una fuente libre solo necesita subirla, apuntarla desde CSS y listo. EOT requiere convertir la fuente primero, lo cual parece un paso innecesario.

Sin embargo, si sólo va a usarse un subconjunto (subset) de una fuente, una conversión es necesaria de todas maneras. Y si un documento utiliza a una mezcla de fuentes libres y no-libres, seria mas fácil aplicar un mismo procedimiento para todas.

Aún asi, es un argumento para permitir ambas, fuentes comunes y EOT en la Web.

Control de acceso via HTTP en vez de EOT

Se ha sugerido que un servidor Web puede verificar el Referer en el encabezado del HTTP, y solamente proporcionar las fuentes si el encabezado indica un documento permitido. Es un procedimiento que algunos sitios usan para no permitir ‘deep linking’, pero mucha gente reconoce que no funciona muy bien.

Algunas organizaciones de hecho recomiendan a los usuarios desactivar el ‘Referer’ por razones de privacidad.

Otra idea, presentada por Mozilla, es dejar al navegador web verificar los enlaces desde una fuente a un documento, como en EOT, pero sin crear un nuevo recurso tipografico. En lugar de eso, los URL se pasarían junto a la fuente en una cabecera HTTP.

Para facilidad de uso, los encabezados HTTP no deberían ser necesarios sobre una fuente que fuera válida para todos los documentos que estén en el mismo servidor donde está la fuente. En ese caso, para fuentes libres, entonces necesitarían un encabezado explícito que diga que no está atada a un sólo dominio.

W3C tiene un grupo de trabajo encargado de crear un encabezado HTTP para tratar con ciertas cuestiones de seguridad en Javascript. Este grupo de trabajo puede extender su ámbito a las cuestiones de licenciamiento también.

La asociación entre fuente y documento es claramente menos fuerte que con EOT: descargando el recurso tipografico o moviéndolo a un servidor diferente se remueve la metadata. Muy pocos hasta ahora han dado su opinión sobre esta idea.

Licencias

Algunos pidieron un sistema en el que las fuentes fueran embebidas sin tener que hacer copias. Entonces, la fuente permanecería en la máquina del vendedor de la fuente y sólo una clave digital permitiria su acceso. Quienes tengan una clave válida para un dominio o documento podrán usar esa fuente.

Esto no permitiría ni ’subsetting’ ni ver el documento sin estar conectado a internet. Pero lo mas importante, no hay propuestas de una tecnología en concreto.

Escrituras minoritarias

Hay cientos de fuentes para alfabetos latinos (algunos limitados solo a ASCII o incluso sólo a mayúsculas) pero la situacion es diferente para algunas escrituras de medio y lejano oriente. Genralmente no hay mercado para fuentes y apenas hay algunas fuentes libres como mucho para hacer visibles páginas Web. Myanmar es el caso extremo, donde hay probablemente solo tres fuentes disponibles que son compatibles con Unicode version 5.1.

Una solución interoperable de ‘font linking’ es esencial para esas lenguas. Ya sea si se trata de EOT o alguna otra cosa sólo es una consideración secundaria.

El argumento Silverlight

Silverlight version 1 de Microsoft no usa EOT y crea fuentes descargables OpenType desprotegidas. Los competidores de Microsoft naturalmente reclaman competencia desleal: si W3C estandariza EOT, aplicaciones DHTML/AJAX podrían tener que usar EOT, pero Microsoft mismo usa una solución mas sencilla.

Microsoft ha dicho que cometió un error y prometió que la versión 2 ya no creará archivos de fuente comunes, solo embebibles. Por tanto, este argumento es poco relevante.

Patentes en TrueType

Apple tiene dos patentes relativas a ‘hinting’ (US patents 5155805 y 5159668) y, tal como reclama Apple, afectarían a OpenType, entonces, indirectamente afectarían a EOT también. Pero la Recomendación WC3 será solo una descripción de EOT, no de OpenType, por lo tanto la politica sobre Patentes Libres de Regalías de WC3 no se extiende a OpenType.

Puede trabajarse alrededor de las patentes y éstas no han impedido que OpenType se convierta en un formato de fuente común, incluso para el software Código Abierto. Por otra parte, las patentes expiran en octubre de 2009.

Este argumento está en contra de OpenType como tal, no en contra de EOT en particular. En la práctica, muy pocas personas parecen estar en contra de la utilización OpenType.

DRM es malo

Lo que usualmente es llamado DRM es una estrategia anti-copia que intenta hacerla dificultosa, en vez de decir cuando y como la copia es permitida.

Por esto, la gente de Creative Commons, ha empezado a usar un nuevo termino, DRE (Digital Rights Expression) para la expresión legible-para-máquinas de quién posee lo derechos. Otro nombre sugerido para el tipo de metadata que provee EOT es “bloqueo de dominio”

Muchos clasifican a EOT como DRM y ven alli otra estrategia para limitar sus libertades.
Argumentos mas reflexivos apuntan al hecho de que varias leyes lamentables, como la DMCA, ahora se refieren a DRM y ahogan la innovación y la libertad, aún cuando la propia tecnología DRM fuera relativamente inofensiva.

EOT, ahora que su especificación es pública, es en realidad un DRE: es casi tan fácil de falsificar la licencia en un archivo EOT como en una página HTML. EOT (y OpenType/TrueType antes) permite que los diseñadores de fuentes puedan poner una licencia en una fuente de la misma manera que los autores HTML ponen una licencia de Creative Commons en una página HTML.

3. La posición de los interesados

Mozilla ha declarado que no quieren EOT. Pero no se oponen a dejar que el navegador verifique licencias, como se evidencia en ‘proposal to let HTTP headers carry license data’ ( propuesta para permitir a encabezados HTTP llevar datos de licencia )

Microsoft ha dicho que no es posible para ellos apoyar un sistema de enlazado a la fuente OpenType nativa, porque hace tiempo los comercializadores de fuentes tipográficas se oponen.

Safari, de Apple, ha implementado la descarga de fuentes sin verificación de licencia. Ellos se han pronunciado en contra de EOT y en contra de que los navegadores web verifiquen licencias.

Opera anunció implementaciones para descargar OpenType nativas y no EOT. Concluyeron que el mercado aparentemente no necesita EOT, y por tanto no ven la necesidad de soportarlo tampoco. Los limitados recursos de WC3 deben usarse en estándares más importantes.

(Por supuesto, el problema de los recursos limitados se soluciona si una o mas de las compañias interesadas se une a WC3 y envia delegados para ayudar en el desarrollo de EOT)

Muchas comercializadoras de tipografías y diseñadores de fuentes expresaron opiniones muy similares. Estan en favor de estandarizar EOT, creen que estimulará la creación y venta de fuentes, y los protegerá aceptablemente en contra de usos indebidos. EOT es comparable con PDF en ese aspecto. Pueden vender fuentes que están embebidas, pero no instalables. Compañias con opiniones similares incluyen a Monotype, Adobe, Ascender, Dalton Maag, Hoefler & Frere-Jones, y Bitstream.

Muchas reconocen sin embargo, que la gente también desea usar las fuentes libres que están disponibles sin necesidad embeberlas, y los navegadores web por tanto deberían descargar fuentes Opentype nativas tambien, con algunas precauciones.

Los autores de FontLab también apoyan la estandarización de EOT, y creen que las fuentes en la web y las fuentes en el escritorio son diferentes cosas y es mejor mantenerlas separadas. (Una opinión también expresada por Stephen Coles de FontFont/FontShop/Typographica). Pero como desarrolladores de herramentas son flexibles en apoyar cualquiera de las soluciones elegidas.

Diseñadores Web como Chris Andreola (adcSTUDIO) es otro defensor de EOT, pero le preocupa que las Web Fonts no sean fáciles de usar, de otra manera no serán adoptadas aunque estas provean alta calidad. Un pensamiento compartido por Ivo Gabrowitsch (FontShop/FontFont).

Adam Twardoch de FontLab explica por qué, desde el punto de vista de mucha gente de la industria, las fuentes no son como los MP3s: las fuentes deben compararse con las cintas maestras, mientras un MP3 es más como el documento que usa una fuente. Considerar una radio que transmite todo el dia una misma canción y un sitio que use una misma fuente en todas la páginas, lo primero no es aceptable para la gente, lo segundo es normal.

David Crossland, un estudiante de diseño tipográfico y defensor del software libre tiene miedo que EOT, aunque es mas bien metadata que un sistema anti-copia, aun asi caerá bajo leyes del tipo DMCA en USA y se convertirá en una barrera para la innovación.

David Berlow (The Font Bureau) es de opinión opuesta. Piensa que EOT, especialmente ahora que se ha publicado, no da suficiente protección. Prefiere una solución donde la verificación de licencias sea realizada por (los servidores de) los vendedores de la fuente mismos.

Tambíen se ha dicho que sería bueno que los navegadores web y otras herramientas expusieran algo de la metadata más claramente. Muchos navegadores tienen medios para listar enlaces e imágenes, y sería mejor si no sólo mostraran una lista de links, sino además quién es el autor de cada uno. Un set de íconos semejantes a los de Creative Commons para señalar las principales licencias para fuentes, podría ayudar a reconocer a los autores.

El fundador de Arabetics, Saad Abulhab, reiteró la preocupación que la mayor prioridad era tener una solución de descarga de fuentes interoperable, porque actualmente para muchos idiomas es completamente imposible hacer paginas web. (Hrant Papazian de The Microfoundry expreso la misma preocupación.)

Él también mencionó una ventaja de EOT: permite a la gente ver las fuentes antes de comprarlas, por medio de un documento de solo lectura con las fuentes embebidas.

Hrant Papazian ha dicho que es importante que las tipografías en la web permitan todas las características de OpenType, incluyendo por ej. bitmaps y hinting. (EOT, por supuesto, permite eso.)

Algunas comercializadoras de fuentes sugirieron que podria haber todo un mercado en servicios web donde se pueda tener un fuente EOT hecha por usuarios en línea, en lugar de hacerlas con herramientas como WEFT. Ellos tendrían la última version y la posibilidad de subsettings mas sofisticados que WEFT, permitiendo archivos mas livianos.

Relacionados

Atribución - Compartir Obras Derivadas Igual 2.5 Genérica El texto de este artículo se publica bajo licencia Atribución - Compartir Obras Derivadas Igual 2.5 Genérica.
Los contenidos tomados con permiso de otros autores mantendrán la licencia original. Puede consultarse la política de WC3 para uso de sus documentos publicados.

One Response to “¿Se viene el estándar EOT (embebido de fuentes para la web) impulsado por Microsoft?”

  1. on 22 Oct 2008 at 15:44 1.Guillermo said …

    Desde la próxima versión de Firefox (3.1) ya se podrá utilizar font-face. Se puede probar en las versiones beta de esta nueva versión que ya están disponibles. Por ahora sólo funciona para las versiones Windows y Mac, pero estará disponible para la versión final en Linux también.

Trackback This Post | Subscribe to the comments through RSS Feed

Deja tu comentario

*
To prove that you're not a bot, enter this code
Anti-Spam Image