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.

Dominik Röttsches
Dominik Röttsches

CSS Yazı Tipi Modülü Düzey 4 spesifikasyonunun "system-ui" bölümü, geliştiricilerin yerleşik, turbo için optimize edilmiş, yerelleştirilmiş, mega yüksek kaliteli, 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 kelimesini tanımlar.

body {
  font-family: system-ui;
}

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

macOS'teki system-ui yazı tipi San Francisco'dur. San Francisco, bir tasarım ekibinin incelediği, test ettiği ve yakın zamanda yeni sürüme geçirdiği bir yazı tipidir. İlk olarak Catalina'daki yeni heyecan verici değişken yazı tipi özelliklerini ele alacağız, ardından birkaç hataya ve Chromium mühendislerinin bunları nasıl çözdüğüne değineceğiz.

Bu gönderide, değişken yazı tipleri hakkında bilginiz olduğu varsayılmıştır. Bu mümkün değilse Web'de değişken yazı tiplerine giriş bölümüne ve aşağıdaki videoya göz atın.

Tarayıcı uyumluluğu

Bu yazının yazıldığı sırada system-ui, Chromium (56 sürümünden itibaren), Edge (79'dan itibaren), Safari (11'den itibaren) ve Firefox'tan (43'ten itibaren) ancak -apple-system anahtar kelimesinden destek almıştır. Güncellemeler için Değişken yazı tipleri kullanabilir miyim? bölümüne bakın.

Yeni güçler

Catalina'nın sistem yazı tipine getirdiği yeni özellikler, Chromium 83 sürümünden itibaren web geliştiricilerinin kullanımına sunuldu. system-ui yazı tipinin artık daha fazla değişken ayarı var: optik boyutlandırma ve 2 benzersiz ağırlık ayarlaması:

Mojave Dili
h1 {
  font-family: system-ui;
  font-weight: 700;
  font-variation-settings:
    'wght' 750
  ;
}

Katalina
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ı olan değişken bir yazı tipidir. system-ui ise Catalina'da wght, opsz, GRAD ve YAXS ayarlarına sahip değişken bir yazı tipidir.

Progresif geliştirme tasarımı için kıymetli fırsatlar olduğunu düşünüyorum. Dilerseniz sistem yazı tipinin inceliklerini inceleyebilirsiniz.

wght

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

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

opsz

Optik boyutlandırma, aralık veya harf aralığına benzerdir, ancak boşluk matematik yerine insan gözü tarafından yapılır. 19 veya daha düşük bir değer metin ve gövde metni aralığı için kullanılırken 20 veya üstü, görüntüleme başlıkları ve başlıkları arasında boşluk bırakmak için kullanılır.

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

GRAD

Ağırlığa benzer, ancak yatay boşluğa dokunulmaz. 400 ile 1000 arasındaki değerleri kabul eder.

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

YAXS

Glifi dikey olarak genişletir. 400 ile 1000 arasındaki değerleri kabul eder.

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

Seçenekleri birleştirme

Birkaç satırlık CSS ile yazı tipi ayarlarını değiştirerek kalın bir hale getirebilir veya diğer ilginç kombinasyonları deneyebiliriz:

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

İşte tam da bu şekilde, macOS'teki Chromium kullanıcıları başka eğlenceli ayarlarla birlikte yükseltilmiş, özel 750 ağırlığınızı görüyor 👍

Playground

Arızanın düzenlenebilir bir kopyasını almak için aşağıdaki Arıza bölümünde Düzenlenecek Remiks'i tıklayın ve ardından, yazı tipini nasıl etkilediğini görmek için yeni font-variation-settings seçeneklerini düzenleyin. Bu hatanın yalnızca macOS Catalina cihazıyla çalışacağını unutmayın.

macOS 10.15, sistem yazı tipine yeni özellikler ekledi ve macOS 10.15'te Chromium hata izleyiciye yanıltıcı bir system-ui hatası kaydedildi. İlişkili olup olmadıklarını merak ediyorum!

Ek: system-ui regresyonu

Bu hikaye farklı bir hatayla başlıyor: #1005969. Bu durum, system-ui yazı tipi aralığı dar ve sıkışık göründüğünden macOS 10.15 ile ilgili olarak bildirildi.

