Saya sangat tertarik pada irisan antara ebook, keamanan, dan web LowJS, jadi topik ini terasa penting
Format ebook portabel dalam satu file memang diperlukan, tetapi PDF bukan jawabannya karena teksnya tidak bisa di-reflow
HTML+CSS pada 2024 bisa mereproduksi hampir semua media cetak sambil tetap memungkinkan teks di-reflow
Saya tidak melihat JavaScript harus menjadi keharusan. Ebook seharusnya berupa buku yang ukurannya bisa diubah secara bermakna, dan fungsi dasarnya sebagai buku harus tetap berjalan meski JavaScript dimatikan. Jika perlu interaksi atau peningkatan, JavaScript boleh dipakai, tetapi jika tanpa JavaScript ia tidak berfungsi sebagai buku, saya menganggap itu bug
Menaruh semua gaya secara inline menurut saya keliru karena bisa merusak CSP sebagian pengguna. Pisahkan gaya sebagai resource dengan path relatif terhadap HTML, dan ebook harus melarang pemuatan resource dari domain lain
Terakhir, distribusikan saja sebagai file zip. Rasanya ebook memang sudah bekerja seperti itu
“Apakah ebook memang sudah bekerja seperti zip” sampai batas tertentu benar. Alat unzip bisa mengekstrak file EPUB, dan jika perlu ekstensinya bisa diubah dari .epub menjadi .zip
Namun arah sebaliknya belum tentu berlaku. Sekumpulan file yang sama, sebelum diekstrak, mungkin merupakan EPUB yang valid, tetapi jika dizip ulang sembarangan, hasilnya bisa menjadi EPUB yang tidak valid File mimetype di dalam zip EPUB bersifat khusus: harus menjadi entri pertama dalam arsip, isinya hanya boleh application/epub+zip, dan harus disimpan tanpa kompresi
Mengejutkannya, banyak alat zip mengubah urutan file atau membuat penyimpanan tanpa kompresi hanya untuk sebagian file menjadi sulit, sehingga ini merepotkan. Program zip baris perintah biasanya bisa melakukannya dengan flag, tetapi di library zip ini cukup menyakitkan. Ini berdasarkan pengalaman membuat perangkat lunak pembuat EPUB
Penting untuk membedakan file zip biasa dan ebook. Ekstensinya cukup gunakan .epub
Yang dijelaskan adalah format ePub, yaitu file HTML, CSS, dan gambar yang dimasukkan ke dalam arsip zip
Bagaimana dengan ZIP yang mengekstrak dirinya sendiri? Misalnya seperti halaman ini: https://gildas-lormeau.github.io/
Di dalamnya juga ada CSP untuk membuatnya aman
Saya kurang suka pendekatan membungkus semuanya dalam zip
Hal yang dulu lebih enak saat memakai file .doc lama dibanding .docx adalah bisa mencari kata tertentu dengan sangat cepat di folder berisi ratusan hingga ribuan file. Dalam format zip, itu tidak bisa dilakukan
Baru saja saya menyimpan sebagai .doc dan membukanya dengan editor heksadesimal; isi sebenarnya tersimpan sebagai teks biasa. Format zip atau file PDF sulit dicari dengan grep, dan saya juga ragu apakah teks beberapa ribu karakter benar-benar perlu dikompresi
Jika pembahasannya adalah “HTML+CSS pada 2024 bisa mereproduksi hampir semua media cetak”, ini juga layak dilihat: https://www.princexml.com/samples/
Ini tulisan yang sangat tersusun rapi dari pengembang Nota, yang berupaya mengangkat format EPUB ke tingkat yang setara dengan PDF. Ia juga sudah membuat viewer, dan tulisan itu sendiri ditampilkan melalui port WASM berbasis browser dari viewer tersebut
Salah satu masalahnya adalah sejauh mana EPUB, yang pada dasarnya XHTML, dapat mereproduksi tata letak secara akurat. Patokan artikel asli adalah dokumen terlihat “cukup meyakinkan”, tetapi ada nuansa bahwa agar bisa menandingi PDF, HTML setidaknya membutuhkan fitur tata letak baru di sisi pemenggalan baris
Tampaknya ada dua cara untuk maju. Pertama, browser menyediakan lebih banyak alat tipografi; text-wrap: pretty disebut membantu, tetapi dari tes singkat, kualitas pemenggalan baris tidak terasa membaik. Kedua, menghitung pemenggalan baris terlebih dahulu, tetapi ini hanya mungkin pada rendering tata letak tetap
Penulis juga menyebut anotasi, tetapi saya kurang tahu bagaimana ia akan mengimplementasikannya
Penulis juga membahas EPUB tata letak tetap. EPUB dapat menetapkan paginasi dasar, pemenggalan baris, font, ukuran font, ukuran halaman, posisi gambar, dan sebagainya agar dirender sama di semua tempat
Ini sudah mungkin di EPUB3, tetapi kekurangannya adalah tampilannya tidak bagus di layar seperti ponsel. Bergantung pada reader, nilai bawaan bisa ditimpa, tetapi itu berarti berharap reader dapat membentuk ulang dokumen agar enak dibaca
Alternatifnya adalah EPUB menentukan beberapa rendering untuk jenis layar yang umum. Meski tidak sempurna, membiarkan pembuat dokumen membuat default dan pengguna menimpanya jika mau tampaknya kompromi yang baik
PDF tidak memiliki fungsi pemenggalan baris. Ia lebih dekat ke format gambar yang mirip SVG dan lebih kaku, sehingga hal seperti reflow teks tidak bisa dilakukan
Yang dibutuhkan format ebook adalah markup semantik yang beradaptasi dengan perangkat tempat ia dirender. HTML+CSS memang awalnya dibuat untuk tujuan itu
Karena itu, perancang tata letak buku harus secara sadar menyerahkan sebagian kendali atas tampilan buku kepada pembaca. Sedikit ketidaksempurnaan visual layak dibayar sebagai imbalannya. Jika membutuhkan kesempurnaan visual, gunakan PDF
Tentu saja, semuanya menjadi sulit jika ada elemen interaktif. Sebaiknya elemen interaktif besar dibuka dalam tampilan khusus saat diperlukan, sementara elemen interaktif kecil menerima reflow
Bukankah CSS pada dasarnya mendukung fitur tata letak media berhalaman? Rasanya reader EPUB hanya perlu mengimplementasikan mode tampilan “pratinjau cetak” tradisional
Ironisnya, contoh anotasi yang diberikan penulis sendiri tidak berjalan baik di lingkungan saya. Di Android Firefox layar sentuh, menekan lama memunculkan tautan, bukan popup
Anotasi dan referensi rasanya sudah ada dalam spesifikasi EPUB, mungkin bahkan dalam spesifikasi HTML
Saya juga tidak setuju bahwa menekan lama untuk popup lebih baik daripada anchor hyperlink biasa. Jika fungsi “kembali” pada reader bekerja dengan baik, atau referensi dua arah memiliki tautan “kembali”, cara berpindah jauh lebih tidak mengganggu
Dulu ada sesuatu bernama XSL Formatting Objects(XSL-FO). Tujuannya seperti PDF berbasis XML, tetapi pada tingkat yang lebih tinggi sehingga reflow teks juga memungkinkan
Idenya adalah mendistribusikan dokumen XML bersama stylesheet XSL, lalu mengubahnya menjadi FO untuk rendering, dan untuk dokumen yang sama bisa ada beberapa stylesheet berdasarkan perangkat target atau ukuran halaman
Di Firefox, saya memakai add-on SinglePage untuk menyimpan DOM halaman saat ini sebagai file HTML mandiri. Caranya dengan menyisipkan CSS dan URL data: untuk gambar secara inline, lalu menghapus dependensi dan skrip
Memang tidak sempurna, dan saya tidak percaya browser akan selalu menjaga kompatibilitas mundur, tetapi saya lebih menyukainya daripada menyimpan halaman sebagai PDF atau sebagai banyak file
Menariknya, salah satu dari sedikit halaman yang gagal ditangani add-on ini adalah tulisan tentang EPUB portabel ini. Sepertinya terlalu banyak “keajaiban” yang dipakai untuk menyesuaikan pemformatan. Halaman yang tersimpan masih bisa dibaca, tetapi gayanya sama sekali berbeda dari aslinya
Saya suka bahwa fbreader di Android menampilkan semua buku dengan cara yang sama sesuai pengaturan aplikasi, bukan mengikuti gaya file EPUB. Saya belum pernah melihatnya mencoba menerapkan CSS atau menjalankan skrip yang disertakan dalam file, dan saya berharap tetap begitu. Memuat dependensi eksternal adalah ide yang lebih buruk lagi, dan saya bahkan tidak tahu bahwa itu diperbolehkan sejak awal
Sepertinya yang dimaksud adalah SingleFile
Ngomong-ngomong soal itu, sistem izin add-on Firefox terasa aneh. Untuk melakukan hal yang menarik, add-on hampir selalu harus meminta semua izin, dan akibatnya terbentuk pasar alami bagi pelaku jahat untuk mencari add-on yang bisa diambil alih
Misalnya, add-on SingleFile memang perlu akses karena harus melihat DOM yang sudah dirender dan menyimpannya sebagai file. Tapi kenapa harus punya akses ke semuanya? Tidak bisakah kita memberi izin seperti snapshot DOM once dan write to a single file saja
Seingat saya, salah satu komentar pertama yang saya tulis di HN sekitar 10 tahun lalu adalah tentang keinginan menyimpan halaman web HTML sebagai HTML, bukan PDF
Saat itu saya mungkin tidak bisa menjelaskan alasannya dengan baik, bahkan tidak benar-benar memahaminya, dan keinginan itu diperlakukan seperti hal yang tidak masuk akal. Sekarang rasanya menyenangkan melihat bahwa saya hanya meleset sekitar 10 tahun dari zamannya
Alasan halaman ini sulit di-parse sudah dijelaskan dengan baik oleh komentar lain. Ini adalah tulisan dari pengembang Nota yang ingin mengangkat EPUB ke tingkat yang setara dengan PDF, dan tulisan itu sendiri ditampilkan melalui viewer berbasis browser dengan WASM
FBReader secara default menggunakan CSS dokumen. Kalau ingatan saya benar, itu bisa dimatikan lewat sekitar empat langkah
KOReader kurang ramah, tetapi memberi lebih banyak kontrol. Anda bisa memilih salah satu dari beberapa file CSS yang disediakan atau menulis sendiri
Keunggulan KOReader juga mencakup dukungan OPDS yang sangat baik dan server sinkronisasi self-hosted yang mudah
Tulisan ini memiliki tombol unduh EPUB
Dengan fitur ini, halaman yang memakai sistem ini tidak lagi membutuhkan SinglePage
Setelah melihat bagian itu, saya jadi melihatnya lagi. Bagian yang berbunyi, “Karena itu, saya memutuskan untuk membuat Bene, sistem pembaca EPUB yang lebih ringan. Inilah yang sedang kalian gunakan sekarang. Dokumen ini adalah EPUB, dan bisa diunduh dengan menekan tombol di kanan atas”
Saat membacanya di browser desktop, saya sama sekali tidak menyadarinya sampai diberi tahu langsung. Di mobile, header mengambil lebih banyak ruang layar sehingga lebih mencolok, tetapi selain itu perilakunya hampir seperti halaman web biasa
Mungkin itu pertanda baik
Berbeda dari yang dikatakan beberapa komentar, saya tidak melihat—atau setidaknya tidak menyadari—spinner saat dokumen pertama kali dimuat. Di ponsel terlihat, tetapi berlalu cukup cepat. Saya tidak tahu apakah itu pemuatan program WASM, atau apakah hanya terjadi saat pemuatan pertama
Yang terutama ditunggu oleh spinner adalah pengunduhan file .epub. File itu berukuran 4,77MB, jadi cukup besar jika tidak punya koneksi cepat. Setelah didekompresi, sebagian besar ukurannya diisi gambar, sekitar 99%
Berbeda dari halaman web biasa atau PDF, rendering tampaknya tidak dimulai sampai semua aset, yaitu seluruh ePub, selesai diunduh
Perbedaan yang saya kira akan dibahas dalam tulisan itu, tetapi ternyata tidak, adalah performa. PDF bisa dioptimalkan agar halaman-halamannya cukup independen, sehingga memungkinkan rendering progresif, akses acak, dan paralelisasi tinggi
Di ponsel, saya sama sekali tidak menyadarinya sampai membaca tulisannya. Saya hanya mengira itu halaman web biasa yang menjelaskan proyek tersebut
Hanya karena browser tidak bisa membuka EPUB, proyek ini terasa agak seperti sudah ditakdirkan gagal. Kalau PDF ditautkan, meski ada sedikit perpindahan konteks, browser akan membuka dan menampilkannya
EPUB, jika sesuai penjelasannya, pada dasarnya adalah HTML, jadi agak aneh browser tidak membukanya; tetapi meyakinkan para birokrat Chrome/Mozilla sepertinya tidak mudah
Hal lain yang mengecewakan adalah HTML dan CSS sudah menjadi terlalu besar dan gemuk, sehingga hampir tidak ada orang yang bisa mengimplementasikan “reader” untuk EPUB/HTML. Pada praktiknya itu menjadi “implementasikan browser baru”. Dalam jangka panjang, pendekatan seperti Djot—Markdown yang mudah di-parse lalu diberi sedikit kemampuan rendering—tampak lebih berpeluang
Kompromi sementara pribadi saya adalah memasukkan CSS, SVG, skrip, bahkan gambar base64 semuanya ke dalam satu file HTML. Mirip EPUB, agak gemuk dan jelek, tetapi dengan sedikit perhatian bisa berfungsi dan browser dapat membukanya secara alami
Namun pengguna tidak punya cara untuk tahu bahwa “halaman web ini bisa diunduh dan disimpan offline”. Akan bagus jika ada ekstensi seperti .htmls yang menandakan bahwa itu HTML tanpa resource eksternal
Sampai belum lama ini, browser juga tidak bisa membuka PDF. Sekarang semua browser menyertakan PDF reader yang ditulis dengan ASM/JS
Tidak tampak ada alasan browser tidak bisa melakukan hal yang sama untuk EPUB. Sudah ada ekstensi browser yang melakukan persis hal itu. Persoalannya adalah apakah format EPUB memperoleh popularitas
HTML pada awalnya adalah hypertext. Hanya beberapa tautan, gambar/image, dan tabel
Lalu desain dan layout seperti majalah menjadi “dibutuhkan”, tetapi karena masih berbasis dokumen, hasilnya tetap cukup baik
Setelah itu, HTML dipaksa masuk sebagai platform distribusi aplikasi. Layout CSS saat ini akhirnya menjadi lebih mirip mesin layout aplikasi tradisional
Menurut saya, 20 tahun terakhir sebagian besar terbuang karena tidak ada cara distribusi aplikasi cross-platform yang tepat. Kecuali Java
Jadi sepertinya tulisan ini sendiri adalah EPUB yang dibuka dengan viewer EPUB WASM
Hambatan terbesarnya terasa seperti cakupan implementasi HTML/CSS. Penulis mengatakan “Prinsip pembuatan HTML portabel: jika memungkinkan, sistem yang menghasilkan EPUB portabel harus menghasilkan HTML portabel”, tetapi rasanya itu belum cukup jauh
Agar format ini bekerja secara konsisten di mana-mana, ia harus distandardisasi dan implementasi rendering engine baru juga harus mudah. Mengandalkan webview tidak terasa seperti jalan ke depan
Keindahan PDF adalah sangat dapat diandalkan. PDF dari 10 tahun lalu pun hari ini dirender persis seperti dulu
Agar upaya seperti ini berhasil, cakupan dokumennya tampaknya harus dipersempit secara besar-besaran. Subset XHTML yang diizinkan harus sangat terbatas, dan kemampuan untuk dirender dengan tampilan yang sama di mana-mana harus diprioritaskan. Pertama layout tetap dengan ukuran halaman tetap, lalu dokumen yang bisa reflow. Standar yang menyertakan dokumen pengujian komprehensif dan output rendering juga diperlukan
Browser memang tidak menyediakan UI yang nyaman untuk membuka EPUB, tetapi seharusnya tidak ada masalah dalam merender file HTML per bab di dalamnya
Jika tidak ada dukungan browser, tidak terlalu sulit menulis proxy di sisi server yang mengubah EPUB menjadi situs yang bisa dinavigasi, dengan kontrol pindah bab dan opsi layout sederhana
Tentu saja, untuk melihat sebagian besar ebook komersial lewat proxy semacam itu, dukungan DRM yang dibutuhkan kemungkinan besar akan sangat bermasalah secara hukum
Kalau dipikir-pikir, dukungan browser untuk EPUB DRM yang disetujui penerbit secara teknis hanya setengah langkah dari dukungan DRM untuk halaman web biasa, dan itu prospek yang cukup mengerikan
Saya menganggap PDF sebagai format legacy yang mengerikan dengan kompleksitas yang tidak perlu. Sebagian besar penggunaan PDF tidak ada hubungannya dengan pencetakan, jadi logika typesetting-nya juga tidak terasa relevan
Untuk mayoritas use case, jauh lebih penting agar mudah dibaca di ponsel, tablet, dan komputer
Karena penulis mengatakan iBooks tidak mendukung tampilan scroll, saya terkejut dan mengeceknya sendiri. iBooks di macOS tidak mendukung scrolling file ePub, tetapi di iOS dan iPadOS mendukung. Keputusan Apple yang sangat aneh https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
Spesifikasi PDF memang menyebalkan, tetapi sama sekali tidak ada penggantinya
Saya belum pernah melihat dokumentasi teknis yang didistribusikan dalam format selain PDF yang nyaman dibaca dan dicari. Di ponsel pun sama
Saya tidak menginginkan dokumen yang tampilannya berubah bergantung pada keadaan sementara seperti perangkat baca atau ukuran jendela. Saya menginginkan dokumen dengan layout tetap yang dirancang baik oleh penulisnya
Saat membaca di layar atau jendela kecil pun, jika itu bukan dokumen teks sederhana, saya menginginkan reader pintar yang memudahkan zoom dan pan cepat, bukan perubahan layout. Tidak boleh ada perilaku bodoh seperti pada sebagian reader Android, di mana scroll vertikal atau Page Up/Page Down juga menggeser posisi horizontal sehingga kolom teks sulit dibaca
Cukup mengikuti rekomendasi tradisional tentang lebar maksimum kolom teks saja sudah cukup untuk nyaman dibaca di ponsel. Membaca di ponsel baru menjadi tidak nyaman ketika penulis membuat kolom terlalu lebar dan melanggar aturan tipografi tradisional
Alasan menginginkan dokumen ber-layout tetap bukan hanya karena pencetakan. Itu karena mempertahankan layout dokumen lebih penting daripada layar kecil
Saya tidak tahu kasus spesifik ini, tetapi sebagian reader mungkin melakukannya demi konsistensi dengan perangkat e-paper. Pada e-paper, scrolling dibatasi secara hardware karena refresh rate rendah, prosesor lemah, dan penghematan baterai
Jadi mencoba membuat satu standar yang cocok untuk semuanya tampaknya ide buruk. Untuk standar dokumen digital, lebih baik ada dua. Satu format dengan multimedia dan interaktivitas penuh selain networking, dan satu lagi sebagai subset-nya: hitam-putih, tanpa multimedia, dan interaktivitas terutama dibatasi pada hyperlink di dalam dokumen
Dan dua format seperti itu nyaris sudah ada: HTML, MHTML=EML, dan EPUB
Tentu saja, untuk penyimpanan fisik dan dokumen digital fixed-layout yang jarang, format ketiga juga diperlukan, dan peran itu tampaknya sudah cukup baik diisi oleh PDF/A
Jika benar-benar harus mencetak sesuatu, PDF adalah jalur yang paling dapat diandalkan dan portabel
SVG multi-halaman mungkin juga bisa, tetapi untuk mencetak banyak halaman dengan benar, pada akhirnya tampaknya tetap harus diekspor dulu ke PDF. Saya mengatakan ini sambil melihat Inkscape
Saya penasaran apa yang diberikan EPUB reader yang tidak ada di browser. Untuk saat ini, jawabannya tampaknya hanya satu hal kecil: file .epub, yaitu file zip, bisa diperlakukan seperti direktori
Kalau perbedaan antara EPUB reader dan subset browser memang hanya itu, cara paling sederhana dan paling minim usaha sepertinya begini
Membuat browser yang sudah ada memperlakukan file zip seperti direktori dalam kondisi tertentu
Mendefinisikan batasan HTML yang bisa diperiksa secara mekanis, yang menjamin aset sepenuhnya lokal seperti yang dibahas di tulisan asli. Persyaratan bahwa semua URL selain tautan harus berupa path relatif saja mungkin sudah cukup
Menyatakan file zip yang memenuhi batasan ini sebagai “EPUB portabel”
Melupakan semua EPUB reader khusus, baik yang lama maupun yang baru
Setuju. Ini terdengar seperti solusi yang sebenarnya
Untuk aset yang sepenuhnya lokal, saya ingin melihat persyaratan bahwa semua objek harus memiliki opsi fallback yang tersedia secara lokal. Misalnya, kalau font itu tidak bisa diambil, gunakan font standar. Meski tidak tampak sempurna, kalau dibatasi dalam cakupan fallback, seharusnya tetap berjalan dengan wajar
Ada satu mode kegagalan yang belum cukup dibahas: gambar yang tidak berfungsi dengan baik. Pada dasarnya, gambar tidak bisa reflow. Sebagian besar bisa diselesaikan dengan memakai SVG, tetapi tidak untuk gambar raster sungguhan. Pada akhirnya mungkin harus menyediakan beberapa resolusi
Saya juga pernah mengalami masalah terkait dan belum melihat jawaban yang bagus: SVG yang sadar resolusi, lalu mengambil gambar yang lebih detail ketika tersedia resolusi yang cukup. Jika menggambar garis subpiksel, hasilnya kabur, tetapi ketika gambar yang sama diperbesar, garis-garis itu menjadi berguna. Ikon Windows mengakui hal ini dengan memungkinkan beberapa resolusi dan memakai yang sesuai situasi
Penulisnya adalah peneliti pascadoktoral yang dibimbing oleh Shriram Krishnamurthi. Shriram Krishnamurthi adalah penulis Programming Languages: Application and Interpretation(PLAI) dan salah satu penulis Data-Centric Introduction to Computing(DCIC)
Saya sedang membaca PLAI dan DCIC, dan benar-benar kagum pada perhatian rinci yang dicurahkan para penulis untuk menjadikannya karya seni pendidikan. Itu benar-benar bentuk kecintaan https://willcrichton.net/
PDF bisa menyertakan font, tetapi sering kali tidak, dan bergantung pada font sistem. Salah satu alasannya adalah memasukkan font ke PDF bisa membuat ukuran file membengkak besar. Dalam beberapa kasus, satu font saja bisa lebih besar daripada seluruh sisa file
Saya pernah mengimplementasikan embedding font di perangkat lunak pembuat PDF, dan ternyata cukup sulit mencari cara agar itu bekerja dengan andal
Anggapan bahwa PDF dirender secara konsisten juga tidak sepenuhnya benar. Beberapa kali saya melihat PDF yang sama dirender berbeda tergantung PDF viewer yang digunakan. Biasanya perbedaannya halus, tetapi kadang ada kasus batas yang perbedaannya cukup besar. Saya juga pernah mengalami versi Acrobat Reader yang sama merender PDF secara berbeda di sistem operasi yang berbeda
Hanya ada beberapa font sistem standar yang boleh dihilangkan dari file PDF, dan dokumen mengasumsikan font yang dipakai untuk rendering memiliki metrik yang sama dengan typeface tradisional seperti Times, Helvetica, dan Courier
Jadi jika memakai font sistem yang kompatibel, tata letak dokumen hasil render seharusnya tidak berubah. Tentu saja ada kasus font sistem yang dipromosikan kompatibel secara metrik dengan font Adobe PostScript lama, tetapi tetap memiliki perbedaan halus
Selain sedikit font sistem standar itu, dokumen PDF biasanya hanya menyertakan subset glyph yang sesuai dengan karakter yang benar-benar dipakai dalam teks, bukan seluruh font tersebut
Selama lebih dari 20 tahun saya mengira PDF dirender secara konsisten, sampai saat wawancara seseorang mengatakan dokumen saya terlihat aneh, barulah saya tahu font bisa hilang
Itu The Daily WTF dalam kehidupan sehari-hari
Saya penasaran apakah ada perangkat lunak yang meminimalkan font dengan menghapus code point yang tidak digunakan dalam dokumen
1 komentar
Pendapat Hacker News
Saya sangat tertarik pada irisan antara ebook, keamanan, dan web LowJS, jadi topik ini terasa penting
Format ebook portabel dalam satu file memang diperlukan, tetapi PDF bukan jawabannya karena teksnya tidak bisa di-reflow
HTML+CSS pada 2024 bisa mereproduksi hampir semua media cetak sambil tetap memungkinkan teks di-reflow
Saya tidak melihat JavaScript harus menjadi keharusan. Ebook seharusnya berupa buku yang ukurannya bisa diubah secara bermakna, dan fungsi dasarnya sebagai buku harus tetap berjalan meski JavaScript dimatikan. Jika perlu interaksi atau peningkatan, JavaScript boleh dipakai, tetapi jika tanpa JavaScript ia tidak berfungsi sebagai buku, saya menganggap itu bug
Menaruh semua gaya secara inline menurut saya keliru karena bisa merusak CSP sebagian pengguna. Pisahkan gaya sebagai resource dengan path relatif terhadap HTML, dan ebook harus melarang pemuatan resource dari domain lain
Terakhir, distribusikan saja sebagai file zip. Rasanya ebook memang sudah bekerja seperti itu
Namun arah sebaliknya belum tentu berlaku. Sekumpulan file yang sama, sebelum diekstrak, mungkin merupakan EPUB yang valid, tetapi jika dizip ulang sembarangan, hasilnya bisa menjadi EPUB yang tidak valid
File mimetype di dalam zip EPUB bersifat khusus: harus menjadi entri pertama dalam arsip, isinya hanya boleh
application/epub+zip, dan harus disimpan tanpa kompresiMengejutkannya, banyak alat zip mengubah urutan file atau membuat penyimpanan tanpa kompresi hanya untuk sebagian file menjadi sulit, sehingga ini merepotkan. Program zip baris perintah biasanya bisa melakukannya dengan flag, tetapi di library zip ini cukup menyakitkan. Ini berdasarkan pengalaman membuat perangkat lunak pembuat EPUB
Yang dijelaskan adalah format ePub, yaitu file HTML, CSS, dan gambar yang dimasukkan ke dalam arsip zip
Di dalamnya juga ada CSP untuk membuatnya aman
Hal yang dulu lebih enak saat memakai file .doc lama dibanding .docx adalah bisa mencari kata tertentu dengan sangat cepat di folder berisi ratusan hingga ribuan file. Dalam format zip, itu tidak bisa dilakukan
Baru saja saya menyimpan sebagai .doc dan membukanya dengan editor heksadesimal; isi sebenarnya tersimpan sebagai teks biasa. Format zip atau file PDF sulit dicari dengan grep, dan saya juga ragu apakah teks beberapa ribu karakter benar-benar perlu dikompresi
Ini tulisan yang sangat tersusun rapi dari pengembang Nota, yang berupaya mengangkat format EPUB ke tingkat yang setara dengan PDF. Ia juga sudah membuat viewer, dan tulisan itu sendiri ditampilkan melalui port WASM berbasis browser dari viewer tersebut
Salah satu masalahnya adalah sejauh mana EPUB, yang pada dasarnya XHTML, dapat mereproduksi tata letak secara akurat. Patokan artikel asli adalah dokumen terlihat “cukup meyakinkan”, tetapi ada nuansa bahwa agar bisa menandingi PDF, HTML setidaknya membutuhkan fitur tata letak baru di sisi pemenggalan baris
Tampaknya ada dua cara untuk maju. Pertama, browser menyediakan lebih banyak alat tipografi;
text-wrap: prettydisebut membantu, tetapi dari tes singkat, kualitas pemenggalan baris tidak terasa membaik. Kedua, menghitung pemenggalan baris terlebih dahulu, tetapi ini hanya mungkin pada rendering tata letak tetapPenulis juga menyebut anotasi, tetapi saya kurang tahu bagaimana ia akan mengimplementasikannya
Ini sudah mungkin di EPUB3, tetapi kekurangannya adalah tampilannya tidak bagus di layar seperti ponsel. Bergantung pada reader, nilai bawaan bisa ditimpa, tetapi itu berarti berharap reader dapat membentuk ulang dokumen agar enak dibaca
Alternatifnya adalah EPUB menentukan beberapa rendering untuk jenis layar yang umum. Meski tidak sempurna, membiarkan pembuat dokumen membuat default dan pengguna menimpanya jika mau tampaknya kompromi yang baik
Yang dibutuhkan format ebook adalah markup semantik yang beradaptasi dengan perangkat tempat ia dirender. HTML+CSS memang awalnya dibuat untuk tujuan itu
Karena itu, perancang tata letak buku harus secara sadar menyerahkan sebagian kendali atas tampilan buku kepada pembaca. Sedikit ketidaksempurnaan visual layak dibayar sebagai imbalannya. Jika membutuhkan kesempurnaan visual, gunakan PDF
Tentu saja, semuanya menjadi sulit jika ada elemen interaktif. Sebaiknya elemen interaktif besar dibuka dalam tampilan khusus saat diperlukan, sementara elemen interaktif kecil menerima reflow
Anotasi dan referensi rasanya sudah ada dalam spesifikasi EPUB, mungkin bahkan dalam spesifikasi HTML
Saya juga tidak setuju bahwa menekan lama untuk popup lebih baik daripada anchor hyperlink biasa. Jika fungsi “kembali” pada reader bekerja dengan baik, atau referensi dua arah memiliki tautan “kembali”, cara berpindah jauh lebih tidak mengganggu
Idenya adalah mendistribusikan dokumen XML bersama stylesheet XSL, lalu mengubahnya menjadi FO untuk rendering, dan untuk dokumen yang sama bisa ada beberapa stylesheet berdasarkan perangkat target atau ukuran halaman
Di Firefox, saya memakai add-on SinglePage untuk menyimpan DOM halaman saat ini sebagai file HTML mandiri. Caranya dengan menyisipkan CSS dan URL
data:untuk gambar secara inline, lalu menghapus dependensi dan skripMemang tidak sempurna, dan saya tidak percaya browser akan selalu menjaga kompatibilitas mundur, tetapi saya lebih menyukainya daripada menyimpan halaman sebagai PDF atau sebagai banyak file
Menariknya, salah satu dari sedikit halaman yang gagal ditangani add-on ini adalah tulisan tentang EPUB portabel ini. Sepertinya terlalu banyak “keajaiban” yang dipakai untuk menyesuaikan pemformatan. Halaman yang tersimpan masih bisa dibaca, tetapi gayanya sama sekali berbeda dari aslinya
Saya suka bahwa fbreader di Android menampilkan semua buku dengan cara yang sama sesuai pengaturan aplikasi, bukan mengikuti gaya file EPUB. Saya belum pernah melihatnya mencoba menerapkan CSS atau menjalankan skrip yang disertakan dalam file, dan saya berharap tetap begitu. Memuat dependensi eksternal adalah ide yang lebih buruk lagi, dan saya bahkan tidak tahu bahwa itu diperbolehkan sejak awal
Ngomong-ngomong soal itu, sistem izin add-on Firefox terasa aneh. Untuk melakukan hal yang menarik, add-on hampir selalu harus meminta semua izin, dan akibatnya terbentuk pasar alami bagi pelaku jahat untuk mencari add-on yang bisa diambil alih
Misalnya, add-on SingleFile memang perlu akses karena harus melihat DOM yang sudah dirender dan menyimpannya sebagai file. Tapi kenapa harus punya akses ke semuanya? Tidak bisakah kita memberi izin seperti
snapshot DOM oncedanwrite to a single filesajaSaat itu saya mungkin tidak bisa menjelaskan alasannya dengan baik, bahkan tidak benar-benar memahaminya, dan keinginan itu diperlakukan seperti hal yang tidak masuk akal. Sekarang rasanya menyenangkan melihat bahwa saya hanya meleset sekitar 10 tahun dari zamannya
KOReader kurang ramah, tetapi memberi lebih banyak kontrol. Anda bisa memilih salah satu dari beberapa file CSS yang disediakan atau menulis sendiri
Keunggulan KOReader juga mencakup dukungan OPDS yang sangat baik dan server sinkronisasi self-hosted yang mudah
Dengan fitur ini, halaman yang memakai sistem ini tidak lagi membutuhkan SinglePage
Setelah melihat bagian itu, saya jadi melihatnya lagi. Bagian yang berbunyi, “Karena itu, saya memutuskan untuk membuat Bene, sistem pembaca EPUB yang lebih ringan. Inilah yang sedang kalian gunakan sekarang. Dokumen ini adalah EPUB, dan bisa diunduh dengan menekan tombol di kanan atas”
Saat membacanya di browser desktop, saya sama sekali tidak menyadarinya sampai diberi tahu langsung. Di mobile, header mengambil lebih banyak ruang layar sehingga lebih mencolok, tetapi selain itu perilakunya hampir seperti halaman web biasa
Mungkin itu pertanda baik
Berbeda dari yang dikatakan beberapa komentar, saya tidak melihat—atau setidaknya tidak menyadari—spinner saat dokumen pertama kali dimuat. Di ponsel terlihat, tetapi berlalu cukup cepat. Saya tidak tahu apakah itu pemuatan program WASM, atau apakah hanya terjadi saat pemuatan pertama
Berbeda dari halaman web biasa atau PDF, rendering tampaknya tidak dimulai sampai semua aset, yaitu seluruh ePub, selesai diunduh
Perbedaan yang saya kira akan dibahas dalam tulisan itu, tetapi ternyata tidak, adalah performa. PDF bisa dioptimalkan agar halaman-halamannya cukup independen, sehingga memungkinkan rendering progresif, akses acak, dan paralelisasi tinggi
Hanya karena browser tidak bisa membuka EPUB, proyek ini terasa agak seperti sudah ditakdirkan gagal. Kalau PDF ditautkan, meski ada sedikit perpindahan konteks, browser akan membuka dan menampilkannya
EPUB, jika sesuai penjelasannya, pada dasarnya adalah HTML, jadi agak aneh browser tidak membukanya; tetapi meyakinkan para birokrat Chrome/Mozilla sepertinya tidak mudah
Hal lain yang mengecewakan adalah HTML dan CSS sudah menjadi terlalu besar dan gemuk, sehingga hampir tidak ada orang yang bisa mengimplementasikan “reader” untuk EPUB/HTML. Pada praktiknya itu menjadi “implementasikan browser baru”. Dalam jangka panjang, pendekatan seperti Djot—Markdown yang mudah di-parse lalu diberi sedikit kemampuan rendering—tampak lebih berpeluang
Kompromi sementara pribadi saya adalah memasukkan CSS, SVG, skrip, bahkan gambar base64 semuanya ke dalam satu file HTML. Mirip EPUB, agak gemuk dan jelek, tetapi dengan sedikit perhatian bisa berfungsi dan browser dapat membukanya secara alami
Namun pengguna tidak punya cara untuk tahu bahwa “halaman web ini bisa diunduh dan disimpan offline”. Akan bagus jika ada ekstensi seperti
.htmlsyang menandakan bahwa itu HTML tanpa resource eksternalTidak tampak ada alasan browser tidak bisa melakukan hal yang sama untuk EPUB. Sudah ada ekstensi browser yang melakukan persis hal itu. Persoalannya adalah apakah format EPUB memperoleh popularitas
Lalu desain dan layout seperti majalah menjadi “dibutuhkan”, tetapi karena masih berbasis dokumen, hasilnya tetap cukup baik
Setelah itu, HTML dipaksa masuk sebagai platform distribusi aplikasi. Layout CSS saat ini akhirnya menjadi lebih mirip mesin layout aplikasi tradisional
Menurut saya, 20 tahun terakhir sebagian besar terbuang karena tidak ada cara distribusi aplikasi cross-platform yang tepat. Kecuali Java
Agar format ini bekerja secara konsisten di mana-mana, ia harus distandardisasi dan implementasi rendering engine baru juga harus mudah. Mengandalkan webview tidak terasa seperti jalan ke depan
Keindahan PDF adalah sangat dapat diandalkan. PDF dari 10 tahun lalu pun hari ini dirender persis seperti dulu
Agar upaya seperti ini berhasil, cakupan dokumennya tampaknya harus dipersempit secara besar-besaran. Subset XHTML yang diizinkan harus sangat terbatas, dan kemampuan untuk dirender dengan tampilan yang sama di mana-mana harus diprioritaskan. Pertama layout tetap dengan ukuran halaman tetap, lalu dokumen yang bisa reflow. Standar yang menyertakan dokumen pengujian komprehensif dan output rendering juga diperlukan
Jika tidak ada dukungan browser, tidak terlalu sulit menulis proxy di sisi server yang mengubah EPUB menjadi situs yang bisa dinavigasi, dengan kontrol pindah bab dan opsi layout sederhana
Tentu saja, untuk melihat sebagian besar ebook komersial lewat proxy semacam itu, dukungan DRM yang dibutuhkan kemungkinan besar akan sangat bermasalah secara hukum
Kalau dipikir-pikir, dukungan browser untuk EPUB DRM yang disetujui penerbit secara teknis hanya setengah langkah dari dukungan DRM untuk halaman web biasa, dan itu prospek yang cukup mengerikan
Saya menganggap PDF sebagai format legacy yang mengerikan dengan kompleksitas yang tidak perlu. Sebagian besar penggunaan PDF tidak ada hubungannya dengan pencetakan, jadi logika typesetting-nya juga tidak terasa relevan
Untuk mayoritas use case, jauh lebih penting agar mudah dibaca di ponsel, tablet, dan komputer
Karena penulis mengatakan iBooks tidak mendukung tampilan scroll, saya terkejut dan mengeceknya sendiri. iBooks di macOS tidak mendukung scrolling file ePub, tetapi di iOS dan iPadOS mendukung. Keputusan Apple yang sangat aneh
https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
Saya belum pernah melihat dokumentasi teknis yang didistribusikan dalam format selain PDF yang nyaman dibaca dan dicari. Di ponsel pun sama
Saya tidak menginginkan dokumen yang tampilannya berubah bergantung pada keadaan sementara seperti perangkat baca atau ukuran jendela. Saya menginginkan dokumen dengan layout tetap yang dirancang baik oleh penulisnya
Saat membaca di layar atau jendela kecil pun, jika itu bukan dokumen teks sederhana, saya menginginkan reader pintar yang memudahkan zoom dan pan cepat, bukan perubahan layout. Tidak boleh ada perilaku bodoh seperti pada sebagian reader Android, di mana scroll vertikal atau Page Up/Page Down juga menggeser posisi horizontal sehingga kolom teks sulit dibaca
Cukup mengikuti rekomendasi tradisional tentang lebar maksimum kolom teks saja sudah cukup untuk nyaman dibaca di ponsel. Membaca di ponsel baru menjadi tidak nyaman ketika penulis membuat kolom terlalu lebar dan melanggar aturan tipografi tradisional
Jadi mencoba membuat satu standar yang cocok untuk semuanya tampaknya ide buruk. Untuk standar dokumen digital, lebih baik ada dua. Satu format dengan multimedia dan interaktivitas penuh selain networking, dan satu lagi sebagai subset-nya: hitam-putih, tanpa multimedia, dan interaktivitas terutama dibatasi pada hyperlink di dalam dokumen
Dan dua format seperti itu nyaris sudah ada: HTML, MHTML=EML, dan EPUB
Tentu saja, untuk penyimpanan fisik dan dokumen digital fixed-layout yang jarang, format ketiga juga diperlukan, dan peran itu tampaknya sudah cukup baik diisi oleh PDF/A
SVG multi-halaman mungkin juga bisa, tetapi untuk mencetak banyak halaman dengan benar, pada akhirnya tampaknya tetap harus diekspor dulu ke PDF. Saya mengatakan ini sambil melihat Inkscape
8 hari lalu ada “Portable Web Documents – An Alternative to PDF Based on HTML5 (2019)” yang mendapat 134 poin
https://news.ycombinator.com/item?id=39036774
https://news.ycombinator.com/item?id=39037135
Saya penasaran apa yang diberikan EPUB reader yang tidak ada di browser. Untuk saat ini, jawabannya tampaknya hanya satu hal kecil: file .epub, yaitu file zip, bisa diperlakukan seperti direktori
Kalau perbedaan antara EPUB reader dan subset browser memang hanya itu, cara paling sederhana dan paling minim usaha sepertinya begini
Membuat browser yang sudah ada memperlakukan file zip seperti direktori dalam kondisi tertentu
Mendefinisikan batasan HTML yang bisa diperiksa secara mekanis, yang menjamin aset sepenuhnya lokal seperti yang dibahas di tulisan asli. Persyaratan bahwa semua URL selain tautan harus berupa path relatif saja mungkin sudah cukup
Menyatakan file zip yang memenuhi batasan ini sebagai “EPUB portabel”
Melupakan semua EPUB reader khusus, baik yang lama maupun yang baru
Untuk aset yang sepenuhnya lokal, saya ingin melihat persyaratan bahwa semua objek harus memiliki opsi fallback yang tersedia secara lokal. Misalnya, kalau font itu tidak bisa diambil, gunakan font standar. Meski tidak tampak sempurna, kalau dibatasi dalam cakupan fallback, seharusnya tetap berjalan dengan wajar
Ada satu mode kegagalan yang belum cukup dibahas: gambar yang tidak berfungsi dengan baik. Pada dasarnya, gambar tidak bisa reflow. Sebagian besar bisa diselesaikan dengan memakai SVG, tetapi tidak untuk gambar raster sungguhan. Pada akhirnya mungkin harus menyediakan beberapa resolusi
Saya juga pernah mengalami masalah terkait dan belum melihat jawaban yang bagus: SVG yang sadar resolusi, lalu mengambil gambar yang lebih detail ketika tersedia resolusi yang cukup. Jika menggambar garis subpiksel, hasilnya kabur, tetapi ketika gambar yang sama diperbesar, garis-garis itu menjadi berguna. Ikon Windows mengakui hal ini dengan memungkinkan beberapa resolusi dan memakai yang sesuai situasi
Penulisnya adalah peneliti pascadoktoral yang dibimbing oleh Shriram Krishnamurthi. Shriram Krishnamurthi adalah penulis Programming Languages: Application and Interpretation(PLAI) dan salah satu penulis Data-Centric Introduction to Computing(DCIC)
Saya sedang membaca PLAI dan DCIC, dan benar-benar kagum pada perhatian rinci yang dicurahkan para penulis untuk menjadikannya karya seni pendidikan. Itu benar-benar bentuk kecintaan
https://willcrichton.net/
https://rust-book.cs.brown.edu/
PDF bisa menyertakan font, tetapi sering kali tidak, dan bergantung pada font sistem. Salah satu alasannya adalah memasukkan font ke PDF bisa membuat ukuran file membengkak besar. Dalam beberapa kasus, satu font saja bisa lebih besar daripada seluruh sisa file
Saya pernah mengimplementasikan embedding font di perangkat lunak pembuat PDF, dan ternyata cukup sulit mencari cara agar itu bekerja dengan andal
Anggapan bahwa PDF dirender secara konsisten juga tidak sepenuhnya benar. Beberapa kali saya melihat PDF yang sama dirender berbeda tergantung PDF viewer yang digunakan. Biasanya perbedaannya halus, tetapi kadang ada kasus batas yang perbedaannya cukup besar. Saya juga pernah mengalami versi Acrobat Reader yang sama merender PDF secara berbeda di sistem operasi yang berbeda
Jadi jika memakai font sistem yang kompatibel, tata letak dokumen hasil render seharusnya tidak berubah. Tentu saja ada kasus font sistem yang dipromosikan kompatibel secara metrik dengan font Adobe PostScript lama, tetapi tetap memiliki perbedaan halus
Selain sedikit font sistem standar itu, dokumen PDF biasanya hanya menyertakan subset glyph yang sesuai dengan karakter yang benar-benar dipakai dalam teks, bukan seluruh font tersebut
Itu The Daily WTF dalam kehidupan sehari-hari