Lo hice y lo entendí

El blog de Vicente Navarro
05 abr

Web Fonts, fuentes descargables para la web

En la época de la guerra de navegadores 4.0, tanto Netscape 4 como Internet Explorer 4 introdujeron infinidad de novedades revolucionarias, muchas de ellas a menudo incompatibles con el navegador del rival. Una de estas novedades era la posibilidad de que las fuentes que se usaran para renderizar la página se pudieran descargar del servidor web y no tener que estar pendientes, por tanto, de si la fuente que queremos usar estará instalada en el sistema del visitante o no.

Recordemos que, según la especificación CSS 2.1, sección de fuentes, a la propiedad CSS font-family le podemos asignar una fuente concreta o una familia genérica de fuentes (serif, sans-serif, monospace) de forma que si la fuente que queremos mostrar no está disponible, se use una de las genéricas que el navegador tiene definidas por defecto:

<family-name>

The name of a font family of choice. In the last example, “Gill” and “Helvetica” are font families.

<generic-family>

In the example above, the last value is a generic family name. The following generic families are defined:

  • ‘serif’ (e.g. Times)
  • ‘sans-serif’ (e.g. Helvetica)
  • ‘cursive’ (e.g. Zapf-Chancery)
  • ‘fantasy’ (e.g. Western)
  • ‘monospace’ (e.g. Courier)

Style sheet designers are encouraged to offer a generic font family as a last alternative. Generic font family names are keywords and must NOT be quoted.

Un ejemplo típico de uso de esta propiedad sería:

body { font-family: Verdana, Arial, sans-serif }

Pero como normalmente no podremos saber seguro de antemano (a menos que estemos desarrollando una página para un entorno corporativo controlado o, por ejemplo, para un kiosko) que el usuario va a tener las fuentes que queremos usar, nunca podremos saber seguro la apariencia que van a tener los textos de nuestra página en otros sistemas.

Por ejemplo, en el ejemplo anterior hemos puesto "Verdana, Arial, sans-serif". Imaginemos que estamos en un sistema Linux en el que el paquete msttcorefonts (que contiene las Core fonts for the Web, o lo que es lo mismo, las fuentes típicas de Microsoft: Arial, Verdana, Times New Roman, Courier, etc.) no está instalado y, por tanto, no tenemos ni la Verdana, ni la Arial y la familia sans-serif se representa con las fuentes free Vera o DejaVu, ambas con un aspecto ligeramente diferente a lo esperado.

Es decir, este mismo código:

<html>
  <head>
    <title>Prueba</title>
  </head>
  <body>
    <h1 style="font-family: Arial, sans-serif;">Texto en sans-serif</h1>
  </body>
</html>

se vería así en Windows:

sans-serif en Windows

Nota: de cara a Windows da igual que pongamos “Arial, sans-serif” que sólo sans-serif, porque en Windows la fuente sans-serif por defecto es la Arial.

se vería igual en un Linux con la fuente Arial instalada:

sans-serif en Linux con Arial

y se vería diferente en un Linux con la fuente Arial no instalada (además del grosor de la fuente, nos podemos fijar, por ejemplo, en el pico de arriba de la “t”, en la forma de la “a” o en que la “e” tiene la abertura más pequeña):

sans-serif en Linux sin Arial

con lo que comprobamos que realmente no tenemos un férreo control sobre las fuentes que finalmente se mostrarán en el destino.

Por tanto, para diseñar una página web en los que el aspecto sea muy importante, en ciertos casos sería ideal poder estar seguros de que la fuente que queremos usar estará disponible en el navegador, aunque tengamos que consumir ancho de banda de nuestro servidor web enviando la fuente junto con el resto de la página. Sin embargo, un problema asociado a la distribución de fuentes es que aunque normalmente las usemos alegremente, muchas de las típicas están bajo un estricto copyright que no permite su distribución indiscriminada a través de nuestra página web.

