ePub ของคุณไม่ได้มีปัญหา

 (andreklein.net)
2 คะแนน โดย GN⁺ 1 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แม้แต่ EPUB แบบไม่มี DRM ที่ผ่านการตรวจสอบแล้วก็อาจถูก Kobo มองว่าเป็นไฟล์ “corrupted” ได้ โดยปัญหาไม่ได้มาจากความผิดพลาดของฟอร์แมตไฟล์ แต่เกิดจากความเข้ากันได้ของเอนจินเรนเดอร์
  • epubcheck เป็นเครื่องมือตรวจสอบมาตรฐานโดยพฤตินัยสำหรับเช็กโครงสร้าง EPUB และการปฏิบัติตามข้อกำหนด แต่ไม่สามารถจับปัญหาของตัวแปลผล CSS รุ่นเก่าในเรนเดอเรอร์บางตัวได้
  • Kobo ใช้ RMSDK ซึ่งเป็นเอนจินเรนเดอร์อีบุ๊กแบบปิดของ Adobe โดยเอนจินนี้สร้างขึ้นบนพื้นฐาน EPUB2 ก่อนจะถูกอัปเดตเล็กน้อยสำหรับ EPUB3 แต่ไม่ได้รับการทำให้ทันสมัย
  • สาเหตุของปัญหาคือบรรทัดเดียว max-width: min(150px, 30vw); ซึ่งเป็นโค้ด CSS level 4 ที่ถูกต้อง แต่ RMSDK ไม่รองรับ ทำให้ Adobe Digital Editions และ Kobo โหลดหนังสือไม่สำเร็จ
  • หากต้องการตรวจสอบความเข้ากันได้กับ Kobo การใช้ epubcheck อย่างเดียวไม่พอ และจำเป็นต้องทดสอบเปิดจริงใน Adobe Digital Editions เพิ่มเติม

ปัญหาที่เริ่มจาก EPUB ที่ผ่าน epubcheck

  • เครื่องมือของ Adobe มักถูกใช้งานเพราะ Creative Suite เป็นมาตรฐานของอุตสาหกรรม หรือเพราะมีทางเลือกไม่มากนัก และประเด็นของบทความนี้ก็เริ่มจากความไม่พอใจต่อซอฟต์แวร์ของ Adobe
  • หนังสือเล่มใหม่ถูกแจกจ่ายเป็น ไฟล์ EPUB แบบไม่มี DRM ที่ส่งตรงถึงผู้อ่าน และก่อนเผยแพร่ได้ผ่านหลายขั้นตอนรวมถึงการตรวจด้วย epubcheck
  • epubcheck เป็นเครื่องมือมาตรฐานโดยพฤตินัยสำหรับตรวจอีบุ๊กที่จัดโครงสร้างถูกต้อง และจะผ่านได้ก็ต่อเมื่อ manifest สะท้อนชิ้นส่วนและรูปภาพทั้งหมดในหนังสืออย่างครบถ้วน
  • หากลำดับขององค์ประกอบ HTML ไม่ถูกต้อง หรือเบี่ยงเบนจากกฎของ International Digital Publishing Forum เพียงเล็กน้อย ก็จะตรวจไม่ผ่าน
  • การทำให้ epubcheck ผ่าน 100% ไม่ใช่เรื่องง่ายสำหรับมือใหม่ แต่สำหรับคนทำงานสำนักพิมพ์ มันมีบทบาทใกล้เคียงกับ type linter หรือชุดทดสอบเชิงรูปแบบ
  • ความคาดหวังเดิมคือหนังสือที่ผ่าน epubcheck แล้วควรทำงานได้ในทุกรีดเดอร์หรือแอปที่รองรับ EPUB

