आपका ePub बिल्कुल ठीक है

 (andreklein.net)
2 पॉइंट द्वारा GN⁺ 1 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • DRM-रहित EPUB जो validation पास कर चुका हो, Kobo पर फिर भी “corrupted” दिख सकता है, और समस्या file format error नहीं बल्कि rendering engine compatibility में होती है
  • epubcheck EPUB structure और rules compliance जाँचने का de facto standard validation tool है, लेकिन यह किसी खास renderer के पुराने CSS parser की समस्याएँ नहीं पकड़ पाता
  • Kobo, Adobe के proprietary ebook rendering engine RMSDK का उपयोग करता है, जो EPUB2 के आधार पर बना था और बाद में EPUB3 के लिए हल्का-सा अपडेट हुआ, लेकिन modernize नहीं किया गया
  • समस्या की जड़ max-width: min(150px, 30vw); की एक पंक्ति थी, और यह valid CSS level 4 code RMSDK में supported नहीं है, इसलिए Adobe Digital Editions और Kobo में किताब load नहीं हो पाती
  • Kobo compatibility जाँचने के लिए सिर्फ epubcheck काफ़ी नहीं है; Adobe Digital Editions में उसे वास्तव में खोलकर देखना भी ज़रूरी है

epubcheck पास करने वाले EPUB से शुरू हुई समस्या

  • Adobe tools अक्सर इसलिए इस्तेमाल होते हैं क्योंकि Creative Suite industry standard है या उसके विकल्प कमज़ोर हैं, और इस लेख की समस्या-चेतना Adobe software को लेकर असंतोष से शुरू होती है
  • नई किताब को पाठकों तक सीधे पहुँचने वाली DRM-रहित EPUB file के रूप में वितरित किया गया, और वितरण से पहले वह कई चरणों से होकर epubcheck validation पास कर चुकी थी
  • epubcheck अच्छी तरह बनाए गए ebook की पुष्टि करने वाला de facto standard tool है, और pass होने के लिए manifest में किताब के सभी हिस्से और images बिना छूटे दर्ज होने चाहिए
  • HTML elements का क्रम सही न हो, या International Digital Publishing Forum के नियमों से थोड़ा भी विचलन हो, तो validation fail हो सकता है
  • epubcheck को 100% pass कराना शुरुआती लोगों के लिए आसान नहीं है, लेकिन publishing workflow में यह type linter या formal test suite जैसी भूमिका निभाता है
  • मूल अपेक्षा यह होती है कि epubcheck पास करने वाली किताब किसी भी EPUB-compatible reader या app में काम करे

सिर्फ Kobo में “corrupted” दिखा

  • नई किताब ने epubcheck ruleset 3.3 पास किया था, लेकिन एक पाठक ने “corrupted” संदेश आने की सूचना दी
  • backward compatibility की संभावना जाँचने के लिए EPUB2 version भी दिया गया, लेकिन वह file भी पूरी तरह rules-compliant होने के बावजूद वही समस्या दिखाती रही
  • उस पाठक ने बताया कि कई पीढ़ियों के Kobo devices में किताब खुल नहीं रही थी
  • वही EPUB Amazon Kindle, Apple Books, Thorium और दूसरे environments में बिना समस्या के काम कर रही थी
  • जाँच में पता चला कि Kobo, Adobe के proprietary ebook rendering engine RMSDK का उपयोग करता है

RMSDK और Adobe Digital Editions तक सिमटी वजह

  • RMSDK, Adobe Digital Editions का core engine है, और कई Kobo devices तथा पुराने Sony और Nook devices में भी इस्तेमाल होता है
  • यह engine लगभग 2010 के आसपास EPUB2 को केंद्र में रखकर बनाया गया था, और बाद में EPUB3 के लिए हल्का अपडेट मिला, लेकिन इसे modernize नहीं किया गया
  • RMSDK के उपयोग की जानकारी मिलने से epubcheck और Kobo के परिणामों के बीच का अंतर तुरंत हल नहीं हुआ, लेकिन debugging की दिशा ज़रूर मिली
  • किताब को Adobe Digital Editions में डालने पर अनुमान के मुताबिक वह load नहीं हुई, और कोई error message भी नहीं दिखा
  • दोबारा load करने की कोशिश पर यह संदेश आया कि यह किताब पहले ही add की जा चुकी है, लेकिन स्क्रीन सफेद ही रही
  • इसके बाद कई variant files बनाकर test किया गया, और सभी variants लगातार epubcheck पास करते रहे
    • folder structure को rearrange करना, metadata हटाना, language attributes हटाना, नया UUID बनाना, directory flatten करना, extension बदलना, ZIP दोबारा बनाना, और manifest बदलना जैसे प्रयास किए गए
    • इन सभी कोशिशों के बावजूद Adobe Digital Editions में loading failure दोहराता रहा