Por ejemplo, supongamos que soy un enamorado de la fuente Helvética (después de haber visitado Arial versus Helvetica. How to tell them apart. Is Arial just a poor copy?, Helvetica vs. Arial o arial or helvetica? a quiz) y me la compro en Helvetica® Font Family – by Linotype Design Studio. La licencia de uso de la fuente me dice claramente que no puedo pasársela a un tercero y que si la incrusto en un documento tengo que asegurarme de que el receptor del documento no podrá usar la fuente de alguna forma para componer otros documentos, lo que no permitiría que yo mandara una fuente en un fichero .ttf así tal cual junto con la página web.

Fuentes .pfr de Netscape y .eot de Internet Explorer

Y es por eso que Netscape 4 incluyó soporte nativo de Portable Font Resource (PFR), una tecnología cerrada de la empresa Bitstream que permitía incluir la fuente junto con el documento web, pero la fuente sólo incluía un subconjunto de caracteres y además sólo se podía usar en la página web para la que se había creado (se verificaba que el dominio asociado a la fuente era desde el que se estaba sirviendo). Entre que no hay ni hubo ninguna herramienta libre/gratuita para generar estas fuentes .pfr y que era un formato propietario de Netscape 4 (ni siquiera las versiones posteriores, de código abierto, lo soportaban, aunque hubo intentos de que la tecnología de Bitstream se liberara y se incorporara en Mozilla: Bugzilla@Mozilla – Bug 59611 Add TrueDoc (or like) support to Mozilla, Bugzilla@Mozilla – Bug 41250 Auto download of fonts) es de entender que cayera completamente en desuso. La forma de usar los ficheros .pfr en Netscape era esta (Fuentes descargables):

<LINK REL="fontdef" SRC="ejemplo.pfr">
<FONT FACE="ejemplo">Texto</FONT>

Microsoft, por supuesto, como no podía ser de otra forma, sacó su propio formato de fuentes para incrustar en páginas web, el Embedded OpenType (EOT), soportado sólo por su Internet Explorer. Sin embargo, en contrate con las .pfr, las fuentes .eot sí que han tenido cierta relevancia. En primer lugar, porque todas las versiones de Internet Explorer, incluso las actuales, lo soportan, lo que supone un importante volumen de potenciales usuarios, y por otro, porque la herramienta para crear estas fuentes a partir de fuentes .ttf está disponible para descargar de forma gratuita: Web Embedding Fonts Tool (WEFT) . Además, la forma de usar estas fuentes está bien documentada (About Font Embedding) e incluso con llamativas demostraciones (Font Embedding for the Web).

Para usar estas fuentes .eot, lo que haríamos sería usar la regla @font-face en la hoja de estilos para especificar qué font-family estamos incorporando y dónde descargarla:

@font-face {
   font-family: "MyFont";
   src: url(FontSourceFile.eot);
}
h1 {
   font-family: "Verdana", "MyFont"
}

El proceso no es muy complicado. Instalamos el Microsoft Weft y un asistente nos va preguntando qué páginas conforman nuestro proyecto, en qué dominio/s vamos a mostrar la página, qué fuentes queremos usar y qué caracteres queremos incluir de cada fuente, aunque no podremos usar todas, ya que muchas tienen un copyright que el Weft respeta:

Microsoft Weft Wizard
Microsoft Weft - Subset Editor
Microsoft Weft

El Weft te crea la fuente .eot e incluso te modifica el fichero HTML con el código necesario para usar la nueva fuente:

<html>
  <head>
    <title>Prueba</title>
   
<STYLE TYPE="text/css">
<!-- /* $WEFT -- Created by: Vicente (vicente@example.com) on 03/04/2008 -- */
  @font-face {
    font-family: Old English Text MT;
    font-style:  normal;
    font-weight: 700;
    src: url(OLDENGL0.eot);
  }
-->
</STYLE>

</head>
  <body>
    <h1 style="font-family: 'Old English Text MT';">Texto en "Old English Text"</h1>
  </body>
</html>

El resultado, el esperado, pero que sólo funciona en Internet Explorer, claro:

Ejemplo uso fuentes .eot en Windows

Nota: Para esta prueba he desinstalado la fuente “Old English Text MT” de Windows.

Hacia la estandarización de las Web Fonts en CSS

Bueno, y ahora que Microsoft supuestamente se ha decidido a “apoyar” los estándares web de verdad, que el Internet Explorer 8 va a salir con el “super-duper standards mode” habilitado por defecto, y que todos somos amiguitos y todos estamos a favor de los estándares en la Web, ¿no se ha llegado a ningún acuerdo para distribuir fuentes por la web de una forma estandarizada y soportada por todos los navegadores?

Pues resulta que sí, y desde 1998. La especificación CSS 2.0, en la sección: 15.3.1 Font Descriptions and @font-face incorporaba la regla @font-face tal cual Microsoft la había introducido para dar soporte a sus fuentes .eot en Internet Explorer. Así, en la propia especificación de CSS 2.0, nos encontramos con el siguiente ejemplo, un calco de lo que hacíamos unas líneas más arriba:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
  <HEAD>
    <TITLE>Font test</TITLE>
    <STYLE TYPE="text/css" MEDIA="screen, print">
      @font-face {
        font-family: "Robson Celtic";
        src: url("http://site/fonts/rob-celt")
      }
      H1 { font-family: "Robson Celtic", serif }
    </STYLE>
  </HEAD>
  <BODY>
    <H1> This heading is displayed using Robson Celtic</H1>
  </BODY>
</HTML>

Además, especifica los diferentes tipos de fuentes que se pueden usar, algo que, evidentemente, Internet Explorer no necesitaba, puesto que sólo soportaba un tipo de fuente:

String Font Format Examples of common extensions
“truedoc-pfr” TrueDoc™ Portable Font Resource .pfr
“embedded-opentype” Embedded OpenType .eot
“type-1″ PostScript™ Type 1 .pfb, .pfa
“truetype” TrueType .ttf
“opentype” OpenType, including TrueType Open .ttf
“truetype-gx” TrueType with GX extensions
“speedo” Speedo
“intellifont” Intellifont

Estas cadenas para especificar el tipo de fuente se usan en el parámetro format del descriptor src:

@font-face {
   font-family: "Robson Celtic";
   src: url("http://site/fonts/rob-celt.ttf") format("truetype");
}

Sin embargo, en la especificación CSS 2.1, sección: 15 Fonts, esta regla ¡ya no está! Además, en el apéndice C de cambios respecto a la versión anterior, sección: C.2.96 Chapter 15 Fonts encontramos:

C.2.96 Chapter 15 Fonts

The ‘font-stretch’ and ‘font-size-adjust’ properties have been removed in CSS 2.1.

Font descriptors, the ‘@font-face’ declaration, and all associated parts of the font matching algorithm have been removed in CSS 2.1.

¿Por qué el W3C eliminaría una propiedad tan útil de CSS 2.1? Pues en el abstract del documento ya nos dan una pista:

CSS 2.1 corrects a few errors in CSS2 (the most important being a new definition of the height/width of absolutely positioned elements, more influence for HTML’s “style” attribute and a new calculation of the ‘clip’ property), and adds a few highly requested features which have already been widely implemented. But most of all CSS 2.1 represents a “snapshot” of CSS usage: it consists of all CSS features that are implemented interoperably at the date of publication of the Recommendation.

Y en la sección: 1.1 CSS 2.1 vs CSS 2 aún nos lo deja más claro:

Removing CSS2 features which, by virtue of not having been implemented, have been rejected by the CSS community. CSS 2.1 aims to reflect what CSS features are reasonably widely implemented for HTML and XML languages in general (rather than only for a particular XML language, or only for HTML).

El artículo de la Wikipedia sobre CSS también lo explica:

Problems with browsers’ patchy adoption of CSS along with errata in the original specification led the W3C to revise the CSS2 standard into CSS2.1, which may be regarded as something nearer to a working snapshot of current CSS support in HTML browsers. Some CSS2 properties which no browser had successfully implemented were dropped, and in a few cases, defined behaviours were changed to bring the standard into line with the predominant existing implementations.