“corrupted” เกิดขึ้นเฉพาะบน Kobo

  • หนังสือเล่มใหม่ผ่าน epubcheck ruleset 3.3 แต่มีผู้อ่านคนหนึ่งพบข้อความว่า “corrupted”
  • เพื่อเช็กความเป็นไปได้ด้าน backward compatibility จึงมีการเตรียมเวอร์ชัน EPUB2 ด้วย แต่ไฟล์นั้นก็ยังเป็นไปตามข้อกำหนดครบถ้วนและเกิดปัญหาเดียวกัน
  • ผู้อ่านคนนั้นแจ้งว่าหนังสือเปิดไม่ได้บน อุปกรณ์ Kobo หลายรุ่นหลายเจเนอเรชัน
  • EPUB ไฟล์เดียวกันนี้กลับทำงานได้ปกติบนสภาพแวดล้อมอื่น เช่น Amazon Kindle, Apple Books และ Thorium
  • จากการตรวจสอบพบว่า Kobo ใช้ RMSDK ซึ่งเป็นเอนจินเรนเดอร์อีบุ๊กแบบปิดของ Adobe

ตีวงสาเหตุแคบลงมาที่ RMSDK และ Adobe Digital Editions

  • RMSDK เป็นเอนจินหลักของ Adobe Digital Editions และยังถูกใช้ในอุปกรณ์ Kobo หลายรุ่น รวมถึงอุปกรณ์ Sony และ Nook รุ่นเก่า
  • เอนจินนี้ถูกสร้างขึ้นราวปี 2010 โดยยึด EPUB2 เป็นหลัก และแม้จะถูกอัปเดตเล็กน้อยสำหรับ EPUB3 ก็ไม่ได้รับการปรับปรุงให้ทันสมัย
  • การรู้ว่าใช้ RMSDK ไม่ได้แก้ปัญหาที่ผลลัพธ์ของ epubcheck กับ Kobo ขัดแย้งกันได้ทันที แต่ช่วยชี้ทิศทางการดีบัก
  • เมื่อนำหนังสือเข้า Adobe Digital Editions ก็พบว่าโหลดไม่สำเร็จตามคาด และไม่มีข้อความผิดพลาดใด ๆ แสดงออกมา
  • เมื่อพยายามเรียกใหม่ โปรแกรมกลับขึ้นว่าหนังสือเล่มนี้ถูกเพิ่มไปแล้วจึงนำเข้าไม่ได้ แต่หน้าจอยังคงเป็นสีขาว
  • หลังจากนั้นมีการสร้างไฟล์ดัดแปลงหลายแบบเพื่อทดสอบ และทุกแบบยังคงผ่าน epubcheck
    • มีการลองจัดโครงสร้างโฟลเดอร์ใหม่, ลบ metadata, ลบ language attribute, สร้าง UUID ใหม่, ทำ directory flattening, เปลี่ยนนามสกุล, สร้าง ZIP ใหม่ และแก้ manifest
    • แต่ถึงอย่างนั้น Adobe Digital Editions ก็ยังโหลดไม่สำเร็จซ้ำเดิม

สาเหตุที่แท้จริง: CSS ที่ถูกต้องเพียงบรรทัดเดียว

  • เมื่อปิดการใช้งานสไตล์ชีต หนังสือกลับโหลดได้ทันที ทำให้ขอบเขตของปัญหาถูกตีแคบลงมาที่ สไตล์ชีต
  • หลังจากสร้างไฟล์ดัดแปลงเพิ่มเติมหลายแบบที่ใช้เพียงบางส่วนของสไตล์ชีต ก็พบหนึ่งบรรทัดที่เป็นต้นเหตุของปัญหา
.copyright img {
    max-width: min(150px, 30vw);
}
  • โค้ดนี้เป็น CSS level 4 ที่ถูกต้องสมบูรณ์ แต่ RMSDK ไม่รองรับ
  • เมื่อเปลี่ยนโค้ดเป็นรูปแบบเก่ากว่าอย่าง max-width: 150px; หนังสือก็เปิดได้ตามปกติใน Adobe Digital Editions
  • CSS parser ของ RMSDK ดูเหมือนจะหยุดอยู่ราวปี 2013 และไม่รองรับ flexbox, grid, mathematical functions หรือ custom properties
  • เมื่อเจอ CSS ที่ไม่รู้จัก มันไม่ได้ fallback หรือแสดงข้อผิดพลาดอย่างชัดเจน แต่ล้มเหลวเงียบ ๆ
  • epubcheck มีการตรวจ CSS พื้นฐานอยู่แล้ว แต่โดยพื้นฐานแล้วมันไม่สามารถตรวจ CSS ให้สอดคล้องกับเรนเดอเรอร์เฉพาะตัวที่มีปัญหาเชิงโครงสร้างได้