Bir Facebook grup sayfasındaki iki paragrafın karşılaştırması. Solda Chrome, sağ tarafta Safari yer alır. Chrome'da boşluk kullanımı hafiftir ancak biraz daha dardır.
Chrome soldaki (daha sıkı izleme), sağda Safari (daha iyi optik boşluk)

Arka plan

macOS 10.14'te, boyutu büyütüldüğünde veya düştüğünde paragraflarınızın veya başlıklarınızın nasıl farklı görünümlü bir yazı tipine "yerleştirildiği"ni 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ş yaptı. Metin 20px altındayken macOS, "San Francisco Metni" seçeneğini kullandı. Metin 20px veya daha büyük olduğunda macOS "San Francisco Display" özelliğini kullandı. Optik boyutlandırma, statik olarak iki ayrı yazı tipinde oluşturuldu.

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ü" öğelerinin yönetilmesi gerekmiyor. Ayrıca, daha önce açıklanan yeni varyasyon ayarını opsz da kazanmıştır.

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

Maalesef yeni Catalina yazı tipindeki varsayılan opsz değeri 20 ve Chromium mühendisleri sistem yazı tipine opsz uygulamak için hazır değildi. Bu durum, daha küçük boyutların çok dar gösterilmesine neden oldu.

Bunu düzeltmek için Chromium'un, opsz öğesini sistem yazı tipine doğru şekilde uygulaması gerekiyordu. Bu nedenle, 1005969 numaralı sorun giderildi. Zafer! Yoksa...?

Henüz tamamlanmadı

Sorun burada oluştu: Chromium opsz özelliğini uyguladı ancak bir şey düzgün görünmüyordu. Mac'teki sistem yazı tiplerinde, yatay boşluk bırakmasını sağlayan trak adlı ek bir yazı tipi tablosu bulunur. Chromium mühendisleri sorunu düzeltmeye çalışırken macOS'te bir CTFontRef nesnesinden yatay metrikler alırken trak metriklerinin metrik sonuçlarına zaten dahil edildiğini fark etti. Chromium'un şekil verme kitaplığı HarfBuzz, trak değerlerinin henüz hesaba katılmadığı metriklere ihtiyaç duyar.

Sistem arayüzü, tüm yazı tipi ağırlığı ve varyasyonları bir listede gösterilir. Bunların yarısına ağırlık farkı uygulanmamıştır.
Sol: 19 ve daha küçük yazı tipi boyutlarına uygulanan kalın ağırlıklar. Sağ: 20 ve üzeri yazı tipi boyutlarında kalın stil kaybedilir