Es decir, que como la regla @font-face no estaba bien soportada por los navegadores, decidieron quitarla de la especificación y dejarla para CSS 3.

CSS 3 está siendo desarrollado de forma modular, tal y como vemos en CSS: Current Work. Con esta forma de trabajo pueden ir finalizando módulos más importantes y dejando para más tarde módulos menos prioritarios, de forma que se puedan ir cerrando partes de la especificación para que los desarrolladores de los navegadores las puedan ir implementando sin tener que esperar a que se finalice la especificación completa. Pues bien, en la especificación CSS 3, el tema que estamos tratando, las Web Fonts, ha merecido un módulo completo: CSS3 module: Web Fonts.

Suporte en los navegadores actuales de Web Fonts y @font-face

Entonces, ¿con qué navegadores podemos disfrutar de esta utilísima característica?

En la entrada de la Wikipedia Comparison of layout engines (CSS) podemos consultar el nivel de soporte de CSS de los diferentes motores de renderizado de los navegadore (Internet Explorer, Gecko, WebKit, KHTML, Opera, etc.) y vemos que @font-face está soportado por Internet Explorer sólo para fuentes .eot y en WebKit (el motor de Safari, un fork del KHTML del Konqueror) desde hace unos meses (Downloadable Fonts – WebKit, también en anieto2k: Fuentes descargables en Webkit y @font-face).

Efectivamente, si instalamos el Safari 3.1 para Windows, veremos que la siguiente página, básicamente igual que la anterior que hemos usado para Internet Explorer pero cambiando la referencia a la fuente .eot por una a la fuente .ttf, que dejamos en el mismo directorio, se muestra con la fuente esperada, aunque la fuente no esté instalada en Windows:

<html>
  <head>
    <title>Prueba</title>

<style type="text/css">
  @font-face {
    font-family: Old English Text MT;
    src: url(OLDENGL.TTF);
  }
</style>

</head>
  <body>
    <h1 style="font-family: 'Old English Text MT';">Texto en "Old English Text"</h1>
  </body>
</html>
Web Fonts en Safari

Nota: Para esta prueba he desinstalado la fuente “Old English Text MT” de Windows.

Desafortunadamente, parece que Firefox 3 todavía no va a soportar las Web Fonts, viendo la Beta 5:

Web Fonts en Firefox 3

y eso que Bugzilla@Mozilla – Bug 70132 Support @font-face lleva abierto desde el año 2001.

Opera 9.50 Beta Build 9864 tampoco es capaz de mostrar Web Fonts todavía:

Web Fonts en Opera 9.50 Beta

sIFR, la alternativa más curiosa que práctica

Mientras los navegadores van incorporando soporte de Web Fonts, el Scalable Inman Flash Replacement (sIFR) puede ser una alternativa en ciertos casos muy concretos. Lo descubrí leyendo Official Google Webmaster Central Blog: Best uses of Flash, una entrada en la que el ingeniero de Google explica que, por motivos obvios, los buscadores apenas puede extraer algunas palabras clave o algunos enlaces de los contenidos en Flash, y no todos los buscadores, que algunos ignoran los contenidos en Flash totalmente. Por eso, el Flash debe restringirse a aquellos sitios donde su uso tenga más sentido que una página en HTML estándar, como animaciones, contenidos interactivos o películas. Y como ejemplo de un uso adecuado de Flash de cara a los buscadores, la entrada habla del sIFR.

¿Qué es sIFR? A grandes rasgos, es un objeto Flash, un fichero .swf que sólo incluye la fuente que queremos usar empotrada en el fichero y una colección de funciones en JavaScript que permiten cargar ese mismo fichero .swf con un texto diferente cada vez reemplazando ciertas partes del código HTML. Como el código HTML sigue estando ahí, esta técnica no supone ningún problema para los robots de los buscadores ni para aquellos que no tengan Flash instalado o que tengan JavaScript deshabilitado en sus navegadores. Además, el texto de estos objetos Flash se puede seleccionar y copiar, con lo que no limita de ninguna forma la accesibilidad de la página.

