Arap tipografisi render etmenin şaşırtıcı deneyimi ve teknik borca interaktif bir giriş

 (lr0.org)
1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Arapça web tipografisi; harf bağlanması, çift yönlü metin, sayı ve noktalama işleme ile satır hizalamanın birlikte düğümlendiği bir render altyapısı sorunudur ve basit bir CSS hatası olarak ele alınması zordur
  • Klasik Arapça dizgide iki yana yaslama, kelimeler arası boşluğu artırmak yerine harflerin içindeki bağlantı çizgisini uzatan kaşida (kashida) ile uygulanıyordu; ancak modern tarayıcılardaki text-align: justify çoğunlukla kelimeler arası boşluğu artırır
  • Arapça harflerde kaydedilen tek bir kod noktası bağlama göre yalıtık, başta, ortada ve sonda biçimlerine dönüşür; OpenType özellikleri ve bir shaping engine olmadan harfler ayrık biçimde render edilir
  • Unicode’daki Arabic Presentation Forms, sayı sistemleri, UAX #9 çift yönlü algoritması ve görünmez kontrol karakterleri; arama başarısızlığı, telefon numarasının ters dönmesi ve imleç hareketinde karışıklık gibi gerçek ürün sorunlarına yol açar
  • HarfBuzz, Amiri, W3C Arabic Layout Requirements gibi temel altyapılar kurulmuş olsa da, tarayıcılardaki Arapça hizalama ve jstf kullanımı hâlâ bir uygulama boşluğu olarak duruyor

Başlangıç noktası: “CSS hatası” gibi görünen Arapça dizgi sorunu

  • Müşteri panosundaki karışık içerikli Arapça paragraf, tasarım maketindeki gibi iki yana yaslanmak yerine sol kenarı girintili çıkıntılı olacak şekilde render edildi
  • Aynı bloğun Latin harfli sürümü “idare eder” görünüyordu; ancak Arapçada satırlar sağdan başladığı için düzensiz kenar solda ortaya çıktı
  • text-align: justify uygulansa da, tasarım ekibinin onayladığı biçimde kelime içi çizgileri uzatarak satırı dolduramadı
  • Aynı üründe daha önce de PDF’lerde isim harflerinin ayrılması, arama indeksleme hataları ve eski Unicode kod noktaları gibi Arapça işleme sorunları tekrar etmişti
  • Sorunun özü belirli bir stil dosyasındaki kusur değil, web’in Arapça tipografi durumuydu

İstinsah geleneğinin çözdüğü problem

  • Klasik Arapça istinsah geleneği, kelimeler arası boşluğu büyütmeden harf formlarının içindeki bağlantı çizgisini uzatarak satırı iki yana yaslıyordu
  • Bu yöntem taṭwīl ya da modern teknik terimle kashida olarak adlandırılır ve belirli harf çiftleri arasındaki bağlantı çizgisinin uzatılmasına dayanır
    1. yüzyıl Naskh’ının iyi düzenlenmiş bir sayfasında iki kenar hizalıdır ve kelime aralığı artmadığı için yoğun, düzenli bir doku oluşur
  • Ibn Muqla’nın sistemleştirdiği al-khaṭṭ al-mansūb, kamış kalemin elmas noktasını, alif yüksekliğini ve yay oranlarını kullanarak harf biçimlerini düzenler
  • Bu gelenekte satır hizalama, boşluk dağıtımı sorunu değil; harf biçimlerini ve alternatif glifleri seçmeye dayanan bir shaping sorunuydu

Tek harf, dört biçim

  • Arapça her zaman el yazısı gibi bitişik akan bir yazıdır; matbaa harfi ile el yazısını ayıran blok harf ayrımı yoktur
  • Her harf komşularına göre yalıtık, başta, ortada veya sonda biçim alır; altı harf ise kendisinden sonrakine bağlanamadığı için kelime içi akışı keser
  • Unicode soyut harfi saklar, font konuma göre glifleri sağlar ve shaping engine isol, init, medi, fina, rlig, mark, mkmk gibi OpenType özelliklerini uygular
  • محمد gibi bir kelime depolamada dört kod noktasından ibarettir; ancak render sırasında çeşitli glif seçimleri ve OpenType aramaları üzerinden tek bir bitişik çizgi gibi görünür
  • HarfBuzz gibi bir shaping engine yoksa ya da PDF üreticisi bu aşamadan geçmiyorsa, aynı kod noktaları birbirinden kopuk yalıtık harfler olarak render edilir