Dahili olarak Skia (aynı adın yazı tipi değil, grafik kitaplığı) hem CoreGraphics kapsamındaki CGFontRef sınıfını hem de CoreText kapsamındaki CTFontRef sınıfını kullanır. Bu nesneler arasındaki dahili dönüşümler (geriye dönük uyumluluğu korumak ve her iki sınıfta 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, 1057654 numaralı sorun sayfasında takip edildi.

Chromium hâlâ macOS 10.11'i desteklediği için Skia'nın macOS 10.11'i desteklemesi gerekmektedir. 10.11'de"San Francisco Metin " ve"San Francisco Ekranı" yazı tipleri değişken yazı tipleri bile değildi. Aksine, bunların her biri, mevcut her ağırlık için ayrı bir yazı tipi ailesiydi. Bir noktada glif kimlikleri birbirleriyle senkronize değildi. Yani Skia, "San Francisco Metni" ile metin şekillendirme (metni, çizilebilecek gliflere dönüştürme) yaptıysa, "San Francisco Display" ile çizildiğinde bu metin anlamsız olur ve bunun tersi de geçerlidir. Ayrıca Skia farklı boyutta bir macOS talep etse bile diğer sürüme geçebilir. Her zaman yazı tiplerinden birini kullanmak ve yalnızca ölçeklendirmek (daha büyük boyut istemek yerine ölçeğini büyütmek için bir matris kullanarak) gerekebilir. Ancak CoreText, sbix (renk emojisi) gliflerini yukarı (yalnızca aşağı) ölçeklendirmeyle ilgili bir sorun yaşıyor. Bu, bundan biraz daha karmaşıktır. CoreText, matris uygulamasından sonra dikey alanı sınırlandırıyor gibi görünüyor. Bu da 45 derecelik açılarda emoji çizememesiyle ilgili görünüyor. Emojinizin büyük görünmesini istiyorsanız her halükarda emojinizin büyük halini almak için yazı tipinin bir kopyasını oluşturmanız gerekir.

Dolayısıyla Chromium, aynı temel yazı tipi verilerinin kullanıldığından emin olarak dahili olarak farklı boyutlarda CTFont nesnelerin kopyalarını oluşturmak için CGFont öğesini CTFont öğesinden çıkardı, ardından CGFont öğesinden yeni bir CTFont işlemi gerçekleştirdi (CGFont nesne boyuttan bağımsızdır, sihirli geçiş CoreText düzeyinde gerçekleşir). Bu durum 10.154'e kadar sorunsuz çalıştı. 10.15'te bu gidiş dönüş çok fazla bilgi kaybetti ve bu da kilo sorununa yol açtı. Flutter, ağırlık sorununu fark etti ve yeni CTFont öğesini doğrudan orijinal CTFont öğesinden oluşturmak ve CoreText ürününde eski ancak belgelenmemiş bir özelliği kullanarak optik boyutu doğrudan kontrol etmek için yeniden boyutlandırmayla ilgili alternatif bir düzeltme yapıldı. Bu, 10.11'de çalışır durumda olmaya devam eder ve diğer sorunları (optik boyutu açıkça varsayılan değere ayarlamak gibi) düzeltir.

Ancak bu şekilde yazı tipindeki CoreText "sihirli" özelliğinin daha büyük bir kısmını korur. Bunlardan biri, trak tablosu (Chromium'un halihazırda bildirilmemiş başka bir özelliği engellemeye çalıştığı uygulama) dışında glif ilerlemelerinde bazı değişiklikler yapmaya devam ettiği görülüyor.

CGFont bu "sihir"den hiçbirini yapmıyor. Peki Chromium, CTFont üzerinde CGFont indirimden yararlanarak sadece ilerleme elde etmek için kullanabilir. CoreText ürününün yazı tiplerini başka şekillerde de değiştirdiği bilindiğinden, maalesef bu işe yaramaz. Örneğin, küçük emojilerin gerçekten istediğinizden biraz daha büyük olmasını sağlar (boyutunu biraz artırır). CGFont adlı kullanıcının bundan haberi olmadığı için emojileri tek bir boyutta ölçtüğünüz için sbix tabanlı emojileriniz birbirine çok yakın olur. Ancak CoreText emojileri belirli bir boyutta büyütür. Chromium, CTFont ilerlemelerini istiyor ancak bunları takip etmeden ve tercihen başka hiçbir endişe olmadan istiyor.

Boşluk bırakma sorununun çözümü, birbirine bağlı Blink ve Skia düzeltmelerinin yapılmasını gerektirdiğinden Chromium mühendisleri sorunu "geri döndüremedi". Chromium mühendisleri, Skia'da yazı tipiyle ilgili bir kod yolunu değiştirmek için farklı bir derleme bayrağı kullanmayı denedi. Bu şekilde kalın yazı tipi sorunu düzeltildi, ancak boşluk bırakma sorunu geri alındı.

Çözüm

Sonuç olarak 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 yerleşik yazı tipi OpenType yazı tipi metrikleri işlevlerini kullanmaya başlıyor. Chromium, bunu kullanarak yazı tipinin trak tablosu olduğunda (emoji yazı tipinin olmadığı durumlar hariç) CoreText ve Skia'nın kullanımını kaldırıyor.

Sistem arayüzü, tüm yazı tipi ağırlığı ve varyasyonları bir listede gösterilir. Önceden çalışmayan bu yarısı artık çok iyi görünüyor.

Bu süre zarfında, Skia Sorunu No.10123 hâlâ mevcuttur. Bu sorunu Skia'da tamamen düzeltmeyi takip edebilir ve HarfBuzz ile uygulanacak mevcut düzeltme yerine Skia'yı sistem yazı tipi metriklerini geri almak için oradan alabilirsiniz.