La página de entrada para comenzar a trabajar con sIFR es sIFR 2.0: Rich Accessible Typography for the Masses, y podemos ver cómo funciona en la página de demostración de sIFR 2.0. Un buen tutorial de sIFR en castellano es Diseñorama: Manual sIFR, paso a paso.

El siguiente cuadro es un iFrame que carga un pequeño ejemplo de sIFR que he preparado. Podemos ver que cuando el sIFR está habilitado, el texto usa la fuente VandenKeere, y cuando lo deshabilitamos, usa la fuente por defecto del navegador:

Si nos fijamos en el código del ejemplo, vemos que para que esto funcione, tenemos que cargar los ficheros CSS y los JavaScript de sIFR (el sifr-addons.js es opcional):

<link rel="stylesheet" href="sIFR-screen.css" type="text/css" media="screen" />
<link rel="stylesheet" href="sIFR-print.css" type="text/css" media="print" />
<script src="sifr.js" type="text/javascript"></script>
<script src="sifr-addons.js" type="text/javascript"></script>

El texto al que le queremos cambiar la fuente es este:

<h1 class="ejemplosifr" style="font-size: 36px">Prueba de texto con sIFR</h1>

y para hacerlo, sólo tenemos que especificar, con la función JavaScript sIFR.replaceElement qué elementos (seleccionados por medio de los selectores CSS) reemplazar con qué objetos Flash:

<script type="text/javascript">
//<![CDATA[

if(typeof sIFR == "function"){

        sIFR.replaceElement(named({sSelector:".ejemplosifr", sFlashSrc:"vandenkeere.swf"}));

};

//]]>
</script>

El objeto Flash vandenkeere.swf en este caso lo he cogido del ejemplo de sIFR, pero podemos integrar la fuente que nosotros queramos en un objeto Flash con el Flash Professional (necesita licencia) o también podemos usar el sIFR Font Embedder (para Windows).

Las desventajas de sIFR no son despreciables:

  • Sólo es apropiado para cabeceras y títulos, no para grandes párrafos de texto.
  • Es pesado en términos de carga y en términos de procesamiento.
  • Necesita una herramienta para empotrar la fuente deseada en el objeto Flash.
  • Necesita que el navegador tenga JavaSript y el plugin de Flash, ¡sólo para mostrar texto!.

Pero al mismo tiempo puede proporcionar a los títulos un aspecto diferente y más atractivo que el que dan las típicas fuentes a las que ya estamos tan acostumbrados sin tener que crear las típicas imágenes con texto que se tanto se usan en el diseño web. El portal Diseñorama es un buen ejemplo de uso de sIFR para conseguir un aspecto original en los títulos sin tener que recurrir a la creación de imágenes.

Conclusión

El artículo de “A List Apart” CSS @ Ten: The Next Big Thing trata de las Web Fonts. Se publicó en agosto de 2007, cuando Safari aún no soportaba Web Fonts, así que el autor se centra en Prince como ejemplo de un motor de renderizado que soporta Web Fonts. Prince es un programa para generar ficheros PDF a partir de documentos HTML/CSS. El autor, del consejo de dirección de la empresa que desarrolla Prince, nos muestra con su producto la espectacularidad que podrían tener las páginas si el uso de Web Fonts se estandarizara.

Pero al mismo tiempo nos advierte de los problemas de las Web Fonts:

Uno de ellos es el respeto al copyright de las fuentes. Aunque hay muchas fuentes free, también hay muchas otras que no se pueden redistribuir, pero no hace falta ser un vidente para darse cuenta de que cuando esta tecnología esté disponible en Internet Explorer y en Firefox y los desarrolladores comiencen a usarla, habrá muchos desarrolladores de páginas web que no se pararán a pensar si tienen derecho a proporcionar esa fuente .ttf que tienen en el disco duro sin violar los legítimos derechos de sus autores. ¿Tú pondrías un fichero MP3 de un artista conocido en tu página web? No, ¿verdad? Porque sabes que esa música no se puede redistribuir libremente. Pues en el futuro tendremos que tener la misma concienciación con las fuentes que incluimos en nuestra página web.