บทเรียนเรื่องการตรวจสอบความเข้ากันได้กับ Kobo

  • แม้ในปี 2026 Kobo ก็ยังใช้ RMSDK เป็นพื้นฐานในการเรนเดอร์หนังสือ ทำให้ CSS ที่ถูกต้องเพียงบรรทัดเดียวสามารถทำให้ EPUB ที่ถูกต้องทั้งไฟล์กลายเป็น “corrupted file” ได้
  • ในกรณีนี้ Kobo ไม่สามารถเปิดหนังสือทั้งเล่มได้ โดยไม่มีทั้งข้อความผิดพลาดที่ชัดเจนและ fallback
  • เพื่อหลีกเลี่ยงปัญหา จึงมีการปล่อยเวอร์ชันใหม่ และมีการดำเนินการเพื่อไม่ให้ผู้อ่านเจอข้อผิดพลาดเดิมซ้ำอีก
  • ในสภาพแวดล้อมที่ควรจะเป็น RMSDK ควรถูกพัฒนาให้พ้นจากสภาพ CSS ที่ล้าสมัย หรืออย่างน้อยควรมีการจัดการข้อผิดพลาด แต่ปัญหานี้ยังคงอยู่เหมือนเดิมในปัจจุบัน
  • หากต้องการให้มั่นใจเรื่องความเข้ากันได้กับ Kobo epubcheck เพียงอย่างเดียวไม่เพียงพอ และต้องตรวจว่าโหลดได้จริงใน Adobe Digital Editions
  • EPUB เป็นมาตรฐานเปิดที่ยอดเยี่ยมสำหรับอีบุ๊ก แต่การนำไปใช้งานจำนวนมากกลับเผยให้เห็นข้อบกพร่องเชิงโครงสร้างที่ให้ความสำคัญกับการจำกัดการเข้าถึงมาก่อน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 1 일 전
