Catalina wprowadza do macOS nową czcionkę systemową o zmiennej szerokości.
Sekcja „system-ui” specyfikacji modułu CSS Fonts na poziomie 4 definiuje słowo kluczowe czcionki system-ui, które umożliwia programistom używanie wbudowanej, zoptymalizowanej pod kątem turbo, zlokalizowanej, megawysokiej jakości i niewymagającej pobierania, domyślnej czcionki systemu operacyjnego bezpośrednio w swoich witrynach i aplikacjach.
body {
font-family: system-ui;
}
Opcja typograficzna jest podobna do polecenia „użyj domyślnej czcionki systemowej dla bieżącego języka użytkownika”.
W systemie macOS czcionka system-ui to San Francisco, która została sprawdzona, przetestowana i niedawno zaktualizowana przez zespół projektantów. Najpierw omówimy nowe, ekscytujące funkcje czcionek w Catalinie, a potem kilka błędów i sposób ich usuwania przez inżynierów Chromium.
W tym wpisie zakładamy, że czcionki zmienne nie są Ci obce. Jeśli nie, zapoznaj się z artykułem Wprowadzenie do czcionek zmiennych w internecie i filmem poniżej.
Zgodność z przeglądarką
W chwili tworzenia tego tekstu usługa system-ui obsługiwała Chromium (od wersji 56), Edge (od wersji 79), Safari (od wersji 11) i Firefox (od wersji 43), ale ze słowem kluczowym -apple-system. Więcej informacji znajdziesz w artykule Czy mogę używać czcionek zmiennych?.
Nowe moce
Nowe możliwości, które font systemowy zyskał w wersji Catalina, są teraz dostępne dla deweloperów webowych od wersji Chromium 83. Czcionka system-ui ma teraz więcej ustawień zmiennych: optyczne dopasowanie rozmiaru i 2 ustawienia grubości:
h1 { font-family: system-ui; font-weight: 700; font-variation-settings: 'wght' 750 ; }
h1 { font-family: system-ui; font-weight: 700; font-variation-settings: 'wght' 750, 'opsz' 20, 'GRAD' 400, 'YAXS' 400 ; }
W Mojavie system-ui to czcionka zmienna z jedynie ustawieniami wght. Natomiast system-ui w wersji Catalina to czcionka zmienna z ustawieniami wght, opsz, GRAD i YAXS.
Wygląda na to, że mamy tu do czynienia z ciekawymi możliwościami udoskonalania progresywnego. Jeśli chcesz, możesz dokładnie przyjrzeć się subtelnym niuanseom czcionki systemowej.
wght
Akceptuje wagę czcionki w zakresie od 0 do 900 i jest stosowana w równym stopniu do wszystkich znaków.
/* 0-900 */
font-variation-settings: 'wght' 750;
opsz
Rozmiar optyczny jest podobny do kerningu lub odstępu między literami, ale odstępy są wykonywane ludzkim okiem, a nie za pomocą obliczeń matematycznych. Wartość 19 lub mniejsza jest przeznaczona do odstępów między tekstem a tekstem głównym, a wartość 20 lub większa do odstępów między nagłówkami i tytułami.
/* 19 or 20 */
font-variation-settings: 'opsz' 20;
GRAD
Podobnie jak waga, ale bez wpływu na odstępy poziome. Może mieć wartości od 400 do 1000.
/* 400-1000 */
font-variation-settings: 'GRAD' 500;
YAXS
Rozciąga glif w pionie. Akceptowane są wartości z zakresu od 400 do 1000.
/* 400-1000 */
font-variation-settings: 'YAXS' 500;
Łączenie opcji
Za pomocą kilku linii kodu CSS możemy zmienić ustawienia czcionki na pogrubienie lub wypróbować inne interesujące kombinacje:
font-weight: 700;
font-weight: bold;
font-variation-settings: 'wght' 750, 'YAXS' 600, 'GRAD' 500, 'opsz' 20;
I tak, użytkownicy Chromium na macOS widzą ulepszony, niestandardowy rozmiar 750 z kilkoma innymi fajnymi zmianami 👍
Plac zabaw
Kliknij Remiksuj, aby edytować w poniższej sytuacji, aby uzyskać edytowalną kopię błędu, a następnie zmodyfikuj nowe opcje font-variation-settings, aby sprawdzić, jak wpływają one na czcionkę. Pamiętaj, że ta Glitch działa tylko na urządzeniach z systemem macOS Catalina.
W systemie macOS 10.15 dodano nowe funkcje do czcionki systemowej, a w systemie macOS 10.15 zarejestrowano w systemie śledzenia błędów Chromium trudny do rozwiązania błąd system-ui. Ciekawe, czy są ze sobą powiązane.
Dodatek: regresja system-ui
Ta historia zaczyna się od innego błędu: #1005969. Problem zgłoszono w systemie macOS 10.15, ponieważ odstępy między znakami system-ui wyglądały na ciasne i zagęszczone.
Tło
Czy zauważyłeś/zauważyłaś, że w macOS 10.14 akapity lub nagłówki „przylegają” do czcionki o innym wyglądzie, gdy ich rozmiar się zwiększa lub zmniejsza?
W Mojave (macOS 10.14) czcionka system-ui przełączała się między 2 czcionkami w zależności od docelowego rozmiaru czcionki. Gdy tekst był poniżej 20px, system macOS używał tekstu „San Francisco Text”. Jeśli tekst miał wartość 20px lub wyższą, system macOS używał „Wyświetlacz w San Francisco”. Rozmiar czcionki został statycznie wbudowany w 2 osobne czcionki.
Catalina (macOS 10.15) zawiera nową czcionkę San Francisco z jednolitą zmienną. Nie musisz już zarządzać opcjami „Tekst” i „Wyświetlanie”. Dodano też nowe ustawienie wariantu opsz, o którym była mowa wcześniej.
h1 {
font-variation-settings: 'opsz' 20;
}
Domyślna wartość opsz w nowej czcionce Catalina to 20, a inżynierowie Chromium nie byli przygotowani do zastosowania wartości opsz do czcionki systemowej. W rezultacie mniejsze rozmiary były wyświetlane zbyt wąsko.
Aby to naprawić, Chromium musiało prawidłowo zastosować opsz do czcionki systemowej. Doprowadziło to do rozwiązania problemu 1005969. Zwycięstwo! A może…?
Nieukończone
Właśnie tu pojawił się problem: Chromium zastosowało opsz, ale coś nadal wyglądało nie tak. Czcionki systemowe na Macu mają dodatkową tabelę czcionek o nazwie trak, w której można dostosować odstępy w poziomie. Podczas pracy nad poprawką inżynierowie Chromium zauważyli, że w systemie macOS podczas pobierania danych poziomych z obiektu CTFontRef dane trak były już uwzględniane w wynikach. Biblioteka kształtowania Chromium HarfBuzz potrzebuje danych, w których wartości trak nie są jeszcze uwzględnione.
Wewnętrznie Skia (biblioteka graficzna, a nie czcionka o tej samej nazwie) używa zarówno klasy CGFontRef z CoreGraphics, jak i klasy CTFontRef z CoreText. Ze względu na wymagane wewnętrzne konwersje między tymi obiektami (używane do zachowania zgodności wstecznej i dostępu do potrzebnych interfejsów API w obu klasach) w pewnych okolicznościach Skia traciłaby informacje o wadze, a czcionki pogrubione przestaną działać. Ten problem został odnotowany w problemie 1057654.
System Skia nadal musi obsługiwać system macOS 10.11, ponieważ Chromium nadal go obsługuje. W wersji 10.11 czcionki „San Francisco Text” i „San Francisco Display” nie były nawet czcionkami zmiennymi. Każda z nich była raczej rodziną osobnych czcionek dla każdej dostępnej grubości. W pewnym momencie identyfikatory znaków nie były już ze sobą zsynchronizowane. Jeśli więc Skia wykonała kształtowanie tekstu (konwersję tekstu na glify, które można narysować) za pomocą czcionki „San Francisco Text”, tekst narysowany za pomocą czcionki „San Francisco Display” byłby niezrozumiały i na odwrót. Nawet jeśli Skia poprosi o inny rozmiar, macOS może przełączyć się na inny. Powinna istnieć możliwość używania zawsze jednego z fontów i jego skalowania (za pomocą macierzy zamiast prośby o większy rozmiar), ale CoreText ma problem z nieskalowaniem glif sbix (kolorowe emotikony) w górę (tylko w dół). To trochę bardziej skomplikowane. CoreText wydaje się ograniczać pionowy zasięg po zastosowaniu macierzy, co wydaje się być związane z brakiem możliwości rysowania emotikonów pod kątem 45 stopni. Jeśli chcesz, aby emotikony były wyświetlane w dużej wersji, musisz utworzyć kopię czcionki.
Aby tworzyć kopie obiektów CTFont o różnych rozmiarach, zachowując jednocześnie te same dane czcionki, Chromium wyodrębnia CGFont z CTFont, a potem tworzy nowy obiekt CTFont z obiektu CGFont (obiekty CGFont są niezależne od rozmiaru, magiczne przełączanie odbywa się na poziomie CoreText). Do wersji 10.154 wszystko działało dobrze. W 10.15 ta podróż powrotna straciła zbyt wiele informacji, co spowodowało problem z wagą. Flutter wykrył problem z wagą i wprowadzono alternatywną poprawkę zmiany rozmiaru, aby utworzyć nowy CTFont bezpośrednio z pierwotnego CTFont, jednocześnie kontrolując rozmiar optyczny bezpośrednio za pomocą starego, ale nieudokumentowanego atrybutu w usłudze CoreText. Dzięki temu wszystko będzie działać w wersji 10.11 i rozwiązane zostaną inne problemy (np. wyraźne ustawienie rozmiaru optycznego na wartość domyślną).
Dzięki temu zachowasz więcej „magii” CoreText czcionki. Wydaje się, że jedną z tych sytuacji jest to, że nadal modyfikuje postępy glifu w inny sposób niż tylko w tabeli trak (aplikacja, której Chromium próbowała już ukryć za pomocą kolejnego nieudokumentowanego atrybutu).
CGFont nie wykazuje się tym „magią”, więc być może Chromium mógłby(-a) zmniejszyć CGFont podczas CTFont i wykorzystać je, by poprawić wyniki? Niestety to nie zadziała, ponieważ CoreText może też w inny sposób zmieniać czcionki. Na przykład powoduje, że małe emotikony są nieco większe niż w Twoim żądaniu (trochę je powiększa). CGFont nie wie o tym, dlatego emotikon w kształcie sbix pojawiłby się zbyt blisko siebie, ponieważ można by mierzyć w jednym rozmiarze, a CoreText nieco je powiększyło. Chromium chce korzystać z ulepszeń CTFont, ale bez śledzenia i najlepiej bez żadnych innych zmian.
Ponieważ rozwiązanie problemu z odstępami wymagało wprowadzenia zestawu połączonych ze sobą poprawek Blink i Skia, inżynierowie Chromium nie mogli „tylko cofnąć” zmian, aby rozwiązać problem. Inżynierowie z zespołu Chromium próbowali też użyć innej flagi kompilacji, aby zmienić ścieżkę kodu związaną z czcionką w Skia. Rozwiązało to problem z pogrubionymi czcionkami, ale spowodowało regres w sprawie odstępów.
Rozwiązanie
Ostatecznie Chromium chciało naprawić oba te problemy. Chromium używa teraz wbudowanych funkcji HarfBuzz do pobierania danych dotyczących czcionek OpenType, aby pobierać dane poziome bezpośrednio z danych binarnych w tablicach czcionek czcionki systemowej. W tym przypadku Chromium pomija CoreText i Skia, gdy czcionka ma tabelę trak (z wyjątkiem czcionki z emotikonami).
Tymczasem jest jeszcze problem nr 10123 firmy Skia, który należy śledzić w całości w Skia. Aby pobrać z niego dane czcionek systemowych w aplikacji Skia, zamiast obecnego rozwiązania, które wprowadza HarfBuzz, możesz skorzystać z tej metody.