Unicode’un fosili: Arabic Presentation Forms

  • DOS ve ilk Windows dönemindeki 8 bitlik kod sayfaları, soyut harfleri değil başta ya da ortada gibi biçimlerin kendisini ayrı karakterler olarak kodluyordu
  • Unicode bunu çift yönlü uyumluluk için kabul etti ve U+FB50 ile U+FEFF arasındaki Arabic Presentation Forms blokları olarak bıraktı
  • Yeni belgelere bu kod noktaları girmemeli, ancak PDF metin çıkarıcıları bugün bile bunları üretebiliyor
  • Aynı isim modern Unicode ile de Presentation Forms ile de saklanabilir; ekranda aynı görünse de dizge karşılaştırması ve aramada farklı işlenirler
  • NFKC normalizasyonu uygulanırsa Presentation Forms soyut harflere indirgenebilir ve arama kaçakları azaltılabilir

Shaping ve çift yönlü işlemeyi atlayan yazılımlar

  • Shaping engine’i ve çift yönlü algoritmayı atlayan yazılımlar, harfleri tek tek yalıtık biçimde çizer ve satırları soldan sağa dizer
  • Bu tür çıktı; dükkân tabelalarında, biniş kartlarında, filigranlarda ve eski film afişlerindeki Arapça yazımlarda Arapça okurların gerçekten karşılaştığı bir şeydir
  • Eski Photoshop sürümleri, varsayılan ayarlı matplotlib, npm’deki çeşitli PDF üreticileri ve fiş yazıcıları bu tür sorunlar çıkarabilir
  • Python’daki yaygın kaçamak çözüm arabic_reshaper ve python-bidi, önceden şekillendirilmiş biçimi dizgeye gömmek için Presentation Forms bloğunu kullanır
  • Bu çözüm, render katmanının yapması gereken işi önden dizgeye yazmak anlamına gelir ve özünde metin yığınının kusurunu açığa çıkarır

Üç tür rakam ve noktalama sorunu

  • Dünyanın “Arabic numerals” dediği 0–9, Arapça okurların çoğunun günlük hayatta kullandığı rakam şekli değildir
  • Mısır, Sudan, Levant, Irak ve Körfez bölgesi Unicode’un ARABIC-INDIC DIGITS ٠١٢٣٤٥٦٧٨٩ biçimini kullanır
  • Mağrip bölgesi Latin rakam gliflerini kullanırken, İran, Afganistan ve Pakistan EXTENDED ARABIC-INDIC DIGITS ۰۱۲۳۴۵۶۷۸۹ kullanır
  • Rakamlar UAX #9’da güçlü karakterler değil zayıf karakterlerdir; bu yüzden önceki güçlü karakterin yönüne göre Avrupa rakamı ya da Arap rakamı olarak yeniden sınıflandırılırlar
  • Arapça bir kelimenin ardından gelen 010-1234-5678 gibi telefon numaraları, tire nötr sayıldığı için ekranda 5678-1234-010 şeklinde ters sırada görünebilir
  • Platformların sunduğu çözüm, numarayı ‎ ya da <bdi> ile sarmalayarak yönlülüğü yalıtmaktır
  • Arapça konuşulan bölgelerde ondalık ve binlik ayırıcılar U+066B ٫ ve U+066C ٬ karakterleridir; ASCII . ve , neredeyse aynı görünse de kod noktaları ve çift yönlü özellikleri farklıdır