Y el otro es “el mal gusto”. Hubo una época en la que los diseñadores de páginas web ponían texto parpadeante en las páginas, así como GIFs animados por todos sitios. La libertad total de elección de fuentes podría traernos páginas asesinas para nuestros ojos, pero es algo que también puede ocurrir ahora y sin necesidad de las Web Fonts y, en cualquier caso, en los navegadores modernos suele ser frecuente que podamos reemplazar las fuentes que haya elegido el diseñador de la página con las que nosotros queremas.

Sea como sea, bienvenidas sean las Web Fonts y esperemos verlas pronto soportadas en Internet Explorer, Firefox, Konqueror y Opera. Por cierto, el test Acid3 hace uso de Web Fonts:

@font-face { font-family: "AcidAhemTest"; src: url(font.ttf); }

y como últimamente parece que hay una cierta competición por parte de los navegadores por conseguir superar este test (anieto2k: Opera supera el Acid3, anieto2k: WebKit pasa el Acid3, Firefox Bug 410460 (acid3) – Acid3 tracking bug), a ver si esto trae definitivamente un soporte uniforme de @font-face por parte de todos los navegadores.

Respecto a Opera, la última versión disponible para descargar, la 9.27 (o incluso la 9.50 Beta Build 9864), sigue sin soportar las Web Fonts. La versión que pasa el test Acid3 y que necesariamente ha de soportar Web Fonts es una versión interna de desarrollo.

Actualización 22/7/08:

Leo en el blog de IE que ha propuesto el EOT como estándar abierto a la W3C para que otros navegadores lo implementen y así, además de que los usuarios podamos tener una mayor variedad de fuentes en páginas web, los creadores de fuentes con copyright verán sus derechos protegidos al no tener que poner fuentes completas disponibles para descarga en el servidor web: Font Embedding on the Web.

Actualización 28/1/10: anieto2k: CSS3 @font-face, una visión general

Actualización 24/5/10: Google Font API
:wq

PD: Entrada dedicada a Oink!, con el que tuve mi primer contacto con las Web Fonts hace ya tantos años…

Entradas relacionadas