ความคิดเห็นจาก Hacker News

  • Adobe ก็เป็นแบบนี้มาตลอด ทำตลาดมหาศาลของ Flash พังทิ้งเอง ทั้งที่ทางแก้คือแค่ทุ่มเงิน QA อีกไม่กี่ล้านดอลลาร์ และสุดท้ายก็ทำให้ผู้ผลิตเบราว์เซอร์ทั้งหมดเห็นพ้องกันว่า “เว็บควรเดินต่อไปโดยไม่มีพาร์ตเนอร์ที่ไว้ใจไม่ได้แบบนี้จะดีกว่า”
    เมื่อก่อนฉันเคยออกของบางอย่างด้วย Flash แต่มันเป็นซอฟต์แวร์สุดสยองที่เต็มไปด้วย ไฮเซนบั๊ก จากการแครชแบบสุ่ม และการเปลี่ยนในส่วนหนึ่งกลับไปทำให้ฟังก์ชันที่ไม่เกี่ยวกันในโมดูลอื่นพังได้ ราคาอยู่ราว ๆ 800 ดอลลาร์ แต่แทบไม่มีซัพพอร์ตเลย ฉันเคยส่งบั๊กหลายตัวที่ทำซ้ำได้ง่ายพร้อมเคสทดสอบย่อส่วนแนบไปด้วย แต่หลังจากรีลีสถัดไปออกมาก็ได้รับแค่ข้อความอัตโนมัติว่า “มันอาจถูกแก้แล้ว ลองซื้อไลเซนส์ราคาเต็มมาตรวจดูสิ”

    • จะชอบหรือเกลียด Steve Jobs ก็ตาม การตัดสินใจไม่รองรับ Flash บน iPhone และผลักดัน HTML5 ทำให้การล่มสลายของ Flash เร็วขึ้นมาก
    • Flash เคยดีกว่านี้ตอนยังใช้ชื่อว่า VideoWorks ;)
      แล้วก็มี MusicWorks ด้วย ทั้งคู่เป็นของ Mac ล้วน ๆ ในยุคแรกมาก แค่เล่าเรื่องนี้ก็เผยอายุแล้ว
    • ทุกวันนี้ Flash ก็ยังไม่มีใครสู้ได้ในฐานะ สื่อสำหรับการเผยแพร่ ที่ง่ายที่สุด
      โครงสร้างซ้อนทับหลายชั้นของ JavaScript build system กับ “มาตรฐานเว็บ” นั้นยากกว่าการแค่วาดอะไรสักอย่าง เขียนฟังก์ชันง่าย ๆ นิดหน่อย แล้วสร้างไฟล์สแตติกที่เอาไปฝังหรือให้ดาวน์โหลดได้ทุกที่มาก ถ้าจะใช้ทางเลือกแทน Flash ก็ต้องเสียเวลากับการตั้งค่าเยอะเกินไป และ “มาตรฐาน” พวกนั้นก็แย่กว่าอีก
      ฉันไม่ชอบทั้ง Steve Jobs ที่ฆ่า Flash และ Adobe ที่บริหารหนึ่งในเทคโนโลยีเว็บที่น่าทึ่งที่สุดได้แย่มาก เด็กที่โตมาในยุคนี้ไม่รู้หรอกว่า Flash เคยมหัศจรรย์แค่ไหน มันเหมือน Roblox หรือ Minecraft สำหรับเว็บ
      เว็บไซต์ทุกวันนี้ยังด้อยกว่าต้นยุค 2000 ที่มี Flash เลย ผ่านมาหลายสิบปีแล้วก็ยังได้แค่เลียนแบบพลังบางส่วนของมัน และเรื่องความง่ายก็ยังเทียบไม่ติดเลย

  • ฉันพยายามจะทำซอฟต์แวร์เครื่องอ่านอีบุ๊กอยู่พักใหญ่ สุดท้ายก็เกือบยอมทำสัญญากับปีศาจแล้วไปสร้างบน RMSDK
    แต่กลับไม่มีทางเข้าถึงมันได้เลย ไม่ใช่แค่ว่าค่าไลเซนส์แพงเกินไปสำหรับนักพัฒนาอิสระ ซึ่งก็จริงอยู่หรอก แต่คือไม่มีแม้แต่คนให้คุยด้วย อีเมลที่อยู่บนเว็บไซต์ไม่ตอบอะไรเลย แม้แต่ “ขอบคุณที่สนใจ” หรือ “จะติดต่อกลับ” ก็ไม่มี
    ฉันเคยถามเพื่อนร่วมงานที่เคยทำงานที่นั่นเรื่องขั้นตอนการเข้าถึง RMSDK เขาก็ไปค้นเอกสารภายในดูแล้วแต่ไม่เจออะไรเลย ลองหาใน LinkedIn ว่าใครน่าจะเกี่ยวข้องกับ RMSDK แล้วไปถามก็เหมือนเดิม
    ขณะเดียวกัน สำนักพิมพ์ก็กระจายหนังสือส่วนใหญ่ผ่าน ผู้ขาย DRM ที่เป็นที่รู้จักอย่าง Apple, Amazon หรือ Adobe เท่านั้น ซึ่งสองเจ้าแรกปิดตายสนิท ถ้านี่ไม่ใช่การผูกขาดแบบต่อต้านการแข่งขันก็ไม่รู้จะเรียกอะไรแล้ว

    • ฉันอ่านหนังสือผ่านแอป FBReader เยอะมาก และมันก็เปิดให้ใช้ SDK สำหรับนำไปใช้ในแอปอื่นได้ด้วย

  • เท่าที่ฉันรู้ อุปกรณ์ Kobo จะใช้ เอนจินเรนเดอร์ ที่ล้ำกว่าถ้าตั้งชื่อไฟล์เป็น .kepub.epub น่าจะอิงกับ ePub 3 แต่ไม่แน่ใจว่าจะช่วยแก้ปัญหานี้ได้ไหม
    ส่วนตัวฉันจะแปลง ePub เป็น kepub ด้วย kepubify(https://pgaskin.net/kepubify/try/) ก่อนย้ายไป Kobo

    • ใช่ ฉันก็ทำแบบนั้นกับทุกไฟล์ สำนักพิมพ์อย่าง Standard Ebooks ก็มี ดาวน์โหลด kepub ให้ด้วย และอย่างที่อธิบายไว้ที่นี่ Adobe reader ก็มีปัญหาด้วย
      https://standardebooks.org/help/how-to-use-our-ebooks#kobo-f...
      ฉันชอบ Kobo Clara Colour มาก และคิดว่าถ้าเอา Adobe reader ออกได้ก็คงสมบูรณ์แบบ ฉันลองใช้ KOReader ด้วย แต่ยังไม่ย้ายไปเต็มตัวเพราะชอบหนังสือห้องสมุดจาก OverDrive กับ Kobo Store

  • น่าเสียดายที่ epub กับ epubcheck ก็ไม่ได้เป็นมาตรฐานชั้นยอดที่ไร้ข้อโต้แย้งอย่างที่ผู้เขียนบอก W3C, Inc. เข้ามาดูแลสเปกช่วง ePub 3.1 และอ้างอิง WHATWG HTML กับสเปกเบราว์เซอร์ที่พองตัวขึ้นเรื่อย ๆ แบบตรง ๆ ([1])
    “มาตรฐานมีชีวิต” แบบนี้ไม่มีทั้งการจัดการเวอร์ชันและ QA ผลก็คือในเมื่อมันอิงกับ HTML เวอร์ชันที่นิยาม header และการแบ่ง section ใหม่ ePub 3.2 ก็เลยทำให้ ePub เดิม ๆ กลายเป็นไม่สอดคล้องตามมาตรฐานไปเสียอย่างนั้น นี่จึงเป็นเหตุผลที่ Calibre และเครื่องมืออื่น ๆ ยังแนะนำให้ใช้ 3.1 หรือดีกว่านั้นคือ 2
    กรณีที่ฟังก์ชัน CSS min() ถูกปฏิเสธก็เป็นอีกจุดที่การยกสเปก CSS ที่ซับซ้อนเกินจำเป็นมาทั้งดุ้นไม่ได้ช่วยอะไรนัก เพราะเครื่องอ่านอีบุ๊กไม่ใช่เบราว์เซอร์ที่อัปเดตตามรุ่นล่าสุดตลอดเวลา
    [1]: https://news.ycombinator.com/item?id=41326179

    • ฝั่ง ePub มีการรู้กันทั่วไปว่า ตั้งเป้า 3.1 หรือ 2 เป็นตัวเลือกที่สมเหตุสมผลกว่า
      เวลาเจอปัญหาความเข้ากันได้ของ EPUB ควรสงสัย CSS เป็นอันดับแรกเสมอ การใช้ฟีเจอร์ CSS “สมัยใหม่” แล้วบ่นว่าไม่มี flexbox หรือ grid นี่เป็นวิธีคิดแบบนักพัฒนาเว็บ
      การที่ EPUB ใช้บางส่วนของสแต็กเดียวกับเว็บ ไม่ได้แปลว่าทั้งสองอย่างทับซ้อนกันทั้งหมด และก็ไม่จำเป็นต้องเป็นแบบนั้นด้วย เครื่องอ่าน e-ink แบบฝังตัวส่วนใหญ่ไม่ได้ใช้เบราว์เซอร์ในการเรนเดอร์ แต่ฝัง toolchain สำหรับแยกวิเคราะห์และเรนเดอร์ HTML/CSS ที่ทำมาเฉพาะงานไว้ในเฟิร์มแวร์ แล้วค่อยอัปเดตนาน ๆ ครั้ง ถ้าสนใจก็ลองดู crengine ของ KOReader หรือ Crosspoint reader ที่รันบน ESP32
      โพสต์บล็อกนั้นมีกลิ่น สำนวน AI ที่มั่นใจเกินเหตุชัดมาก แต่อย่าหลงเชื่อ

  • ถ้าใครกำลังมองหาอุปกรณ์ ก็มี PineNote ด้วย
    https://pine64.org/devices/pinenote/
    มันแพงกว่าและมีซอฟต์แวร์ที่พร้อมใช้งานทันทีน้อยกว่า แต่ในแง่ความเป็นเจ้าของอุปกรณ์และข้อจำกัดเกี่ยวกับซอฟต์แวร์ที่สามารถรันได้ ตรงไปตรงมามากกว่าและมีเงื่อนไขผูกมัดน้อยกว่ามาก
    มีบทความที่สรุปประสบการณ์ใช้งาน PineNote ไว้ดีเหมือนกัน
    https://shom.dev/posts/20250308_pinenote-day-one/
    https://shom.dev/posts/20250406_a-pinenote-only-5-day-weeken...

    • อยากรู้ว่าได้ลองใช้ PineNote ด้วยตัวเองไหม ราคาอยู่ที่ 400 ดอลลาร์ และเขียนไว้ว่า “สำหรับนักพัฒนา Linux ที่มีความรู้ด้านระบบฝังตัวอย่างมาก หรือผู้มีประสบการณ์กับ mobile Linux” เฟิร์มแวร์ที่ชุมชนทำไว้ตามลิงก์ก็ไม่ได้อัปเดตมานานกว่าหนึ่งปีแล้ว
      Kobo เองก็ไม่ได้จำกัดสิ่งที่ทำได้เหมือนกัน คุณสามารถไซด์โหลดซอฟต์แวร์อ่านอีบุ๊กทางเลือกอย่าง KOReader เพื่อปรับปรุงความสามารถของตัวอ่านที่ติดมากับเครื่องได้
    • หน้าจอ e-ink 60Hz แบบ โอเพนซอร์ส ของคนนี้ก็น่าดูเหมือนกัน: [video] https://www.youtube.com/watch?v=nHbA2-_qzH4

  • จริง ๆ แล้ว Kobo กำลังเขียนซอฟต์แวร์อ่านอีบุ๊กใหม่ทั้งหมด และในสหภาพยุโรปสามารถดาวน์โหลดเบต้าได้ แทบจะแน่นอนแล้วว่าไม่ได้ อิง RMSDK อีกต่อไป
    Adobe บริหารได้ย่ำแย่ และต่อมาก็ยิ่งทำให้ผู้ใช้ปลายทางกับแพลตฟอร์มหงุดหงิดกว่าเดิมด้วยการขายต่อให้บุคคลที่สามซึ่งทำการย้ายระบบพัง เท่ากับยกตลาด EPUB DRM ให้ LCP ไปแบบถวายพานเลยทีเดียว แพลตฟอร์มต่าง ๆ กำลังหนีออกจาก Adobe เร็วกว่าที่เคย

    • อยากรู้ว่าได้ลองใช้เบต้าหรือยัง อยากรู้ว่ามันดีขึ้นพอสมควรจริงไหม

  • พอเห็นประโยคที่ว่า “ช่วงเวลาที่น่ากลัวคือการกดปุ่มตรวจสอบบนหนังสือที่ทำเสร็จหลังจากทำงานมาหลายเดือน เพราะมันมักจะหาเรื่องมาตำหนิได้เสมอ” ก็ทำให้นึกถึงนักศึกษาปริญญาโทที่แทบร้องไห้ตอนพยายามคอมไพล์ ดราฟต์บทความ LaTeX
    เขาตีความคำว่า “เขียนไปก่อนแล้วค่อยคิดเรื่องฟอร์แมตทีหลัง” แบบตรงตัวเกินไป จนเพิ่งมาลองคอมไพล์ครั้งแรกเอาเกือบถึงเส้นตาย

    • ถึงอย่างนั้น โดยรวมแล้วก็น่าจะประหยัดเวลาไปได้ไม่น้อย แค่ดูจากเวลาคอมไพล์อย่างเดียว ถ้าเริ่มตรวจวนซ้ำเร็วกว่านั้นก็คงเสียเวลาไปมากกว่านี้อีก
      แต่เส้นตายที่ใกล้เข้ามามีผลต่อความรู้สึกนั้นแค่ไหนก็คงไม่รู้ ;-P

  • ถ้าผู้อ่านใช้ ePub reader ที่รองรับ max-width หรืออย่างน้อยก็เมินมันได้ ก็ถือว่าโชคดีแล้ว :-P
    ส่วนตัวแล้วเวลาใช้ ePub reader บางทีก็ต้องแก้ไฟล์เอง เพราะมีสไตล์ที่ไม่จำเป็นแล้วทำให้มันใช้ไม่ได้หรือแสดงผลแปลก ๆ เคยได้ยินด้วยว่าไฟล์ที่ฝั่งฉันไม่มีปัญหาอะไร กลับอ่านไม่ได้สำหรับคนอื่น และถ้าไม่ใช่ฟอร์แมตหวือหวาที่จำเป็นจริง ๆ ก็รู้สึกว่าควรอยู่กับ HTML พื้นฐานที่สุดที่แม้แต่ IE4 ก็ยังเรนเดอร์ไม่ผิดเพี้ยนมากนักจะดีกว่า
    เลยมีบางครั้งที่คิดว่าอยากทำเครื่องมือ epub reconstruct ที่จัด ePub ใหม่ให้เป็น HTML/CSS ที่เรียบง่ายที่สุด โดยอุดมคติแล้วควรตั้งค่าได้เพื่อให้รองรับได้สูงสุด

    • แม้แต่ในสภาพแวดล้อมเว็บเบราว์เซอร์เป้าหมายเอง HTML/CSS ก็ยังแทบจะทำงานได้แบบกระท่อนกระแท่นอยู่แล้ว เลยไม่รู้ว่าใครคิดว่านี่เป็นไอเดียที่ดีสำหรับหนังสือ
      ฉันมักคิดอยู่บ่อย ๆ ว่าถ้ากำหนด subset ที่ทำงานได้เร็วบนคอมพิวเตอร์ทุกเครื่อง แล้วใช้แค่สิ่งนั้นกับเว็บเพจที่ฉันทำจะเป็นอย่างไร ถ้ามีใครสรุปขอบเขตแบบนั้นให้ ePub ด้วย มันก็คงมีประโยชน์ขึ้นมาก
    • เหมือนเวลาวาดรูปแล้วต้องไม่ลงสีตรงกลาง เพราะแว่นของใครบางคนอาจร้าวทำให้ภาพดูเพี้ยนไปงั้นแหละ หรือไม่ก็ควรบอกให้ผู้ผลิตแว่นทำแว่นที่ดีกว่านี้ แล้วปล่อยให้ศิลปินทำงานศิลปะของตัวเอง

  • Adobe Digital Editions และ RMSDK ถูกขายให้ Wipro Engineering ไปเมื่อไม่นานนี้: https://helpx.adobe.com/enterprise/kb/eol-faq-adobe-digital-...

    • สงสัยว่านี่คือการขายจริง ๆ หรือเป็นแค่ การเอาต์ซอร์ส

  • เข้าใจความอัดอั้นของผู้เขียนนะ แต่จะมีผู้อ่านสักกี่คนกันที่ยังใช้ ePub reader เก่าซึ่งไม่ได้อัปเกรดมานาน หรืออัปเกรดไม่ได้? ถ้าผู้เขียนอยากให้งานของตัวเองเข้าถึงผู้อ่านทุกคน ก็ต้องยึดตาม ตัวหารร่วมต่ำสุด
    ถ้านั่นคืออะไรสักอย่างจากปี 2013 ก็น่าเสียดาย แต่ก็นั่นแหละคือความจริงของตลาด

    • ฉันอ่านว่า Kobo รุ่นใหม่ที่ออกในปี 2026 จะยังใช้ซอฟต์แวร์ Adobe DRM ที่กฎ CSS หยุดอยู่ที่ปี 2013