1990 tarihli Word for Macintosh 4 dosyası olan özgün WWW önerisi bugün açılabilir mi?

 (blog.jgc.org)
1 puan yazan GN⁺ 2024-02-14 | 1 yorum | WhatsApp'ta paylaş
  • Tim Berners-Lee’nin özgün WWW önerisi, 68.608 bayt boyutunda bir Microsoft Word for Macintosh 4.0 belgesiydi; temel mesele, modern ortamlarda özgün hâline yakın biçimde açılıp PDF’ye dönüştürülüp dönüştürülemeyeceğiydi
  • Microsoft Word ve Apple Pages başarısız oldu; Apache OpenOffice dosyayı açtı ama biçimlendirmeyi ve diyagramları düzgün koruyamadı
  • LibreOffice belgeyi açıp net diyagramları da gösterdi; ancak kenar boşlukları, yazı tipi boyutu, üstbilgi/altbilgi ve boşluklar özgünden farklı olduğu için ek düzeltmeler gerekti
  • CERN’in 1998 tarihli PDF’i 20 sayfayken, Infinite Mac üzerinde 1990’lar Macintosh’u ve Word ile kontrol edilen özgün düzen A4’e göre 22 sayfa olarak göründü
  • Elle düzeltilen .odt ve emüle edilmiş Mac’te oluşturulan PDF GitHub’a yüklendi; 34 yıllık bir belgeyi bile doğru açıp korumak kolay değil

Özgün dosyanın kimliği ve dönüştürme hedefi

  • W3C, Tim Berners-Lee’nin original WWW proposal sayfasında özgün belge dosyası gibi görünen bir indirme sunuyor
  • Bu indirmeye “I think - I can't test it” açıklaması eklenmişti; ayrıca ayrı bir RTF sürümü ve 1998’de özgün dosyadan üretilmiş bir HTML sürümü de var
  • Mac’teki file komutu özgün belgeyi Microsoft Word for Macintosh 4.0 dosyası olarak tanımlıyor
  • W3C sayfasındaki not da bu belgenin Mart 1989’da yazılmış özgün MacWord veya Word for Mac belgesi olduğunu, Mayıs 1990 tarihinin eklenmesi dışında değiştirilmeden yeniden dağıtıldığını belirtiyor
  • Amaç, özgün belgeyi açmak ve mümkünse yüksek doğruluklu PDF gibi modern bir biçime dönüştürmekti

Modern yazılımlarla açma denemelerinin sonucu

  • Önce Microsoft Word ile denemek için dosyaya .doc uzantısı eklenip OneDrive’a yüklendi ve açılmaya çalışıldı
  • Apple Pages de eski Microsoft Word for Macintosh dosyasını anlayamadı
  • Apache OpenOffice dosyayı açabildi, ancak biçimlendirme kayboldu ve diyagramlar eksikti
  • LibreOffice dosyayı açtı ve diyagramları da net biçimde gösterdi
    • Ancak kenar boşlukları tuhaftı ve başka biçimlendirme sorunları da kalmıştı

CERN PDF’i ile LibreOffice çıktısı arasındaki fark

  • CERN, önerinin bir PDF sürümünü sağlıyor
  • Bu PDF’in 1998’de Acrobat Distiller Daemon 2.1 for SunOS/Solaris(SPARC) ile oluşturulduğu anlaşılıyor ve 20 sayfa
  • LibreOffice’e aktarılan sürüm 24 sayfaydı
  • LibreOffice sürümünden PDF oluşturulduktan sonra Apple Preview’un contact sheet görünümünde CERN PDF’iyle karşılaştırıldı
    • LibreOffice sürümünde sağ kenar boşluğu kayboluyor
    • Metnin büyük bölümü CERN PDF’indeki 12pt yerine 14pt olarak görünüyor
    • TBL’nin baş harflerini içeren üstbilgi altbilgiye dönüşüyor
    • Görsellerin konumuna bakıldığında sayfa sonları genel olarak doğru görünüyordu; en büyük sorun yazı tipi boyutu gibi görünüyordu
    • CERN PDF’inde başlığın altında boşluk var, ancak LibreOffice sürümünde yoktu