असली कारण: valid CSS की एक पंक्ति

  • stylesheet को disable करते ही किताब अचानक load हो गई, जिससे समस्या का दायरा stylesheet तक सिमट गया
  • stylesheet के कुछ हिस्सों के साथ कई variants और बनाकर जाँच करने के बाद समस्या पैदा करने वाली एक पंक्ति पहचानी गई
.copyright img {
    max-width: min(150px, 30vw);
}
  • यह code पूरी तरह valid CSS level 4 code है, लेकिन RMSDK इसे support नहीं करता
  • इस code को पुराने तरीके वाले max-width: 150px; से बदलते ही Adobe Digital Editions में किताब सामान्य रूप से खुल गई
  • RMSDK का CSS parser लगभग 2013 के स्तर पर अटका हुआ है, और यह flexbox, grid, math functions, तथा custom properties को support नहीं करता
  • अनपहचाने CSS से टकराने पर यह fallback या स्पष्ट error देने के बजाय चुपचाप crash हो जाता है
  • epubcheck बुनियादी CSS checks करता है, लेकिन वह स्वभावतः किसी खास renderer की टूटी हुई implementation के हिसाब से CSS validate नहीं कर सकता

Kobo compatibility validation से मिली सीख

  • 2026 में भी Kobo अगर किताब rendering की नींव के रूप में RMSDK का उपयोग करता है, तो valid CSS की एक पंक्ति पूरे valid EPUB को “corrupted file” बना सकती है
  • इस स्थिति में Kobo बिना किसी स्पष्ट error message या fallback के पूरी किताब खोलने में विफल हो सकता है
  • समस्या से बचने के लिए नया version जारी किया गया, ताकि पाठकों को वही error दोबारा न झेलनी पड़े
  • आदर्श स्थिति में RMSDK को CSS के पुराने स्तर से आगे बढ़ना चाहिए या कम-से-कम error handling देनी चाहिए, लेकिन फिलहाल समस्या जस की तस है
  • Kobo compatibility पक्का करने के लिए epubcheck अकेला काफ़ी नहीं है; Adobe Digital Editions में वास्तविक loading की पुष्टि करनी होगी
  • EPUB ebooks के लिए एक बेहतरीन open standard है, लेकिन इसकी कई implementations access restrictions को प्राथमिकता देने वाली संरचना में अपनी मूलभूत कमज़ोरियाँ उजागर करती हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 1 일 전