Baskıdan web’e uzanan kaçamaklar ve sadeleştirmeler

  • 1514’te Fano’da basılan Kitāb Ṣalāt al-Sawāʿī, hareketli harflerle basılmış ilk Arapça kitaptı ve harf bağlantılarının kopması ile nokta yerleşimi hatalarını gösteren bir örnektir
  • 1537’de Venedik’te basılan Paganini Qurʾān, dizgi ve metin hatalarının birleşmesiyle ticari başarısızlığa uğradı; tek bir nüsha 1987’de Venedik’teki bir manastır kütüphanesinde bulundu
  • Osmanlı’daki matbaa yasağı anlatısında Bayezid II ve Selim I’e ait fermanların asılları elde değildir; anlatı büyük ölçüde Avrupalı seyyah kayıtlarına dayanır
  • Kahire’deki Bulaq Press, 1820’de Muhammad Ali tarafından kuruldu ve yüzlerce harf parçası ile büyük sabır sayesinde Arapça metal dizginin kalitesini yükseltti
  • 1924 Kahire Kur’an’ı, Amiria Press’te metal harflerle üretildi ve 20. yüzyılda metin ile tipografinin standartlaşmasına katkı sağladı
  • 1950’lerin sonunda Kamel Mrowa ve Linotype, 90 kanallı dergi sistemine uyması için baştaki biçimleri ortadakilerle, sondakileri yalıtık biçimlerle birleştirip ligatürleri azaltarak Simplified Arabic geliştirdi
  • Simplified Arabic, ucuz ve hızlı gazete üretimini mümkün kıldı ve bir nesil içinde Arapça haber merkezlerine hâkim oldu

Web’in hâlâ çizemediği kaşida

  • CSS Text Module Level 3’ün ilk taslaklarında text-justify için kashida diye bir değer vardı ve Internet Explorer 5.5 bunu 2000 yılında uyguladı
  • IE 5.5 ayrıca text-kashida-space özelliğini de sunuyordu; ancak diğer tarayıcılar bunu uygulamayınca ilgili değer spesifikasyondan çıkarıldı
  • Güncel Chrome, Firefox ve Safari’de text-align: justify, Arapçada kelimeler arası boşluğu artırarak çalışır
  • CSS Working Group’un Arapça hizalama konusu en az 2015’ten beri açık ve W3C Arabic Layout Requirements çalışması da aynı yıl başladı
  • Kaşida ile hizalama zordur; çünkü uzatılan glif genişliği değiştirir, genişlik değişimi satır kırılımını ve gereken uzatma miktarını yeniden değiştirir; dolayısıyla shaping ile layout’un satır bazında tekrar tekrar uzlaşması gerekir
  • OpenType’ta 1990’lardan beri fontun hizalama önceliklerini bildirmesine yarayan jstf tablosu vardı; ancak shaping engine’ler bunu neredeyse hiç okumaz ve font geliştiricileri de neredeyse hiç sağlamaz
  • Microsoft Word ve InDesign Middle East Edition kaşida hizalaması sunar; ancak insanların en çok okuduğu tarayıcı render motorları harfleri uzatamaz

Tatweel hileleri ve ligatür ile hareke sorunları

  • Web’de yaygın bir kaçamak, doğrudan metne U+0640 TATWEEL karakteri ekleyerek uzatılmış bağlantı çizgisi görüntüsü vermektir
  • Tatweel içeriği değiştirdiği için arama eşleşmesi, kopyala-yapıştır, ekran okuyucular ve sütun yeniden akıtımı gibi alanlarda sorun çıkarır
  • Tatweel’in çizdiği çubuk, font ve harf kurallarına göre yerleşen bir kaşida değil; yazarın tahmin ederek eklediği daktilo tarzı bir çizgidir
  • OpenType ligatürleri rlig, liga, dlig olarak ayrılır; lām-alif gibi zorunlu ligatürler bozulduğunda mesele sadece çirkin görünmekten çıkıp yanlış yazıma dönüşür
  • U+200C ZERO WIDTH NON-JOINER harflerin arasına konursa kaydedilen harfler korunur ama render her harfi yalıtık olmaya zorlar
  • Safari "rlig" 0, "liga" 0 ayarlarını yok saydığı için zorunlu ligatürü kapatma demoları etkisiz kalır
  • Amiri, Khaled Hosny’nin 2011’de SIL Open Font License ile yayımladığı bir Naskh fontudur; 2022’deki 1.0 yeniden yazımından sonra kıvrımlı kaşida ve gelişmiş hareke istifleme sunar
  • line-height: 1 ile overflow: hidden bir kart bileşeninde birleştiğinde, tam harekeli Arapça metindeki üst harekeler kesilebilir

