Każdy z nas zapewne niejednokrotnie otrzymał od klienta / grafika projekt strony w którym zastosowano czcionki z poza grupy tzw. "web safe". Czcionki "web safe" to takie, co do których mamy pewność, że posiada je u siebie odwiedzający i wyświetlą się one poprawnie - najczęściej jest to Arial, Verdana czy Tahoma. Zwykle w przypadku kiedy konieczne było zastosowanie jakiejś "nietypowej" czcionki aby mieć pewność, że będzie ona wyglądać poprawnie wstawialiśmy obrazki.

Początek rewolucji

Mimo, że większość przeglądarek (w tym nawet archaiczne IE6) pozwalało w ten czy inny sposób używać czcionek zdefiniowanych przez programistę nie było to ani proste ani skuteczne. Jako pierwszy problem pozwolił nieco zniwelować skrypt zwany sIFR (ang. Scalable Inman Flash Replacement). Jak można się domyśleć po nazwie - było to rozwiązanie oparte na technologii Flash. Za pomocą kilku magicznych linijek nasz tekst zamieniany był na elementy Flash i wyświetlany zdefiniowanym przez nas krojem tekstu. Minusem rozwiązania było oczywiście poleganie na Flash, ale bardziej przeszkadzał efekt "podmiany" tekstu na element Flash, który dało się zauważyć gołym okiem. Ten sam problem dotykał także kolejnego rozwiązania - Cufón. Tym razem zamiast generować pliki SWF skrypt generował dane w postaci ścieżek wektorów i wyświetlał tekst jako <canvas> lub VML (ang. Vector Markup Language) (dla przeglądarek IE). Poza wspomnianym wcześniej problemem ze "Wskakiwaniem" nowej czcionki Cufón posiada inne ograniczenia (tj. brak poprawnej obsługi text-align czy text-decoration).

Nadejście (użytecznego) @font-face

Z biegiem czasu oraz coraz lepszą implementacją standardów rzeczy zaczęły się zmieniać. Coraz więcej osób zaczęło dostrzegać możliwości i potencjał jakie niesie ze sobą @font-face Za pomocą tego elementu CSS możemy w "prosty sposób" definiować własne czcionki:

@font-face {
        font-family: Delicious;
        font-weight: bold;
        src: url('http://example.com/Delicious-Bold.ttf');
}

b.delic {
	font-family: 'Delicious';
}

I już - jeżeli nasza przeglądarka obsługuje @font-face wskazany tekst zostanie wyrenderowany pogrubioną wersją czcionki 'Delicious'. Oczywiście nic w naszym życiu nie jest aż tak proste. Powyższy kod zadziała tylko dla przeglądarek obsługujących standard TrueType (.ttf). Żeby mieć pewność, że tekst wyświetli się poprawnie pod IE, Firefox, Opera, Chrome ... i to jeszcze w każdej "w miarę" popularnej wersji musimy zastosować format odpowiedni dla każdej z tych przeglądarek:

@font-face {
        font-family: Delicious;
        font-weight: bold;
        src: url('http://example.com/Delicious-Bold.eot'); /* IE9 w trybie kompatybilności */
	src: url('http://example.com/Delicious-Bold.eot?#iefix') format('embedded-opentype'), /* IE6-8 */
		url('http://example.com/Delicious-Bold.woff') format('woff'), /* Nowoczesne przeglądarki */
		url('http://example.com/Delicious-Bold.ttf') format('truetype'), /* Przeglądarki oparte na Webkit */
		url('http://example.com/Delicious-Bold.svg#EASSansRegular') format('svg'); /* Starse wersje iOS */

}

Tak przygotowany kod wymaga oczywiście wygenerowania czcionek w każdym z tych formatów. Z pomocą przychodzi nam tu doskonały serwis Font Squirrel. W serwisie tym znajdziemy setki czcionek gotowych do pobrania i użycia na naszej stronie. Domyślnie każda czcionka dostępna jest w standardzie TTF, EOT, SVG i WOFF. Dodatkowo, za pomocą generatora możemy wygenerować paczkę dla naszej wyjątkowej czcionki. W takim wypadku należy jednak upewnić się, że zezwala na to licencja na jakiej rozpowszechniana jest dana czcionka (pamiętaj - jeżeli nie chcesz być stratnym, nigdy ślepo nie akceptuj czcionki od klienta, a i grafik nie zawsze musi wiedzieć, czego używa).

