Taşınabilir EPUB’lar

 (willcrichton.net)
1 puan yazan GN⁺ 2024-01-27 | 1 yorum | WhatsApp'ta paylaş

İlgili okumalar

1 yorum

 
GN⁺ 2024-01-27
Hacker News yorumları

  • E-kitaplar, güvenlik ve LowJS web kesişimine çok ilgi duyduğum için bu konu bana önemli geliyor
    Tek dosya olarak taşınabilir bir e-kitap biçimine ihtiyaç var; ancak PDF metnin yeniden akışına izin vermediği için cevap değil
    2024’te HTML+CSS, neredeyse tüm basılı medyayı yeniden üretebilirken metnin yeniden akmasını da mümkün kılıyor
    JavaScript’in zorunlu olması gerektiğini düşünmüyorum. E-kitap, boyutu anlamlı biçimde değiştirilebilen bir kitap olmalı; JavaScript kapalıyken de kitap olarak temel işlevleri çalışmalı. Etkileşim veya zenginleştirme gerekiyorsa JavaScript kullanılabilir; ama JavaScript olmadan kitap gibi çalışmıyorsa bunu bir hata olarak görürüm
    Tüm stilleri inline koymanın bazı kullanıcıların CSP’sini bozabileceği için yanlış olduğunu düşünüyorum. Stilleri HTML’e göre göreli yol kaynakları olarak ayırmalı ve e-kitap başka alan adlarından kaynak yüklenmesini yasaklamalı
    Son olarak, basitçe zip dosyası olarak dağıtılabilir. E-kitaplar zaten bu şekilde çalışmıyor mu diye düşünüyorum

    • “E-kitaplar zaten zip gibi mi çalışıyor?” sorusu bir ölçüde doğru. Unzip araçları EPUB dosyalarını açabilir; gerekirse uzantıyı .epub’dan .zip’e değiştirmek yeterli
      Ancak tersi yönde bu her zaman geçerli değil. Aynı dosya paketi açılmadan önce geçerli bir EPUB olsa bile, gelişigüzel yeniden zip’lenirse geçerli bir EPUB olmayabilir
      EPUB zip’i içindeki mimetype dosyası özeldir: arşivin ilk girdisi olmalı, içeriği yalnızca application/epub+zip olmalı ve sıkıştırılmadan saklanmalıdır
      Şaşırtıcı derecede çok zip aracı dosya sırasını değiştirerek veya yalnızca bazı dosyaları sıkıştırmadan saklamayı zorlaştırarak bunu zahmetli hale getiriyor. Komut satırı zip programlarında bu genellikle bayraklarla mümkün, ama zip kütüphanelerinde epey acı verici. EPUB oluşturma yazılımı geliştirme deneyimimden konuşuyorum
    • Sıradan zip dosyaları ile e-kitapları ayırt etmek önemli. Uzantı olarak .epub kullanılmalı
      Anlatılan şey, HTML, CSS ve görsel dosyalarının bir zip arşivine konduğu ePub biçimi
    • Kendini açan ZIP nasıl olur diye düşünüyorum. Örneğin şu sayfa gibi: https://gildas-lormeau.github.io/
      Güvenli hale getirmek için CSP de içeriyor
    • Her şeyi zip’e koyma yaklaşımını pek sevmiyorum
      Eski .doc dosyalarını .docx’e göre kullanırken sevdiğim şey, yüzlerce-binlerce dosyanın bulunduğu bir klasörde belirli bir kelimeyi çok hızlı arayabilmekti. Zip biçiminde bu mümkün değil
      Az önce .doc olarak kaydedip hex editörde açtım; gerçek içerik düz metin olarak duruyordu. Zip biçimini veya PDF dosyalarını grep ile aramak zor; birkaç bin karakterlik metin için sıkıştırmanın gerçekten gerekli olup olmadığından da şüpheliyim
    • “2024’te HTML+CSS neredeyse tüm basılı medyayı yeniden üretebilir” deniyorsa, şuna da bakmaya değer: https://www.princexml.com/samples/

  • Nota geliştiricisinin yazdığı, EPUB biçimini PDF ile aynı seviyeye çıkarmaya çalışan çok iyi kurgulanmış bir yazı. Zaten bir görüntüleyici de yapmış; yazının kendisi de bu görüntüleyicinin tarayıcı tabanlı WASM portu ile gösteriliyor
    Sorunlardan biri, fiilen XHTML olan EPUB’ın yerleşimi ne kadar doğru yeniden üretebileceği. Orijinal yazının ölçütü belgenin “makul görünmesi”; PDF ile boy ölçüşmesi için en azından satır sonlandırma tarafında HTML’e yeni yerleşim özellikleri gerektiği ima ediliyor
    İlerlemek için iki yol var gibi görünüyor. Biri tarayıcıların daha fazla tipografi aracı sunması; text-wrap: pretty yardımcı oluyor deniyor ama kısa bir testte satır sonlandırma kalitesinin arttığını görmedim. Diğeri satır sonlandırmayı önceden hesaplamak; bu ise yalnızca sabit yerleşimli render’da mümkün
    Ayrıca yazar notlardan bahsediyor ama bunları nasıl uygulamayı düşündüğünü tam bilmiyorum

    • Yazar sabit yerleşimli EPUB konusunu da ele alıyor. EPUB; temel sayfalama, satır sonları, yazı tipi, yazı tipi boyutu, sayfa boyutu, görsel konumu vb. belirleyerek her yerde aynı şekilde render edilmesini sağlayabilir
      Bu EPUB3’te zaten mümkün, ancak telefon gibi ekranlarda iyi görünmemesi gibi bir dezavantajı var. Okuyucuya bağlı olarak varsayılanlar geçersiz kılınabilir; fakat o zaman okuyucunun belgeyi yeniden güzel hale getirmesini beklemek gerekir
      Alternatif, EPUB’ın yaygın ekran türleri için birden fazla render tanımlamasıdır. Mükemmel olmasa da belge üreticisinin varsayılanları oluşturması ve kullanıcının isterse bunları geçersiz kılabilmesi iyi bir uzlaşma gibi görünüyor
    • PDF’de satır sonlandırma özelliği yok. SVG’ye benzer bir çizim biçimine daha yakın ve daha katı; bu yüzden metin yeniden akışı gibi şeyler mümkün değil
      Bir e-kitap biçiminin ihtiyaç duyduğu şey, render edildiği cihaza uyum sağlayan anlamsal işaretlemedir. HTML+CSS zaten bu amaçla tasarlandı
      Bu nedenle kitap yerleşimini hazırlayan kişi, kitabın nasıl görüneceği üzerindeki kontrolün bir kısmını bilinçli olarak okura devretmeli. Bir miktar görsel kusur bunun ödenebilir bedeli. Görsel mükemmellik gerekiyorsa PDF kullanılabilir
      Elbette etkileşimli öğeler girince iş zorlaşıyor. Büyük etkileşimli öğeleri gerektiğinde özel bir görünümde açmak, küçük etkileşimli öğelerde ise yeniden akışı kabul etmek iyi olur
    • CSS’in temelde sayfalı medya yerleşimi özelliklerini desteklediğini sanıyorum. EPUB okuyucusunun yalnızca geleneksel “baskı önizleme” görüntüleme modunu uygulaması yeterli değil mi?
    • İronik biçimde, yazarın not örneği olarak verdiği şey benim ortamımda düzgün çalışmıyor. Dokunmatik ekranlı Android Firefox’ta uzun basınca açılır pencere yerine bağlantı çıkıyor
      Notlar ve referanslar zaten EPUB belirtiminde, hatta belki HTML belirtiminde de yer almıyor mu diye düşünüyorum
      Ayrıca açılır pencere için uzun basma yönteminin sıradan hiperlink ankrajından daha iyi olduğuna katılmıyorum. Okuyucunun “geri dön” işlevi düzgün çalışıyorsa veya çift yönlü referanslarda “geri” bağlantısı varsa, gezinerek gitmek çok daha az bölücü olur
    • Eskiden XSL Formatting Objects(XSL-FO) diye bir şey vardı. XML tabanlı PDF benzeri bir şeyi hedefliyordu ama daha yüksek seviyeliydi; bu yüzden metnin yeniden akışı da mümkündü
      Fikir, XML belgesini ve XSL stil sayfasını birlikte dağıtmak; bunları render için FO’ya dönüştürmek ve aynı belge için hedef cihaza veya sayfa boyutuna göre birden fazla stil sayfası bulundurabilmekti

  • Firefox’ta SinglePage eklentisini kullanarak mevcut sayfanın DOM’unu bağımsız çalışabilen bir HTML dosyası olarak kaydediyorum. CSS ve görseller için data: URL’lerini satır içine koyuyor, bağımlılıkları ve betikleri kaldırıyor
    Kusursuz değil ve tarayıcının her zaman geriye dönük uyumluluğu koruyacağına inanmıyorum; yine de sayfayı PDF olarak ya da birden fazla dosya halinde kaydetmeye tercih ediyorum
    İlginçtir, bu eklentinin başarısız olduğu az sayıdaki sayfadan biri de taşınabilir EPUB’lar hakkındaki bu yazıydı. Biçimlendirmeyi tutturmak için fazla fazla sihir kullanılmış gibi. Kaydedilen sayfa okunabiliyordu ama stili özgün sayfadan tamamen farklıydı
    Android’deki fbreader’ın tüm kitapları EPUB dosyasının stili yerine uygulama ayarlarına göre aynı şekilde göstermesini seviyorum. CSS uygulamaya ya da dosyaya gömülü betikleri çalıştırmaya çalıştığını hiç görmedim; umarım ileride de yapmaz. Dış bağımlılıkları yüklemek daha da kötü bir fikir; zaten buna izin verildiğini bile bilmiyordum

    • Sanırım SingleFile’dan bahsediyorsun
      Bu konu açılmışken, Firefox eklenti izin sistemi tuhaf. İlginç bir şey yapmak için neredeyse tüm izinleri istemek zorunda kalıyorsunuz; bunun sonucu olarak da kötü niyetli aktörlerin devralacak eklenti aradığı doğal bir pazar oluşuyor
      Örneğin SingleFile eklentisinin render edilmiş DOM’a bakıp dosyaya kaydetmesi gerektiği için erişim iznine ihtiyacı var. Ama neden her şeye erişmesi gerekiyor diye düşünüyorum. snapshot DOM once, write to a single file gibi izinler verilemez mi
    • Sanırım yaklaşık 10 yıl önce HN’de bıraktığım ilk yorumlardan biri, HTML web sayfalarını PDF olarak değil HTML olarak kaydetmek istediğimle ilgiliydi
      O zamanlar nedenini ne iyi açıklayabiliyordum ne de tam anlayabiliyordum; ama bu saçma bir istekmiş gibi karşılanmıştı. Şimdi bakınca sadece zamana göre yaklaşık 10 yıl ters düşmüşüm gibi görünüyor; bunu görmek sevindirici
    • Bu sayfanın neden ayrıştırmasının zor olduğunu başka bir yorum iyi açıklıyor. Nota geliştiricisinin EPUB’u PDF ile eşdeğer bir seviyeye çıkarmaya çalıştığı bir yazı bu; yazının kendisi de tarayıcı tabanlı bir WASM görüntüleyiciyle gösteriliyor
    • FBReader varsayılan olarak belgenin CSS’ini kullanır. Yanlış hatırlamıyorsam bunu yaklaşık dört adımda kapatabiliyorsunuz
      KOReader daha az kullanıcı dostu ama daha fazla kontrol sunuyor. Sunulan çeşitli CSS dosyalarından belirli birini seçebilir ya da kendiniz yazabilirsiniz
      KOReader’ın avantajları arasında mükemmel OPDS desteği ve kolayca kendi barındırabileceğiniz bir senkronizasyon sunucusu da var
    • Bu yazıda bir EPUB indirme düğmesi var
      Bu özellik varsa, bu sistemi kullanan sayfalarda SinglePage’e gerek kalmıyor

  • O kısmı görünce tekrar baktım. Şu kısımdan bahsediyorum: “Bu nedenle daha hafif bir EPUB okuma sistemi olan Bene’yi yapmaya karar verdik. Şu anda kullandığınız şey de bu. Bu belge bir EPUB’dur ve sağ üstteki düğmeye basarak indirebilirsiniz”
    Masaüstü tarayıcıda okurken biri doğrudan söyleyene kadar hiç fark etmemiştim. Mobilde başlık ekranın daha büyük bir bölümünü kapladığı için daha göze çarpıyor, ama onun dışında neredeyse normal bir web sayfası gibi davranıyor
    Muhtemelen iyiye işaret
    Bazı yorumlarda söylenenlerin aksine, belge ilk yüklenirken bir yükleme göstergesi görmedim ya da en azından fark etmedim. Telefonda gördüm ama oldukça hızlı geçti. Bunun WASM programının yüklenmesi mi olduğunu, yoksa yalnızca ilk yüklemede mi gerçekleştiğini bilmiyorum

    • Yükleme göstergesinin esas beklediği şey .epub dosyasının indirilmesi. Dosya 4,77 MB olduğu için hızlı bir bağlantı yoksa epey büyük. Sıkıştırma açıldıktan sonra boyutun çoğunu, yaklaşık %99’unu görseller kaplıyor
      Normal bir web sayfasından ya da PDF’den farklı olarak, tüm varlıklar, yani ePub’ın tamamı indirilmeden render işlemi başlamıyor gibi görünüyor
      Yazının ele alacağını sanıp ele almadığı fark performans. PDF, sayfalar oldukça bağımsız olacak şekilde optimize edilebilir; bu da kademeli render, rastgele erişim ve yüksek paralelleştirme sağlar
    • Telefonda, yazıyı okuyana kadar hiç fark etmemiştim. Sadece projeyi açıklayan normal bir web sayfası olduğunu sanmıştım

  • Tarayıcının EPUB açamaması tek başına bile projeyi biraz başarısızlığa mahkûm gibi hissettiriyor. PDF’ye bağlantı verince az da olsa bağlam değişimi oluyor ama tarayıcı açıp görüntülüyor.
    EPUB, anlatıldığı kadarıyla aslında HTML; buna rağmen tarayıcının açmaması tuhaf. Ama Chrome/Mozilla bürokratlarını ikna etmek pek kolay olmayacak gibi.
    Bir başka moral bozucu nokta da HTML ve CSS’in o kadar devasa ve şişkin hâle gelmesi ki EPUB/HTML için bir “okuyucu” uygulayabilecek neredeyse kimse kalmamış olması. Fiilen “yeni bir tarayıcı uygulayın” demek oluyor. Djot gibi ayrıştırması kolay bir Markdown’ın üzerine biraz işleme yeteneği eklemek uzun vadede daha mümkün görünüyor.
    Benim kişisel geçici uzlaşımım CSS, SVG, betikler ve base64 görseller dâhil her şeyi tek bir HTML dosyasına koymak. EPUB’a benziyor; biraz şişkin ve çirkin ama azıcık özen gösterilirse çalışıyor ve tarayıcı doğal biçimde açabiliyor.
    Ancak kullanıcının “bu web sayfasını indirip çevrimdışı saklayabilirim” diye anlamasının bir yolu yok. Dış kaynak içermeyen HTML olduğunu belirten .htmls gibi bir uzantı olsa iyi olurdu.

    • Çok yakın zamana kadar tarayıcılar PDF de açamıyordu. Şimdi tüm tarayıcılar ASM/JS ile yazılmış bir PDF okuyucu içeriyor.
      EPUB için de tarayıcının aynı şeyi yapamaması için bir neden görünmüyor. Zaten tam olarak bunu yapan tarayıcı uzantıları var. Mesele EPUB biçiminin popülerlik kazanıp kazanmayacağı.
    • HTML aslında hiper metindi. Birkaç bağlantı, çizim/görsel, tablo kadardı.
      Sonra dergi benzeri tasarım ve yerleşim “gerekli” hâle geldi ama hâlâ belge tabanlı olduğu için oldukça iyiydi.
      Daha sonra HTML’i uygulama dağıtım platformu olarak zorla uydurmaya çalıştılar. Bugünkü CSS yerleşimi nihayet geleneksel uygulama yerleşim motorlarına daha yakın hâle geldi.
      Bence son 20 yıl, uygun bir çapraz platform uygulama dağıtım yöntemi olmadığı için büyük ölçüde boşa harcandı. Java’yı saymazsak.
    • Yani bu yazının kendisi de WASM EPUB görüntüleyiciyle açılmış bir EPUB gibi görünüyor.
    • En büyük engel HTML/CSS uygulama kapsamı gibi geliyor. Yazar “taşınabilir HTML üretme ilkesi: mümkün olduğunda taşınabilir EPUB üreten sistem taşınabilir HTML çıktısı vermelidir” diyor ama yeterince ileri gitmiş gibi değil.
      Bu biçimin her yerde tekrarlanabilir şekilde çalışması için standartlaşması ve yeni işleme motoru uygulamalarının da kolay olması gerekir. WebView’a bağımlı olmak ileriye dönük yol gibi hissettirmiyor.
      PDF’nin güzelliği çok güvenilir olmasında. 10 yıl önceki bir PDF bugün de eskisiyle aynı şekilde işlenir.
      Bu çabanın başarılı olması için belge kapsamını ciddi biçimde daraltmak gerekecek gibi. İzin verilen XHTML alt kümesi çok sınırlı olmalı ve her yerde aynı görünümle işlenebilme yeteneğine öncelik vermeli. Önce sabit sayfa boyutlu sabit yerleşim, sonra yeniden akıtılabilir belgeler gelmeli. Kapsamlı test belgeleri ve işlenmiş çıktılar içeren bir standart da gerekli.
    • Tarayıcılar EPUB açmak için kullanışlı bir arayüz sunmuyor ama içindeki bölüm bazlı HTML dosyalarını işlemede sorun yaşamamaları gerekir.
      Tarayıcı desteği yoksa, sunucu tarafında EPUB’u gezilebilir bir siteye dönüştüren, bölüm geçiş kontrolleri ve basit yerleşim seçenekleri ekleyen bir proxy yazmak çok zor olmaz.
      Elbette böyle bir proxy ile ticari e-kitapların çoğunu görüntülemek için gereken DRM desteği hukuken çok sorunlu olabilir.
      Düşününce, yayıncıların onaylayacağı DRM’li EPUB tarayıcı desteği teknik olarak sıradan web sayfaları için DRM desteğinden yalnızca yarım adım uzakta; bu da epey korkunç bir ihtimal.

  • PDF’nin gereksiz karmaşıklık içeren berbat bir eski format olduğunu düşünüyorum. PDF’nin kullanım alanlarının çoğu baskıyla ilgili olmadığından dizgi mantığı da bana anlamlı gelmiyor.
    Çoğu kullanım senaryosunda telefonda, tablette ve bilgisayarda kolay okunabilir olması çok daha önemli.
    Yazar iBooks’un kaydırma görünümünü desteklemediğini söyleyince şaşırıp kendim kontrol ettim. macOS’teki iBooks ePub dosyalarında kaydırmayı desteklemiyor, ama iOS ve iPadOS’te destekliyor. Apple’ın çok tuhaf bir kararı.
    https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...

    • PDF belirtimi can sıkıcı, ama onun yerini alacak hiçbir şey yok.
      Teknik belgelerin PDF dışı bir formatta dağıtılıp okunmasının ve aranmasının rahat olduğu bir örnek görmedim. Telefonda da durum aynı.
      Okuma cihazı ya da pencere boyutu gibi geçici duruma göre görünümü değişen belgeler istemiyorum. Yazarın iyi tasarlanmış, yerleşimi sabit bir belgesini istiyorum.
      Küçük ekranda ya da pencerede okurken de, düz metin belge değilse yerleşim değişikliği değil, hızlı yakınlaştırma/uzaklaştırma ve gezinmeyi kolaylaştıran akıllı bir okuyucu istiyorum. Bazı Android okuyuculardaki gibi dikey kaydırmanın veya Page Up/Page Down’ın yatay konumu da değiştirip metin sütununu okumayı zorlaştırdığı aptalca davranışlar olmamalı.
      Geleneksel metin sütunu azami genişlik önerilerine uyulması bile telefonda rahat okumak için yeterli. Telefonda okuma ancak yazar aşırı geniş sütunlar yapıp geleneksel tipografi kurallarını bozduğunda zorlaşıyor.
    • Sabit yerleşimli belge istememin nedeni yalnızca baskı değil. Çünkü belge yerleşimini sabit tutmak, küçük ekrandan daha önemli.
    • Bu özel durumu bilmiyorum ama bazı okuyucular bunu e-mürekkep cihazlarla tutarlılık için yapıyor olabilir. E-mürekkepte düşük yenileme hızı, zayıf işlemci ve pil tasarrufu nedeniyle kaydırma donanımsal olarak sınırlı.
      Bu yüzden her şeye uyan tek bir standart yaratmaya çalışmak kötü bir fikir gibi. Dijital belge standardı iki tane olsa daha iyi olur: biri ağ iletişimi hariç tam multimedya ve etkileşim özelliklerine sahip bir format, diğeri ise bunun alt kümesi olup siyah-beyaz, multimedya içermeyen ve etkileşimi çoğunlukla belge içi hiper bağlantılarla sınırlı bir format.
      Zaten neredeyse böyle iki format var: HTML, MHTML=EML ve EPUB.
      Elbette fiziksel arşivleme ve nadir dijital sabit yerleşimli belgeler için üçüncü bir format da gerekli; bu rol için PDF/A zaten oldukça iyi görünüyor.
    • Gerçekten bir şeyi yazdırmanız gerekiyorsa PDF en güvenilir ve taşınabilir yol.
      Çok sayfalı SVG de mümkün olabilir ama düzgün şekilde çok sayfalı yazdırmak için sonunda yine önce PDF’ye dışa aktarmak gerekecek gibi. Bunu Inkscape’e bakarak söylüyorum.

  • 8 gün önce 134 puan alan “Portable Web Documents – An Alternative to PDF Based on HTML5 (2019)” vardı
    https://news.ycombinator.com/item?id=39036774

  • Bir EPUB okuyucunun tarayıcıda olmayan ne sunduğunu merak ediyorum. Şu anda görünen tek yanıt var, o da önemsiz bir şey: .epub dosyalarını, yani zip dosyalarını dizin gibi ele alabilmesi
    EPUB okuyucu ile tarayıcı alt kümesi arasındaki fark gerçekten sadece buysa, en basit ve en az çaba gerektiren yol şöyle olurdu
    Mevcut tarayıcının belirli koşullarda zip dosyalarını dizin gibi ele almasını sağlamak
    Orijinal yazıda sözü edilen tamamen yerel varlıkları garanti eden, mekanik olarak denetlenebilir bir HTML kısıtı tanımlamak. Bağlantılar dışındaki tüm URL’lerin göreli yol olmasını şart koşmak bile yeterli olabilir
    Bu kısıtı karşılayan zip dosyalarını “taşınabilir EPUB” olarak ilan etmek
    Eski ya da yeni, tüm özel EPUB okuyucuları unutmak

    • Katılıyorum. Gerçek çözüm buymuş gibi geliyor
      Tamamen yerel varlıklar konusunda, tüm nesnelerin yerelde kullanılabilir yedek seçeneklere sahip olmasının şart koşulmasını görmek isterdim. İlgili yazı tipi alınamazsa standart yazı tipinin kullanılması gibi. Kusursuz görünmese de, yedek kapsamı içinde sınırlandırılırsa makul biçimde çalışmalı
      Henüz yeterince ele alınmamış bir hata modu var: düzgün çalışmayan görseller. Temelde görseller yeniden akıtılamadığı için. Bunun önemli bir kısmı SVG kullanımıyla çözülebilir, ama gerçek raster görseller söz konusuysa olmaz. Sonuçta birkaç farklı çözünürlük sunmaktan başka çare yok gibi
      İlgili bir sorunla da karşılaştım ama henüz iyi bir yanıt görmedim. Çözünürlüğün farkında olan ve yeterli çözünürlük olduğunda daha ayrıntılı görseli getiren SVG. Alt piksel çizgiler çizildiğinde bulanıklaşır, ama aynı görsel büyütüldüğünde o çizgiler yararlı hale gelir. Windows ikonları, birden fazla çözünürlük içerebilip duruma uygun olanı kullanarak bunu kabul ediyor

  • Yazar, Shriram Krishnamurthi’nin danışmanlığında çalışan bir doktora sonrası araştırmacı. Shriram Krishnamurthi, Programming Languages: Application and Interpretation(PLAI) kitabının yazarı ve Data-Centric Introduction to Computing(DCIC) yazarlarından biri
    Şu anda hem PLAI’yi hem DCIC’yi okuyorum; yazarların bunları eğitim amaçlı sanat eserlerine dönüştürmek için gösterdiği incelikli özen beni gerçekten hayran bırakıyor. Bu gerçek bir sevgi
    https://willcrichton.net/

  • PDF yazı tiplerini içerebilir, ama çoğu zaman içermez ve sistem yazı tiplerine dayanır. Bunun bir nedeni, yazı tiplerini PDF’ye koymanın dosya boyutunu ciddi biçimde artırabilmesidir. Bazı durumlarda tek bir yazı tipi, dosyanın geri kalanının tamamından daha büyük olabilir
    PDF oluşturan yazılımda yazı tipi gömmeyi uygulamıştım; güvenilir çalışmasını sağlamanın yolunu bulmak beklediğimden şaşırtıcı derecede zordu
    PDF’nin tutarlı biçimde render edildiği de sanıldığı kadar doğru değil. Aynı PDF’nin hangi PDF görüntüleyicinin kullanıldığına bağlı olarak farklı render edildiği birçok durum var. Genellikle farklar incelikli olur, ama bazen oldukça büyük fark yaratan sınır durumları da çıkar. Acrobat Reader’ın aynı sürümünün işletim sistemine bağlı olarak PDF’yi farklı render ettiği durumlarla da karşılaştım

    • PDF dosyasında atlanabilecek standart sistem yazı tipleri yalnızca birkaç tanedir ve belge, render işleminde kullanılan yazı tipinin geleneksel Times, Helvetica, Courier gibi yazı tipleriyle aynı metriklere sahip olduğunu varsayar
      Bu yüzden uyumlu sistem yazı tipleri kullanıldığında render edilen belge düzeninin değişmemesi gerekir. Elbette eski Adobe PostScript yazı tipleriyle metrik uyumlu diye tanıtıldığı halde ince farkları olan sistem yazı tipi örnekleri var
      Az sayıdaki standart sistem yazı tipi dışında, PDF belgeleri genellikle ilgili yazı tipinin tamamını değil, gerçek metinde kullanılan karakterlere karşılık gelen glif alt kümesini içerir
    • 20 yıldan fazla PDF’nin tutarlı render edildiğini düşündüm; ancak bir mülakatta belgemin garip göründüğünü duyduktan sonra yazı tiplerinin eksik olabileceğini öğrendim
      Gündelik hayattan bir The Daily WTF idi
    • Belgede kullanılmayan kod noktalarını kaldırarak yazı tipini küçülten bir yazılım olup olmadığını merak ediyorum