Chromium 83'teki macOS system-ui yazı tipi için daha fazla değişken yazı tipi seçenekleri

Catalina, macOS'e yeni bir birleşik değişken sistem yazı tipi sunuyor.

CSS Yazı Tipleri Modülü Düzey 4 spesifikasyonunun "system-ui" bölümünde, geliştiricilerin yerleşik, turbo için optimize edilmiş, yerelleştirilmiş, mega yüksek kalitede, indirmeye gerek olmayan, varsayılan işletim sistemi yazı tipini doğrudan sitelerinde ve uygulamalarında kullanmalarına olanak tanıyan bir system-ui yazı tipi anahtar kelimesi tanımlar.

body {
  font-family: system-ui;
}

Bu yazı tipi seçimi, "bu kullanıcının mevcut yerel ayarı için varsayılan sistem yazı tipini kullan" ifadesine benzer.

macOS'te system-ui yazı tipi San Francisco'dur. Bu yazı tipi, tasarım ekibi tarafından incelenmiş, test edilmiş ve yakın zamanda yükseltilmiştir. Öncelikle Catalina'daki heyecan verici yeni değişken yazı tipi özelliklerini, ardından birkaç hatayı ve Chromium mühendislerinin bunları nasıl çözdüğünü ele alacağız.

Bu yayında, değişken yazı tiplerini zaten bildiğiniz varsayılmaktadır. Değişken yazı tiplerini kullanmaya başlamadıysanız Web'de değişken yazı tiplerine giriş başlıklı makaleyi ve aşağıdaki videoyu inceleyin.

Tarayıcı uyumluluğu