Çift yönlü algoritma ve yalan söyleyen imleç

  • Arapça bir paragraf içindeki sürüm numaraları, İngilizce tanımlayıcılar, URL’ler ve Fransızca kelimeler Unicode Çift Yönlü Algoritması UAX #9’u devreye sokar
  • Arapça harfler güçlü sağdan sola karakterler, Latin harfleri güçlü soldan sağa karakterler, rakamlar bağlama uyan zayıf karakterler, boşluk ve noktalama ise nötr karakterlerdir
  • Algoritma her karaktere bir yön sınıfı atar, zayıf ve nötr karakterleri aşamalı olarak yorumlar, ardından gömme seviyeleri verip aynı seviyedeki dizileri ters çevirir
  • Ekrandaki görsel sıra ile bellekteki mantıksal sıra farklı olduğu için imleç hareketi, fare tıklaması ve seçim davranışı bu iki sıra arasında sürekli çeviri yapmak zorundadır
  • Çalışma dizisi sınırlarında mantıksal konum ve görsel konum diye iki meşru imleç yeri vardır; Chrome, Firefox, Qt ve Outlook bunları birbirinden farklı ele alabilir
  • Arapça-İngilizce karışık metin yazmak, 2026’da bile büyük editörlerde, e-posta istemcilerinde ve sohbet uygulamalarında varsayılan olarak bilişsel yükü yüksek bir deneyim olmaya devam ediyor
  • الصفحات 10-20 gibi bir aralık, W2 kuralı ve nötr tire işleme nedeniyle “20’den 10’a” gibi görünebilir; bunu düzeltmek için başına U+200E LEFT-TO-RIGHT MARK eklenebilir

