Justif - Web için Knuth-Plass iki yana yaslama ve mikro tipografi

 (justif.lyall.co)
1 puan yazan GN⁺ 2 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Justif, tarayıcının varsayılan render çıktısı ile yayın kalitesinde metin iki yana yaslamayı doğrudan karşılaştıran bir web demosudur
  • Tireleme ve karakter taşması, genişlik esnetme, harf aralığı ayarı ve son satır boşluk dengelemesi ayrı ayrı yapılandırılabilir
  • Minimum son satır genişliği ile noktalama dışa taşması aralığı ayarlanabilir ve text-wrap: pretty uygulamasının sonucu ile de karşılaştırma yapılabilir
  • Yalnızca İngilizce edebiyat ve teknik metinler değil, İbranice ve Arapça RTL metinler ile Japonca da serif, sans ve monospace yazı tiplerinde test edilebilir
  • Satır sayısı, tireli satır sonları, taşan satırlar, kısa son satırlar, boşluk sapması ve river'lar tarayıcı render çıktısıyla yan yana ölçülür

İki yana yaslama ve ayrıntılı ayarlar

  • Justif, web üzerinde Knuth-Plass iki yana yaslama ve çeşitli mikro tipografi özelliklerini test edebilmek için hazırlanmıştır
    • Tireleme
    • Karakter taşması
    • Genişlik esnetme
    • Harf aralığı ayarı
    • Son satır boşluk dengelemesi
  • Noktalama dışa taşması, karakter taşması etkinleştirildiğinde kullanılabilir ve satır sonuna, ilk satır başlangıcına veya tüm aralığa uygulanabilir
  • Minimum son satır genişliği 0.33, metin genişliği ise 13em olarak ayarlanabilir

Metin·yazı tipi karşılaştırması ve ölçümler

  • Alice in Wonderland, Frog Prince, Frankenstein, Ulysses, teknik yazılar, RFC 2324 ve yazı tipi örnekleri arasından karşılaştırılacak metin seçilebilir
  • İbranice ve Arapça RTL metinler ile Japonca metinler de sunulur
  • Desteklenen yazı tipleri arasında Junicode, EB Garamond, Alegreya, IM Fell English, Vollkorn, Amstelvar, Latin Modern, Georgia, Roboto Flex, Courier Prime, IBM Plex Mono ve sistem yazı tipleri bulunur
  • Sonuçlara tıklanırsa veya uzun basılırsa tarayıcının varsayılan render çıktısı görünür ve Justif render çıktısıyla karşılaştırılabilir
  • Karşılaştırma araçları text-wrap: pretty, bulanıklaştırma, kenar boşluğu cetveli ve düzensiz boşluk gösterimini destekler
  • Ölçüm öğeleri; satır sayısı, tireli satır sonları, taşan satırlar, kısa son satırlar ve river'ların yanı sıra ortalama boşluk, doğal boşluğa göre ortalama sapma, standart sapma ve en geniş boşluğu içerir

İlgili okumalar

