Więcej zmiennych opcji czcionek w interfejsie systemu macOS w Chromium 83

W systemie Catalina wprowadzono nową ujednoliconą czcionkę systemową o zmiennej szerokości.

Sekcja „system-ui” w specyfikacji modułu czcionek CSS na poziomie 4 definiuje system-ui słowo kluczowe czcionki, które umożliwia programistom używanie wbudowanej, zoptymalizowanej pod kątem szybkości, zlokalizowanej, bardzo wysokiej jakości, niewymagającej pobierania domyślnej czcionki systemu operacyjnego bezpośrednio w witrynach i aplikacjach.

body {
  font-family: system-ui;
}

Ten wybór typografii jest podobny do stwierdzenia „użyj domyślnej czcionki systemowej dla bieżącej lokalizacji użytkownika”.

W systemie macOS czcionką system-ui jest San Francisco, która została sprawdzona, przetestowana i niedawno ulepszona przez zespół projektantów. Najpierw omówimy nowe, ciekawe funkcje czcionek zmiennych w systemie Catalina, a potem opowiemy o kilku błędach i sposobach ich rozwiązania przez inżynierów Chromium.

W tym poście zakładamy, że znasz już czcionki zmienne. Jeśli nie, zapoznaj się z artykułem Wprowadzenie do czcionek zmiennych w internecie i obejrzyj poniższy film.

Zgodność z przeglądarką

W momencie pisania tego artykułu system-ui jest obsługiwany przez Chromium (od wersji 56), Edge (od wersji 79), Safari (od wersji 11) i Firefox (od wersji 43), ale ze słowem kluczowym -apple-system. Aktualne informacje znajdziesz w artykule Czy mogę używać czcionek zmiennych?

Nowe moce

Nowe możliwości, które Catalina wprowadziła do czcionki systemowej, są teraz dostępne dla deweloperów stron internetowych w Chromium 83. Czcionka system-ui ma teraz więcej ustawień zmiennych: optymalizację rozmiaru i 2 unikalne dostosowania grubości:

Mojave
h1 {
  font-family: system-ui;
  font-weight: 700;
  font-variation-settings:
    'wght' 750
  ;
}
Catalina
h1 {
  font-family: system-ui;
  font-weight: 700;
  font-variation-settings:
    'wght' 750,
    'opsz' 20,
    'GRAD' 400,
    'YAXS' 400
  ;
}

W systemie Mojave system-ui to czcionka zmienna z tylko wght ustawieniami. system-ui w systemie Catalina to czcionka zmienna z ustawieniami wght, opsz, GRADYAXS.

Wygląda na to, że mamy tu ciekawe możliwości stopniowego ulepszania projektu. Jeśli chcesz, możesz dokładnie przyjrzeć się subtelnościom czcionki systemowej.

wght

Akceptuje grubość czcionki z przedziału od 0 do 900 i jest stosowana 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ą ustalane przez ludzkie oko, a nie przez obliczenia matematyczne. Wartość 19 lub mniejsza jest przeznaczona do odstępów w tekście i treści, a 20 lub większa – do odstępów w nagłówkach i tytułach.

/* 19 or 20 */
font-variation-settings: 'opsz' 20;

GRAD

Podobne do grubości, ale bez wpływu na odstępy poziome. Może mieć wartość z zakresu od 400 do 1000.

/* 400-1000 */
font-variation-settings: 'GRAD' 500;

YAXS

Rozciąga glif w pionie. Może mieć wartość z zakresu od 400 do 1000.

/* 400-1000 */
font-variation-settings: 'YAXS' 500;

Łączenie opcji

Za pomocą kilku linijek kodu CSS możemy zmienić ustawienia czcionki na pogrubioną lub wypróbować inne ciekawe kombinacje:

font-weight: 700;
font-weight: bold;
font-variation-settings: 'wght' 750, 'YAXS' 600, 'GRAD' 500, 'opsz' 20;

Użytkownicy Chromium w systemie macOS zobaczą ulepszoną, niestandardową czcionkę o wadze 750 z kilkoma innymi ciekawymi zmianami 👍