Çalışan temel ve kalan boşluk

  • Khaled Hosny, Amiri’yi yaptı; HarfBuzz komut satırı aracı hb-shape’i yazdı ve ayrıca HarfBuzz’ın ortak bakımcılarından biri oldu
  • Behdad Esfahbod, Hosny’den önce HarfBuzz’ın büyük bir kısmını yazdı ve bugün tarayıcılarda Arapça harfleri doğru çizen shaping engine’e katkıda bulundu
  • Brill, Semitics kataloğunda gereken tüm çevriyazı karakterlerini kapsamak için John Hudson’a Brill yazı tipini sipariş etti ve bunu 2011’de ticari olmayan kullanım için ücretsiz yayımladı
  • Sakhr AX-170, yaklaşık 1984’te ROM’dan Arapça görüntüleyen Suudi-Kuveyt ortak yapımı bir MSX bilgisayardı ve sağdan sola yazılan Arabic BASIC tanımlayıcılarını destekliyordu
  • HarfBuzz, Amiri, Scheherazade, GNU Unifont’un Presentation Forms desteği, Noto Arabic ve W3C Arabic Layout belgeleri; az sayıda kişi, kurum ve gönüllünün çabasına büyük ölçüde bağımlı kaldı
  • Tarayıcı üreticileri HarfBuzz ücretsiz ve tamamlanmış hâle geldikten sonra bunu benimsedi; ancak istinsah geleneğindeki hizalama yöntemini ekranda uygulayacak layout döngüsüne neredeyse hiç katkı sunmadı
  • Kalan fark, birkaç layout engine’de uygulanması gereken iyi anlaşılmış algoritmalardan ibaret; müşteri panosundaki pürüzlü sol kenar da bu yatırım eksikliğinin kullanıcıya görünen yüzüdür

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Lobste.rs yorumları

  • Gerçekten muhteşem bir yazı
    Ayrıca şu karakterin ﷽ tek bir kod noktası olması da hoşuma gidiyor. Kopyalayıp deneyince insanı şaşırtıyor
    Anlamı da “Rahman ve Rahim olan Allah'ın adıyla” imiş

    • ﷽ hakkında yazıdaki şu cümle şiirsel:
      “Render motorlarına kimsenin güvenmediği için render işleminin encoding'in içine gömüldüğü bir dönemin anıtı. Tıpkı kehribarın içinde sonsuza dek korunmuş bir resitasyon sineği gibi”
    • Bu Unicode karakteri burada da ele alınmıştı: https://lobste.rs/s/7s4sjp
      Orada referans verilen Wikipedia bağlantısının kaynaklarını takip etmek de eğlenceliydi: https://lobste.rs/c/dq2ucz
      Kısacası, bu karakterin Unicode'a girmesinin nedeni Pakistan kod sayfasında zaten bulunmasıydı; oraya girmesinin nedeni de hukuki belgelerde bu ifadenin yer almasını zorunlu kılan yasal bir gereklilik olmasıydı. Urdu, Hint-Avrupa dil ailesine ait bir dil olduğu için, o dönemin teknolojisiyle Basmala yazmak amacıyla Arapça kod sayfasına bir tür “dış çağrı” yapar gibi geçiş yapmak zor olmuş olmalı
      Ne yazık ki tüm yorumlar o topluluğun güçlü yanlarını göstermiyor

  • Meta: Böyle yazılar için typography etiketi gerektiğine dair bir harika örnek daha

    • Neden gerektiğini bilmiyorum. Konu epey popüler görünüyor; gerçekten bu tür içeriği gizlemeye yönelik güçlü bir talep mi var?
      lobste.rs'de etiketler esas olarak filtreleme için kullanılıyor

  • IE'nin text-justify özelliği ha, o dönemde ilginç şeyler çoktu. text-justify: newspaper da vardı; onlarca yıl sonra bazıları bunu Knuth-Plass ya da benzeri bir şeyle açıkladı ama gerçekten öyle olduğuna inanmıyorum
    https://mediumwell.com/wp-content/uploads/… bağlantısı, o zamanlar text-justify: newspaper denilen davranışın bugünkü spesifikasyondaki text-justify: inter-character ile örtüştüğünü gösteriyor
    IE, gerçekten oldukça erken bir dönemde birçok havalı özellikle gelmişti ve diğer tarayıcılar bunları “fazla zor” sepetine bırakmıştı. Sonunda ya hiç geri dönmediler ya da ancak 15 ya da 30 yıl sonra geri geldiler. Firefox text-justify: inter-character desteğini 2017'de aldı, Chromium bu kısmı ancak birkaç ay önce uyguladı, Safari'de ise hâlâ yok

  • İnanılmaz derecede iyi ve öğretici bir yazı. Tüm anlatıya geniş bir bağlam kazandıran tarihsel arka planı özellikle sevdim
    Hem tarih alanında derecesi hem de BT kariyeri olan biri olarak, iki ilgi alanıma da kusursuz biçimde dokunan bir yazıydı

  • Yazının bazı kısımları bende LLM dedektörünü tetikliyor, bu üzücü. Çünkü derinliği var ve modern teknoloji yığınında daha az belgelenmiş alanları ele alıyor
    LLM işi gibi duran örneklerden biri şu; aslında yazının genelinde böyle bir hava var:
    “Bunu hiçbir tarayıcının sunmamasının nedeni yapısal ve engel olarak bu yapı oldukça zarif. Latin hizalama, şekillendirilmiş metni sabit kabul eder, kelimeleri ölçer, artan boşluğu aralıklara döker ve işi bitirir. Şekillendirme ile yerleşim kendi kutularında kalır ve bugün çalışan her metin yığını bu ayrımın etrafında tasarlanmıştır. Kashida hizalaması ise o kutuyu açıp dağıtır.”
    @lr0'a sormak isterim: Bu yazının gövdesi LLM ile üretildi, düzenlendi ya da çevrildi mi? Eğer öyleyse, son çıktı üzerindeki LLM kontrol seviyesini ayarlamak iyi olabilir. Önceki blog yazıları, örneğin https://lr0.org/blog/p/gpt/ ve https://lr0.org/blog/p/linux_new_users/ çok daha insan eli değmiş gibi hissettiriyordu