Ten poradnik wyjaśnia bezpieczne ograniczanie zestawu glifów. Skupia się na działaniach, które można sprawdzić w pliku fontu i w rzeczywistym podglądzie, zamiast na samych nazwach formatów. Wszystkie przykłady można wykonać lokalnie w narzędziach font.podziel.pl.
Dlaczego ten temat ma znaczenie
Dobry rezultat typograficzny nie zależy wyłącznie od wyglądu liter. Trzeba uwzględnić format pliku, mapę znaków, metryki, funkcje OpenType, sposób ładowania w przeglądarce oraz warunki licencji. W praktyce pominięcie jednego z tych elementów prowadzi do brakujących liter, sztucznego pogrubienia, przesunięć układu albo niepotrzebnie ciężkiej strony.
Co sprawdzić przed rozpoczęciem
Zachowaj oryginalny plik jako kopię, zanotuj źródło i licencję oraz sprawdź pełną nazwę rodziny i stylu. Wczytaj font do analizatora, odczytaj typ konturów, liczbę glifów, rekordy name, tabelę OS/2 i listę tabel. Dzięki temu kolejne kroki wykonasz świadomie, bez zgadywania na podstawie rozszerzenia pliku.
Procedura krok po kroku
Najpierw wykonaj analizę źródła. Następnie przetestuj własny tekst, polskie znaki i kilka rozmiarów. Włącz funkcje typograficzne, których wymaga projekt. Jeżeli przygotowujesz webfont, zachowaj tylko potrzebne znaki przez HarfBuzz, wygeneruj WOFF2, utwórz regułę @font-face i sprawdź wynik w prawdziwej stronie demonstracyjnej.
- Wczytaj oryginał i zapisz raport JSON.
- Sprawdź mapę Unicode i potrzebne języki.
- Porównaj tekst z funkcjami OpenType włączonymi i wyłączonymi.
- Wykonaj konwersję lub subset dopiero po potwierdzeniu praw.
- Otwórz plik wynikowy ponownie i użyj strony demo.
Jak ocenić wynik
Nie ograniczaj kontroli do informacji, że plik dał się pobrać. Otwórz wynik ponownie, porównaj liczbę glifów i podstawowe metryki, sprawdź tekst próbny oraz wybrane funkcje OpenType. Przy subsettingu szczególnie ważne są znaki łączone, ligatury, spacja, interpunkcja i glify dostępne tylko przez podstawienia.
Najczęstsze błędy
Do typowych błędów należą: konwersja fontu bez sprawdzenia licencji, zmiana typu konturów, pominięcie polskich znaków, wpisanie złej wartości font-weight, publikowanie wszystkich wag rodziny oraz preload każdego pliku. Problemem jest także systemowy fallback, który może ukryć brakujący znak podczas zwykłego podglądu.
Praktyczna lista kontrolna
Przed wdrożeniem potwierdź: poprawną nazwę rodziny, zgodność stylu i wagi, pełny potrzebny zestaw znaków, prawidłowe WOFF2, działanie bez fallbacku, rozsądny rozmiar, odpowiednie font-display, poprawne nagłówki MIME i CORS oraz zgodność użycia z licencją.
Przykład związany z tematem
W przypadku zagadnienia „Czym jest subset fontu” zacznij od jednego reprezentatywnego fontu i krótkiego tekstu zawierającego litery, cyfry, interpunkcję oraz element charakterystyczny dla projektu. Zapisz rozmiar źródła i wynik testu, a następnie zmieniaj tylko jeden parametr naraz. Taka metoda pozwala rozpoznać, czy różnica wynika z kompresji, zestawu znaków, funkcji OpenType czy ustawienia CSS.
Jeżeli wynik ma trafić na stronę, wykonaj test w nagłówku, akapicie, przycisku oraz tabeli. Font może dobrze wyglądać w dużym tytule, a jednocześnie mieć zbyt małą wysokość x lub zbyt duży line gap dla długiego tekstu. Sprawdź także polskie znaki bez fallbacku i porównaj szerokość tekstu z fontem zastępczym.
Jak interpretować wynik w praktyce
Wynik dotyczący „Czym jest subset fontu” trzeba zawsze odnieść do konkretnego miejsca użycia. Sama obecność tabeli, glifu albo deklaracji nie oznacza jeszcze, że font będzie działał identycznie w każdej przeglądarce i aplikacji. Porównaj co najmniej dwa rozmiary tekstu, zwykłą i pogrubioną odmianę oraz tekst z polskimi znakami. W projekcie internetowym sprawdź również zachowanie przed i po załadowaniu webfontu. Zwróć uwagę na zmianę szerokości wierszy, wysokość linii i możliwość pojawienia się zastępczego kroju.
Parametry techniczne należy czytać łącznie. Mały plik nie jest zaletą, jeśli zabrakło znaków, ligatur albo potrzebnych odmian. Z kolei duża liczba glifów nie oznacza automatycznie pełnej obsługi języka, ponieważ znaczenie mają także mapowanie Unicode, pozycjonowanie znaków i reguły podstawień. Dlatego raport powinien prowadzić do testu renderowania, a nie zastępować go.
Test przed wdrożeniem produkcyjnym
Przygotuj prostą stronę demonstracyjną działającą bez frameworka. Umieść na niej tytuł, dwa akapity, przycisk, ceny, daty, tabelę oraz tekst zawierający polskie znaki. Otwórz ją w Chrome, Firefoxie i Safari lub ich odpowiednikach mobilnych. Sprawdź konsolę, kartę sieciową, nagłówki MIME i reguły CORS. Wyłącz pamięć podręczną, aby zobaczyć pierwszy render, a następnie włącz ją ponownie i oceń kolejne wejście.
Dla tematu „Czym jest subset fontu” zapisz wynik testu razem z nazwą rodziny, wersją fontu, sumą SHA-256 oraz zastosowanym CSS. Dzięki temu późniejsza aktualizacja pliku nie zostanie pomylona z wcześniejszą wersją. W środowisku produkcyjnym kontroluj również licencję, ponieważ możliwość technicznej konwersji lub osadzenia nie jest równoznaczna z prawem do publikacji.
Kiedy zachować plik źródłowy bez zmian
Nie modyfikuj fontu tylko dlatego, że narzędzie udostępnia taką możliwość. Jeśli licencja nie zezwala na konwersję, subsetting lub redystrybucję, użyj plików dostarczonych przez właściciela. Zachowaj oryginał również wtedy, gdy projekt trafia do druku, archiwum albo wielu aplikacji o różnych wymaganiach. Wersję zoptymalizowaną dla strony traktuj jako osobny artefakt wdrożeniowy, a nie zamiennik pliku źródłowego.
Dokumentowanie decyzji i późniejsza aktualizacja
Do wdrożenia dołącz krótką notatkę opisującą źródło fontu, jego wersję, licencję, wybrane zakresy znaków, formaty wynikowe i reguły CSS. Zapisz także datę przygotowania paczki oraz sumy kontrolne plików. Taka dokumentacja jest szczególnie ważna, gdy kilka osób pracuje nad stroną albo rodzina fontów jest później aktualizowana. Po każdej zmianie powtórz kontrolę znaków, test funkcji OpenType i pomiar zachowania układu. Nie zakładaj, że nowa wersja ma identyczne metryki, nazwy wewnętrzne lub zestaw glifów. Powtarzalny raport pozwala szybko wykryć zmianę, odtworzyć wcześniejszą paczkę i uniknąć przypadkowego opublikowania niewłaściwego pliku.
Wnioski
Najbezpieczniejszy proces jest powtarzalny: analiza źródła, kontrolowany podgląd, modyfikacja lokalna, ponowna walidacja i test wdrożeniowy. Pozwala to ograniczyć rozmiar pliku bez przypadkowego usuwania potrzebnych danych.