W systemie macOS 10.15 dodano nowe funkcje do czcionki systemowej, a w systemie macOS 10.15 w trackerze błędów Chromium zarejestrowano trudny do wyeliminowania system-ui błąd. Ciekawe, czy są ze sobą spokrewnione.

Dodatek: regresja system-ui

Ta historia zaczyna się od innego błędu: #1005969. Zgłoszono problem w systemie macOS 10.15, ponieważ system-ui wyglądało na wąskie i ściśnięte.

Porównanie dwóch akapitów ze strony grupy na Facebooku. Po lewej stronie jest Chrome, a po prawej Safari. Chrome ma subtelne, ale nieco mniejsze odstępy.
Chrome po lewej (węższe śledzenie), Safari po prawej (lepsze odstępy optyczne)

Tło

Czy w systemie macOS 10.14 zdarzyło Ci się zauważyć, że akapity lub nagłówki „przeskakiwały” do innego kroju pisma, gdy zmieniał się ich rozmiar?

W systemie Mojave (macOS 10.14) czcionka system-ui zmieniała się w zależności od docelowego rozmiaru. Gdy tekst był mniejszy niż 20px, macOS używał czcionki „San Francisco Text”. Gdy tekst miał 20px lub więcej, macOS używał czcionki „San Francisco Display”. Rozmiar optyczny został statycznie wbudowany w 2 osobne czcionki.

W systemie Catalina (macOS 10.15) wprowadzono nową, ujednoliconą czcionkę zmienną San Francisco. Nie musisz już zarządzać „Tekstem” i „Reklamami displayowymi”. Zyskał też nowe ustawienie wariantu opsz opisane wcześniej.

h1 {
  font-variation-settings: 'opsz' 20;
}

Niestety domyślna wartość opsz w nowej czcionce Catalina to 20, a inżynierowie Chromium nie byli gotowi na zastosowanie opsz w czcionce systemowej. W rezultacie mniejsze rozmiary były zbyt wąskie.

Aby to naprawić, Chromium musi prawidłowo zastosować opsz do czcionki systemowej. Dzięki temu udało się rozwiązać problem nr 1005969. Zwycięstwo! A może…?

Jeszcze nie

W tym momencie pojawił się problem: Chromium zastosował opsz, ale coś nadal nie wyglądało dobrze. Czcionki systemowe na Macu mają dodatkową tabelę czcionek o nazwie trak, która dostosowuje odstępy poziome. 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 pomiarów. Biblioteka kształtowania Chromium HarfBuzz potrzebuje danych, w których wartości trak nie są jeszcze uwzględnione.

Wyświetlanie interfejsu systemu i wszystkich jego grubości czcionek oraz odmian na liście. W przypadku połowy z nich nie zastosowano różnic wagi.
Po lewej: pogrubione wagi zastosowane do rozmiarów czcionki 19 pikseli i mniejszych. Po prawej: rozmiary czcionki 20 i większe tracą styl pogrubienia

Wewnętrznie Skia (biblioteka graficzna, a nie krój pisma o tej samej nazwie) używa zarówno klasy CGFontRefCoreGraphics, jak i klasy CTFontRefCoreText. Ze względu na wymagane wewnętrzne konwersje między tymi obiektami (używane do zachowania zgodności wstecznej i uzyskiwania dostępu do potrzebnych interfejsów API w obu klasach) Skia w określonych okolicznościach traciłaby informacje o wadze, a pogrubione czcionki przestałyby działać. Problem został zarejestrowany w zgłoszeniu nr 1057654.