12 Comentarios a “Web Fonts, fuentes descargables para la web”

  • Osk dice:

    ¡Qué grande!
    ¡Éste es un tema de los que siempre he tenido unas dudas tremendas a la hora de utilizar CSS, y no he encontrado un sitio que explicara las cosas de forma sencilla: siempre dando tumbos! Y me da mucha rabia porque esto de las fuentes me parece un asunto tan evidente que no entiendo por qué resulta tan complicado poner de acuerdo a todo el mundo con un sistema universal. Al menos parece que la cosa va avanzando.
    Este post parece escrito para mí. Aclara muchas cosas.
    ¡Muchas gracias!

  • Raist dice:

    Como todos tus articulos , interesantisimo , y a demas me va como anillo al dedo para remodelar una pagina que tengo pendiente . Una lastima leer que esto no entre aun en firefox 3 . Un saludo !

  • @Osk, @Raist ¡Me alegro mucho de que os haya gustado!

  • Oink! dice:

    ¡Grandioso artículo, Supercoco! :-) Es una pena ver que las cosas siguen más o menos igual que en 2003 cuando nos pusimos a mirar este tema por primera vez. Parece que han avanzado un poco (por lo menos te has encontrado con bastante más información que entonces, que ya es un gran paso) y parece que al final todos los navegadores darán soporte para ttf (si no recuerdo mal, por el tema de los derechos de autor, pretendían que las fuentes viniesen firmadas con un certificado digital, con lo que el ttf se quedaba fuera…).

    Es una lástima que no esté ya soportado. Estamos justo en el momento preciso. Ahora va a llegar la nueva ola de navegadores web (Internet Explorer 8 y Firefox 3, principalmente). Llevamos años sufriendo al infame Internet Explorer 6 como el navegador más usado, y parece que justo ahora se están cambiando esos porcentajes hacia navegadores más avanzados. Se espera que los usuarios cambien masivamente a Firefox 3 e Internet Explorer 8 (este último, como siempre, favorecido por un nuevo OS de MS que viene instalado por defecto en la mayoría de los ordenadores personales vendidos) pero parece que esta tecnología no estará lista todavía y perderemos ese tren hasta el próximo gran cambio de versioes :-(

  • @Oink! ¡Gracias! ¡Me alegra de que te haya gustado!

    Sí, estamos casi igual que hace tantos años. Afortunadamente, últimamente, con eso de pasar el Acid3, y como el Acid3 incluye el @font-face, parece que ya hay más interés por este tema por parte de los navegadores, sobre todo de Safari y de Opera. La lástima es el Firefox 3 que parece que aún va muy atrasado. ¡Tendremos que esperar al Firefox 4 y al IE9 por lo menos para que las Web Fonts se comiencen a usar de forma generalizada!.

    ¡Gracias por tu comentario!

  • Aladejur dice:

    “Un ejemplo típico de uso de esta propiedad sería:

    body { font-family: Verdana, Arial, sans-serif }

    Pero como normalmente no podremos saber seguro de antemano (a menos que estemos desarrollando una página para un entorno corporativo controlado o, por ejemplo, para un kiosko) que el usuario va a tener las fuentes que queremos usar, nunca podremos saber seguro la apariencia que van a tener los textos de nuestra página en otros sistemas.”

    Éso de que no podremos saber si el usuario dispone de esas fuentes… si un 90% de los usuarios de ordenador utilizan Windows, sabemos que “casi” todo Dios va a interpretar correctamente lo que hagamos. ¿Linux?, pues nada, que se instalen las corefonts, ¿no?

  • @Aladejur Bueno, las “MS Core Fonts” normalmente las tendrán incluso los usuarios de Linux que también suelen tenerlas instaladas. Sólo pretendía ser un ejemplo de que no podemos salir de ese subconjunto de fuentes que trae por defecto Windows en el desarrollo de páginas web si no queremos arriesgarnos a que en la mayoría de los casos la fuente no esté instalada. E incluso a veces nos encontraremos con que el visitante no tiene ni siquiera ese subconjunto de fuentes, y ahí es donde las Web Fonts se hacen necesarias.

    Las Web Fonts, caso de implementarse en todos los navegadores, nos permitirían usar cualquier fuente siempre que tuviéramos licencia para su redistribución.

  • Tostadilla dice:

    Grande Super Coco, como siempre. Casi diria que tus entradas son las mejor documentadas que he visto en la blogosfera.

    Por cierto, lo que el Seamonkey hace con el pobre Acid 3 debe ser ilegal.

  • Tostadilla dice:

    Jar, no he llegado a tiempo de modificar el comentario XD. Comentar que en la ultima beta de Firefox (la 5) mejoraron mucho el ACID 3. Parece que los caballos de batalla de los navegadores en esta guerra son los estandares, la velocidad y los recursos. Lo cual está de puta madre, la verdad. Aunque es una pena que el prometido OpenId parece que se queda fuera. :P. Con lo que prometia para no tener que estar registrandote en mil webs…

  • @Tostadilla Sí, debe de serlo ;-) . Respecto a los estándares, es una excelente noticia que se compita para cumplirlos. La mala noticia es que mientras Internet Explorer no los cumpla (aunque el IE8 lo hiciera aún tardaría años y años en extenderse), los desarrolladores no podrán crear webs usando dichos estándares :-( .

  • Guaje dice:

    ¿Sabeis cómo cambiar el tamaño de letra de la ventana de descargas de Firefox 3?. Por defecto es demasiado grande.

Trackbacks y pingbacks:

Tema LHYLE09, creado por Vicente Navarro