PDF สามารถฝังฟอนต์ได้ แต่ก็มักจะไม่ฝัง และพึ่งพาฟอนต์ของระบบแทน เหตุผลหนึ่งคือการใส่ฟอนต์ลงใน PDF อาจทำให้ขนาดไฟล์ใหญ่ขึ้นมาก ในบางกรณีฟอนต์เดียวอาจใหญ่กว่าส่วนที่เหลือของไฟล์ทั้งหมดด้วยซ้ำ
ฉันเคยลองทำระบบฝังฟอนต์ในซอฟต์แวร์สร้าง PDF มาก่อน และพบว่ายากอย่างน่าประหลาดที่จะทำให้มันทำงานได้อย่างเสถียร
เรื่องที่ว่า PDF เรนเดอร์ได้สม่ำเสมอก็ไม่จริงเสียทีเดียว ฉันเคยเห็นหลายครั้งที่ PDF เดียวกันเรนเดอร์ต่างกันขึ้นอยู่กับว่าใช้ PDF viewer ตัวไหน โดยปกติความต่างจะเล็กน้อย แต่บางครั้งก็มี edge case ที่ต่างกันค่อนข้างมาก ฉันยังเคยเจอกรณีที่ Acrobat Reader เวอร์ชันเดียวกันเรนเดอร์ PDF ต่างกันตามระบบปฏิบัติการด้วย
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
สนใจจุดตัดระหว่างอีบุ๊ก ความปลอดภัย และ เว็บ LowJS มาก เลยรู้สึกว่าประเด็นนี้สำคัญ
รูปแบบอีบุ๊กแบบไฟล์เดียวที่พกพาได้เป็นสิ่งจำเป็น แต่ PDF ไม่ใช่คำตอบเพราะไม่รองรับการไหลของข้อความใหม่
HTML+CSS ในปี 2024 สามารถถ่ายทอดสื่อสิ่งพิมพ์ได้แทบทุกแบบ ขณะเดียวกันก็ยังให้ข้อความไหลใหม่ได้
ไม่คิดว่า JavaScript จำเป็นต้องเป็นสิ่งบังคับ อีบุ๊กควรเป็นหนังสือที่ปรับขนาดได้อย่างมีความหมาย และแม้ปิด JavaScript ฟังก์ชันพื้นฐานในฐานะหนังสือก็ควรยังทำงานได้ ถ้าต้องการปฏิสัมพันธ์หรือส่วนเสริมก็ใช้ JavaScript ได้ แต่ถ้าไม่มี JavaScript แล้วมันไม่ทำงานเป็นหนังสือ ก็ถือว่าเป็นบั๊ก
การใส่สไตล์ทั้งหมดไว้แบบอินไลน์ดูเป็นความผิดพลาด เพราะอาจทำให้ CSP ของผู้ใช้บางคนพังได้ ควรแยกสไตล์เป็นทรัพยากรแบบ relative path ตาม HTML และอีบุ๊กควรห้ามโหลดทรัพยากรจากโดเมนอื่น
สุดท้ายก็แค่แจกเป็นไฟล์ zip ได้เลย คิดว่าอีบุ๊กเองก็ทำงานแบบนั้นอยู่แล้วไม่ใช่หรือ
แต่ในทางกลับกันไม่จำเป็นต้องจริงเสมอไป ต่อให้ชุดไฟล์เดียวกันเคยเป็น EPUB ที่ถูกต้องก่อนแตกไฟล์ ถ้านำกลับไป zip ใหม่แบบลวก ๆ ก็อาจไม่เป็น EPUB ที่ถูกต้องอีกต่อไป
ไฟล์ mimetype ภายใน zip ของ EPUB มีความพิเศษตรงที่ต้องเป็นรายการแรกของ archive และเนื้อหาต้องมีแค่
application/epub+zipเท่านั้น อีกทั้งต้องถูกเก็บแบบไม่บีบอัดน่าแปลกที่เครื่องมือ zip จำนวนมากมักสลับลำดับไฟล์ หรือทำให้การเก็บบางไฟล์แบบไม่บีบอัดทำได้ยากจนเป็นเรื่องน่ารำคาญ โปรแกรม zip บนบรรทัดคำสั่งมักทำได้ด้วยแฟลก แต่ในไลบรารี zip นั้นค่อนข้างทรมาน อันนี้พูดจากประสบการณ์ทำซอฟต์แวร์สร้าง EPUB
ที่อธิบายคือฟอร์แมต ePub ซึ่งเป็นไฟล์ HTML, CSS และรูปภาพที่อยู่ใน zip archive
มี CSP สำหรับทำให้ปลอดภัยรวมอยู่ด้วย
ข้อดีอย่างหนึ่งของการใช้ ไฟล์ .doc แบบเก่าแทน .docx คือสามารถค้นหาคำบางคำได้เร็วมากในโฟลเดอร์ที่มีไฟล์หลายร้อยหรือหลายพันไฟล์ ซึ่งในฟอร์แมต zip ทำแบบนั้นไม่ได้
เมื่อกี้ลองบันทึกเป็น .doc แล้วเปิดด้วย hex editor พบว่าเนื้อหาจริงอยู่ในนั้นเป็นข้อความล้วน ไฟล์ฟอร์แมต zip หรือ PDF ค้นหาด้วย grep ได้ยาก และก็ยังสงสัยว่าข้อความแค่ไม่กี่พันตัวอักษรจำเป็นต้องบีบอัดจริงหรือไม่
เป็นบทความที่เขียนได้ดีมากจากนักพัฒนา Nota ซึ่งพยายามยกระดับฟอร์แมต EPUB ให้ทัดเทียมกับ PDF ตอนนี้เขาทำตัว viewer แล้ว และตัวบทความเองก็แสดงผลด้วย พอร์ต WASM แบบเบราว์เซอร์ของ viewer ตัวนั้น
ปัญหาอย่างหนึ่งคือ EPUB ซึ่งโดยพฤตินัยเป็น XHTML จะถ่ายทอดเลย์เอาต์ได้แม่นยำแค่ไหน เกณฑ์ของบทความต้นฉบับคือเอกสารดู “พอใช้ได้” แต่ถ้าจะให้เทียบชั้น PDF ก็มีนัยว่าฝั่ง HTML ยังต้องมีความสามารถด้านเลย์เอาต์ใหม่ ๆ อย่างน้อยในเรื่องการตัดบรรทัด
ดูเหมือนจะมีสองแนวทางในการพัฒนา อย่างแรกคือให้เบราว์เซอร์มีเครื่องมือด้าน typography มากขึ้น ซึ่ง
text-wrap: prettyบอกว่าช่วยได้ แต่พอลองทดสอบสั้น ๆ ก็ยังไม่รู้สึกว่าคุณภาพการตัดบรรทัดดีขึ้น อีกทางคือคำนวณการตัดบรรทัดไว้ล่วงหน้า ซึ่งทำได้เฉพาะกับการเรนเดอร์เลย์เอาต์คงที่อีกอย่างคือแม้ผู้เขียนจะพูดถึงเชิงอรรถ แต่ก็ยังไม่ชัดเจนว่าเขาตั้งใจจะทำอย่างไร
ความสามารถนี้มีอยู่แล้วใน EPUB3 แต่ข้อเสียคือดูไม่ดีบนหน้าจออย่างโทรศัพท์ แม้จะให้ตัวอ่านเขียนค่าทับค่าเริ่มต้นได้ แต่แบบนั้นก็ต้องหวังให้ตัวอ่านช่วยจัดเอกสารใหม่ให้ออกมาดูดี
ทางเลือกคือให้ EPUB ระบุการเรนเดอร์หลายแบบสำหรับประเภทหน้าจอที่พบบ่อย ถึงจะไม่สมบูรณ์แบบ แต่การให้ผู้สร้างเอกสารตั้งค่าพื้นฐานไว้ แล้วให้ผู้ใช้เลือกเขียนทับได้หากต้องการ ก็ดูเป็นจุดประนีประนอมที่ดี
สิ่งที่ฟอร์แมตอีบุ๊กต้องการคือ semantic markup ที่ปรับตัวตามอุปกรณ์ที่ใช้เรนเดอร์ได้ ซึ่ง HTML+CSS ก็ถูกสร้างมาเพื่อจุดประสงค์นั้นตั้งแต่แรก
ดังนั้นคนจัดเลย์เอาต์หนังสือต้องยอมส่งมอบอำนาจควบคุมบางส่วนของหน้าตาหนังสือให้ผู้อ่านอย่างตั้งใจ ความไม่สมบูรณ์ทางภาพเล็กน้อยถือเป็นราคาที่คุ้มจะจ่าย หากต้องการความสมบูรณ์ทางภาพจริง ๆ ก็ใช้ PDF ไป
แน่นอนว่าถ้ามีองค์ประกอบแบบโต้ตอบเข้ามาก็จะยากขึ้น องค์ประกอบโต้ตอบขนาดใหญ่ควรเปิดในมุมมองเฉพาะเมื่อจำเป็น ส่วนองค์ประกอบเล็ก ๆ ก็ควรยอมรับการไหลใหม่
เชิงอรรถและการอ้างอิงน่าจะมีอยู่แล้วในสเปก EPUB หรืออาจรวมถึงสเปก HTML ด้วย
และก็ไม่เห็นด้วยว่าการกดค้างเพื่อเปิดป๊อปอัปดีกว่า anchor ของไฮเปอร์ลิงก์ทั่วไป ถ้าฟังก์ชัน “ย้อนกลับ” ของตัวอ่านทำงานได้ดี หรือมีลิงก์ “กลับ” ในการอ้างอิงแบบสองทาง วิธีการกระโดดไปมาจะรบกวนน้อยกว่ามาก
แนวคิดคือแจกจ่ายเอกสาร XML พร้อม XSL stylesheet แล้วแปลงเป็น FO สำหรับการเรนเดอร์ และสำหรับเอกสารเดียวกันก็สามารถมี stylesheet หลายชุดตามอุปกรณ์เป้าหมายหรือขนาดหน้าได้
ใน Firefox ฉันใช้ ส่วนเสริม SinglePage เพื่อบันทึก DOM ของหน้าปัจจุบันเป็นไฟล์ HTML แบบสแตนด์อโลน โดยจะฝัง CSS และ
data:URL สำหรับรูปภาพไว้แบบอินไลน์ แล้วลบ dependency และสคริปต์ออกมันไม่ได้สมบูรณ์แบบ และฉันก็ไม่ได้เชื่อว่าบราว์เซอร์จะคงความเข้ากันได้ย้อนหลังไว้เสมอ แต่ก็ยังชอบมากกว่าการบันทึกหน้าเป็น PDF หรือเป็นหลายไฟล์
ที่น่าสนใจก็คือ หนึ่งในไม่กี่หน้าที่ส่วนเสริมนี้ล้มเหลวก็คือบทความนี้เกี่ยวกับ Portable EPUB เอง ดูเหมือนจะมีเวทมนตร์เยอะเกินไปเพื่อให้การจัดรูปแบบออกมาถูกต้อง หน้าที่บันทึกไว้อ่านได้ก็จริง แต่สไตล์ต่างจากต้นฉบับโดยสิ้นเชิง
ฉันชอบที่ fbreader บน Android แสดงหนังสือทุกเล่มเหมือนกันตามการตั้งค่าของแอป แทนที่จะใช้สไตล์ของไฟล์ EPUB ไม่เคยเห็นมันพยายามใช้ CSS หรือรันสคริปต์ที่มากับไฟล์เลย และหวังว่าจะไม่ทำแบบนั้นต่อไป การโหลด dependency ภายนอกเป็นความคิดที่แย่ยิ่งกว่า และเดิมทีฉันก็ไม่รู้ด้วยซ้ำว่าอนุญาตให้ทำได้
พูดถึงเรื่องนั้นแล้ว ระบบสิทธิ์ของส่วนเสริม Firefox มันแปลก ๆ ถ้าจะทำอะไรที่น่าสนใจก็แทบจะต้องขอสิทธิ์ทุกอย่าง ผลลัพธ์คือเกิดตลาดตามธรรมชาติสำหรับผู้ไม่หวังดีที่คอยช็อปปิงหาส่วนเสริมที่จะเข้ายึด
ตัวอย่างเช่น ส่วนเสริม SingleFile จำเป็นต้องมีสิทธิ์เข้าถึง เพราะต้องดู DOM ที่เรนเดอร์แล้วและบันทึกออกเป็นไฟล์ แต่ก็ยังสงสัยว่าทำไมต้องเข้าถึงทุกอย่างด้วย จะให้แค่สิทธิ์แบบ
snapshot DOM once,write to a single fileไม่ได้หรือตอนนั้นฉันคงอธิบายหรือแม้แต่เข้าใจเหตุผลได้ไม่ดีนัก แต่ถูกมองเหมือนเป็นความต้องการเพ้อฝัน พอมาดูตอนนี้ก็รู้สึกดีที่เหมือนฉันแค่มาก่อนเวลาสัก 10 ปี
KOReader เป็นมิตรน้อยกว่าแต่ให้การควบคุมมากกว่า คุณสามารถเลือกไฟล์ CSS เฉพาะจากหลายไฟล์ที่มีให้ หรือเขียนเองก็ได้
ข้อดีของ KOReader ยังรวมถึง การรองรับ OPDS ที่ยอดเยี่ยม และเซิร์ฟเวอร์ซิงก์แบบโฮสต์เองที่ตั้งค่าได้ง่าย
ถ้ามีฟีเจอร์นี้อยู่ สำหรับหน้าที่ใช้ระบบนี้ก็ไม่จำเป็นต้องใช้ SinglePage แล้ว
ฉันกลับไปดูใหม่หลังเห็นส่วนนั้น ตรงที่บอกว่า “ดังนั้นเราจึงตัดสินใจสร้าง Bene ซึ่งเป็นระบบอ่าน EPUB ที่เบากว่า และนั่นคือสิ่งที่คุณกำลังใช้อยู่ตอนนี้ เอกสารนี้คือ EPUB และคุณสามารถกดปุ่มมุมขวาบนเพื่อดาวน์โหลดได้”
ตอนอ่านบนเบราว์เซอร์เดสก์ท็อป ฉันไม่ทันสังเกตเลยจนกว่าจะมีคนบอก บนมือถือจะสังเกตง่ายกว่าเพราะเฮดเดอร์กินพื้นที่หน้าจอมากกว่า แต่นอกนั้นมันก็ทำงานแทบไม่ต่างจากหน้าเว็บทั่วไป
น่าจะเป็นสัญญาณที่ดี
ต่างจากที่บางคอมเมนต์พูดไว้ ฉันไม่ได้เห็นหรืออย่างน้อยก็ไม่ได้สังเกตเห็นสปินเนอร์ตอนโหลดเอกสารครั้งแรก บนมือถือเห็นนะ แต่หายไปค่อนข้างเร็ว ไม่รู้ว่านั่นคือการโหลดโปรแกรม WASM หรือเกิดเฉพาะตอนโหลดครั้งแรก
ต่างจากหน้าเว็บทั่วไปหรือ PDF ดูเหมือนว่าจะยังไม่เริ่มเรนเดอร์จนกว่าจะดาวน์โหลด asset ทั้งหมด หรือก็คือ ePub ทั้งก้อนเสร็จ
ความต่างที่คิดว่าบทความน่าจะพูดถึงแต่ไม่ได้พูดคือเรื่องประสิทธิภาพ PDF สามารถปรับให้แต่ละหน้าค่อนข้างเป็นอิสระจากกันได้ จึงรองรับการเรนเดอร์แบบค่อยเป็นค่อยไป การเข้าถึงแบบสุ่ม และการทำงานขนานในระดับสูง
แค่เพราะเบราว์เซอร์เปิด EPUB ไม่ได้ ก็ทำให้รู้สึกว่าเป็นโปรเจกต์ที่เหมือนถูกกำหนดให้ล้มเหลวไว้ส่วนหนึ่งแล้ว PDF แค่ลิงก์ก็ยังพอมีการสลับบริบทเล็กน้อย แต่เบราว์เซอร์ก็เปิดและแสดงผลให้ได้
ถ้าตามคำอธิบาย EPUB ก็คือ HTML ในทางปฏิบัติ การที่เบราว์เซอร์ไม่เปิดมันจึงดูแปลก แต่คงไม่ง่ายที่จะไปโน้มน้าวพวกขุนนาง Chrome/Mozilla
อีกเรื่องที่น่าหดหู่คือ HTML และ CSS ใหญ่โตและบวมเกินไป จนแทบไม่มีใครสามารถทำ “รีดเดอร์” สำหรับ EPUB/HTML ได้ สุดท้ายมันแทบจะกลายเป็น “ไปสร้างเบราว์เซอร์ใหม่สิ” มากกว่า วิธีแบบ Djot ที่ใช้ Markdown ซึ่ง parse ง่าย แล้วเพิ่มความสามารถด้าน rendering เข้าไปอีกนิด ดูมีอนาคตกว่าในระยะยาว
ทางประนีประนอมชั่วคราวของผมคือใส่ CSS, SVG, สคริปต์ และแม้แต่รูปภาพ base64 ไว้ทั้งหมดใน ไฟล์ HTML เดียว คล้าย EPUB อยู่บ้าง ทั้งอ้วนทั้งไม่สวย แต่ถ้าระวังหน่อยก็ใช้งานได้ และเบราว์เซอร์ก็เปิดได้ตามธรรมชาติ
แต่ผู้ใช้ไม่มีทางรู้ได้ว่า “อ้อ เว็บเพจนี้ดาวน์โหลดไปเก็บไว้ออฟไลน์ได้สินะ” ถ้ามีนามสกุลอย่าง
.htmlsไว้บอกว่าเป็น HTML ที่ไม่มี resource ภายนอกก็คงดีEPUB ก็ดูไม่มีเหตุผลว่าทำไมเบราว์เซอร์จะทำแบบเดียวกันไม่ได้ มีส่วนขยายเบราว์เซอร์ที่ทำสิ่งนี้อยู่แล้วด้วย ประเด็นคือฟอร์แมต EPUB จะได้ความนิยมในวงกว้างหรือไม่
ต่อมาดีไซน์และเลย์เอาต์แบบนิตยสารกลายเป็นสิ่งที่ “จำเป็น” แต่ก็ยังโอเคอยู่พอสมควรเพราะยังอิงเอกสารเป็นหลัก
หลังจากนั้นก็พยายามยัด HTML ให้เป็นแพลตฟอร์มแจกจ่ายแอปพลิเคชัน ตอนนี้เลย์เอาต์ CSS ก็ในที่สุดเริ่มใกล้กับเอนจินเลย์เอาต์ของแอปแบบดั้งเดิมมากขึ้น
ผมมองว่า 20 ปีที่ผ่านมาเสียเปล่าไปเยอะพอสมควรเพราะไม่มีวิธีแจกจ่ายแอปข้ามแพลตฟอร์มที่เหมาะสม ยกเว้น Java
ถ้าจะให้ฟอร์แมตนี้ทำงานซ้ำได้เหมือนกันทุกที่ มันต้องถูกทำให้เป็นมาตรฐาน และต้องทำให้การเขียนเอนจินเรนเดอร์ใหม่เป็นเรื่องง่ายด้วย แนวทางที่พึ่งพา webview ไม่ค่อยดูเป็นหนทางข้างหน้า
ความงามของ PDF คือความเชื่อถือได้สูงมาก PDF เมื่อ 10 ปีก่อนก็ยังเรนเดอร์ออกมาเหมือนเดิมทุกอย่างในวันนี้
ถ้าความพยายามแบบนี้จะสำเร็จ ขอบเขตของเอกสารคงต้องถูกลดลงมาก ส่วนย่อยของ XHTML ที่อนุญาตควรจำกัดมาก ๆ และต้องให้ความสำคัญกับความสามารถในการเรนเดอร์ให้เหมือนกันทุกที่ก่อน เริ่มจาก fixed layout ขนาดหน้าคงที่ก่อน แล้วค่อยไปสู่เอกสารแบบ reflowable และยังต้องมีมาตรฐานที่มาพร้อมเอกสารทดสอบและผลลัพธ์การเรนเดอร์แบบครบถ้วนด้วย
ถ้าไม่มีการรองรับจากเบราว์เซอร์ การเขียนพร็อกซีฝั่งเซิร์ฟเวอร์เพื่อแปลง EPUB ให้เป็นไซต์ที่คลิกสำรวจได้ พร้อมปุ่มเปลี่ยนบทและตัวเลือกเลย์เอาต์ง่าย ๆ ก็คงไม่ยากนัก
แน่นอน ถ้าจะใช้พร็อกซีแบบนั้นดูอีบุ๊กเชิงพาณิชย์ส่วนใหญ่ ก็น่าจะมีปัญหาทางกฎหมายหนักมากกับการรองรับ DRM ที่จำเป็น
คิดไปคิดมา การรองรับ DRM EPUB ในเบราว์เซอร์แบบที่สำนักพิมพ์ยอมรับได้ จริง ๆ แล้วก็ห่างจากการรองรับ DRM สำหรับเว็บเพจทั่วไปแค่ครึ่งก้าวทางเทคนิคเท่านั้น ซึ่งเป็นภาพอนาคตที่ค่อนข้างสยอง
ผมคิดว่า PDF เป็นฟอร์แมตมรดกสุดสยองที่มีความซับซ้อนเกินจำเป็น การใช้งาน PDF ส่วนใหญ่ก็ไม่ได้เกี่ยวกับการพิมพ์ จึงรู้สึกว่า logic ด้านการจัดหน้าไม่ได้ตอบโจทย์เท่าไร
สำหรับกรณีใช้งานส่วนใหญ่ สิ่งที่สำคัญกว่ามากคืออ่านง่ายบนมือถือ แท็บเล็ต และคอมพิวเตอร์
ผู้เขียนบอกว่าแปลกใจที่ iBooks ไม่รองรับมุมมองแบบเลื่อน ผมเลยไปเช็กเอง macOS iBooks ไม่รองรับการเลื่อนสำหรับไฟล์ ePub แต่บน iOS และ iPadOS รองรับ นี่เป็นการตัดสินใจที่แปลกมากของ Apple
https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
ผมไม่เคยเห็นกรณีที่เอกสารเทคนิคถูกแจกจ่ายในฟอร์แมตที่ไม่ใช่ PDF แล้วทั้งอ่านและค้นหาได้สะดวกกว่า แม้แต่บนมือถือก็เหมือนกัน
ผมไม่ต้องการเอกสารที่หน้าตาเปลี่ยนไปตามสถานะชั่วคราวอย่างอุปกรณ์ที่ใช้ดูหรือขนาดหน้าต่าง ผมต้องการเอกสารที่มีเลย์เอาต์คงที่ซึ่งผู้เขียนออกแบบไว้อย่างดี
แม้อ่านบนหน้าจอหรือหน้าต่างขนาดเล็ก ถ้าไม่ใช่เอกสารข้อความล้วน ผมก็ต้องการ รีดเดอร์อัจฉริยะ ที่ซูมและเลื่อนได้สะดวก ไม่ใช่เปลี่ยนเลย์เอาต์ และไม่ควรมีพฤติกรรมโง่ ๆ แบบรีดเดอร์ Android บางตัว ที่การเลื่อนแนวตั้งหรือกด Page Up/Page Down ดันขยับตำแหน่งแนวนอนด้วยจนอ่านคอลัมน์ข้อความลำบาก
แค่ยึดตามคำแนะนำดั้งเดิมเรื่องความกว้างสูงสุดของคอลัมน์ข้อความ ก็เพียงพอแล้วที่จะอ่านบนมือถือได้สบาย จะลำบากก็เฉพาะเวลาผู้เขียนทำคอลัมน์กว้างเกินไปจนฝ่าฝืนกฎ typography แบบดั้งเดิมเท่านั้น
เพราะงั้นการพยายามสร้างมาตรฐานเดียวที่ใช้ได้กับทุกอย่างจึงดูเป็นความคิดที่ไม่ดี มาตรฐานเอกสารดิจิทัลน่าจะมีสองแบบดีกว่า แบบหนึ่งเป็นฟอร์แมตที่มีความสามารถมัลติมีเดียและการโต้ตอบครบถ้วน ยกเว้นการเชื่อมต่อเครือข่าย อีกแบบเป็น subset ของมันที่จำกัดไว้เป็นขาวดำ ไม่มีมัลติมีเดีย และการโต้ตอบมีหลัก ๆ แค่ไฮเปอร์ลิงก์ภายในเอกสาร
และจริง ๆ แล้วฟอร์แมตสองแบบที่ว่าแทบมีอยู่แล้ว: HTML, MHTML=EML, และ EPUB
แน่นอนว่ายังต้องมีฟอร์แมตที่สามสำหรับการเก็บรักษาทางกายภาพและเอกสารดิจิทัลแบบ fixed layout ที่ไม่ได้ใช้บ่อยนัก และ PDF/A ก็ดูจะทำหน้าที่นั้นได้ค่อนข้างดีอยู่แล้ว
SVG หลายหน้าก็อาจเป็นไปได้ แต่ถ้าจะพิมพ์หลายหน้าให้ถูกต้อง สุดท้ายก็คงต้อง export เป็น PDF ก่อนอยู่ดี พูดจากประสบการณ์กับ Inkscape
เมื่อ 8 วันก่อนมีโพสต์ “Portable Web Documents – An Alternative to PDF Based on HTML5 (2019)” ที่ได้ 134 คะแนน
https://news.ycombinator.com/item?id=39036774
https://news.ycombinator.com/item?id=39037135
ฉันสงสัยว่า EPUB reader ให้อะไรที่เบราว์เซอร์ไม่มี ตอนนี้ดูเหมือนว่าคำตอบมีแค่อย่างเดียว และเป็นเรื่องเล็กน้อยมาก นั่นคือสามารถจัดการ ไฟล์ .epub หรือก็คือไฟล์ zip ให้เหมือนเป็นไดเรกทอรีได้
ถ้าความต่างระหว่าง EPUB reader กับส่วนย่อยของเบราว์เซอร์มีแค่นั้นจริง วิธีที่ง่ายที่สุดและใช้แรงน้อยที่สุดก็น่าจะเป็นแบบนี้
ทำให้เบราว์เซอร์ที่มีอยู่จัดการไฟล์ zip เป็นไดเรกทอรีได้ภายใต้เงื่อนไขบางอย่าง
กำหนดข้อจำกัดของ HTML ที่ตรวจสอบได้เชิงกลไกและรับประกัน asset ภายในเครื่องครบถ้วนตามที่โพสต์ต้นฉบับพูดถึง บางทีแค่กำหนดให้ URL ทั้งหมดนอกจากลิงก์ต้องเป็นพาธแบบสัมพัทธ์ก็อาจพอแล้ว
ประกาศให้ไฟล์ zip ที่ผ่านข้อจำกัดนี้เป็น “Portable EPUB”
ลืม EPUB reader แบบเฉพาะทางทั้งหมดไปได้เลย ทั้งของเดิมและของใหม่
สำหรับ asset ภายในเครื่องครบถ้วน ฉันอยากเห็นข้อกำหนดว่าทุกอ็อบเจ็กต์ต้องมี ตัวเลือกสำรอง ที่ใช้งานได้ในเครื่อง เช่น ถ้าโหลดฟอนต์นั้นไม่ได้ก็ใช้ฟอนต์มาตรฐานแทน แม้มันจะไม่สมบูรณ์แบบ แต่ถ้าจำกัดให้อยู่ในขอบเขตของ fallback ก็น่าจะทำงานได้อย่างสมเหตุสมผล
ยังมี failure mode อย่างหนึ่งที่ยังพูดถึงไม่มากพอ คือรูปภาพที่แสดงผลได้ไม่ถูกต้อง โดยพื้นฐานแล้วรูปภาพไม่สามารถ reflow ได้ ปัญหาส่วนหนึ่งอาจแก้ได้ด้วยการใช้ SVG แต่ใช้ไม่ได้กับกรณีที่เป็นภาพแรสเตอร์จริง ๆ สุดท้ายก็คงต้องมีหลายความละเอียดให้เลือกใช้
ฉันก็เคยเจอปัญหาที่เกี่ยวข้องเหมือนกัน แต่ยังไม่เห็นคำตอบที่ดีนัก: SVG ที่รับรู้ความละเอียดและดึงภาพที่ละเอียดขึ้นเมื่อมีความละเอียดเพียงพอ ถ้าวาดเส้นระดับ subpixel มันจะเบลอ แต่ถ้าซูมภาพเดียวกัน เส้นพวกนั้นกลับมีประโยชน์ขึ้นมา ไอคอนของ Windows รองรับหลายความละเอียดและยอมรับประเด็นนี้ด้วยการเลือกใช้ให้เหมาะกับสถานการณ์
ผู้เขียนเป็นนักวิจัยหลังปริญญาเอกที่มี Shriram Krishnamurthi เป็นอาจารย์ที่ปรึกษา 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 สามารถฝังฟอนต์ได้ แต่ก็มักจะไม่ฝัง และพึ่งพาฟอนต์ของระบบแทน เหตุผลหนึ่งคือการใส่ฟอนต์ลงใน PDF อาจทำให้ขนาดไฟล์ใหญ่ขึ้นมาก ในบางกรณีฟอนต์เดียวอาจใหญ่กว่าส่วนที่เหลือของไฟล์ทั้งหมดด้วยซ้ำ
ฉันเคยลองทำระบบฝังฟอนต์ในซอฟต์แวร์สร้าง PDF มาก่อน และพบว่ายากอย่างน่าประหลาดที่จะทำให้มันทำงานได้อย่างเสถียร
เรื่องที่ว่า PDF เรนเดอร์ได้สม่ำเสมอก็ไม่จริงเสียทีเดียว ฉันเคยเห็นหลายครั้งที่ PDF เดียวกันเรนเดอร์ต่างกันขึ้นอยู่กับว่าใช้ PDF viewer ตัวไหน โดยปกติความต่างจะเล็กน้อย แต่บางครั้งก็มี edge case ที่ต่างกันค่อนข้างมาก ฉันยังเคยเจอกรณีที่ Acrobat Reader เวอร์ชันเดียวกันเรนเดอร์ PDF ต่างกันตามระบบปฏิบัติการด้วย
ดังนั้นถ้าใช้ฟอนต์ระบบที่เข้ากันได้ เลย์เอาต์ของเอกสารที่เรนเดอร์ออกมาไม่ควรเปลี่ยน แน่นอนว่าก็มีกรณีของฟอนต์ระบบที่โฆษณาว่า metric-compatible กับฟอนต์ Adobe PostScript รุ่นเก่า แต่จริง ๆ แล้วมีความต่างเล็กน้อย
นอกเหนือจากฟอนต์ระบบมาตรฐานไม่กี่ตัวนั้น เอกสาร PDF มักจะไม่ได้ฝังทั้งฟอนต์ แต่ฝังแค่ ชุดย่อยของ glyph ที่ตรงกับอักขระที่ใช้จริงในข้อความ
เป็น The Daily WTF ในชีวิตประจำวันจริง ๆ