Özgün düzenin emülasyonla kontrol edilmesi

  • Gerçek özgün belgenin nasıl göründüğünü kontrol etmek için Infinite Mac üzerinde 1990’lar Macintosh’u başlatıldı ve özgün belge Word for Macintosh 4.0 ile çalıştırıldı
  • Bu yöntemle gerçek yazı tipleri, yazı tipi boyutları ve düzen kontrol edilebildi
  • Emüle edilmiş Mac’te yapılan kontrole göre, özgün Mac belgesi ile CERN PDF’i epey farklıydı
    • CERN PDF’i 20 sayfa
    • Word for Macintosh 4.0 ile A4 kâğıt ayarında açılan belge 22 sayfa
  • Bundan sonra hedef, CERN PDF’ine uydurmak değil, Mac’te görünen özgün belgeye yakın hâle getirmek yönünde değişti

Elle düzeltme ve koruma sonucu

  • LibreOffice belgesini özgüne yaklaştırmak için birçok öğe elle ayarlandı
    • Kâğıt A4 olarak ayarlandı
    • Sağ kenar boşluğu sol kenar boşluğuyla aynı boyuta getirildi
    • İlk sayfada cilt payı, altbilgi ve üstbilgi aynı olmadığı için ayrı bir biçimle ayarlandı
    • Gövde metninin yazı tipi 14pt ve diğer boyutlardan 12pt’ye değiştirildi
    • Sayfalar arasında yanlış bölünen metin ve hizalama sorunları elle giderildi
    • Altbilgiye dönüşen öğe üstbilgi olarak düzeltildi
  • Nihai sonuç, Mac’te görünen belgeye oldukça yaklaştı
  • Dönüştürme sonucu olan .odt sürümü GitHub deposuna yüklendi
  • Bu çalışma, eski belgeleri modern biçimlerde korumanın zor olduğunu ve açık kaynak yazılımların bu tür dönüşümlerde yararlı olabileceğini gösteriyor
  • Başlangıçtaki amaç, bir sunumda kullanmak üzere özgün önerinin yüksek kaliteli diyagramlarını elde etmekti; ancak beklenenden uzun sürdü

Emüle edilmiş Mac ile oluşturulan ek PDF

  • Hacker News yorumlarında, emüle edilmiş Mac ile PostScript dosyası veya PDF oluşturulabileceği önerildi
  • System 7 ve 1992 tarihli Word ile PDF dosyası oluşturan yazıcı sürücüsü Print2PDF kullanılarak Word for Macintosh 5.1a’dan doğrudan çıktı alındı
  • Bu yöntemle oluşturulan PDF de GitHub’a eklendi
    • Bu sürüm 20 sayfa
    • Yazı tipi farklı olsa da asıl gereksinim olan PDF oluşturma karşılandı
  • Bir başka Hacker News yorumu, farklı Word sürümleri ve ayarlamalarla modern biçimde iyi bir dönüştürme örneğine bağlantı verdi

İlgili okumalar