Skia musi nadal 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ą oddzielnych czcionek dla każdego dostępnego kroju. W pewnym momencie ich identyfikatory glifów przestały być zsynchronizowane. Jeśli więc Skia przekształci tekst (przekonwertuje go na glify, które można narysować) za pomocą czcionki „San Francisco Text”, po narysowaniu za pomocą czcionki „San Francisco Display” będzie on bezsensowny i odwrotnie. Nawet jeśli Skia poprosi o inny rozmiar, macOS może przełączyć się na inny. Zawsze powinna być możliwość użycia jednej z czcionek i skalowania jej (za pomocą macierzy, a nie przez proszenie o większy rozmiar), ale CoreText ma problem z tym, że nie skaluje w górę glifów sbix (kolorowych emoji) (tylko w dół). To nieco bardziej skomplikowane. Wygląda na to, że CoreText ogranicza zakres pionowy po zastosowaniu macierzy, co prawdopodobnie wynika z tego, że nie może rysować emotikonów pod kątem 45 stopni. Jeśli chcesz, aby emoji były wyświetlane w dużym rozmiarze, musisz skopiować czcionkę, aby uzyskać dużą wersję.

Aby utworzyć kopie obiektów CTFont w różnych rozmiarach, ale z zachowaniem tych samych danych czcionki, Chromium wyodrębnił CGFontCTFont, a następnie utworzył nowy obiekt CTFontCGFont (obiekty CGFont są niezależne od rozmiaru, a przełączanie odbywa się na poziomie CoreText). Działało to dobrze do wersji 10.154. W wersji 10.15 ta podróż w obie strony spowodowała utratę zbyt wielu informacji, co doprowadziło do problemu z wagą. Flutter zauważył problem z grubością i wprowadził alternatywną poprawkę zmiany rozmiaru, aby utworzyć nowy element CTFont bezpośrednio z oryginalnego elementu CTFont, kontrolując rozmiar optyczny bezpośrednio za pomocą starego, ale nieudokumentowanego atrybutu w CoreText. Dzięki temu wszystko będzie działać w wersji 10.11 i rozwiążemy inne problemy (np. jawne ustawienie rozmiaru optycznego na wartość domyślną).

Zachowuje to jednak więcej „magii” CoreTextczcionki. Jednym z nich jest to, że nadal w jakiś sposób modyfikuje postępy glifów, a nie tylko tabelę trak (której zastosowanie Chromium próbowało już tłumić za pomocą jeszcze innego nieudokumentowanego atrybutu).

CGFont nie wykonuje żadnych z tych „magicznych” czynności, więc może Chromium mogłoby usunąć CGFontCTFont i używać go tylko do uzyskiwania postępów? Niestety to nie zadziała, ponieważ znak CoreText może też wpływać na czcionki w inny sposób. Na przykład sprawia, że małe emoji są nieco większe niż w rzeczywistości (zwiększa ich rozmiar). CGFont nie wie o tym, więc emotikony oparte na sbix będą zbyt blisko siebie, ponieważ będziesz mierzyć je w jednym rozmiarze, a CoreText będzie rysować je w większym rozmiarze. Chromium chce CTFont, ale bez śledzenia i najlepiej bez żadnych innych kombinacji.

Rozwiązanie problemu z odstępami wymagało wprowadzenia powiązanych ze sobą poprawek w Blinku i Skia, więc inżynierowie Chromium nie mogli po prostu cofnąć zmian. Inżynierowie Chromium próbowali też użyć innego flagi kompilacji, aby zmienić ścieżkę kodu związaną z czcionkami w bibliotece Skia. Rozwiązało to problem z pogrubionymi czcionkami, ale spowodowało regresję problemu z odstępami.

Rozwiązanie

Oczywiście zespół Chromium chciał naprawić oba te problemy. Chromium używa teraz wbudowanych w HarfBuzz funkcji pomiarów czcionek OpenType do pobierania pomiarów poziomych bezpośrednio z danych binarnych w tabelach czcionek systemowych. Dzięki temu Chromium omija CoreText i Skia, gdy czcionka zawiera tabelę trak (z wyjątkiem czcionki emoji).

Wyświetlanie interfejsu systemu oraz wszystkich jego grubości i odmian czcionek na liście. Połowa, która wcześniej nie działała, wygląda teraz świetnie.

W międzyczasie możesz śledzić problem nr 10123 w Skia, aby dowiedzieć się, kiedy zostanie on w pełni rozwiązany w Skia i kiedy będzie można wrócić do pobierania z niego danych czcionki systemowej zamiast korzystać z obecnego rozwiązania, które przechodzi przez HarfBuzz.