Yazıldığı sırada system-ui, Chromium (56'dan itibaren), Edge (79'dan beri), Safari (11'den beri) ve Firefox'tan (43'ten itibaren) ancak -apple-system anahtar kelimesini kullanmıştır. Güncellemeler için Değişken yazı tiplerini kullanabilir miyim? başlıklı makaleyi inceleyin.

Yeni güçler

Catalina'nın sistem yazı tipine getirdiği yeni özellikler, Chromium 83 itibarıyla web geliştiricileri tarafından kullanılabilir. system-ui yazı tipi artık daha fazla değişken ayarına sahip: optik boyutlandırma ve 2 benzersiz kalınlık ayarı:

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
  ;
}

Mojave'de system-ui, yalnızca wght ayarlarına sahip bir değişken yazı tipidir. Catalina'da system-ui; wght, opsz, GRAD ve YAXS ayarlarına sahip bir değişken yazı tipidir.

Bana göre, aşamalı iyileştirme tasarımı için bazı güzel fırsatlar var. İsterseniz sistem yazı tipinin inceliklerini inceleyebilirsiniz.

wght

0 ile 900 arasında bir yazı tipi ağırlığı kabul eder ve tüm karakterlere eşit şekilde uygulanır.

/* 0-900 */
font-variation-settings: 'wght' 750;

opsz

Optik boyutlandırma, kerning'e veya harf aralığına benzer ancak aralıklar matematik yerine insan gözü tarafından ayarlanır. 19 veya daha düşük bir değer, metin ve gövde metnindeki boşluk kullanımı için kullanılırken 20 veya üstü bir değer, ekran başlıklarında ve başlıklarda boşluk kullanımı için kullanılır.

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

GRAD

Ağırlığa benzer ancak yatay aralığa dokunmaz. 400 ile 1000 arasındaki değerleri kabul eder.

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

YAXS

Glifi dikey olarak uzatır. 400 ile 1000 arasındaki değerleri kabul eder.

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

Seçenekleri birleştirme

Birkaç satır CSS ile yazı tipi ayarlarını seçtiğiniz bir kalın yazı tipine ayarlayabilir veya diğer ilginç kombinasyonları deneyebilirsiniz:

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

Böylece macOS'teki Chromium kullanıcıları yeni, özel 750 kilonuzun yanı sıra eğlenceli başka ufak değişiklikler görebilirler 👍

Çocuk parkı

Glitch'in düzenlenebilir bir kopyasını almak için aşağıdaki Glitch'te Düzenlemek için remiksle'yi tıklayın ve ardından yeni font-variation-settings seçeneklerini düzenleyerek yazı tipinizi nasıl etkilediğini görün. Bu hatanın yalnızca macOS Catalina cihaz kullanıyorsanız çalışacağını unutmayın.

macOS 10.15, sistem yazı tipine yeni özellikler ekledi ve macOS 10.15'te Chromium hata izleyiciye sorunlu bir system-ui hatası kaydedildi. Acaba bunlar birbiriyle alakalı mı?

Ek: system-ui regresyonu

Bu hikaye farklı bir hatayla başlıyor: #1005969. Bu hata, system-ui yazı tipi aralığı dar ve sıkışık olduğu için macOS 10.15'te bildirilmiştir.

Bir Facebook grup sayfasındaki iki paragrafın karşılaştırması. Soldaki Chrome, sağdaki ise Safari'dir. Chrome'da boşluklar daha azdır ancak fark çok belirgin değildir.
Solda Chrome (daha sıkı izleme), sağda Safari (daha iyi optik aralıklar)

Arka plan

macOS 10.14'te paragraflarınızın veya üstbilgilerinizin boyutu arttığında ya da azaldığında farklı bir yazı tipine "geçiş yaptığını" fark ettiniz mi?

Mojave'de (macOS 10.14) system-ui yazı tipi, hedef yazı tipi boyutuna bağlı olarak iki yazı tipi arasında geçiş yapıyordu. Metin 20px altındayken macOS "San Francisco Metni"ni kullanıyordu. Metin 20px veya daha büyük olduğunda macOS "San Francisco Display"i kullanıyordu. Optik boyutlandırma, iki ayrı yazı tipine statik olarak yerleştirildi.

Catalina (macOS 10.15), San Francisco için yeni bir birleşik değişken yazı tipi kullanıma sundu. Artık "Metin" ve "Görüntülü"yü yönetmek yok. Ayrıca, daha önce açıklanan yeni varyasyon ayarı opsz da eklendi.

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

Maalesef yeni Catalina yazı tipindeki varsayılan opsz değeri 20'tır ve Chromium mühendisleri opsz değerini sistem yazı tipine uygulamaya hazır değildi. Bu durum, daha küçük boyutların çok dar gösterilmesine yol açıyordu.

Bu sorunu düzeltmek için Chromium'un opsz karakterini sistem yazı tipine doğru şekilde uygulaması gerekiyordu. Bu sayede 1005969 numaralı sorun düzeltildi. Zafer! Yoksa…?

Henüz tamamlanmadı

İşin zor kısmı burada başlıyor: Chromium, opsz'ü uyguladı ancak bir şeyler hâlâ doğru görünmüyordu. Mac'teki sistem yazı tiplerinde, yatay aralığı düzenleyen trak adlı ek bir yazı tipi tablosu bulunur. Chromium mühendisleri, düzeltme üzerinde çalışırken macOS'te bir CTFontRef nesnesinden yatay metrikler alınırken trak metriklerinin zaten metrik sonuçlarına dahil edildiğini fark etti. Chromium'un şekillendirme kitaplığı HarfBuzz, trak değerlerinin henüz hesaba katılmadığı metriklere ihtiyaç duyar.

system-ui ve tüm yazı tipi kalınlıkları ile varyantlarının bir listede gösterilmesi. Yarısına ağırlık farkı uygulanmamış.
Sol: 19 ve önceki yazı tipi boyutlarına uygulanan kalın ağırlıklar. Sağ: 20 ve üzeri yazı tipi boyutlarında kalın stil kaybolur

Dahili olarak Skia (aynı ada sahip yazı tipi değil, grafik kitaplığı), hem CoreGraphics'teki CGFontRef sınıfını hem de CoreText'teki CTFontRef sınıfını kullanır. Bu nesneler arasında gerekli dahili dönüşümler (geriye dönük uyumluluğu korumak ve her iki sınıfta da gerekli API'lere erişmek için kullanılır) nedeniyle Skia belirli durumlarda ağırlık bilgilerini kaybeder ve kalın yazı tipleri çalışmayı durdurur. Bu sorun Sorunun numarası: 1057654 başlıklı makalede takip edilmiştir.

Chromium hâlâ macOS 10.11'i desteklediğinden Skia'nın bu sürümü desteklemesi gerekiyor. 10.11'de "San Francisco Metin" ve "San Francisco Görüntüleme" yazı tipleri bile değişken yazı tipleri değildi. Bunun yerine, her biri mevcut her ağırlık için ayrı bir yazı tipi ailesiydi. Bir noktada glif kimlikleri birbirleriyle senkronize olmuyor. Dolayısıyla Skia, metin şekillendirmeyi ("San Francisco Metin" ile metni çizilebilen karakterlere dönüştürme) "San Francisco Görüntü" ile yaparsa "San Francisco Görüntü" ile çizildiğinde anlamsız olur ve bunun tersi de geçerlidir. Skia farklı bir boyut istemiş olsa bile macOS diğerine geçebilir. Yazı tiplerinden birini her zaman kullanmak ve ölçeklendirmek (daha büyük bir boyut istemek yerine ölçeklendirmek için bir matris kullanarak) mümkün olmalıdır ancak CoreText'te sbix (renkli emoji) karakterlerinin ölçeklendirilmemesi (yalnızca küçültülmesi) sorunu vardır. Durum bundan biraz daha karmaşık. CoreText, matris uygulamasından sonra dikey kapsamı sınırlıyor. Bunun nedeni, emoji'nin 45 derecelik açılarda çizilememesi olabilir. Her durumda, emoji'nizin büyük gösterilmesini istiyorsanız büyük bir sürüm elde etmek için yazı tipinin bir kopyasını oluşturmanız gerekir.

Bu nedenle Chromium, aynı temel yazı tipi verilerinin kullanıldığından emin olurken aynı temel yazı tipi verilerinin kullanıldığından emin olmak üzere dahili olarak farklı boyutlarda CTFont nesnelerin kopyalarını oluşturmak için CGFont öğesini CTFont cihazından çıkardı, ardından CGFont nesnesinden yeni bir CTFont yaptı (CGFont nesnenin boyutu bağımsızdır, sihir geçişi CoreText düzeyinde gerçekleşir). Bu yöntem 10.154 sürümüne kadar sorunsuz çalışıyordu. 10.15'te bu gidiş dönüş işlemi çok fazla bilgi kaybettiği için ağırlık sorunu ortaya çıktı. Flutter, ağırlık sorununu fark etti ve yeni CTFont öğesini doğrudan orijinal CTFont öğesinden oluşturmak için yeniden boyutlandırmayla ilgili alternatif bir düzeltme yapıldı. Bu düzeltme, optik boyutu doğrudan CoreText öğesindeki eski ancak belgelenmemiş bir özelliği kullanarak kontrol ediyordu. Bu işlem, 10.11'de işlerin çalışmasını sağlar ve diğer sorunları (ör. optik boyutu varsayılan değere açıkça ayarlama) düzeltir.

Ancak bu yöntem, yazı tipindeki CoreText "sihirinin" daha fazlasını korur. Bunlardan biri, glifteki ilerlemeleri sadece trak tablosundan (Chromium'un belgelenmemiş başka bir özelliği engellemeye çalıştığı uygulama) farklı bir şekilde değiştirdiği anlaşılıyor.

CGFont bu "sihir"den hiçbirini yapmaz. Dolayısıyla Chromium, CGFont ürününün CTFont indirimini alıp bunu yalnızca ilerlemek için kullanabilir. CoreText'ün yazı tipleriyle başka şekillerde de uğraştığı bilindiği için maalesef bu işe yaramaz. Örneğin, küçük emojileri aslında istediğinizden biraz daha büyük yapar (boyutlarını biraz artırır). CGFont bu konudan haberdar olmadığından, sbix tabanlı emojileriniz birbirine çok yakın olur. Bunun nedeni, CGFont'ın emojileri bir boyutta ölçerken CoreText'ın onları biraz daha büyük çizmesidir. Chromium, CTFont gelişmelerini istiyor ancak bunları izleme olmadan ve tercihen başka bir karışıklık olmadan istiyor.

Boşluk sorununun düzeltilmesi için birbirine bağlı bir dizi Blink ve Skia düzeltmesi gerektiğinden Chromium mühendisleri sorunu düzeltmek için "geri dönme" işlemini yapamadı. Chromium mühendisleri, Skia'da yazı tipiyle ilgili bir kod yolunu değiştirmek için farklı bir derleme işareti kullanmayı da denedi. Bu, kalın yazı tipi sorununu düzeltti ancak boşluk sorununu geri getirdi.

Düzeltme

Elbette Chromium, her iki sorunu da düzeltmek istedi. Chromium artık yatay metrikleri doğrudan sistem yazı tipinin yazı tipi tablolarındaki ikili verilerden almak için HarfBuzz'ın yerleşik yazı tipi OpenType yazı tipi metrikleri işlevlerini kullanıyor. Bu sayede Chromium, yazı tipinde trak tablosu olduğunda (emoji yazı tipi hariç) CoreText ve Skia'yı atlar.

system-ui ve tüm yazı tipi kalınlıkları ile varyantlarının bir listede gösterilmesi. Daha önce çalışmayan yarı artık mükemmel görünüyor.

Bu arada, sorunun Skia'da tamamen düzeltilmesini ve HarfBuzz üzerinden yapılan mevcut düzeltme yerine sistem yazı tipi metriklerini almak için Skia'yı kullanmaya geri dönmeyi takip etmek üzere Skia Issue #10123 (Skia sorunu 10123) hâlâ açıktır.