1 yorum

 
GN⁺ 2024-02-14
Hacker News yorumları

  • İlgilenenler için, vektör çizimleri ve yazı tiplerinin tamamı korunmuş modern Word biçiminde bir belge yükledim: https://jasomill.at/proposal.docx
    Dönüştürmeyi, QEMU ile emüle edilmiş bir Power Mac’te Word 98[1] ile açıp yeniden kaydettikten sonra modern Word for Mac 16.82’de açarak yaptım
    Ancak resimler eksikti ve Word “There is not enough memory or disk space to display or print the picture.” diyordu; bu RAM sorunundan ziyade Word’ün artık PICT görüntü biçimini desteklememesi gibi görünüyor
    Görselleri, Word 98’de Acrobat 5.0.10’un PDF yazdırmasıyla PDF oluşturarak; ardından modern Adobe Illustrator ile üç görselin her birini PDF olarak çıkarıp özgün yazı tiplerini, vektörleri, boyutu ve sınırlayıcı kutuyu koruyarak ve Finder’dan sürükleyip bırakarak geri yükledim
    Karşılaştırma için, Power Mac’te Word 98’in Acrobat ile oluşturduğu PDF https://jasomill.at/proposal-Word98.pdf, macOS Sonoma’daki modern Word’ün oluşturduğu PDF ise https://jasomill.at/proposal-Word16.82.pdf
    [1] https://archive.org/details/ms-word98-special-edition

    • Resimleri ayrı çıkarıp başka bir programla doğrudan dönüştürmeyi denedin mi merak ediyorum. Archive Team’e göre LibreOffice vektör PICT dosyalarını okuyabiliyor[1] ve SVG olarak da kaydedebiliyor
      Elbette içinde metin varsa yazı tipi sorunu hâlâ kalır, ama PDF ile vektörleri koruma fikri aklıma gelmemişti; PDF yazı tipi gömmeyi de gayet iyi yapıyor
      [1] http://fileformats.archiveteam.org/wiki/PICT
    • Bu arada MacClippy 98 durumun zaten farkındaydı: https://jasomill.at/Clippy.png
    • Bilimkurguda geçen dijital arkeolog mesleği gerçeğe dönüşüyor
    • Bu kadar eski bir belgede LHC göreceğimi hiç sanmazdım
      Çalışırken kısaca baktığım kadarıyla LHC projesinin ne zaman başladığını ve 1990’da zaten ilgili olup olmadığını doğrulayamadım; ama gerçek çalışmaya başlamasından 20 yıl önce olması da beklediğimden çok daha uzun bir süre gibi geliyor

  • “Gerçek yazı tipini, yazı tipi boyutunu ve düzeni görüp belgenin nasıl görünmesi gerektiğini doğrulayabilirsiniz” ifadesi, özgün yazı tipleri varsa geçerli
    Word 4.0, System 6 için çıkmıştı ve System 3.2’ye kadar destekliyordu; o dönemde yazı tipleri, çıktı çözünürlüğüne göre ekran dosyaları ve yazıcı dosyaları olarak ayrı ayrı bulunuyordu
    Yazıcı yazı tipi yoksa ekran yazı tipi en yakın komşu yöntemiyle büyütülerek yazdırılıyor; ekran yazı tipi de yoksa sistem yazı tipiyle değiştiriliyordu. Ekran görüntüsündeki gibi varsayılan Geneva
    Bu örnekte gerekenler yalnızca ünlü Palatino ve Courier, ancak LibreOffice, Palatino Linotype kurulu olmasına rağmen Times New Roman ile değiştirdi

    • Muhtemelen bunun nedeni, Palatino Linotype’ın dahili adının Windows paketli sürümünde PalatinoLinotype, Adobe OpenType sürümünde ise PalatinoLTStd olması
      Sabit kodlanmış istisnalar yoksa ortak önek tabanlı yazı tipi eşleştirmesi kolayca uygunsuz sonuçlar üretebilir. Örneğin Lucida, LucidaConsole ile eşleştirilebilir; oysa belge yazarının niyeti açısından neredeyse herhangi bir orantılı sans-serif yazı tipi bundan daha iyi olabilir
      Üstelik tam ad eşleştirmesi de garanti değil. Apple, dahili adı NewYork olan bir yazı tipini iki kez dağıttı: biri Susan Kare’in 1983 tarihli özgün Macintosh bitmap tasarımının TrueType’a dönüştürülmüş hâli, diğeri ise 2019’da çıkan alakasız bir tasarım
    • Bu tür farkları bir ölçüde açıklayabilir, ama emülasyonda asıl kontrol etmeye çalıştığımız şey yazı tipi boyutuydu

  • Bu küçük hikâyede kolayca hafife alınabilecek kahraman, eski file(1) komutu
    proposal: Microsoft Word for Macintosh 4.0
    Bir dosyanın ne olduğunu merak ettiğimde neredeyse refleks olarak kullanıyorum; döndürdüğü bilgi merakı giderecek ve pratik olacak kadar tam kararında olduğundan gerçekten kullanışlı

    • Katılıyorum. file harika bir araç
      Eskiden iş için kullandığım bir Windows bilgisayarın başına oturup bu aracı kolayca kullanamadığımda birkaç kez söylenmiştim. Sonradan WSL sayesinde işler kolaylaştı; şimdi ise neyse ki neredeyse hiç Windows kullanmıyorum

  • LibreOffice bu dosyayı doğrudan açıyor. Eski belge dosya biçimi desteği gerçekten çok iyi; bu tür işler için kurulu tutuyorum: https://imgur.com/a/JENgq6V
    Yine de BasiliskII ve InfiniteMac emülatörlerini kullanmayı da seviyorum

    • Orijinal metinde de LibreOffice’in açtığı söylenmişti, ama aynı zamanda “kenar boşlukları garip ve başka biçimlendirme sorunları da var” deniyordu
      Ekran görüntüsünde de bu sorun görülüyor gibi; bu kadar eski, tescilli bir biçimi bu seviyede desteklemesi oldukça iyi, ancak böyle sorunlar varken “gerçekten çok iyi” demek biraz tartışmalı
    • QEMU da denemeye değer. Güncel sürümler Power Mac emülasyonunu iyi yapıyor; classic Mac OS’in en yeni PowerPC sürümü olan 9.2.2’yi de Mac OS X 10.5’i de çalıştırabiliyor
    • O dönemde StarOffice zaten vardı
      Şimdi LibreOffice’in içinde 1990’ların başına ait üçüncü taraf biçim ayrıştırma kodu hâlâ duruyor mu, yoksa çok daha sonraki Word sürümlerinin tersine mühendisliğiyle yapılmış uyumluluk/dönüştürme kodu mu asıl işi yapıyor, merak ettim

  • Microsoft’un geriye dönük uyumluluğunu gösteren bir örnek olarak, Windows sürümü Word 2401’de dosya genel olarak sorunsuz açıldı ve düzeni de yazıdaki PDF ile aynı görünüyordu.
    Varsayılan olarak dosya biçimi engellenmişti ama izin vermek kolaydı.
    Ancak Microsoft Word Picture biçimi için grafik filtresi olmadığından görseller açılmadı. Epey uzun zaman önce kullanımdan kaldırılmış gibi görünüyor; ama Word 2003’ün açabileceğini düşünüyorum ve modern sistemlerde çalıştırılamayacak kadar eski de değil.

    • Word 2003’ü kurmayı denedim; varsayılan ayarlarla belge anında ve kusursuz biçimde açıldı.
      Orada kaydedince modern .doc biçimine dönüştürüldü ve Office 365’te açılıp PDF vb. biçimlere dönüştürülebildi.
      Buradan çıkarılacak ders, Windows Office ekibinin geriye dönük uyumluluğa biraz daha fazla zaman ayırıyor gibi görünmesi.

  • Microsoft gibi bir şirketin, Microsoft Word’ün herhangi bir sürümünün oluşturduğu belgeleri, ne kadar eski olursa olsun açılabilir kılmayı önemli görmesi gerektiğini düşünüyorum.
    Sosyal, tarihsel ve ekonomik bir sorumluluğu olduğunu düşünüyorum.
    Eski ayrıştırma kodlarındaki güvenlik açıkları endişe yaratıyorsa, bunu harici bir sürece taşıyıp sandbox izolasyonunda çalıştırarak anında yeni, okunabilir bir sürüm üretmesini sağlayabilirler. Bu işlevin kendisi kaldırılmamalı.
    Düzeltme: Masaüstü Word’ün dosyayı sorunsuz açtığını, yalnızca web sürümünün açamadığını öğrendim; bu yüzden bu yazı geçersiz sayılabilir.
    Düzeltme 2: Belge açılıyor, ancak gömülü grafikleri gösteremiyor ya da yazdıramıyor gibi görünüyor.

    • Eski biçimlerin önemli bir kısmı aslında belleğin ikili dökümüydü ya da bundan çok da farklı değildi.
      Biçimleri belgelemek de standart bir uygulama değildi. Sosyal sorumluluk olduğu konusunda katılıyorum; ama dijital arşivleme işi yapmış biri olarak eski dönemler gerçekten, gerçekten dağınıktı. Cidden.
    • 1990’a kadar gitmeye gerek yok; modern Microsoft uygulamalarının, özellikle bulut uygulamalarının, önceki sürümlerde oluşturulmuş belgeleri açarken sorun yaşadığı durumları kolayca bulabilirsiniz.
    • Microsoft’tan daha iyi bir ticari yazılım geriye dönük uyumluluğu itibarına sahip bir şirket olup olmadığını gerçekten merak ediyorum.
    • Eski dosya biçimlerinde güvenlik açıkları var. Word’ün çevrimiçi sürümü temelde yalnızca docx için tasarlanmış ve sadece bazı ikili belgeleri açabiliyor.
    • Asıl Word’ün bu dosyayı sorunsuz açtığını kaçırmışım. Sorun yaşayan yalnızca oyuncak gibi web sürümü; Mac’te de böyle olabilir ama o ayrı konu.

  • O dönemde basılı çıktının tam olarak nasıl göründüğünü istiyorsanız, Word for Mac 4.0 çalıştıran bir emülatöre PostScript dosyası oluşturan bir yazdırma kuyruğu kurmak mümkün olmalı.
    Bu .ps dosyası PDF’ye dönüştürülebilir.
    Ya da bu kadar eski bir OS’te bile Acrobat varsa, sanal yazıcı sürücüsüyle doğrudan PDF oluşturmak da mümkün olabilir.

    • https://web.mit.edu/ghostscript/www/Ps2pdf.htm
      Daha fazla ayarı kendiniz yapmak istiyorsanız Ghostscript’in derin sularına dalabilirsiniz :)
      https://www.ghostscript.com
    • Hâlâ Word 5.1a çalıştıran bir Mac’im var ve kişisel olarak bunun ihtiyaç duyduğum son Word sürümü olduğunu düşünüyorum.
      Word 4.0 dosyalarını da açtığımı hatırlıyorum.
    • İyi öneri. Az önce Print2PDF ile Word’den PDF oluşturdum ve blogu güncelleyeceğim.

  • LibreOffice şaşırtıcı. Yalnızca pek çok belge biçimini açabilmekle kalmıyor, headless çalıştırma ve komut satırı seçenekleriyle biçim dönüştürme gibi işleri otomatikleştirebiliyor.
    Bu tür işler başka yöntemlerle çoğu zaman zor oluyor.
    https://help.libreoffice.org/latest/en-US/text/shared/guide/start_parameters.html
    https://opensource.com/article/21/3/libreoffice-command-line

  • Şirketlerin sık sık hafife aldığı potansiyel bir sorun var. Bazı şirketlerin süresiz saklanan yedekleri oluyor.
    10 yıl saklanan yedekler yaygın; yasal nedenlerle 20 yıl saklayan yerler de var, ancak çoğu “okunabilir” ile “kullanılabilir” arasındaki farkı anlamıyor.
    Veriye bağlı olarak değişir ama tüm sanal makineleri süresiz yedekleyip ileride çalıştırabileceklerine inanan şirketler de var. Bir vSphere 5.x makinesini güncel vSphere 8’de geri yüklemek bile yeterince zorken, bu alan israfını pek anlayamıyorum.

    • Her şeyi yedeklerseniz daha sonra temizleyebilirsiniz; sonunda temizlemeseniz de olur. Google Cloud’da 1 TB depolamanın maliyeti ayda 1 dolar.
      Bu fiyata temizlik yapmaya değmez. Bir DevOps çalışanının saati 100 dolardan fazlaya mal oluyor; daha üretken işler yerine sıkıcı temizlik yapmanın fırsat maliyeti buna dahil bile değil.
      Şirket satın alındıktan ya da yeterince zaman geçtikten sonra veriyi temizlemeden silebilir veya atabilirsiniz.
      Sanal makinelerde de, örneğin VMDK ise, başlatmadan ham diski okuyabilirsiniz. Ayda 10 dolar tasarruf etmek için veri kaybı riskini almaya değmez; bu tutar, bir geliştiricinin ekip etkinliğinde fazladan bir bira içmesine benzer.
    • Eski dosyalar veya disk imajları, modern dosya boyutlarına kıyasla çoğu zaman küçüktür.
      Bu yüzden bu, alan israfından çok yönetimsel bir israfa daha yakındır.

  • Biçimlerin ne kadar hızlı eskidiğini, özellikle de kapalı biçimlerin ne kadar tehlikeli olduğunu gösteren iyi bir ibretlik hikâye
    Uzun süre saklanacak belgeler için Markdown, düz metin ve PNG kullanıyorum
    Bu biçimler ortadan kalksa bile ayrıştırıcıyı baştan kendimiz yeniden uygulamak kolay olur

    • Markdown ayrıştırıcısı uygulamak hiç de basit değildir
      Basit durumlarda Markdown ayrıştırıcısı gibi davranıp insanları ayrıştırma yaptığına inandıran bir ayrıştırıcı yapmak kolaydır, ama gerçek ayrıştırıcı farklıdır
      Yine de Markdown verisinin kurtarılabilir olma olasılığı yüksektir. Veriyi kendiniz üretiyorsanız HTML daha güvenli bile olabilir
    • Markdown’ın sorunu, biçimlendirilmiş sayfalar kümesine dönüştürüldüğünde çıktının dönüştürücü sürümüne göre değişmesidir
      HTML de benzerdir, düz metin de bir ölçüde öyledir. PDF’in sonsuza kadar birebir aynı kalması gerekir; ancak düzenlenebilir belge biçimleri arasında, yazılım güncellense bile aynı biçimlendirmeyi gerçekten koruduğunu bildiğim tek şey TeX/LaTeX
      Gerçekten de LaTeX’te aynı girdi belgesi önceki sürümle birebir aynı yerleşimi üretmezse bu resmen bir bug sayılır
    • Bu nedenle protokol ve dosya biçimi belgelerinin mümkün olduğunca saf ASCII metin olarak yazılmasının iyi olduğunu düşünüyorum
      Daha karmaşık bir biçimin ya da protokolün belgelerini o biçimin veya protokolün kendisiyle yazmak gerekiyorsa bu özellikle sorun olur
      Just Solve The File Format Problem adlı bir wiki de var. Ben de bir zamanlar içerik eklemiştim; HTML kullanıyor ve tüm dosya biçimlerinin eksiksiz şartnameleri yok, bazıları harici dosyalara bağlantı veriyor ama dosya biçimi bilgisi bulmak için işe yarıyor
    • Markdown da düz metin değil mi? Önermediğimi söylemedim
    • Kâğıt çıktıları arşivlemeyi azaltmaya başladığımız andan itibaren toplum olarak dijital korumayı daha ciddiye almamız gerekirdi
      Tarihi bilmeyenlerin aynı hataları tekrarladığı söylenir; ama belgelerimiz gelecekteki kuşaklar tarafından okunamaz hâle gelir ya da yok olursa, onlar bizim hatalarımızdan nasıl ders çıkarabilir?