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ı:
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 ; }
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.
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.
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.
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.