1 yorum

 
GN⁺ 2 시간 전
Lobste.rs yorumları

  • Bu proje Fable ile vibe coding yapılarak geliştirilmiş: https://news.ycombinator.com/item?id=48946738#49002419

    • Yazının konusu vibe coding olmadığı hâlde bu etiketin gerçekten gerekli olup olmadığını merak ediyorum.
      LLM kullanım deneyimleri okumakla ilgilenmiyorum ve bunları filtrelemek istiyorum; ama pratikte, yalnızca bir kodlama yardımcısı kullanıldığına dair şüphe olsa bile, metinle ilgisi olmasa da etiket ekleniyor gibi görünüyor.
      Bu sefer kullanım açıkça ortada, ama sırf kodlama yardımcısı kullanan katkıcıları kabul ettiği için proje yazılarına etiket konduğunu da gördüm.
    • Bu projeyi yaparken LLM kullandığımı çekinmeden kabul ediyorum.
      Ancak vibe coding terimi ve burada kullanılan etiket artık faydasını yitirdi; LLM kullanımını konu alan yazılar ile üretim sürecinde tesadüfen LLM kullanılmış çıktıları ayıran daha doğru ve üretken bir ifadeye ihtiyaç var.
    • Istakoz 1: “Kanseri tedavi eden bir ilaç geliştirmişler!”
      Istakoz 2: “Evet… ama AlphaFold ve CRISPR, bir de… davul sesleri… Fable kullanmışlar.”
      Istakoz 1: “Aman Tanrım, kabul edilemez! İnsanlık uğruna hepsini çöpe atalım ve proteinleri kara tahtaya pastel boyayla çizmek için 40 yıl harcayalım!”

  • Çıktı çok etkileyici; microtype paketi kullanılmayan TeX’ten bile daha iyi.
    Bu tür dizgi özelliklerini tarayıcıların doğrudan halletmesi gerekir.
    Bazı tarayıcılar text-wrap: pretty uyguladı, ama sanki birkaç satırla sınırlı gibi.

    • Güncel Safari’de pretty düzgün uygulanmış durumda, ancak justify ile birlikte kullanıldığında bir hata var.
      https://matklad.github.io/2026/02/14/justifying-text-wrap-pretty.html
    • text-wrap: pretty spesifikasyonuna bakınca, davranışı tanımlanmamış saf bir ipucu olduğunu görüyorsunuz.
      Kullanıcı aracısının hız yerine daha iyi yerleşimi önceliklendirmesi ve satır sonlarını belirlerken birden fazla satırı dikkate alması gerektiği kadarını söylüyor; bunun dışında auto ile aynı.
      Aşırı kısa son satırları, satırlar arasında nehir gibi görünen boşlukları, art arda gelen tireleri vb. önleyebilir; ama tam olarak nasıl iyileştireceği tarayıcıdan tarayıcıya değişir.
      Birden fazla tarayıcı bunu birbirinden farklı uygulayacağını söyleyince, aşırı kısıtlamadan kaçınmak için spesifikasyona bu şekilde girdiğini hatırlıyorum.
      Bu, uygulamaların sonunda SQLite kullanacağı gerçeği açığa çıktığı için Web SQL’in kaldırılmasına benzer bir durum.
      Bir gün bu özelliklerin text-wrap: auto içinde varsayılan hâle gelip text-wrap: pretty’nin hiçbir etkisi kalmamasını umuyorum; ayrıca https://bugzilla.mozilla.org/show_bug.cgi?id=630181 ’in de uygulanmasını bekliyorum.
      Bu tür ipuçları yeni değil; will-change de önceki nesil tarayıcılar için bir optimizasyon ipucuydu.
      Standartlaştırıldığı sıralarda Firefox’ta büyük ölçüde gereksizdi, bazı yeni nesil motorlarda ise hiç işe yaramıyordu; buna rağmen ağır biçimde kötüye kullanıldı. Belki de açıkça bir hile olan transformZ(0)ı korumak daha iyi olurdu.
    • İdeal bir dünyada bu kütüphanenin var olmasına gerek kalmazdı.
      Demoda text-wrap: pretty ayarını değiştirerek tarayıcıya göre davranışları deneyebiliyorsunuz; Blink·WebKit·Gecko’nun işleme biçimleri şaşırtıcı derecede farklı, bu yüzden birkaç tarayıcıda denemenizi öneririm.

  • Asılı noktalamanın genel olarak fazla uygulandığını uzun zamandır düşünüyorum.
    Göze çarpıyorsa zaten aşırıya kaçılmıştır; özellikle “ neredeyse her zaman belirgin durur, bu yüzden bugünkünün yarısından bile az dışarı taşmalı.
    Buna karşılık paragraf başındaki “ işaretinin küçük bir girinti gibi işlev görmesi hoşuma gidiyor.
    Asılı noktalama kapatılıp daha ince bir taşma açık bırakıldığında sonuç katlanılır, ama çoğu durumda ikisini de kapatmayı tercih ederim.
    Bu tür işlem yazı tipine çok bağlı.
    Kullandığım serif yazı tipi Equity’de satır sonundaki “f,” için bunu uygulayınca, kerning nedeniyle virgül zaten f’nin altına girmiş oluyor ve f’nin üst kısmına kadar satır dışına taşıyor; bu da tuhaf duruyor.
    Serif yazı tipleri harflerin kuyruklarını ya da çıkıntılarını karakter genişliğinin dışına koyarak doğal biçimde taşırıyorsa, bunlar çoğu noktalama işaretinden daha uygun hedefler olabilir.
    Harf aralığı ayarlamasında letter-spacing ligatürlerle iyi uyuşmadığı için riskli.
    Ligatür önce uygulanırsa “T h i s i s fi n e!” gibi olur; sıfır olmayan letter-spacing ligatürü kapatırsa da f, i’nin noktasıyla çarpışır.
    Genellikle ikincisi görülür, ama yazı sistemine, yazı tipine ve açıkça etkinleştirilmiş OpenType özelliklerine göre değişir; istemeden ortaya çıkması da kolaydır.

    • Kişisel olarak asılı noktalamanın görünümünü seviyorum, ama elbette ayarlarla değiştirilebilir.
      Ligatürler yüzünden harf aralığı ayarlamasının zor olduğuna katılıyorum; ancak varsayılan sınır olan ±%3 ile iyi göründüğünü düşünüyorum.
      “Type Specimen” örneğinin ilk paragrafının sonunda fl, fi, ffi ligatürlerinin art arda geldiği kısmı görebilirsiniz; %3 sınırı da ayarlanabiliyor.
    • Bazı İsveç sitelerinde açılış sağ çift tırnağının önceki satırın sonunda tek başına kalıp beni sinirlendirdiği olguyu noktalama asması açıklıyor olabilir.
      İsveççede alıntıların başında da sonunda da yalnızca sağ çift tırnak kullanılır.
      Belirli bir metnin dilini ya da yerel ayarını tarayıcıya bildirip tırnak işaretleri ve ondalık ayırıcılar gibi şeyleri otomatik işlettirmenin bir yolu olup olmadığını uzun zamandır merak ediyorum.

  • Örneklerin, iyileştirme etkisini vurgulamak için yapay biçimde dar satır genişliği kullandığını belirtmek isterim.
    Genelde bir satır için küçük harfli alfabenin iki seti kadar, yani yaklaşık 60 karakter genişlik uygun önerilir.

    • Eski gazete sütunlarının genişliği de örneğe benzerdi diye düşünüyorum; ama bu, bugün izlenmesi gereken ölçüt olduğu anlamına gelmez.
    • Sütun genişliğini artırıp gerçekçi gövde metni genişliğinde karşılaştırma yapabilirsiniz.
      Fark çok daha az dramatik, ama hâlâ açık; 36em satır genişliğinde bile istatistikler varsayılandan çok daha iyi çıkıyor.

  • Başka bir sitede yazarın LLM kullandığını söylemesi nedeniyle mi vibe coding etiketi kondu, merak ediyorum.
    Bağlantının içeriği LLM veya vibe coding ile ilgisiz, bu yüzden bu etiket artık cadı avı gibi hissettiriyor.

    • Daha iyi niyetli bakarsak, bunun nedeni etiketin iki rol üstlenmesi; bir yazının vibe coding’i ele aldığını belirtmenin yanında, sık sık tetikleyici unsur uyarısı olarak da kullanılıyor.
      Daha açık olan kullanımla çakıştığı için kafa karıştırıcı ve gereğinden saldırgan görünebilir.
      Tek bir etiketin iki amacı olması ideal değil; yine de genel olarak tetikleyici unsur uyarılarını ve görmek istemediğiniz içerikleri serbestçe filtreleyebilme özelliğini destekliyorum.
      Kafa karıştırıcı bir etiket olsa da en azından yazara bir zarar vermiyor.