Alternatywą dla generowania czcionek jest skorzystanie z platformy udostępniającej gotowe czcionki w odpowiednim formacie. Najpopularniejszą z których jest Google Web Fonts. W przypadku tej usługi dobieranie i wysyłanie odpowiedniego formatu czcionki leży po stronie Google - my ograniczamy się do dodania jednej linijki HTML:

	<link href='http://fonts.googleapis.com/css?family=Enriqueta' rel='stylesheet' type='text/css'>

I już możemy w naszym CSS użyć zapisu font-fmily: 'Enriqueta; by wyświetlić tekst odpowiednim krojem. Zaletą Google Web Font jest niewątliwie przekazanie obowiązku serwowania czcionki na serwery CDN firmy Google, co skutkuje zwiększeniem prędkości ładowania strony i zmniejszeniem transferu. Minusem jest niewątpliwie niewielki wybór czcionek, który zmniejsza się jeszcze bardziej gdy zależy nam na czcionce posiadającej polskie znaki diakrytyczne.

Czy @font-face jest rozwiązaniem doskonałym?

Chociaż @font-face może wydawać się idealnym sposobem na zakończenie zabawy w wyświetlanie tekstu jako grafiki na skutek kilku szczegółów nie jest nim (a przynajmniej nie dziś). Do minusów @font-face zaliczyć można na pewno:

• niejednolite renderowanie tekstu w różnych przeglądarkach, systemach operacyjnych - czcionka może być renderowana z odpowiednim wygładzeniem krawędzi i nie mamy na to większego wpływu
• zablokowana obsługa pobierania i wyświetlania czcionek w przeglądarce użytkownika
• brak obsługi kerningu (odległości pomiędzy poszczególnymi glifami - letter-spacing zmienia odległości pomiędzy każdym ze znaków, kerning pozwala na ustalenie jej dla pojedynczego znaku w tekście)
• konieczność generowania odpowiednich plików czcionki dla:
  1. różnych przeglądarek
  2. różnych typów kroju (oddzielna dla zwykłego, oddzielna dla pogrubionego, kolejna dla tekstu pochylonego)

Kiedy więc najlepiej stosować @font-face? Wszędzie tam, gdzie tekst jest dynamiczny - w treści stron, pozycjach menu etc. Elementy, co do których mamy pewność, że nie będą zmieniane przez długi czas od umieszczenia na stronie (np. nagłówki sekcji) najlepiej wciąż umieszczać jako grafika.

Komentarze

2

Komentarz użytkownika BTM

16 12 2011

Dzięki za uwagi - na pewno wezmę je sobie do serca :)

Z serwisów oferujących generowanie/hostowanie wymieniłem tylko FS i GFA ponieważ tylko z tych 2 przyszło mi do tej pory korzystać, a skupiam się raczej na tym co sam przetestowałem i jestem w pełni gotów polecić.

3

Komentarz użytkownika trójkąt

16 12 2011

(Komentarz zmodyfikowany 17.12.2011 o 13:32)

Elementy, co do których mamy pewność, że nie będą zmieniane przez długi czas od umieszczenia na stronie (np. nagłówki sekcji) najlepiej wciąż umieszczać jako grafika.

Google daje też możliwość pobrania liter wybiórczo, co znacząco zmniejsza rozmiar czcionki:
http://code.google.com/apis/webfonts/docs/getting_started.html#OptimizingRequests

4

Komentarz użytkownika trójkąt

16 12 2011

PS. dałbyś info, że w komentarzach można stosować Markdown, to był chociaż link zrobił :-)

5

Komentarz użytkownika BTM

17 12 2011

@trójkąt: w cytowanym fragmencie chodziło mi raczej o to, że jeżeli zależy nam na pixel-perfect wyświetleniu elementu tak, jak zaplanował to grafik - wtedy lepiej zostać przy obrazkach.

Już nie powinno być markdown - niestety, dotyczy to tylko nowych komentarzy.