Catalina wprowadza w systemie macOS nową czcionkę systemową o zjednoczonych zmiennych.
Sekcja „system-ui” w specyfikacji CSS Fonts Module na poziomie 4 definiuje słowo kluczowe czcionki system-ui, które pozwala deweloperom używać w swoich witrynach i aplikacjach wbudowanej, zlokalizowanej, zoptymalizowanej pod kątem turbo, zlokalizowanej domyślnej czcionki systemu operacyjnego, wysokiej jakości i niewymagających pobierania.
body {
font-family: system-ui;
}
Ten wybór typograficzny jest podobny do polecenia „Użyj domyślnej czcionki systemowej w bieżącym języku tego użytkownika”.
W systemie macOS czcionka system-ui to San Francisco. Jest to czcionka, którą zespół projektowy sprawdził, przetestował i ... niedawno uaktualnił. Najpierw omówimy nowe, ciekawe funkcje zmiennych czcionek w Catalina, a potem omówimy kilka błędów i sposób ich rozwiązania przez inżynierów Chromium.
W tym poście zakładamy, że znasz się już na zmiennych czcionkach. Jeśli nie, obejrzyj Wprowadzenie do zmiennych czcionek w internecie i film poniżej.
Zgodność z przeglądarką
W momencie napisania tego tekstu system-ui obsługuje przeglądarkę Chromium (od 56), Edge (od wersji 79), Safari (od 11) i Firefoksa (od 43), ale ze słowem kluczowym -apple-system. Więcej informacji znajdziesz w artykule Czy mogę używać zmiennych czcionek?.
Nowe moce
Nowe możliwości wprowadzone przez Catalina do czcionki systemowej są teraz dostępne dla programistów stron internetowych od Chromium 83. Czcionka system-ui ma teraz więcej zmiennych ustawień: rozmiar optyczny i 2 unikalne opcje dostosowania wagi:
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 Mojave system-ui to czcionka zmienna, która ma tylko ustawienia wght. Z kolei system-ui w Catalina to zmienna czcionka z ustawieniami wght, opsz, GRAD i YAXS.
Chyba jakieś fajne możliwości udoskonalania w zakresie progresywnych ulepszeń. Jeśli chcesz, możesz zagłębić się w subtelności czcionki systemowej.
wght
Akceptuje grubość czcionki z zakresu od 0 do 900 i jest stosowana jednakowo do wszystkich znaków.
/* 0-900 */
font-variation-settings: 'wght' 750;
opsz
Rozmiar optyczny jest podobny do kerningu i odstępów między literami, ale odstępy są wykonywane przez ludzkie oko, a nie za pomocą matematyki. Wartość 19 lub mniejsza oznacza odstępy w tekście i treści, a 20 lub więcej – odstępy między nagłówkami i tytułami.
/* 19 or 20 */
font-variation-settings: 'opsz' 20;
GRAD
Podobne do szerokości, ale nie dotykając odstępów w poziomie. Może mieć wartości od 400 do 1000.
/* 400-1000 */
font-variation-settings: 'GRAD' 500;
YAXS
Rozciąga glif w pionie. Może mieć wartości od 400 do 1000.
/* 400-1000 */
font-variation-settings: 'YAXS' 500;
Łączenie opcji
Wykorzystując kilka linijek kodu CSS, możemy dostosować ustawienia czcionek, aby pogrubić nasz wybór lub wypróbować inne ciekawe kombinacje:
font-weight: 700;
font-weight: bold;
font-variation-settings: 'wght' 750, 'YAXS' 600, 'GRAD' 500, 'opsz' 20;
I tak jak to możliwe, użytkownicy Chromium w systemie macOS widzą Twoją ulepszoną, niestandardową wagę 750 z nowymi ulepszeniami 👍
Plac zabaw
W sekcji Zakłócenie poniżej kliknij Remiksuj, aby edytować, aby uzyskać edytowalną kopię błędu. Następnie edytuj nowe opcje font-variation-settings, aby zobaczyć, jak wpłynie to na czcionkę. Pamiętaj, że ten błąd będzie działać tylko wtedy, gdy używasz urządzenia z macOS Catalina.
W systemie macOS 10.15 do czcionki systemowej pojawiły się nowe funkcje, a w systemie macOS 10.15 w narzędziu do śledzenia błędów Chromium pojawił się trudny błąd system-ui. zastanawiam się, czy są jakieś ze sobą powiązane.
Dodatek: regresja system-ui
Ta historia zaczyna się od innego błędu: #1005969. Zgłoszono to w systemie macOS 10.15, ponieważ odstępy między czcionkami system-ui wyglądały na zawężone i zatłoczone.
Wprowadzenie
Czy zauważyłeś(-aś), że w systemie macOS 10.14 akapity i nagłówki są „zastępowane” inną czcionką przy zwiększaniu lub zmniejszaniu rozmiaru?
W Mojave (macOS 10.14) czcionka system-ui przełącza się między 2 czcionkami w zależności od docelowego rozmiaru czcionki. Gdy tekst był poniżej 20px, macOS używało „San Francisco Text”. Kiedy wartość tekstu wynosiła co najmniej 20px, system macOS używał ustawienia „San Francisco Display”. Rozmiar optyczny został wbudowany statycznie przy użyciu 2 osobnych czcionek.
Firma Catalina (macOS 10.15) udostępniła nową, zjednoczoną czcionkę o zmiennej czcionce, przeznaczonej dla San Francisco. Nie musisz już zarządzać reklamami tekstowymi i displayowymi. Zastosowano też nowe ustawienie odmiany opsz opisane 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 opsz do czcionki systemowej. Powoduje to, że małe rozmiary są zbyt wąskie.
Aby to naprawić, Chromium musiał prawidłowo zastosować opsz do czcionki systemowej. Doprowadziło to do rozwiązania problemu nr 1005969. Zwycięstwo! A może właśnie...?
Jeszcze nie ukończono
Coś poszło nie tak: Chromium zastosował opsz, ale coś nadal nie wyglądało tak jak powinno. Czcionki systemowe na komputerach Mac mają dodatkową tabelę czcionek o nazwie trak, która dostosowuje odstępy w poziomie. Podczas prac nad rozwiązaniem tego problemu 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 danych. Biblioteka kształtowania HarfBuzz Chromium wymaga danych, w których wartości trak nie zostały jeszcze uwzględnione.
Wewnętrznie Skia (biblioteka graficzna, a nie krój czcionki o tej samej nazwie) używa zarówno klasy CGFontRef z CoreGraphics, jak i klasy CTFontRef z CoreText. Ze względu na konieczność wewnętrznych konwersji między tymi obiektami (umożliwia to uzyskanie zgodności wstecznej i uzyskiwanie dostępu do wymaganych interfejsów API w obu klasach) Skia w pewnych okolicznościach traci informacje o wadze, a pogrubione czcionki przestaną działać. Było to monitorowane w numerze 1057654.
Skia nadal musi obsługiwać system macOS 10.11, bo Chromium nadal obsługuje ten system. 10 grudnia czcionki „San Francisco Text” i „San Francisco Display” nie miały nawet zmiennych czcionek. Każda z nich stanowiła rodzinę osobnych czcionek dla każdej dostępnej grubości. W pewnym momencie ich identyfikatory glifów przestały być zsynchronizowane. Jeśli więc Skia zastosowała modelowanie tekstu (przekształcenie tekstu w glify, które można narysować) za pomocą słowa „Tekst z San Francisco”, byłoby to bezsensowny tekst po narysowaniu za pomocą „San Francisco Display” i odwrotnie. A nawet jeśli Skia poprosiła o inny rozmiar systemu macOS, może się przełączyć na inny. Zawsze można używać jednej z czcionek i po prostu ją skalować (za pomocą macierzy w celu przeskalowania w górę, zamiast prosić o większy rozmiar). CoreText ma jednak problem polegający na tym, że nie skaluje glifów sbix (kolorów emotikonów) w górę (tylko w dół). To trochę bardziej złożone. CoreText Wydaje się, że po zastosowaniu macierzy matryca osiąga ona zasięg w pionie, co prawdopodobnie wiąże się z brakiem możliwości rysowania emotikonów pod kątem 45 stopni. Jeśli chcesz, aby Twój emotikon był duży, musisz utworzyć kopię czcionki, aby uzyskać dużą wersję.
Aby utworzyć wewnętrznie kopie obiektów CTFont w różnych rozmiarach, a jednocześnie mieć pewność, że te same podstawowe dane czcionek są używane, Chromium pobrał CGFont z CTFont, a następnie utworzył nowy obiekt CTFont z tabeli CGFont (obiekty CGFont są niezależne od rozmiaru, więc magiczne przełączanie odbywa się na poziomie CoreText). Działało tak do 10.15.2015. W 10.15 ta podróż w obie strony spowodowała utratę zbyt wielu informacji, co spowodowało problem z wagą. Flutter zauważył problem z wagą i wprowadzono alternatywne rozwiązanie umożliwiające zmianę rozmiaru, aby utworzyć nowy obiekt CTFont bezpośrednio z pierwotnego elementu CTFont, jednocześnie kontrolując rozmiar optyczny bezpośrednio za pomocą starego, ale nieudokumentowanego atrybutu w CoreText. To umożliwia działanie w wersji 10.11 i rozwiązuje inne problemy (takie jak jawne ustawienie rozmiaru optycznego na wartość domyślną).
Pozwoli to jednak zachować więcej „magii” elementu CoreText w czcionce. Wydaje się, że jednym z nich jest to, że wciąż udoskonala postępy glifów w inny sposób niż tylko w tabeli trak (zastosowanie, którego Chromium próbował już pominąć przez kolejny nieudokumentowany atrybut).
CGFont nie wykonuje żadnej tej „magii”, więc może Chromium pozbędzie się CGFont systemu CTFont i użyje ich do polepszenia wyników? Niestety to się nie uda, ponieważ w usłudze CoreText często umieszcza się czcionki również w inny sposób. Na przykład powoduje to, że małe emotikony są nieco większe niż te, o które prosisz (trochę zwiększając ich rozmiar). CGFont tego nie wie, więc emotikony oparte na sbix byłyby zbyt blisko siebie, ponieważ mierzysz do jednego rozmiaru, a CoreText do pewnego rozmiaru je zwiększyłby. Chromium dąży do postępu CTFont, ale chce ich bez śledzenia i najlepiej bez bałaganu.
Ponieważ rozwiązanie problemu ze odstępami wymagało zestawu poprawek połączonych ze sobą Blink i Skia, inżynierowie Chromium nie mogli po prostu przywrócić połączenia, aby rozwiązać problem. Inżynierowie Chromium spróbowali też użyć innej flagi kompilacji do zmiany ścieżki kodu związanej z czcionkami w Skia. Rozwiązało to problem z pogrubionymi czcionkami, ale spowodowało zmniejszenie odstępów.
Poprawka
W ostatecznym rozrachunku oczywiście Chromium chciał naprawić oba te problemy. Chromium korzysta teraz z wbudowanych w HarfBuzz funkcji danych OpenType czcionek, aby pobierać dane poziome bezpośrednio z danych binarnych w tabelach czcionek systemowych. Dzięki temu Chromium pomija elementy CoreText i Skia, gdy czcionka ma tabelę trak (z wyjątkiem czcionki emotikonów).
Tymczasem możesz sprawdzić problem nr 10123 dotyczący rozwiązania tego problemu w Skia i wrócić do pobierania danych dotyczących czcionek systemowych w Skia, a nie do bieżącej poprawki z HarfBuzz.