Catalina, macOS'e yeni birleşik değişken sistem yazı tipi getiriyor.
CSS Fonts Module Level 4 spesifikasyonunun "system-ui" bölümü, geliştiricilerin yerleşik, turbo optimizasyonlu, yerelleştirilmiş, çok yüksek kaliteli, indirme gerektirmeyen, varsayılan işletim sistemi yazı tipini doğrudan sitelerinde ve uygulamalarında kullanmalarına olanak tanıyan bir system-ui yazı tipi anahtar kelimesini tanımlar.
body {
font-family: system-ui;
}
Bu tipografi seçimi, "bu kullanıcının geçerli yerel ayarı için varsayılan sistem yazı tipini kullan" demeye benzer.
macOS'te system-ui yazı tipi, bir tasarım ekibi tarafından incelenen, test edilen ve yakın zamanda yükseltilen San Francisco yazı tipidir. İlk olarak Catalina'daki yeni ve heyecan verici değişken yazı tipi özelliklerini ele alacak, ardından bazı hataları ve Chromium mühendislerinin bunları nasıl çözdüğünü inceleyeceğiz.
Bu yayında, değişken yazı tipleri hakkında bilgi sahibi olduğunuz varsayılmaktadır. Değilse Web'de değişken yazı tiplerine giriş başlıklı makaleyi ve aşağıdaki videoyu inceleyin.
Tarayıcı uyumluluğu
Bu makalenin yazıldığı sırada system-ui; Chromium (56. sürümden itibaren), Edge (79. sürümden itibaren), Safari (11. sürümden itibaren) ve Firefox (43. sürümden itibaren) tarafından destekleniyordu ancak Firefox'ta -apple-system anahtar kelimesiyle kullanılıyordu. 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'ten itibaren web geliştiriciler tarafından kullanılabiliyor. system-ui yazı tipinde artık daha fazla değişken ayar var: optik boyutlandırma ve 2 benzersiz ağırlı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ını içeren bir değişken yazı tipidir. Catalina'daki system-ui ise wght, opsz, GRAD ve YAXS ayarlarını içeren değişken bir yazı tipidir.
Bana göre, ilerleyici geliştirme tasarımında bazı güzel fırsatlar var. İsterseniz sistem yazı tipinin ayrıntılarına da göz atabilirsiniz.
wght
0 ile 900 arasında bir yazı tipi ağırlığını kabul eder ve tüm karakterlere eşit olarak uygulanır.
/* 0-900 */
font-variation-settings: 'wght' 750;
opsz
Optik boyutlandırma, karakter aralığına veya harf aralığına benzer ancak aralık, matematiksel olarak değil, insan gözüyle belirlenir. 19 veya daha düşük bir değer, metin ve gövde metni aralığı için, 20 veya daha yüksek bir değer ise görüntüleme başlıkları ve başlıkları 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 koduyla yazı tipi ayarlarını istediğimiz kalınlıkta olacak şekilde değiştirebilir veya diğer ilginç kombinasyonları deneyebiliriz:
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ı, yükseltilmiş ve özelleştirilmiş 750 ağırlığındaki yazı tipinizi diğer bazı eğlenceli düzenlemelerle birlikte görür. 👍
macOS 10.15, sistem yazı tipine yeni özellikler ekledi ve macOS 10.15'te Chromium hata izleyicide zorlu bir system-ui hatası kaydedildi. Acaba aralarında bir ilişki var mı?
Ek: system-ui regresyonu
Bu hikaye farklı bir hata ile başlıyor: #1005969. system-ui yazı tipi aralığı dar ve sıkışık göründüğü için bu sorun macOS 10.15'te bildirildi.
Arka plan
macOS 10.14'te, boyut arttığında veya azaldığında paragraflarınızın ya da başlıklarınızın farklı bir yazı tipine "oturduğunu" hiç 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 Text"i kullanıyordu. Metin 20px veya daha fazla olduğunda macOS, "San Francisco Display"i kullanıyordu. Optik boyutlandırma, iki ayrı yazı tipine statik olarak yerleştirilmiştir.
Catalina (macOS 10.15), San Francisco için yeni birleşik değişken yazı tipiyle birlikte gelir. Artık "Metin" ve "Görüntülü" reklamları yönetmenize gerek yok. Ayrıca, daha önce açıklanan yeni varyasyon ayarı opsz eklendi.
h1 {
font-variation-settings: 'opsz' 20;
}
Maalesef, yeni Catalina yazı tipindeki varsayılan opsz değeri 20 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örünmesine neden oldu.
Bu sorunu düzeltmek için Chromium'un opsz öğesini sistem yazı tipine doğru şekilde uygulaması gerekiyordu. Bu durum, 1005969 numaralı sorunun düzeltilmesine yol açtı. Zafer! Yoksa…?
Henüz tamamlanmadı
İşin zorlaştığı nokta burasıydı: Chromium opsz uygulandı ancak yine de bir şeyler doğru görünmüyordu. Mac'teki sistem yazı tiplerinde, yatay aralığı ayarlayan trak adlı ek bir yazı tipi tablosu bulunur. Düzeltme üzerinde çalışırken Chromium mühendisleri, macOS'te bir CTFontRef nesnesinden yatay metrikler alınırken trak metriklerinin metrik sonuçlarına zaten dahil edildiğini fark etti. Chromium'un şekillendirme kitaplığı HarfBuzz, trak değerlerinin henüz hesaba katılmadığı metrikler gerektirir.
Dahili olarak Skia (aynı ada sahip yazı tipi değil, grafik kitaplığı), hem CoreGraphics içindeki CGFontRef sınıfını hem de CoreText içindeki CTFontRef sınıfını kullanır. Bu nesneler arasında gerekli olan 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, 1057654 numaralı sorunda takip edildi.
Chromium hala desteklediği için Skia'nın macOS 10.11'i desteklemeye devam etmesi gerekiyor. 10.11'de"San Francisco Text " ve"San Francisco Display" yazı tipleri değişken yazı tipleri bile değildi. Bunun yerine, her biri mevcut her ağırlık için ayrı yazı tipi ailesiydi. Bir noktada glif kimlikleri senkronize olmamaya başladı. Bu nedenle, Skia "San Francisco Text" ile metin şekillendirme (metni çizilebilen gliflere dönüştürme) işlemi yaparsa "San Francisco Display" ile çizildiğinde anlamsız olur ve bunun tersi de geçerlidir. Skia farklı bir boyut istese bile macOS diğerine geçebilir. Yazı tiplerinden birini her zaman kullanmak ve yalnızca ölçeklendirmek (daha büyük bir boyut istemek yerine ölçeklendirmek için bir matris kullanmak) mümkün olmalıdır ancak CoreText, sbix (renkli emoji) gliflerini yalnızca küçültüp büyütmemeyle ilgili bir soruna sahiptir. Ancak durum düşündüğünüzden biraz daha karmaşık. CoreText, matris uygulamasından sonra dikey boyutu sınırlıyor gibi görünüyor. Bu durum, emojileri 45 derecelik açılarla çizememesiyle ilgili olabilir. Her durumda, emojinizin 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, aynı temel yazı tipi verilerinin kullanılmasını sağlarken CTFont nesnelerinin farklı boyutlarda kopyalarını oluşturmak için Chromium, CTFont'dan CGFont'yi çıkardı ve ardından CGFont'den yeni bir CTFont oluşturdu (CGFont nesneleri boyuttan bağımsızdır, sihirli geçiş CoreText düzeyinde gerçekleşir). Bu, 10.154 sürümüne kadar sorunsuz çalışıyordu. 10.15 sürümünde bu gidiş-dönüş yolculuğu çok fazla bilgi kaybına neden oldu ve ağırlık sorunu ortaya çıktı. Flutter, ağırlık sorununu fark etti ve yeniden boyutlandırma için alternatif bir düzeltme yapılarak CTFont içinde eski ancak belgelenmemiş bir özellik kullanılarak optik boyut doğrudan kontrol edilirken yeni CTFont doğrudan orijinal CTFont öğesinden oluşturuldu.CoreText Bu, 10.11'de işlerin çalışmaya devam etmesini sağlar ve diğer sorunları (ör. optik boyutu açıkça varsayılan değere ayarlama) düzeltir.
Ancak bu, yazı tipindeki CoreText "sihri" daha fazla korur. Bunlardan biri, trak tablosunun (Chromium'un, belgelenmemiş başka bir özellik aracılığıyla bastırmaya çalıştığı) dışında bir şekilde glif ilerlemelerini ayarlamaya devam etmesidir.
CGFont bu "sihir"lerin hiçbirini yapmıyor. Belki Chromium, CGFont'yı CTFont'dan çıkarıp sadece ilerlemeler elde etmek için kullanabilir mi? Maalesef bu yöntem işe yaramaz. Çünkü CoreText, yazı tiplerini başka şekillerde de bozmaktadır. Örneğin, küçük emojileri istediğinizden biraz daha büyük hale getirir (boyutlarını biraz artırır). CGFont bu durumdan haberdar olmadığı için emoji'leriniz birbirine çok yakın görünür. Bunun nedeni, emoji'leri tek bir boyutta ölçmenize rağmen CoreText tarafından biraz daha büyük çizilmesidir. Chromium, CTFont gelişmelerini istiyor ancak bunları izleme olmadan ve tercihen başka herhangi bir karışıklık olmadan istiyor.
Boşluk sorununu düzeltmek için bir dizi birbirine bağlı Blink ve Skia düzeltmesi gerektiğinden Chromium mühendisleri sorunu düzeltmek için "yalnızca geri dönemedi". 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üzeltse de aralık sorununu tekrarladı.
Düzeltme
Elbette Chromium sonunda her iki sorunu da düzeltmek istedi. Chromium artık sistem yazı tipinin yazı tipi tablolarındaki ikili verilerden doğrudan yatay metrikleri 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, Skia'da tamamen düzeltilmesini takip etmek ve HarfBuzz üzerinden geçen mevcut düzeltme yerine sistem yazı tipi metriklerini almak için Skia'yı kullanmaya geri dönmek üzere Skia Sorunu #10123'ü takip etmeye devam edebilirsiniz.