मुझे e-book, security, और LowJS web के intersection में बहुत दिलचस्पी है, इसलिए यह विषय अहम लगता है
single-file portable e-book format की ज़रूरत है, लेकिन PDF इसका जवाब नहीं है क्योंकि उसमें text reflow नहीं होता
2024 का HTML+CSS लगभग सभी print media को reproduce कर सकता है, और साथ ही text reflow भी संभव बनाता है
मुझे नहीं लगता कि JavaScript का अनिवार्य होना ज़रूरी है. e-book ऐसी किताब होनी चाहिए जिसका आकार अर्थपूर्ण तरीके से बदला जा सके, और JavaScript बंद होने पर भी किताब के रूप में उसकी मूल functionality काम करनी चाहिए. interaction या enhancement चाहिए तो JavaScript इस्तेमाल कर सकते हैं, लेकिन अगर JavaScript के बिना वह किताब की तरह काम ही नहीं करती, तो मैं उसे bug मानूँगा
styles को पूरा inline डालना गलती लगता है, क्योंकि इससे कुछ users की CSP टूट सकती है. styles को HTML के हिसाब से relative-path resources में अलग रखना चाहिए, और e-book को दूसरे domains से resources load करने से रोकना चाहिए
आखिर में, इसे बस zip file के रूप में distribute किया जा सकता है. क्या e-book पहले से वैसे ही काम नहीं करती?
“क्या e-book पहले से zip की तरह काम करती है” — यह कुछ हद तक सही है. unzip tool EPUB file को खोल सकता है, और ज़रूरत पड़े तो extension को .epub से .zip में बदला जा सकता है
लेकिन उल्टी दिशा में यह हमेशा सही नहीं होता. वही file bundle unpack करने से पहले valid EPUB रहा हो, फिर भी अगर उसे जैसे-तैसे दोबारा zip कर दिया जाए, तो वह valid EPUB न रहे
EPUB zip के अंदर mimetype file खास होती है: वह archive की पहली entry होनी चाहिए, उसमें सिर्फ application/epub+zip होना चाहिए, और उसे uncompressed state में store किया जाना चाहिए
हैरानी की बात है कि बहुत से zip tools file order बदल देते हैं या कुछ files को ही uncompressed रखने में मुश्किल पैदा करते हैं, जिससे यह झंझट बन जाता है. command-line zip program में यह आमतौर पर flags से हो जाता है, लेकिन zip libraries में यह काफ़ी painful है. यह बात EPUB generation software बनाने के अनुभव से कह रहा हूँ
साधारण zip file और e-book में फ़र्क करना ज़रूरी है. extension के लिए .epub इस्तेमाल किया जा सकता है
जो बताया गया है वह ePub format है, जिसमें HTML, CSS, और image files zip archive के अंदर जाती हैं
self-extracting ZIP कैसा रहेगा? उदाहरण के लिए, इस page की तरह: https://gildas-lormeau.github.io/
इसमें उसे सुरक्षित बनाने के लिए CSP भी शामिल है
मुझे सब कुछ zip में पैक करने का तरीका पसंद नहीं है
पुराने .doc files को .docx की तुलना में इस्तेमाल करने का एक अच्छा पहलू यह था कि सैकड़ों या हज़ारों files वाले folder में किसी खास शब्द को बहुत तेज़ी से खोजा जा सकता था. zip format में यह नहीं हो पाता
अभी .doc में save करके hex editor में खोला तो असली content plain text में मौजूद था. zip format या PDF files में grep से खोजना मुश्किल होता है, और मुझे यह भी संदेह है कि कुछ हज़ार characters के text के लिए compression सच में ज़रूरी भी है या नहीं
अगर बात यह है कि “2024 का HTML+CSS लगभग सभी print media को reproduce कर सकता है”, तो यह भी देखने लायक है: https://www.princexml.com/samples/
यह Nota developer द्वारा लिखा गया बहुत सुव्यवस्थित लेख है, जिसका मकसद EPUB format को PDF के बराबर स्तर तक ले जाना है. उन्होंने viewer भी बना लिया है, और लेख खुद भी उसी viewer के browser-based WASM port में दिखाया जा रहा है
असल समस्याओं में से एक यह है कि EPUB, जो व्यवहार में XHTML ही है, layout को कितनी सटीकता से reproduce कर सकता है. मूल लेख का मानदंड यह है कि document “काफ़ी ठीक” दिखे, लेकिन PDF के बराबर पहुँचने के लिए कम से कम line breaking के मामले में HTML को नई layout features चाहिए — ऐसा संकेत मिलता है
आगे बढ़ने के दो रास्ते दिखते हैं. एक यह कि browser अधिक typography tools दे; कहा जाता है कि text-wrap: pretty मदद करता है, लेकिन मैंने थोड़ी testing की तो line breaking quality बेहतर नहीं लगी. दूसरा तरीका line breaks को पहले से calculate करना है, लेकिन यह सिर्फ fixed-layout rendering में ही संभव है
लेखक ने annotations का ज़िक्र तो किया है, लेकिन उन्हें कैसे implement करना है, यह साफ़ नहीं है
लेखक fixed-layout EPUB की भी चर्चा करता है. EPUB में default pagination, line breaks, fonts, font sizes, page size, image positions आदि तय किए जा सकते हैं ताकि हर जगह rendering एक जैसी हो
यह EPUB3 में पहले से संभव है, लेकिन phone जैसी screens पर इसका नतीजा अच्छा नहीं दिखता. reader के हिसाब से defaults override किए जा सकते हैं, लेकिन तब उम्मीद करनी पड़ती है कि reader document को दोबारा अच्छे ढंग से बना दे
एक विकल्प यह है कि EPUB आम screen types के लिए कई renderings बताए. यह perfect तो नहीं होगा, लेकिन document creator को defaults बनाने देना और user को चाहें तो override करने देना एक अच्छा compromise लगता है
PDF में line breaking functionality नहीं होती. वह SVG जैसे image format के ज़्यादा क़रीब है और उससे भी ज़्यादा rigid है, इसलिए उसमें text reflow जैसी चीज़ें नहीं होतीं
e-book format को semantic markup चाहिए जो render होने वाली device के मुताबिक adapt करे. HTML+CSS मूल रूप से इसी उद्देश्य के लिए बनाए गए थे
इसलिए book layout designer को यह बात मानकर चलना होगा कि किताब कैसी दिखेगी, इस पर उसका कुछ नियंत्रण जानबूझकर पाठक को सौंपना पड़ेगा. थोड़ी visual imperfection इसकी उचित कीमत है. अगर visual perfection चाहिए, तो PDF इस्तेमाल करें
बेशक interactive elements आने पर बात मुश्किल हो जाती है. बड़े interactive elements को ज़रूरत पड़ने पर dedicated view में खोला जा सकता है, और छोटे interactive elements को reflow स्वीकार करना चाहिए
क्या CSS मूल रूप से paged media layout features को support नहीं करता? लगता है EPUB reader को बस पारंपरिक “print preview” display mode implement करना होगा
विडंबना यह है कि लेखक ने annotation के लिए जो उदाहरण दिया है, वही मेरे environment में ठीक से काम नहीं करता. touchscreen Android Firefox में long-press करने पर popup की जगह link खुलता है
annotations और references शायद पहले से EPUB spec में हैं, शायद HTML spec में भी
और मैं इस बात से सहमत नहीं हूँ कि popup के लिए long-press करना सामान्य hyperlink anchor से बेहतर है. अगर reader का “back” function ठीक से काम करे, या bidirectional references में “back” link हो, तो navigation वाला तरीका कहीं कम बाधक है
पहले XSL Formatting Objects(XSL-FO) नाम की चीज़ हुआ करती थी. इसका लक्ष्य XML-based PDF जैसा कुछ बनाना था, लेकिन यह उससे ऊँचे स्तर का था, इसलिए text reflow भी संभव था
विचार यह था कि XML document और XSL stylesheet को साथ में distribute किया जाए, फिर rendering के लिए उसे FO में transform किया जाए, और एक ही document के लिए target device या page size के हिसाब से कई stylesheets रखी जा सकें
Firefox में SinglePage addon का इस्तेमाल करके मौजूदा page DOM को standalone HTML file के रूप में सेव किया जाता है। इसमें CSS और images के लिए data: URL को inline किया जाता है, और dependencies व scripts हटा दिए जाते हैं
यह परफेक्ट नहीं है, और मुझे यह भरोसा भी नहीं कि browser हमेशा backward compatibility बनाए रखेंगे, लेकिन page को PDF या कई files में सेव करने की तुलना में मैं इसे ज़्यादा पसंद करता हूँ
दिलचस्प बात यह है कि जिन बहुत कम pages पर यह addon फेल हुआ, उनमें से एक यही portable EPUBs वाला लेख था। लगता है formatting मिलाने के लिए इसमें बहुत ज़्यादा जादू लगाया गया है। सेव किया गया page पढ़ने लायक था, लेकिन style मूल से बिल्कुल अलग था
Android पर fbreader की यह बात अच्छी लगती है कि वह सभी किताबों को EPUB file की style के बजाय app settings के अनुसार एक जैसा दिखाता है। मैंने उसे कभी CSS apply करते या file में शामिल scripts चलाते नहीं देखा, और उम्मीद है आगे भी ऐसा न करे। बाहरी dependencies लोड करना तो और भी बुरा विचार है, और मुझे तो पता भी नहीं था कि यह शुरू से allowed है
लगता है आप SingleFile की बात कर रहे हैं
वैसे इस बारे में कहूँ तो Firefox addon permission system अजीब है। कुछ भी दिलचस्प करने के लिए लगभग हर permission माँगनी पड़ती है, और नतीजे में ऐसे addons के लिए एक स्वाभाविक market बन जाता है जिन्हें कोई दुर्भावनापूर्ण actor खरीद सके
उदाहरण के लिए SingleFile addon को rendered DOM देखने और उसे file में सेव करने के लिए access permission चाहिए ही। लेकिन यह क्यों हर चीज़ तक पहुँच माँगे, यह समझ नहीं आता। क्या snapshot DOM once, write to a single file जैसी permissions नहीं दी जा सकतीं
लगभग 10 साल पहले HN पर मेरी शुरुआती comments में से एक शायद इस बारे में थी कि मैं HTML webpage को PDF नहीं बल्कि HTML के रूप में सेव करना चाहता हूँ
तब मैं न तो इसका कारण ठीक से समझा पा रहा था, न खुद समझता था, लेकिन इसे किसी बेहूदा इच्छा की तरह लिया गया था। अब देखकर अच्छा लगता है कि मैं बस लगभग 10 साल समय से आगे या पीछे था
इस page को parse करना मुश्किल क्यों है, यह दूसरी comments में अच्छी तरह समझाया गया है। Nota developer EPUB को PDF के बराबर स्तर तक ले जाने की बात कर रहा है, और खुद यह लेख browser-based WASM viewer में दिखाया जा रहा है
FBReader डिफ़ॉल्ट रूप से document का CSS इस्तेमाल करता है। अगर मुझे सही याद है, तो इसे लगभग चार स्तरों में बंद किया जा सकता है
KOReader कम friendly है, लेकिन ज़्यादा control देता है। दिए गए कई CSS files में से कोई खास file चुनी जा सकती है या खुद भी लिखी जा सकती है
KOReader की खूबियों में शानदार OPDS support और आसान self-hosted sync server भी है
इस लेख में EPUB download button है
यह सुविधा होने पर, इस system का उपयोग करने वाले pages पर SinglePage की ज़रूरत नहीं रहती
वह हिस्सा देखकर मैंने फिर से ध्यान दिया। बात उस हिस्से की है: “इसलिए मैंने एक हल्का EPUB reading system, Bene, बनाने का फैसला किया। आप अभी वही इस्तेमाल कर रहे हैं। यह document EPUB है, और इसे ऊपर दाईं ओर के button से download किया जा सकता है”
desktop browser में पढ़ते समय, जब तक किसी ने सीधे बताया नहीं, मुझे इसका बिल्कुल एहसास नहीं हुआ। mobile पर header ज़्यादा screen space लेता है इसलिए यह थोड़ा अधिक दिखता है, लेकिन उसके अलावा यह लगभग एक सामान्य webpage की तरह काम करता है
शायद यह अच्छा संकेत है
कुछ comments में जो कहा गया, उसके विपरीत मुझे document के पहली बार load होने पर spinner दिखा नहीं, या कम से कम ध्यान नहीं गया। phone पर दिखा था, लेकिन काफ़ी जल्दी गायब हो गया। वह WASM program loading था या सिर्फ पहली load पर होता है, यह नहीं पता
spinner ज़्यादातर .epub file download का इंतज़ार कर रहा होता है। वह file 4.77MB की है, इसलिए तेज़ connection न हो तो यह काफ़ी बड़ी लगती है। unzip करने के बाद ज़्यादातर size images की है, लगभग 99%
सामान्य webpage या PDF के विपरीत, ऐसा लगता है कि rendering तब तक शुरू नहीं होती जब तक सभी assets, यानी पूरा ePub, download न हो जाए
एक अंतर जिसे लगा था कि लेख में लिया जाएगा लेकिन नहीं लिया गया, वह performance है। PDF को इस तरह optimize किया जा सकता है कि pages काफ़ी हद तक स्वतंत्र रहें, इसलिए progressive rendering, random access, और high parallelization संभव होते हैं
phone पर तो लेख पढ़ने तक मुझे बिल्कुल पता नहीं चला। मुझे लगा यह बस project को समझाने वाला एक सामान्य webpage है
सिर्फ़ इस वजह से भी यह कुछ हद तक पहले से असफल दिखने वाला प्रोजेक्ट लगता है कि browser EPUB खोल नहीं पाता। PDF को link करें तो थोड़ा context switch होता है, लेकिन browser उसे खोलकर दिखा देता है
EPUB विवरण के अनुसार मूलतः HTML ही है, इसलिए browser का उसे न खोलना अजीब है, लेकिन Chrome/Mozilla के अधिकारियों को मनाना आसान नहीं होगा
एक और निराशाजनक बात यह है कि HTML और CSS इतने बड़े और फूले हुए हो चुके हैं कि EPUB/HTML के लिए “reader” लागू कर सकने वाले लोग लगभग नहीं के बराबर हैं। बात practically “एक नया browser implement करो” तक पहुँच जाती है। Djot जैसे आसानी से parse होने वाले markdown पर थोड़ा rendering जोड़ने वाला तरीका लंबी अवधि में ज़्यादा संभव लगता है
मेरा निजी अस्थायी समझौता यह है कि CSS, SVG, script, यहाँ तक कि base64 images भी सब कुछ एक single HTML file में डाल दिया जाए। यह EPUB जैसा है, थोड़ा भारी और बदसूरत भी, लेकिन थोड़ी देखभाल से काम करता है और browser इसे स्वाभाविक रूप से खोल सकता है
लेकिन user के पास यह जानने का कोई तरीका नहीं होता कि “मैं इस webpage को download करके offline रख सकता हूँ।” अच्छा होगा अगर .htmls जैसा कोई extension हो जो बताए कि यह external resources के बिना HTML है
कुछ समय पहले तक browser PDF भी नहीं खोल पाते थे। अब सभी browser में ASM/JS से लिखा हुआ PDF reader शामिल है
EPUB के लिए browser वही काम क्यों नहीं कर सकते, इसका कोई कारण नज़र नहीं आता। ठीक यही काम करने वाले browser extensions पहले से मौजूद हैं। सवाल यह है कि EPUB format को जन-स्वीकृति मिलती है या नहीं
HTML मूल रूप से hypertext था। कुछ links, चित्र/images, और शायद tables तक
फिर magazine जैसी design और layout “ज़रूरी” हो गई, लेकिन तब भी यह document-केंद्रित होने के कारण काफ़ी ठीक था
बाद में HTML को ज़बरदस्ती application distribution platform की तरह इस्तेमाल करने की कोशिश हुई। अब CSS layout आखिरकार पारंपरिक application layout engines के काफ़ी करीब पहुँच गया है
मेरा मानना है कि पिछले 20 सालों का बड़ा हिस्सा सही cross-platform application distribution तरीके के अभाव में बर्बाद हुआ। Java को छोड़कर
तो लगता है यह पोस्ट खुद WASM EPUB viewer में खुला हुआ एक EPUB है
सबसे बड़ी बाधा HTML/CSS implementation scope ही लगती है। लेखक कहते हैं, “portable HTML generation principle: जहाँ संभव हो, portable EPUB बनाने वाली system को portable HTML output करना चाहिए”, लेकिन यह काफ़ी आगे तक जाता हुआ नहीं लगता
अगर इस format को हर जगह दोहराए जा सकने लायक काम करना है, तो इसे standardize करना होगा और नया rendering engine बनाना भी आसान होना चाहिए। WebView पर निर्भर तरीका आगे का रास्ता नहीं लगता
PDF की खूबसूरती इसकी बहुत ऊँची reliability में है। 10 साल पुराना PDF भी आज पहले जैसा ही render होता है
अगर ऐसी कोशिश सफल होनी है, तो document scope को काफ़ी कम करना पड़ेगा। अनुमति-प्राप्त XHTML subset बहुत सीमित होना चाहिए, और हर जगह एक जैसा render होने की क्षमता को प्राथमिकता मिलनी चाहिए। पहले fixed page size वाला fixed layout, उसके बाद reflowable documents। rendering output के साथ व्यापक test documents वाला standard भी चाहिए
browser EPUB खोलने के लिए सुविधाजनक UI नहीं देते, लेकिन अंदर मौजूद chapter-wise HTML files को render करने में कोई समस्या नहीं होनी चाहिए
अगर browser support न हो, तो server side पर ऐसा proxy लिखना बहुत मुश्किल नहीं होगा जो EPUB को एक browseable site में बदल दे और chapter navigation controls तथा कुछ साधारण layout options दे दे
बेशक, ऐसे proxy के ज़रिए अधिकांश commercial ebooks देखने के लिए ज़रूरी DRM support कानूनी रूप से बहुत समस्याग्रस्त हो सकता है
सोचें तो publisher-स्वीकृत DRM EPUB browser support तकनीकी रूप से सामान्य webpages के लिए DRM support से सिर्फ़ आधा कदम दूर है, जो काफ़ी डरावना भविष्य है
मुझे लगता है PDF अनावश्यक जटिलता वाला एक भयानक legacy format है। PDF के अधिकांश उपयोग print से जुड़े नहीं होते, इसलिए इसकी typesetting logic भी ज़्यादा समझ नहीं आती
ज़्यादातर use cases में phone, tablet, और computer पर आसानी से पढ़ा जाना कहीं अधिक महत्वपूर्ण है
यह सुनकर हैरानी हुई कि लेखक के अनुसार iBooks scrolling view support नहीं करता, इसलिए मैंने खुद जाँच लिया। macOS पर iBooks ePub files के लिए scrolling support नहीं देता, लेकिन iOS और iPadOS पर देता है। यह Apple का बहुत अजीब फ़ैसला है https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
PDF spec परेशान करने वाली है, लेकिन इसकी जगह लेने वाला कुछ भी नहीं है
मैंने कभी किसी technical document को PDF के अलावा किसी और format में वितरित होते नहीं देखा, जहाँ पढ़ना और search करना ज़्यादा आसान रहा हो। phone पर भी यही बात लागू होती है
मैं ऐसे documents नहीं चाहता जिनका रूप पढ़ने वाले device या window size जैसी अस्थायी स्थिति के अनुसार बदल जाए। मैं अच्छी तरह डिज़ाइन किया गया, लेखक-निर्धारित fixed layout document चाहता हूँ
छोटे screen या window पर पढ़ते समय भी, अगर वह सिर्फ़ plain text document नहीं है, तो layout बदलने के बजाय मैं तेज़ zoom/pan वाला smart reader चाहता हूँ। कुछ Android readers की तरह ऐसा बेवकूफ़ाना व्यवहार नहीं होना चाहिए जहाँ vertical scrolling या Page Up/Page Down horizontal position भी बदल दे और text columns पढ़ना मुश्किल बना दे
अगर पारंपरिक text column maximum width की सिफ़ारिशें मानी जाएँ, तो phone पर आराम से पढ़ना पूरी तरह संभव है। phone पर पढ़ना तभी असुविधाजनक होता है जब लेखक बहुत चौड़े columns बना देता है और पारंपरिक typography के नियम तोड़ देता है
fixed layout document चाहने की वजह सिर्फ़ print नहीं है। छोटे screen की तुलना में document layout को स्थिर रखना ज़्यादा महत्वपूर्ण है
इस खास मामले के बारे में पक्का नहीं कह सकता, लेकिन कुछ readers ऐसा e-ink devices के साथ एकरूपता के कारण कर सकते हैं। e-ink में कम refresh rate, कमज़ोर processor, और battery बचत के कारण scrolling हार्डवेयर स्तर पर सीमित होती है
इसलिए हर चीज़ के लिए एक ही standard बनाने की कोशिश बुरी लगती है। digital document standards दो होना बेहतर होगा। एक ऐसा format जिसमें networking को छोड़कर पूरा multimedia और interaction हो, और दूसरा उसका subset, जिसमें black-and-white, बिना multimedia, और interaction मुख्यतः document के अंदर hyperlinks तक सीमित हो
और लगभग ऐसे दो formats पहले से मौजूद हैं। HTML, MHTML=EML, और EPUB
बेशक, physical archiving और दुर्लभ digital fixed-layout documents के लिए तीसरा format भी चाहिए, और उस भूमिका के लिए PDF/A पहले से काफ़ी अच्छा दिखता है
अगर सचमुच कुछ print करना हो, तो PDF सबसे reliable और portable रास्ता है
शायद multi-page SVG भी काम आ सके, लेकिन कई pages को सही ढंग से print करने के लिए अंततः पहले PDF में export करना ही पड़ेगा। यह मैं Inkscape को देखकर कह रहा हूँ
मुझे जिज्ञासा है कि EPUB reader browser के मुकाबले ऐसा क्या देता है जो browser में नहीं है। अभी तो जवाब सिर्फ एक, और वह भी मामूली, चीज़ लगता है: .epub फ़ाइल, यानी zip फ़ाइल, को directory की तरह handle कर पाना
अगर EPUB reader और browser के किसी subset के बीच सचमुच बस इतना ही फ़र्क है, तो सबसे सरल और कम मेहनत वाला तरीका यह होगा
मौजूदा browsers को कुछ शर्तों में zip फ़ाइल को directory की तरह handle करने दिया जाए
ऐसी HTML restrictions परिभाषित की जाएँ जिन्हें मशीन से verify किया जा सके, जो मूल पोस्ट में कही गई पूरी तरह local assets की गारंटी दें। शायद सिर्फ यह शर्त ही काफी हो कि links को छोड़कर सभी URL relative paths हों
इस restriction को पूरा करने वाली zip फ़ाइल को “portable EPUB” घोषित कर दिया जाए
मौजूदा या नए, सभी dedicated EPUB readers को भूल जाएँ
सहमत हूँ। यह सच में असली समाधान जैसा लगता है
पूरी तरह local assets के लिए मैं यह requirement देखना चाहूँगा कि हर object के पास local में उपलब्ध fallback option होना चाहिए। जैसे वह font न मिले तो standard font इस्तेमाल हो। वह बिल्कुल परफ़ेक्ट न दिखे, लेकिन fallback की सीमा में बाँध दें तो ठीक-ठाक काम करना चाहिए
एक failure mode अभी भी है जिस पर पर्याप्त बात नहीं हुई है: images का ठीक से काम न करना। मूल समस्या यह है कि images reflow नहीं होतीं। इसका एक बड़ा हिस्सा SVG के इस्तेमाल से सुलझ सकता है, लेकिन जहाँ सचमुच raster images हों वहाँ नहीं। आख़िर में शायद कुछ resolutions देना ही पड़ेगा
मैंने इससे जुड़ी समस्या भी झेली है, लेकिन अभी तक अच्छा जवाब नहीं देखा। ऐसा SVG जो resolution पहचान ले और पर्याप्त resolution होने पर ज़्यादा detailed image ले आए। subpixel lines खींचो तो वे धुंधली हो जाती हैं, लेकिन उसी image को zoom करो तो वही lines काम की बन जाती हैं। Windows icons कई resolutions शामिल कर सकते हैं और स्थिति के हिसाब से सही वाला इस्तेमाल करते हैं, जो इसी बात को स्वीकार करता है
लेखक Shriram Krishnamurthi के मार्गदर्शन में काम करने वाले postdoc researcher हैं। Shriram Krishnamurthi Programming Languages: Application and Interpretation(PLAI) के लेखक हैं, और Data-Centric Introduction to Computing(DCIC) के सह-लेखकों में से एक हैं
मैं अभी PLAI और DCIC दोनों पढ़ रहा हूँ, और इस बात से सच में प्रभावित हूँ कि लेखकों ने इन्हें शैक्षिक कला-कृतियों जैसा बनाने में कितनी बारीक मेहनत की है। वही असली लगाव है https://willcrichton.net/
PDF fonts embed कर सकता है, लेकिन अक्सर करता नहीं है और system fonts पर निर्भर रहता है। एक कारण यह है कि font को PDF में डालने से फ़ाइल का आकार बहुत बढ़ सकता है। कुछ मामलों में एक अकेला font बाकी पूरी फ़ाइल से भी बड़ा हो सकता है
मैंने PDF बनाने वाले software में font embedding लागू किया है, और इसे भरोसेमंद तरीके से काम कराने का तरीका निकालना उम्मीद से कहीं अधिक कठिन था
यह भी उतना सच नहीं है कि PDF हमेशा एक जैसा render होता है। मैंने कई बार देखा है कि एक ही PDF अलग-अलग PDF viewers में अलग तरह से render होती है। आम तौर पर फ़र्क मामूली होता है, लेकिन कभी-कभी boundary cases में काफ़ी बड़ा अंतर भी आ जाता है। मैंने यह भी देखा है कि Acrobat Reader का वही version अलग operating systems पर PDF को अलग तरह से render करता है
PDF फ़ाइलों में सिर्फ कुछ standard system fonts ही छोड़े जा सकते हैं, और document यह मानकर चलता है कि rendering में इस्तेमाल हुआ font पारंपरिक Times, Helvetica, Courier जैसी typefaces के समान metrics रखता है
इसलिए compatible system font इस्तेमाल किया जाए तो rendered document layout नहीं बदलना चाहिए। हालाँकि ऐसे system fonts के उदाहरण भी हैं जो पुराने Adobe PostScript fonts के metric-compatible होने का दावा करते हैं, लेकिन उनमें सूक्ष्म अंतर होते हैं
कुछ standard system fonts को छोड़कर, PDF documents आम तौर पर पूरे font को नहीं बल्कि असल text में इस्तेमाल हुए characters के glyph subset ही शामिल करते हैं
20 साल से भी ज़्यादा समय तक मुझे लगता रहा कि PDF एक जैसा render होता है, फिर एक interview में मुझे बताया गया कि मेरा document अजीब दिख रहा था, तब जाकर पता चला कि fonts गायब हो सकते हैं
यह रोज़मर्रा की ज़िंदगी वाला The Daily WTF था
मैं सोचता हूँ क्या ऐसा software है जो document में इस्तेमाल न होने वाले code points हटाकर font को न्यूनतम कर दे
1 टिप्पणियां
Hacker News की राय
मुझे e-book, security, और LowJS web के intersection में बहुत दिलचस्पी है, इसलिए यह विषय अहम लगता है
single-file portable e-book format की ज़रूरत है, लेकिन PDF इसका जवाब नहीं है क्योंकि उसमें text reflow नहीं होता
2024 का HTML+CSS लगभग सभी print media को reproduce कर सकता है, और साथ ही text reflow भी संभव बनाता है
मुझे नहीं लगता कि JavaScript का अनिवार्य होना ज़रूरी है. e-book ऐसी किताब होनी चाहिए जिसका आकार अर्थपूर्ण तरीके से बदला जा सके, और JavaScript बंद होने पर भी किताब के रूप में उसकी मूल functionality काम करनी चाहिए. interaction या enhancement चाहिए तो JavaScript इस्तेमाल कर सकते हैं, लेकिन अगर JavaScript के बिना वह किताब की तरह काम ही नहीं करती, तो मैं उसे bug मानूँगा
styles को पूरा inline डालना गलती लगता है, क्योंकि इससे कुछ users की CSP टूट सकती है. styles को HTML के हिसाब से relative-path resources में अलग रखना चाहिए, और e-book को दूसरे domains से resources load करने से रोकना चाहिए
आखिर में, इसे बस zip file के रूप में distribute किया जा सकता है. क्या e-book पहले से वैसे ही काम नहीं करती?
लेकिन उल्टी दिशा में यह हमेशा सही नहीं होता. वही file bundle unpack करने से पहले valid EPUB रहा हो, फिर भी अगर उसे जैसे-तैसे दोबारा zip कर दिया जाए, तो वह valid EPUB न रहे
EPUB zip के अंदर mimetype file खास होती है: वह archive की पहली entry होनी चाहिए, उसमें सिर्फ
application/epub+zipहोना चाहिए, और उसे uncompressed state में store किया जाना चाहिएहैरानी की बात है कि बहुत से zip tools file order बदल देते हैं या कुछ files को ही uncompressed रखने में मुश्किल पैदा करते हैं, जिससे यह झंझट बन जाता है. command-line zip program में यह आमतौर पर flags से हो जाता है, लेकिन zip libraries में यह काफ़ी painful है. यह बात EPUB generation software बनाने के अनुभव से कह रहा हूँ
जो बताया गया है वह ePub format है, जिसमें HTML, CSS, और image files zip archive के अंदर जाती हैं
इसमें उसे सुरक्षित बनाने के लिए CSP भी शामिल है
पुराने .doc files को .docx की तुलना में इस्तेमाल करने का एक अच्छा पहलू यह था कि सैकड़ों या हज़ारों files वाले folder में किसी खास शब्द को बहुत तेज़ी से खोजा जा सकता था. zip format में यह नहीं हो पाता
अभी .doc में save करके hex editor में खोला तो असली content plain text में मौजूद था. zip format या PDF files में grep से खोजना मुश्किल होता है, और मुझे यह भी संदेह है कि कुछ हज़ार characters के text के लिए compression सच में ज़रूरी भी है या नहीं
यह Nota developer द्वारा लिखा गया बहुत सुव्यवस्थित लेख है, जिसका मकसद EPUB format को PDF के बराबर स्तर तक ले जाना है. उन्होंने viewer भी बना लिया है, और लेख खुद भी उसी viewer के browser-based WASM port में दिखाया जा रहा है
असल समस्याओं में से एक यह है कि EPUB, जो व्यवहार में XHTML ही है, layout को कितनी सटीकता से reproduce कर सकता है. मूल लेख का मानदंड यह है कि document “काफ़ी ठीक” दिखे, लेकिन PDF के बराबर पहुँचने के लिए कम से कम line breaking के मामले में HTML को नई layout features चाहिए — ऐसा संकेत मिलता है
आगे बढ़ने के दो रास्ते दिखते हैं. एक यह कि browser अधिक typography tools दे; कहा जाता है कि
text-wrap: prettyमदद करता है, लेकिन मैंने थोड़ी testing की तो line breaking quality बेहतर नहीं लगी. दूसरा तरीका line breaks को पहले से calculate करना है, लेकिन यह सिर्फ fixed-layout rendering में ही संभव हैलेखक ने annotations का ज़िक्र तो किया है, लेकिन उन्हें कैसे implement करना है, यह साफ़ नहीं है
यह EPUB3 में पहले से संभव है, लेकिन phone जैसी screens पर इसका नतीजा अच्छा नहीं दिखता. reader के हिसाब से defaults override किए जा सकते हैं, लेकिन तब उम्मीद करनी पड़ती है कि reader document को दोबारा अच्छे ढंग से बना दे
एक विकल्प यह है कि EPUB आम screen types के लिए कई renderings बताए. यह perfect तो नहीं होगा, लेकिन document creator को defaults बनाने देना और user को चाहें तो override करने देना एक अच्छा compromise लगता है
e-book format को semantic markup चाहिए जो render होने वाली device के मुताबिक adapt करे. HTML+CSS मूल रूप से इसी उद्देश्य के लिए बनाए गए थे
इसलिए book layout designer को यह बात मानकर चलना होगा कि किताब कैसी दिखेगी, इस पर उसका कुछ नियंत्रण जानबूझकर पाठक को सौंपना पड़ेगा. थोड़ी visual imperfection इसकी उचित कीमत है. अगर visual perfection चाहिए, तो PDF इस्तेमाल करें
बेशक interactive elements आने पर बात मुश्किल हो जाती है. बड़े interactive elements को ज़रूरत पड़ने पर dedicated view में खोला जा सकता है, और छोटे interactive elements को reflow स्वीकार करना चाहिए
annotations और references शायद पहले से EPUB spec में हैं, शायद HTML spec में भी
और मैं इस बात से सहमत नहीं हूँ कि popup के लिए long-press करना सामान्य hyperlink anchor से बेहतर है. अगर reader का “back” function ठीक से काम करे, या bidirectional references में “back” link हो, तो navigation वाला तरीका कहीं कम बाधक है
विचार यह था कि XML document और XSL stylesheet को साथ में distribute किया जाए, फिर rendering के लिए उसे FO में transform किया जाए, और एक ही document के लिए target device या page size के हिसाब से कई stylesheets रखी जा सकें
Firefox में SinglePage addon का इस्तेमाल करके मौजूदा page DOM को standalone HTML file के रूप में सेव किया जाता है। इसमें CSS और images के लिए
data:URL को inline किया जाता है, और dependencies व scripts हटा दिए जाते हैंयह परफेक्ट नहीं है, और मुझे यह भरोसा भी नहीं कि browser हमेशा backward compatibility बनाए रखेंगे, लेकिन page को PDF या कई files में सेव करने की तुलना में मैं इसे ज़्यादा पसंद करता हूँ
दिलचस्प बात यह है कि जिन बहुत कम pages पर यह addon फेल हुआ, उनमें से एक यही portable EPUBs वाला लेख था। लगता है formatting मिलाने के लिए इसमें बहुत ज़्यादा जादू लगाया गया है। सेव किया गया page पढ़ने लायक था, लेकिन style मूल से बिल्कुल अलग था
Android पर fbreader की यह बात अच्छी लगती है कि वह सभी किताबों को EPUB file की style के बजाय app settings के अनुसार एक जैसा दिखाता है। मैंने उसे कभी CSS apply करते या file में शामिल scripts चलाते नहीं देखा, और उम्मीद है आगे भी ऐसा न करे। बाहरी dependencies लोड करना तो और भी बुरा विचार है, और मुझे तो पता भी नहीं था कि यह शुरू से allowed है
वैसे इस बारे में कहूँ तो Firefox addon permission system अजीब है। कुछ भी दिलचस्प करने के लिए लगभग हर permission माँगनी पड़ती है, और नतीजे में ऐसे addons के लिए एक स्वाभाविक market बन जाता है जिन्हें कोई दुर्भावनापूर्ण actor खरीद सके
उदाहरण के लिए SingleFile addon को rendered DOM देखने और उसे file में सेव करने के लिए access permission चाहिए ही। लेकिन यह क्यों हर चीज़ तक पहुँच माँगे, यह समझ नहीं आता। क्या
snapshot DOM once,write to a single fileजैसी permissions नहीं दी जा सकतींतब मैं न तो इसका कारण ठीक से समझा पा रहा था, न खुद समझता था, लेकिन इसे किसी बेहूदा इच्छा की तरह लिया गया था। अब देखकर अच्छा लगता है कि मैं बस लगभग 10 साल समय से आगे या पीछे था
KOReader कम friendly है, लेकिन ज़्यादा control देता है। दिए गए कई CSS files में से कोई खास file चुनी जा सकती है या खुद भी लिखी जा सकती है
KOReader की खूबियों में शानदार OPDS support और आसान self-hosted sync server भी है
यह सुविधा होने पर, इस system का उपयोग करने वाले pages पर SinglePage की ज़रूरत नहीं रहती
वह हिस्सा देखकर मैंने फिर से ध्यान दिया। बात उस हिस्से की है: “इसलिए मैंने एक हल्का EPUB reading system, Bene, बनाने का फैसला किया। आप अभी वही इस्तेमाल कर रहे हैं। यह document EPUB है, और इसे ऊपर दाईं ओर के button से download किया जा सकता है”
desktop browser में पढ़ते समय, जब तक किसी ने सीधे बताया नहीं, मुझे इसका बिल्कुल एहसास नहीं हुआ। mobile पर header ज़्यादा screen space लेता है इसलिए यह थोड़ा अधिक दिखता है, लेकिन उसके अलावा यह लगभग एक सामान्य webpage की तरह काम करता है
शायद यह अच्छा संकेत है
कुछ comments में जो कहा गया, उसके विपरीत मुझे document के पहली बार load होने पर spinner दिखा नहीं, या कम से कम ध्यान नहीं गया। phone पर दिखा था, लेकिन काफ़ी जल्दी गायब हो गया। वह WASM program loading था या सिर्फ पहली load पर होता है, यह नहीं पता
सामान्य webpage या PDF के विपरीत, ऐसा लगता है कि rendering तब तक शुरू नहीं होती जब तक सभी assets, यानी पूरा ePub, download न हो जाए
एक अंतर जिसे लगा था कि लेख में लिया जाएगा लेकिन नहीं लिया गया, वह performance है। PDF को इस तरह optimize किया जा सकता है कि pages काफ़ी हद तक स्वतंत्र रहें, इसलिए progressive rendering, random access, और high parallelization संभव होते हैं
सिर्फ़ इस वजह से भी यह कुछ हद तक पहले से असफल दिखने वाला प्रोजेक्ट लगता है कि browser EPUB खोल नहीं पाता। PDF को link करें तो थोड़ा context switch होता है, लेकिन browser उसे खोलकर दिखा देता है
EPUB विवरण के अनुसार मूलतः HTML ही है, इसलिए browser का उसे न खोलना अजीब है, लेकिन Chrome/Mozilla के अधिकारियों को मनाना आसान नहीं होगा
एक और निराशाजनक बात यह है कि HTML और CSS इतने बड़े और फूले हुए हो चुके हैं कि EPUB/HTML के लिए “reader” लागू कर सकने वाले लोग लगभग नहीं के बराबर हैं। बात practically “एक नया browser implement करो” तक पहुँच जाती है। Djot जैसे आसानी से parse होने वाले markdown पर थोड़ा rendering जोड़ने वाला तरीका लंबी अवधि में ज़्यादा संभव लगता है
मेरा निजी अस्थायी समझौता यह है कि CSS, SVG, script, यहाँ तक कि base64 images भी सब कुछ एक single HTML file में डाल दिया जाए। यह EPUB जैसा है, थोड़ा भारी और बदसूरत भी, लेकिन थोड़ी देखभाल से काम करता है और browser इसे स्वाभाविक रूप से खोल सकता है
लेकिन user के पास यह जानने का कोई तरीका नहीं होता कि “मैं इस webpage को download करके offline रख सकता हूँ।” अच्छा होगा अगर
.htmlsजैसा कोई extension हो जो बताए कि यह external resources के बिना HTML हैEPUB के लिए browser वही काम क्यों नहीं कर सकते, इसका कोई कारण नज़र नहीं आता। ठीक यही काम करने वाले browser extensions पहले से मौजूद हैं। सवाल यह है कि EPUB format को जन-स्वीकृति मिलती है या नहीं
फिर magazine जैसी design और layout “ज़रूरी” हो गई, लेकिन तब भी यह document-केंद्रित होने के कारण काफ़ी ठीक था
बाद में HTML को ज़बरदस्ती application distribution platform की तरह इस्तेमाल करने की कोशिश हुई। अब CSS layout आखिरकार पारंपरिक application layout engines के काफ़ी करीब पहुँच गया है
मेरा मानना है कि पिछले 20 सालों का बड़ा हिस्सा सही cross-platform application distribution तरीके के अभाव में बर्बाद हुआ। Java को छोड़कर
अगर इस format को हर जगह दोहराए जा सकने लायक काम करना है, तो इसे standardize करना होगा और नया rendering engine बनाना भी आसान होना चाहिए। WebView पर निर्भर तरीका आगे का रास्ता नहीं लगता
PDF की खूबसूरती इसकी बहुत ऊँची reliability में है। 10 साल पुराना PDF भी आज पहले जैसा ही render होता है
अगर ऐसी कोशिश सफल होनी है, तो document scope को काफ़ी कम करना पड़ेगा। अनुमति-प्राप्त XHTML subset बहुत सीमित होना चाहिए, और हर जगह एक जैसा render होने की क्षमता को प्राथमिकता मिलनी चाहिए। पहले fixed page size वाला fixed layout, उसके बाद reflowable documents। rendering output के साथ व्यापक test documents वाला standard भी चाहिए
अगर browser support न हो, तो server side पर ऐसा proxy लिखना बहुत मुश्किल नहीं होगा जो EPUB को एक browseable site में बदल दे और chapter navigation controls तथा कुछ साधारण layout options दे दे
बेशक, ऐसे proxy के ज़रिए अधिकांश commercial ebooks देखने के लिए ज़रूरी DRM support कानूनी रूप से बहुत समस्याग्रस्त हो सकता है
सोचें तो publisher-स्वीकृत DRM EPUB browser support तकनीकी रूप से सामान्य webpages के लिए DRM support से सिर्फ़ आधा कदम दूर है, जो काफ़ी डरावना भविष्य है
मुझे लगता है PDF अनावश्यक जटिलता वाला एक भयानक legacy format है। PDF के अधिकांश उपयोग print से जुड़े नहीं होते, इसलिए इसकी typesetting logic भी ज़्यादा समझ नहीं आती
ज़्यादातर use cases में phone, tablet, और computer पर आसानी से पढ़ा जाना कहीं अधिक महत्वपूर्ण है
यह सुनकर हैरानी हुई कि लेखक के अनुसार iBooks scrolling view support नहीं करता, इसलिए मैंने खुद जाँच लिया। macOS पर iBooks ePub files के लिए scrolling support नहीं देता, लेकिन iOS और iPadOS पर देता है। यह Apple का बहुत अजीब फ़ैसला है
https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
मैंने कभी किसी technical document को PDF के अलावा किसी और format में वितरित होते नहीं देखा, जहाँ पढ़ना और search करना ज़्यादा आसान रहा हो। phone पर भी यही बात लागू होती है
मैं ऐसे documents नहीं चाहता जिनका रूप पढ़ने वाले device या window size जैसी अस्थायी स्थिति के अनुसार बदल जाए। मैं अच्छी तरह डिज़ाइन किया गया, लेखक-निर्धारित fixed layout document चाहता हूँ
छोटे screen या window पर पढ़ते समय भी, अगर वह सिर्फ़ plain text document नहीं है, तो layout बदलने के बजाय मैं तेज़ zoom/pan वाला smart reader चाहता हूँ। कुछ Android readers की तरह ऐसा बेवकूफ़ाना व्यवहार नहीं होना चाहिए जहाँ vertical scrolling या Page Up/Page Down horizontal position भी बदल दे और text columns पढ़ना मुश्किल बना दे
अगर पारंपरिक text column maximum width की सिफ़ारिशें मानी जाएँ, तो phone पर आराम से पढ़ना पूरी तरह संभव है। phone पर पढ़ना तभी असुविधाजनक होता है जब लेखक बहुत चौड़े columns बना देता है और पारंपरिक typography के नियम तोड़ देता है
इसलिए हर चीज़ के लिए एक ही standard बनाने की कोशिश बुरी लगती है। digital document standards दो होना बेहतर होगा। एक ऐसा format जिसमें networking को छोड़कर पूरा multimedia और interaction हो, और दूसरा उसका subset, जिसमें black-and-white, बिना multimedia, और interaction मुख्यतः document के अंदर hyperlinks तक सीमित हो
और लगभग ऐसे दो formats पहले से मौजूद हैं। HTML, MHTML=EML, और EPUB
बेशक, physical archiving और दुर्लभ digital fixed-layout documents के लिए तीसरा format भी चाहिए, और उस भूमिका के लिए PDF/A पहले से काफ़ी अच्छा दिखता है
शायद multi-page SVG भी काम आ सके, लेकिन कई pages को सही ढंग से print करने के लिए अंततः पहले PDF में export करना ही पड़ेगा। यह मैं Inkscape को देखकर कह रहा हूँ
8 दिन पहले 134 points पाने वाली “Portable Web Documents – An Alternative to PDF Based on HTML5 (2019)” पोस्ट थी
https://news.ycombinator.com/item?id=39036774
https://news.ycombinator.com/item?id=39037135
मुझे जिज्ञासा है कि EPUB reader browser के मुकाबले ऐसा क्या देता है जो browser में नहीं है। अभी तो जवाब सिर्फ एक, और वह भी मामूली, चीज़ लगता है: .epub फ़ाइल, यानी zip फ़ाइल, को directory की तरह handle कर पाना
अगर EPUB reader और browser के किसी subset के बीच सचमुच बस इतना ही फ़र्क है, तो सबसे सरल और कम मेहनत वाला तरीका यह होगा
मौजूदा browsers को कुछ शर्तों में zip फ़ाइल को directory की तरह handle करने दिया जाए
ऐसी HTML restrictions परिभाषित की जाएँ जिन्हें मशीन से verify किया जा सके, जो मूल पोस्ट में कही गई पूरी तरह local assets की गारंटी दें। शायद सिर्फ यह शर्त ही काफी हो कि links को छोड़कर सभी URL relative paths हों
इस restriction को पूरा करने वाली zip फ़ाइल को “portable EPUB” घोषित कर दिया जाए
मौजूदा या नए, सभी dedicated EPUB readers को भूल जाएँ
पूरी तरह local assets के लिए मैं यह requirement देखना चाहूँगा कि हर object के पास local में उपलब्ध fallback option होना चाहिए। जैसे वह font न मिले तो standard font इस्तेमाल हो। वह बिल्कुल परफ़ेक्ट न दिखे, लेकिन fallback की सीमा में बाँध दें तो ठीक-ठाक काम करना चाहिए
एक failure mode अभी भी है जिस पर पर्याप्त बात नहीं हुई है: images का ठीक से काम न करना। मूल समस्या यह है कि images reflow नहीं होतीं। इसका एक बड़ा हिस्सा SVG के इस्तेमाल से सुलझ सकता है, लेकिन जहाँ सचमुच raster images हों वहाँ नहीं। आख़िर में शायद कुछ resolutions देना ही पड़ेगा
मैंने इससे जुड़ी समस्या भी झेली है, लेकिन अभी तक अच्छा जवाब नहीं देखा। ऐसा SVG जो resolution पहचान ले और पर्याप्त resolution होने पर ज़्यादा detailed image ले आए। subpixel lines खींचो तो वे धुंधली हो जाती हैं, लेकिन उसी image को zoom करो तो वही lines काम की बन जाती हैं। Windows icons कई resolutions शामिल कर सकते हैं और स्थिति के हिसाब से सही वाला इस्तेमाल करते हैं, जो इसी बात को स्वीकार करता है
लेखक Shriram Krishnamurthi के मार्गदर्शन में काम करने वाले postdoc researcher हैं। Shriram Krishnamurthi Programming Languages: Application and Interpretation(PLAI) के लेखक हैं, और Data-Centric Introduction to Computing(DCIC) के सह-लेखकों में से एक हैं
मैं अभी PLAI और DCIC दोनों पढ़ रहा हूँ, और इस बात से सच में प्रभावित हूँ कि लेखकों ने इन्हें शैक्षिक कला-कृतियों जैसा बनाने में कितनी बारीक मेहनत की है। वही असली लगाव है
https://willcrichton.net/
https://rust-book.cs.brown.edu/
PDF fonts embed कर सकता है, लेकिन अक्सर करता नहीं है और system fonts पर निर्भर रहता है। एक कारण यह है कि font को PDF में डालने से फ़ाइल का आकार बहुत बढ़ सकता है। कुछ मामलों में एक अकेला font बाकी पूरी फ़ाइल से भी बड़ा हो सकता है
मैंने PDF बनाने वाले software में font embedding लागू किया है, और इसे भरोसेमंद तरीके से काम कराने का तरीका निकालना उम्मीद से कहीं अधिक कठिन था
यह भी उतना सच नहीं है कि PDF हमेशा एक जैसा render होता है। मैंने कई बार देखा है कि एक ही PDF अलग-अलग PDF viewers में अलग तरह से render होती है। आम तौर पर फ़र्क मामूली होता है, लेकिन कभी-कभी boundary cases में काफ़ी बड़ा अंतर भी आ जाता है। मैंने यह भी देखा है कि Acrobat Reader का वही version अलग operating systems पर PDF को अलग तरह से render करता है
इसलिए compatible system font इस्तेमाल किया जाए तो rendered document layout नहीं बदलना चाहिए। हालाँकि ऐसे system fonts के उदाहरण भी हैं जो पुराने Adobe PostScript fonts के metric-compatible होने का दावा करते हैं, लेकिन उनमें सूक्ष्म अंतर होते हैं
कुछ standard system fonts को छोड़कर, PDF documents आम तौर पर पूरे font को नहीं बल्कि असल text में इस्तेमाल हुए characters के glyph subset ही शामिल करते हैं
यह रोज़मर्रा की ज़िंदगी वाला The Daily WTF था