จาก Markdown เป็น PDF และกลับ: การแปลงรูปแบบเก็บอะไรไว้
Markdown↔PDF เก็บหัวเรื่อง รายการ และตารางง่ายได้ดีกว่าพิกเซล ฟอนต์เป๊ะ การแบ่งหน้า และเลย์เอาต์ไม่รอดเป็น round trip ที่ไม่สูญเสีย
Markdown กับ PDF เหมาะกับสัญญาที่ต่างกัน Markdown เป็นโครงสร้างที่เข้ากับการควบคุมเวอร์ชัน ส่วน PDF เป็นคำอธิบายหน้าคงที่ การแปลงไปทางหนึ่งแล้วแปลงกลับมีประโยชน์ แต่ไม่ใช่รอบอาร์ไคฟ์ที่ไม่สูญเสียข้อมูล
Markdown เป็น PDF: โครงสร้างกลายเป็นหน้า
Markdown to PDF (POST /api/v1/convert/markdown/pdf) รับไฟล์ .md หรือ ZIP ที่มี Markdown การอัปโหลดที่ไม่ใช่ Markdown และไม่ใช่ ZIP จะถูกปฏิเสธ ส่วนอินพุต .md ธรรมดาต้องเป็น UTF-8 ไปป์ไลน์จะเรนเดอร์ Markdown เป็น HTML โดยเปิดใช้ตาราง ขีดฆ่า และรายการงาน แล้วห่อ HTML นั้นด้วย CSS ที่มุ่งไปทางการพิมพ์ (รวมสแตกฟอนต์หลายสคริปต์ และ RTL เมื่อตรวจพบภาษาอาหรับ) จากนั้นจึงพิมพ์เป็น PDF ด้วย WeasyPrint
สิ่งที่มักรอด:
- หัวเรื่อง ย่อหน้า รายการ และตาราง Markdown ง่าย ๆ
- ข้อความหลายสคริปต์ที่เส้นทาง HTML จัดวางได้ (CJK ละติน และสคริปต์อื่นที่ CSS สำหรับพิมพ์ครอบคลุม)
- PDF ที่พิมพ์และแชร์ได้สำหรับเวิร์กโฟลว์ docs-as-code
สิ่งที่มักไม่รอด:
- ฟอนต์ธีมของตัวแก้ไขคุณที่จะตรงกันเสมอในทุกโปรแกรมอ่าน
- การขึ้นบรรทัดบนจอที่เหมือนเป๊ะกับไฟล์
.md - ฟีเจอร์ Markdown แบบโต้ตอบที่ไม่มีอะไรเทียบเท่าใน PDF (เช็กบ็อกซ์สด ส่วนที่พับได้ ลิงก์วิกิ)
อินพุตแบบ ZIP มีไว้แพ็ก Markdown พร้อมแอสเซตที่เส้นทาง HTML แก้ที่อยู่ข้างเอกสารได้ ให้ถือเป็นความสะดวกในการแพ็ก ไม่ใช่การรับประกันว่าภาพหรือ CSS ทุกอันจะดูเหมือนกันในทุกโปรแกรมอ่าน
PDF เป็น Markdown: เลเยอร์ข้อความเข้า Markdown ออก
PDF to Markdown (POST /api/v1/convert/pdf/markdown) ดึงเนื้อหาข้อความออกมาเป็น Markdown ผ่าน pdf-inspector การตอบกลับเป็น text/markdown และดาวน์โหลดเป็นไฟล์ .md PDF แบบ born-digital ที่มีเลเยอร์ข้อความสะอาดจะแปลงได้ดีที่สุด ส่วนหน้าสแกนที่ไม่มีเลเยอร์ข้อความจะได้ Markdown ว่างหรือใช้งานไม่ได้ จนกว่าจะ OCR ก่อน และ OCR บนไซต์นี้ก็คืน Markdown เช่นกัน ไม่ใช่เลเยอร์ PDF ที่ค้นหาได้
สิ่งที่ควรคาดหวัง:
- หัวเรื่องและย่อหน้าเมื่อฮิวริสติกเรื่องขนาดฟอนต์ทำงานถูก (คุณอาจยังต้องเรียงระดับ
#ใหม่ด้วยมือ) - ตารางกลายเป็นตาราง Markdown เมื่อการรู้จำทำงาน ส่วนเลย์เอาต์หลายคอลัมน์อาจเรียงเป็นลำดับการอ่านอื่น
- หัวและท้ายที่ซ้ำทุกหน้า (ต้องตัดภายหลัง)
- ภาพและสมการที่เป็นภาพไม่กลายเป็นแอสเซตในเครื่องหรือ LaTeX อัตโนมัติ
ถ้าต้องการร้อยแก้วล้วนโดยไม่มีฮิวริสติกเรื่องหัวเรื่อง PDF to Text คือการดึงที่แบนกว่า ส่วนการส่งออกที่คืน HTTP 204 หมายความว่าไม่พบบล็อกแบบคอลัมน์ ดู ส่งออกตารางว่าง (204)
Round trip พิสูจน์อะไรจริง ๆ
| รอดพอสมควร | มักไม่รอด |
|---|---|
| คำ ลำดับชั้นของหัวเรื่อง โครงสร้างรายการ | เรขาคณิตหน้าของภาพแบบพิกเซลเป๊ะ |
| ตารางง่ายในรูปข้อความ | ฟอนต์และเคอร์นิงที่ตรงเป๊ะ |
| ฉบับร่างที่ใช้งานได้สำหรับ Git หรือเอเจนต์ | การแบ่งหน้าที่เหมือนพิมพ์เป๊ะ |
การ round-trip สองครั้งจะเริ่มคลาดเคลื่อน Markdown→PDF ไหลใหม่ผ่าน WeasyPrint ส่วน PDF→Markdown สร้างโครงสร้างขึ้นใหม่จากฮิวริสติกของการดึง ไม่มีขั้นตอนใดเก็บตัวกลางแบบไม่สูญเสียของโมเดลเลย์เอาต์ของอีกรูปแบบหนึ่ง
เลือกทิศทางหลัก
ถ้าต้องการเลย์เอาต์สำหรับพิมพ์เป็นระบบบันทึก ให้เก็บ PDF ไว้ และถือ Markdown เป็นการส่งออกหรือฟีดให้เอเจนต์ ถ้าต้องการ diff การรีวิวโค้ด และการกลืนข้อมูลของเอเจนต์ ให้ใช้ Markdown เป็นหลักและถือ PDF เป็นขั้นตอนเผยแพร่ อย่าเก็บทั้งสองอย่างเป็น “แหล่งความจริง” ที่เท่ากันแล้วหวังว่าจะเหมือนกันหลังแก้ไข
ลูป docs-as-code ที่ใช้ได้จริง: แก้ Markdown ใน Git → Markdown to PDF เพื่อได้อาร์ติแฟกต์สำหรับแชร์ → หลีกเลี่ยง PDF→Markdown→PDF เป็นนิสัยประจำวัน ใช้ PDF→Markdown เมื่อคุณได้ PDF แบบ born-digital มาและต้องการข้อความให้เอเจนต์ แล้วถือ Markdown นั้นเป็นฉบับร่างใหม่ ไม่ใช่การรับประกันการแบ่งหน้าเดิม
ไฟล์ที่เข้ารหัสต้อง Unlock อย่างได้รับอนุญาตก่อนการแปลงใด ๆ ส่วนไฟล์เสียที่ parse ไม่ได้ควรผ่าน Get Info / Repair ก่อน เอนด์พอยต์เดียวกันผ่าน HTTP: Developers