Hacker News की राय

  • Adobe भी हमेशा ऐसा ही था। उसने Flash की भारी-भरकम market share गंवा दी, जबकि विकल्प बस QA पर कुछ मिलियन डॉलर खर्च करने का था, और आखिरकार उसने सभी browser निर्माताओं को इस बात पर सहमत कर दिया कि “वेब के लिए ऐसे अविश्वसनीय partner के बिना आगे बढ़ना बेहतर है”
    मैंने पहले Flash में कुछ चीज़ें ship की थीं, लेकिन वह बेहद खराब software था, जिसमें random crashes और एक हिस्से में बदलाव से दूसरे module की असंबंधित functionality टूट जाने वाले Heisenbugs भरे रहते थे। इसकी कीमत लगभग 800 डॉलर थी, पर support नाम की चीज़ लगभग नहीं थी; मैंने कई bugs रिपोर्ट किए थे जो minimized test case के साथ आसानी से reproduce हो जाते थे, लेकिन अगला release आने के बाद बस यही automated जवाब मिला कि “शायद यह ठीक हो गया हो, जांचने के लिए full-price license खरीदकर देखें”

    • Steve Jobs को पसंद करें या नापसंद, iPhone पर Flash को support न करने और HTML5 को आगे बढ़ाने के फैसले ने Flash के पतन को काफी तेज़ कर दिया
    • Flash, जब उसे VideoWorks कहा जाता था, तब ज़्यादा अच्छा था ;)
      MusicWorks भी था, और दोनों बहुत शुरुआती Mac-only products थे। सिर्फ यह बात कहने से ही उम्र का पता चल जाता है
    • Flash अब भी सबसे आसान publishing medium के रूप में बेजोड़ है
      JavaScript build systems की परत-दर-परत जटिलता और “web standards”, बस कुछ draw करके थोड़े simple functions लिखने और फिर एक static file बनाने से कहीं ज़्यादा मुश्किल हैं जिसे कहीं भी embed या download किया जा सके। Flash alternatives इस्तेमाल करने के लिए setup पर बहुत ज़्यादा समय खर्च करना पड़ता है, और वे “standards” भी बदतर हैं
      Flash को मारने वाले Steve Jobs भी पसंद नहीं, और वेब की सबसे अद्भुत technologies में से एक को बुरी तरह manage करने वाली Adobe भी पसंद नहीं। आज बड़े हो रहे बच्चों को पता ही नहीं कि Flash कितना जादुई था। यह वेब का Roblox या Minecraft जैसा कुछ था
      वेबसाइटें आज भी 2000 के शुरुआती दशक के Flash से पीछे हैं। इतने दशकों बाद भी वे उसकी ताकत का सिर्फ कुछ हिस्सा ही नकल कर पाई हैं, और उसकी आसानी के आसपास भी नहीं पहुँचतीं

  • मैंने काफी समय तक e-book reader software बनाने की कोशिश की, और आखिर में शैतान से सौदा करने जैसा मानकर उसे RMSDK पर बनाने की सोची
    लेकिन वहाँ पहुँचने का कोई रास्ता ही नहीं है। मतलब सिर्फ यह नहीं कि स्वतंत्र developer के लिए license fee बहुत महंगी है, हालांकि वह भी सही है, बल्कि बात करने के लिए कोई है ही नहीं। वेबसाइट पर दिया email कभी जवाब नहीं देता, “रुचि दिखाने के लिए धन्यवाद” या “हम फिर संपर्क करेंगे” जैसी बात भी नहीं
    वहाँ पहले काम कर चुके एक सहकर्मी से मैंने RMSDK access process के बारे में पूछा, तो उसने internal docs ढूँढे लेकिन कुछ भी नहीं मिला। LinkedIn पर RMSDK से जुड़े लगने वाले लोगों को खोजकर पूछा, तब भी वही हाल था
    दूसरी ओर publishers अपनी ज़्यादातर किताबें सिर्फ Apple, Amazon, Adobe जैसे जाने-माने DRM vendors में से किसी एक के जरिए distribute करते हैं, और पहले दो पूरी तरह बंद हैं। अगर यह anti-competitive monopoly behavior नहीं है, तो फिर क्या है, समझ नहीं आता

    • मैंने FBReader app में बहुत-सी किताबें पढ़ी हैं, और वह दूसरे apps में इस्तेमाल के लिए अपना SDK उपलब्ध कराता है

  • जहाँ तक मुझे पता है, Kobo devices अगर filename .kepub.epub रखा जाए तो एक अधिक उन्नत rendering engine इस्तेमाल करते हैं। शायद यह ePub 3 पर आधारित है, लेकिन इससे यहाँ की समस्या ठीक होगी या नहीं, पता नहीं
    मैं व्यक्तिगत रूप से Kobo पर भेजने से पहले ePub को kepubify(https://pgaskin.net/kepubify/try/) से convert कर लेता हूँ

    • सही है, मैं भी हर file के साथ यही करता हूँ। Standard Ebooks जैसे publishers भी kepub download देते हैं, और जैसा यहाँ बताया गया है, Adobe reader में भी समस्याएँ हैं
      https://standardebooks.org/help/how-to-use-our-ebooks#kobo-f...
      मुझे Kobo Clara Colour बहुत पसंद है, और अगर Adobe reader हटा दिया जाए तो यह लगभग perfect होगा। मैंने KOReader भी इस्तेमाल किया है, लेकिन मुझे OverDrive library books और Kobo Store पसंद हैं, इसलिए पूरी तरह switch नहीं किया

  • दुर्भाग्य से epub और epubcheck, जैसा लेखक कहता है, वैसा निर्विवाद रूप से उत्कृष्ट benchmark नहीं हैं। जब W3C, Inc. ने ePub 3.1 के आसपास spec management संभाला, तो उसने WHATWG HTML और लगातार बढ़ती browser specs को ज्यों का त्यों refer कर लिया([1])
    ऐसे “living standards” में न versioning होती है, न QA। नतीजा यह हुआ कि headers और sectioning को फिर से परिभाषित करने वाले HTML version पर आधारित होकर, ePub 3.2 ने पुराने ePub को non-compliant बना दिया। इसी वजह से Calibre और दूसरे tools अब भी 3.1, या उससे भी बेहतर 2, recommend करते हैं
    CSS min() function के reject होने जैसी घटनाएँ भी दिखाती हैं कि बेहिसाब जटिल CSS specs को पूरा का पूरा उठा लेना खास मददगार नहीं है। e-book readers हमेशा up-to-date browsers नहीं होते
    [1]: https://news.ycombinator.com/item?id=41326179

    • ePub में 3.1 या 2 को target करना ज़्यादा समझदारी भरा विकल्प माना जाता है
      EPUB compatibility issues में CSS को हमेशा पहली प्राथमिकता से शक करना चाहिए। “modern” CSS features इस्तेमाल करके फिर यह शिकायत करना कि flexbox या grid नहीं है, यह web developer वाली सोच है
      सिर्फ इसलिए कि EPUB और web stack का कुछ हिस्सा साझा करते हैं, इसका मतलब यह नहीं कि दोनों पूरी तरह एक जैसे हैं, और ऐसा होना ज़रूरी भी नहीं। ज़्यादातर e-ink embedded reader devices rendering के लिए browser इस्तेमाल नहीं करते; वे purpose-built HTML/CSS parsing और rendering toolchain को firmware में bake करके रखते हैं और बहुत कम update करते हैं। दिलचस्पी हो तो KOReader के crengine या ESP32 पर चलने वाले Crosspoint reader को देख सकते हैं
      उस ब्लॉग पोस्ट में जरूरत से ज़्यादा आत्मविश्वासी AI writing style की गंध आती है, लेकिन उससे धोखा नहीं खाना चाहिए

  • अगर कोई डिवाइस ढूंढ रहा है, तो PineNote भी है
    https://pine64.org/devices/pinenote/
    यह ज़्यादा महंगा है और तुरंत इस्तेमाल के लिए उपलब्ध software कम है, लेकिन डिवाइस पर मालिकाना हक़ और उस पर कौन-सा software चला सकते हैं, इस मामले में यह कहीं ज़्यादा सीधा है और शर्तें भी कम हैं
    PineNote के उपयोग अनुभव को अच्छी तरह समेटने वाले लेख भी हैं
    https://shom.dev/posts/20250308_pinenote-day-one/
    https://shom.dev/posts/20250406_a-pinenote-only-5-day-weeken...

    • जानना चाहूंगा कि क्या आपने PineNote को सीधे इस्तेमाल किया है। इसकी कीमत 400 डॉलर है, और इसे “एम्बेडेड सिस्टम का गहरा ज्ञान रखने वाले Linux developers या mobile Linux अनुभव रखने वालों” के लिए बताया गया है। लिंक किया गया community-provided firmware भी एक साल से ज़्यादा समय से अपडेट नहीं हुआ है
      Kobo भी यह सीमित नहीं करता कि आप क्या कर सकते हैं। आप KOReader जैसे वैकल्पिक ebook reader software को sideload करके बिल्ट-इन reader की क्षमता बेहतर कर सकते हैं
    • इस व्यक्ति की open source 60Hz e-ink screen भी देखने लायक है: [video] https://www.youtube.com/watch?v=nHbA2-_qzH4

  • Kobo सचमुच अपने ebook reader software को पूरी तरह फिर से लिख रहा है, और EU में beta डाउनलोड किया जा सकता है। लगभग तय है कि यह अब RMSDK-आधारित नहीं है
    Adobe एक प्रबंधक के रूप में कमज़ोर रहा, और बाद में migration भी बिगाड़ दिया; फिर इसे ऐसे third party को बेच दिया जिसने end users और platforms को और नाराज़ किया, और इस तरह EPUB DRM बाज़ार लगभग थाली में सजाकर LCP को दे दिया। Platforms पहले से कहीं तेज़ी से Adobe से दूर जा रहे हैं

    • जानना चाहूंगा कि क्या आपने beta इस्तेमाल किया है। यह वाकई कितना बेहतर हुआ है, यह जानना है

  • “कई महीनों के काम के बाद तैयार हुई किताब में validation button दबाने का वह पल डरावना था। वह हमेशा कोई न कोई कमी निकाल ही लेता था” — यह पढ़कर LaTeX thesis draft compile करते-करते रोने को तैयार एक master's student याद आ गया
    उसने “पहले लिखो, formatting बाद में सोचो” वाली बात को कुछ ज़्यादा ही शाब्दिक अर्थ में ले लिया था, और deadline से ठीक पहले पहली बार compile करने की कोशिश कर रहा था

    • फिर भी कुल मिलाकर शायद समय काफ़ी बचा हो। सिर्फ compile time देखें तो, अगर वह पहले से बार-बार जांच करता, तो शायद और भी ज़्यादा समय बर्बाद होता
      हां, पास आती deadline ने उस अनुभव को कितना प्रभावित किया, यह कहना मुश्किल है ;-P

  • अगर पाठक शुरू से ही ऐसा ePub reader इस्तेमाल कर रहा हो जो max-width जैसी चीज़ों को सपोर्ट करता हो, या कम से कम उन्हें नज़रअंदाज़ कर देता हो, तो इसे सौभाग्य ही मानना चाहिए :-P
    मैंने खुद ePub readers इस्तेमाल करते हुए कभी-कभी ऐसी files को हाथ से ठीक किया है जो बेकार styles की वजह से काम नहीं करती थीं या अजीब दिखती थीं। मैंने यह भी सुना है कि जो file मेरी तरफ़ ठीक थी, वह किसी और के लिए पढ़ने लायक नहीं थी, और मुझे लगता है कि जब तक कोई सचमुच ज़रूरी fancy formatting n हो, तब तक सबसे बुनियादी HTML पर टिके रहना बेहतर है — इतना बुनियादी कि IE4 भी उसे बहुत ग़लत render न करे
    इसी वजह से कभी-कभी सोचता हूं कि एक epub reconstruct tool बनाऊं, जो ePub को सबसे सरल HTML/CSS में फिर से बना दे। आदर्श रूप से, अधिकतम compatibility के लिए यह configurable होना चाहिए

    • target web browser environment में भी HTML/CSS जैसे-तैसे ही काम करता है, तो पता नहीं किसी ने क्यों सोचा कि इसे किताबों के लिए इस्तेमाल करना अच्छा विचार होगा
      मैं अक्सर सोचता था कि क्यों न ऐसा subset तय कर लिया जाए जो किसी भी computer पर तेज़ी से चले, और मैं अपने बनाए web pages में सिर्फ वही इस्तेमाल करूं। अगर ePub के लिए भी कोई ऐसी सीमा तय कर दे, तो यह कहीं ज़्यादा उपयोगी हो जाएगा
    • शायद यह ऐसा है जैसे चित्र बनाते समय बीच का हिस्सा इसलिए न रंगो कि किसी के चश्मे में दरार हो सकती है और उसे चित्र अजीब दिखे। या फिर चश्मा बनाने वालों से बेहतर चश्मा बनाने को कहना चाहिए, और कलाकार को अपनी कला करने देनी चाहिए

  • Adobe Digital Editions और RMSDK हाल ही में Wipro Engineering को बेचे गए हैं: https://helpx.adobe.com/enterprise/kb/eol-faq-adobe-digital-...

    • यह बिक्री थी, या फिर outsourcing, यह जानने की जिज्ञासा है

  • लेखक की झुंझलाहट समझ में आती है, लेकिन पुराने, upgrade न हुए या upgrade न किए जा सकने वाले ePub readers इस्तेमाल करने वाले पाठक कितने होंगे? अगर लेखक अपनी रचना हर पाठक तक पहुंचाना चाहता है, तो उसे minimum common denominator के हिसाब से चलना होगा
    अगर वह 2013 की किसी चीज़ का स्तर है, तो अफ़सोस, लेकिन बाज़ार की हक़ीक़त यही है

    • मैंने इसे ऐसे पढ़ा कि 2026 में आने वाला नया Kobo भी 2013 में अटका हुआ Adobe DRM software इस्तेमाल करता है