2 คะแนน โดย GN⁺ 2026-04-29 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ผสานความสามารถด้าน การจัดเอกสารบนพื้นฐาน Markdown เข้ากับงานจัดพิมพ์ระดับ LaTeX ทำให้สร้างได้ครบในเครื่องมือเดียวตั้งแต่งานวิจัย หนังสือ งานนำเสนอ เว็บไซต์แบบสแตติก ไปจนถึงฐานความรู้
  • ภายใน ไวยากรณ์ที่ลด boilerplate สามารถใส่องค์ประกอบอย่างผู้เขียน ระยะขอบ บทคัดย่อ รูปภาพ และคำคมได้โดยตรง จึงเขียนทั้งเนื้อหาและเลย์เอาต์ไปพร้อมกันได้
  • สลับประเภทเอกสาร paged, plain, docs, slides ได้ด้วยการตั้งค่า .doctype เพียงบรรทัดเดียว และยังรองรับงานนำเสนอแบบอินเทอร์แอ็กทีฟ
  • มี การคอมไพล์ที่รวดเร็วและไลฟ์พรีวิว พร้อมสคริปต์แบบ Turing complete ที่ช่วยลดงานเลย์เอาต์ซ้ำ ๆ ด้วยการนำฟังก์ชันและอาร์กิวเมนต์กลับมาใช้ซ้ำ
  • ให้ใช้งานฟรีและเป็น โอเพนซอร์ส โดยคอมไพเลอร์ยังคงพัฒนาอย่างต่อเนื่องและดูแลในฐานะซอฟต์แวร์เสรี

การเปลี่ยนแปลงในรุ่น 2.0.0 : เปิดตัวเมื่อ 23 เมษายน 2026

  • เอาต์พุต HTML เปลี่ยนเป็นออฟไลน์เต็มรูปแบบ ทำให้ปัญหาสไตล์เพี้ยนและฟังก์ชันขาดหายจากการพึ่งพา CDN และ Google Fonts ลดลงอย่างมาก
  • เพิ่ม ระบบสิทธิ์ ใหม่ ทำให้ควบคุมขอบเขตที่เอกสารเข้าถึงได้ระหว่างคอมไพล์ด้วย --allow, --deny และหากไม่มีสิทธิ์จะเกิดข้อผิดพลาดทันที จึงปลอดภัยยิ่งขึ้น
  • ไดเรกทอรีเอาต์พุตเริ่มต้นเปลี่ยนจาก ./output เป็น ./quarkdown-output ดังนั้นเวิร์กโฟลว์เดิมที่อิงพาธเริ่มต้นเก่าจำเป็นต้องปรับ
  • เมื่อใช้ --preview ชื่อเอาต์พุตเริ่มต้นจะไม่อิง .docname อีกต่อไป แต่เปลี่ยนเป็นรูปแบบ preview-<mainfile>-<hash> ทำให้การพรีวิวมีความเสถียรมากขึ้น
  • มีการนำ การเรนเดอร์แบบขนาน มาใช้ ทำให้เอกสารขนาดใหญ่ประมวลผลองค์ประกอบระดับเดียวกันพร้อมกันได้และช่วยเพิ่มประสิทธิภาพการเรนเดอร์
  • สามารถคัดลอก ไดเรกทอรี public/ ที่อยู่รากโปรเจ็กต์ไปยังรากของผลลัพธ์ HTML ได้โดยตรง ช่วยให้เผยแพร่ robots.txt, CNAME และทรัพยากรสแตติกส่วนกลางได้ง่ายขึ้น
  • ฟังก์ชัน .htmloptions ใหม่สามารถตั้งค่า baseurl เพื่อเพิ่ม canonical link ให้แต่ละหน้าและสร้าง sitemap.xml ได้ จึงเป็นมิตรต่อเสิร์ชเอนจินมากขึ้น
  • ระหว่างคอมไพล์ HTML รองรับ สัญลักษณ์พาธราก @ ในลิงก์และรูปภาพ ทำให้อ้างอิงทรัพยากรส่วนกลางได้สม่ำเสมอจากทุกซับเอกสาร
  • เพิ่ม primitive function .image ใหม่ ที่ควบคุมขนาด คำบรรยาย และการใช้พาธสัมพัทธ์แบบคงที่ได้ละเอียดขึ้น และเข้ากันได้ดีกับการใช้ทรัพยากรใน public/
  • รองรับ ลิงก์อ้างอิงข้ามสำหรับองค์ประกอบที่อ้างอิงได้ทั้งหมด ทำให้คลิกไปยังรูป ตาราง โค้ดบล็อก สมการ และบล็อกลำดับเลขแบบกำหนดเองได้
  • ชื่อโมดูลมาตรฐานไลบรารี Injection เปลี่ยนเป็น Html ดังนั้นเอกสารหรือโค้ดอ้างอิงเดิมจำเป็นต้องแก้ไข
  • ยังแก้ปัญหาแสงวาบสีขาวในไลฟ์พรีวิวธีมมืดและปัญหา ลิงก์วิกิ Quarkdoc ไปพร้อมกัน ทำให้ประสบการณ์ใช้งานดีขึ้น

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

 
GN⁺ 2026-04-29
ความคิดเห็นจาก Hacker News
  • พูดตามตรงก็น่าประทับใจอยู่ แต่สำหรับผม แก่นของ Markdown คือความเรียบง่ายสุดขีด
    แก้ไขได้โดยไม่ต้องมี GUI จะเขียนใน VIM บนเทอร์มินัลก็ยังพอเดาได้ว่าผลลัพธ์จะออกมาประมาณไหน และไฟล์ .md แบบ raw เองก็อ่านได้สบาย
    แต่พอเริ่มใส่ฟีเจอร์เพิ่มเข้าไปเรื่อย ๆ ก็ต้องคอยไปค้นหาคำสั่งแปลก ๆ สุดท้ายก็จำไม่ได้ และถ้าไม่เรนเดอร์ก็ไม่มั่นใจด้วยว่าหน้าตาจะเป็นอย่างไร จนเริ่มอยากได้ตัวแก้ไขแบบ WYSIWYG
    มันดูคล้ายแนวคิดที่อยากยัดทั้งอักษรซีริลลิก เทวนาครี จีน อาหรับ ลงไปในคีย์บอร์ด QWERTY แล้วสุดท้ายความรู้สึกก็เหมือนกลับไปพิมพ์แบบ hunt and peck อีกครั้ง

    • สำหรับผม จุดเด่นใหญ่ข้อหนึ่งของ Markdown คือมันเป็น WYSIWYG แบบครึ่ง ๆ
      ไวยากรณ์พื้นฐานเอาวิธีที่คนใช้เลียนแบบการจัดรูปแบบในข้อความมาใช้ต่อ ทำให้ตัวอินพุตเองโดยมากก็ยังอ่านง่ายอยู่แล้ว
      ต่อให้ไม่รู้วิธีเขียน Markdown แบบเป๊ะ ๆ ส่วนใหญ่ก็ยังอ่านได้ไม่มีปัญหา ตารางก็ดูเป็นตาราง ย่อหน้าก็ดูเป็นย่อหน้า
      บางทีก็ต้องกลับไปเปิดดูไวยากรณ์ใหม่บ้าง แต่ก็ไม่เป็นไร คำศัพท์ที่เข้าใจได้เวลาอ่านมีมากกว่าคำศัพท์ที่ใช้ได้เองเป็นเรื่องปกติ
      เพราะงั้นผมมักตัดสินจากความอ่านง่ายของต้นฉบับที่พิมพ์เข้าไป ซึ่งหลายอย่างที่โชว์ไว้ที่นี่ดูแล้วไม่ได้มีข้อได้เปรียบเสียเปรียบมากนักตามเกณฑ์นั้น
      แต่ผมยังไม่ได้เห็นตัวอย่างการจัดรูปแบบสมการ และกรณีไม่กี่ครั้งที่ผมใช้ LaTeX ก็มักเป็นเพราะสมการคณิตศาสตร์ที่ Markdown ทำไม่ได้อยู่แล้ว เลยอยากรู้ว่าส่วนนั้นหน้าตาจริง ๆ เป็นอย่างไร
    • ข้อโต้แย้งนั้นฟังขึ้นมาก
      ถึงอย่างนั้น Quarkdown ก็ดูเป็นตัวแทนที่เหนือกว่าการพิมพ์ LaTeX ตรง ๆ อย่างชัดเจน และก็ดูน่าจะให้ผลลัพธ์ที่คาดเดาได้มากกว่า พร้อมทั้งเข้ากับการแก้ไขโดยมี LLM ช่วยได้ดีกว่า GUI editor แบบ Word
    • ก็แค่สร้าง Quarkdown ที่เก่งกว่านี้โดยไม่ต้องท่องคำสั่งใหม่ประหลาด ๆ แถมมี UI/UX ลื่น ๆ
      ชื่อมันก็คือ Microsoft Word ไง
    • ผมเองก็กำลังทำ Markdown renderer ตัวเล็ก ๆ อยู่ แค่ตั้งชื่อก็ยากแล้ว และต่อให้เสร็จ การทำให้คนใช้ยิ่งยากกว่า
      ทุกวันนี้แค่ตัวแก้ไข "plain markdown" ธรรมดา ๆ มันเด่นได้ยาก และถ้าจะไปถึงหน้าแรก HN สุดท้ายก็ดูเหมือนต้องมีทั้งฟังก์ชันการทำงานและความสมบูรณ์ที่เกินกว่า Markdown ทั่วไป
      มันให้ความรู้สึกเหมือนการคัดเลือกโดยธรรมชาติ
    • Obsidian.md เป็น WYSIWYG editor สำหรับ Markdown พื้นฐานที่ยอดเยี่ยมมาก
  • น่าจะดีถ้ามีข้อมูลที่เปรียบเทียบเครื่องมือและภาษา markup พวกนี้ในที่เดียว
    อยากเห็น MyST, Pandoc, Quarkdown, Quarto, Typst วางเทียบกันไปเลย
    Quarto กับ Pandoc ใช้ Pandoc Markdown และ https://www.zettlr.com/ ก็เหมือนกัน
    ส่วน Quarkdown กับ Typst จะให้ความรู้สึกใกล้กับ ภาษา markup แบบ programmable ทางฝั่ง LaTeX หรือ HTML+Javascript มากกว่า เลยดูเหมือนว่ายังไม่ชัดว่าใครจะเป็น ผู้สืบทอดของ LaTeX ตัวจริง

    • ผมลองใช้มาส่วนใหญ่แล้วและก็คิดว่าจะใช้ต่อไป โดยคร่าว ๆ แบ่งได้แบบนี้
      Markdown ก็เหมือน .txt ที่โรย syntactic sugar เพิ่มนิดหน่อยและส่งออกเป็น PDF หรือ HTML ได้
      Quarto คือ Markdown สำหรับคนที่อยากรัน code block
      ส่วน Typst คือ LaTeX ที่ทำใหม่ให้ทันสมัยขึ้น ลดของจุกจิกไป 90% แต่ก็เหมือนหายความสามารถไปราว 10% ด้วย
      วงการวิชาการเดิมทีก็ไม่ค่อยชอบของใหม่อยู่แล้ว ต่อให้ใช้ Typst ก็น่าจะยังไม่ค่อยถูกใจพวกเขา
      Pandoc สุดท้ายก็คือเครื่องมือสำหรับส่งออกไปเป็นฟอร์แมตต่าง ๆ อย่าง PDF, HTML และอื่น ๆ
      โดยมากก็มองออกเร็วว่าเครื่องมือที่ต้องใช้คือฝั่งไหน และถึงจะมีอย่าง asciidoc ด้วย แต่ถ้าลองคิดว่ามีพื้นที่ไหนที่ชุด markdown/quarto/typst ครอบไม่ถึง ก็มีไม่มากนัก
      ที่เหลือจริง ๆ ก็คงเป็นพวก WYSIWYG editor
    • รายการเปรียบเทียบน่าจะใส่ djot ด้วย
      มันดูเหมือน superset ของ Markdown ที่ออกแบบมาดีและค่อนข้างรอบคอบ
      https://djot.net/
    • ผมอยากจะชอบ Typst มาก ๆ
      ถ้าเลิกใช้ LaTeX ได้จริงก็คงดีที่สุด แต่พอเอาไปใช้กับโปรเจ็กต์จริงกลับเจอ corner case เยอะเกินไป สุดท้ายเลยกลับไปหา LaTeX อีก
      มีทั้งส่วนที่ขาดเมื่อเทียบกับ LaTeX และเรื่องความสามารถในการแปลงผ่าน Pandocที่ยังไม่พอด้วย
      หวังจริง ๆ ว่าจะเติม 10% สุดท้ายนั้นได้
    • ถ้าหมายถึงการเปรียบเทียบแบบนี้ ก็มีอยู่แล้ว
      https://github.com/iamgio/quarkdown#comparison
    • Pandoc อยู่คนละชั้นกับเครื่องมืออื่น
      มันสามารถใส่ฟิลเตอร์อะไรก็ได้กับ JSON format ขั้นกลาง ทำให้แทบจะสร้างการแปลงแบบไหนก็ได้ตามต้องการ และยังแปลงฟอร์แมตต่าง ๆ ไปเป็น JSON นั้นหรือย้อนกลับได้ด้วย
      เพราะงั้นผมเลยชอบระบบที่อิง Pandoc และหลายครั้งสิ่งที่เครื่องมือพื้นฐานทำไม่ได้ก็แก้ได้ด้วย inline filter ง่าย ๆ
  • ตามแบบจำลองมาตรฐานของซอฟต์แวร์ฟิสิกส์ ถ้าแก้ไข Quarkdown ใน Atom มันจะกลายเป็น Quarkup และต้องเปลี่ยน Neutron Mail เป็น Proton Mail
    แต่จะใช้ได้ก็ต่อเมื่อคุณพิมพ์ด้วยมือซ้ายพร้อมสร้างแอป Electron และเขียน anti-Neutrinos AI blogpost ไปด้วยเท่านั้น

  • ถ้าให้วิจารณ์สั้น ๆ ของผม มันใกล้เคียงกับ Markdown ที่ใส่ แมโครสไตล์ LaTeX มากกว่า
    เพียงแต่ที่นี่เรียกมันว่าฟังก์ชัน ซึ่งก็น่าจะเพราะอย่างน้อยมีฟังก์ชันหนึ่งที่มี side effect นั่นคือฟังก์ชันที่ใช้สร้างฟังก์ชันใหม่
    ผมชอบความบริสุทธิ์ทางไวยากรณ์แบบ "ทุกอย่างคือฟังก์ชัน" แต่การเอาโครงสร้างและการจัดสไตล์มาผสมกันอย่างเป็นธรรมชาติแบบ HTML/CSS ก็ทำให้รู้สึกก้ำกึ่งนิดหน่อย แน่นอนว่าเส้นแบ่งนั้นเดิมทีก็พร่าอยู่แล้ว
    ถึงอย่างนั้นมันก็ค่อนข้างเท่ และผมก็เข้าใจว่าทำไมคนถึงตอบสนองแบบกังขากับความพยายามเปลี่ยน Markdown ครั้งใหญ่
    คำวิจารณ์ที่ว่าถ้าใช้ฟังก์ชันมากเกินไปจะทำให้อ่านต้นฉบับยากขึ้นก็ถูกต้อง และบางครั้งความไม่สมบูรณ์แบบทัวริงก็อาจเป็นข้อดีได้
    แต่ถ้ามองแค่ในฐานะการออกแบบที่เพิ่มฟังก์ชันให้ Markdown ผมว่ามันเป็นงานออกแบบที่สะอาดตาทีเดียว

  • ผมคือผู้สร้างและหัวหน้าโปรเจ็กต์ของ Quarkdown
    ตอนแรกมันเริ่มจากโปรเจ็กต์วิจัยในมหาวิทยาลัย และผมก็ไม่เคยนึกเลยว่าอีก 2 ปีต่อมามันจะกลายมาเป็นแบบนี้
    ขอบคุณที่สนใจนะครับ แล้วผมจะพยายามตอบคอมเมนต์ให้ได้มากที่สุด

    • สงสัยว่าใน v3 มีแผนจะ "แก้" ไวยากรณ์ตัวหนา ไหม
      ผมคิดมาตลอดว่า *bold* กับ _italic_ ดูเข้าท่ากว่า **bold** และ *italic*
      เครื่องหมายดอกจันที่เพิ่มมาอีกตัวใน Markdown ออกแบบไม่ค่อยดีนัก โดยเฉพาะเวลาแก้ไข Markdown บนมือถือหรือแท็บเล็ตมันค่อนข้างไม่สะดวก
    • แนวคิดเรื่องใส่ฟังก์ชันลงในฟอร์แมตข้อความให้ความรู้สึกแปลกใหม่พอสมควร
      แม้แต่ในเอกสาร GUI คนก็มักพยายามเลี่ยงแมโครอยู่แล้ว เลยสงสัยว่าเดิมที Quarkdown ถูกออกแบบมาสำหรับเอกสารที่ซับซ้อนและทำซ้ำเยอะหรือเปล่า
      ขอบคุณที่เปิดรับคำถามนะ
    • ผมลองอ่าน https://iamgio.eu/2025-12-10-accidentally-in-silicon-valley/ แล้ว ดีใจที่ดูเหมือนทุกอย่างจะไปได้สวย
  • ผมลองไล่อ่านเอกสารดูแล้วก็แอบกังวลนิดหน่อยว่าโมเดลการประเมินผลจะเหมาะกับงานนี้หรือไม่
    การจัดวางข้อความปกติแล้วพอปรับส่วนหนึ่ง ตำแหน่งของส่วนอื่นก็มักพังตาม ต้องรัน layout pass ใหม่อีก จึงต้องมีโครงสร้างที่วนซ้ำจนถึงจุดคงตัว
    Typst มีแนวคิด context สำหรับเรื่องนี้ https://typst.app/docs/reference/context/ แต่ใน Quarkdown ผมยังไม่เห็นอะไรคล้ายกัน อาจเป็นเพราะผมมองข้ามไป
    ตอนทำหนังสือ ผมย้ายจากชุด pandoc/md/LaTeX ไปเป็น Typst และก็ค่อนข้างพอใจ
    ความรู้สึกที่ได้เขียนโปรแกรมด้วยภาษาสมัยใหม่มันดี และความเร็วก็สูงกว่า pandoc+LaTeX มาก
    https://functionalprogrammingstrategies.com/

  • ถ้ามองจากฝั่ง AsciiDoc ไวยากรณ์ของ Quarkdown ก็ดูสะอาดดี โดยเฉพาะ ฟังก์ชันที่ผู้ใช้กำหนดเอง
    แต่ผมรู้สึกว่าสิ่งที่ยากกว่าในสายนี้ไม่ใช่ตัวภาษาต้นทางเองเท่าไร แต่เป็นpipeline ฝั่งเอาต์พุตมากกว่า
    ส่วนขยายของ Markdown อย่าง cross-reference, admonition, conditional content, การ reuse แบบใช้ฟังก์ชันนั้นในเชิงการออกแบบจัดการได้อยู่แล้ว
    กำแพงจริงอยู่ถัดจากนั้น เช่น tagged PDF ที่ผ่านมาตรฐาน PDF/UA, deterministic build ที่ไม่สั่นคลอนแม้อยู่คนละสภาพแวดล้อม, hreflang และ cross-document linking สำหรับไซต์เอกสารหลายภาษา, หรือ incremental rebuild ที่ยังไหวแม้หนังสือยาว 500 หน้า
    โดยเฉพาะใน EU หลังวันที่ 28 มิถุนายน 2025 ที่ European Accessibility Act มีผลบังคับใช้ ความสำคัญของ PDF/UA ก็ยิ่งสูงขึ้น
    เลยอยากรู้ว่ามีแผนจะพา doctype ทั้งสี่แบบ โดยเฉพาะฝั่ง paged ไปทางไหน

  • ในตารางเปรียบเทียบควรใส่ MyST ด้วย
    https://mystmd.org/
    ฝั่งนี้ดูมีโอกาสจะกลายเป็น มาตรฐาน Markdown ใหม่ในอนาคตก็ได้

    • หรือจะใส่ Typst ด้วยก็ได้
      แม้จะไม่ใช่ส่วนขยายของ Markdown แต่เป้าหมายกับกรณีใช้งานค่อนข้างคล้ายกัน
    • ชุด MyST + Sphinx ดีมาก
      แต่ก็น่าเสียดายที่การรองรับ LSPยังไม่แข็งแรง อย่างน้อยผมก็ทำให้มันทำงานดี ๆ ใน helix ไม่สำเร็จ
      บล็อกของผมเองก็ทำด้วย pydata-sphinx-theme กับ myst
    • ผมไม่ค่อยรู้จักฝั่งนั้นเท่าไร
      ถ้าอยากก็ส่ง PR มาอัปเดตตารางเองได้เลย
  • ในแอปของผม ผมเลือกแนวทางที่ต่างออกไปเล็กน้อย
    ผมโฟกัสที่ความอ่านง่ายและการจัดการกับ ไดอะแกรม Mermaid ขนาดใหญ่ให้สะดวก และช่วงหลังยังเพิ่มโหมดเต็มจอที่ท่องดูได้เหมือนแผนที่ด้วย
    https://mdview.io/s/97af684b

  • เวลาใช้ SSG ผมมักชอบเก็บอินพุตให้เป็น Markdown ที่สะอาดที่สุด แล้วโยนรายละเอียดเรื่องการจัดรูปแบบไปไว้ที่ CSS แทน
    ตัวอย่างเช่นไม่จำเป็นต้องใส่อะไรอย่าง .abstract ก็ได้ แค่ทำให้ CSS จัดย่อหน้าแรกให้เป็น abstract ก็พอ
    แต่โปรเจ็กต์นี้ดูเหมือนจะเดินไปทางการสร้างเอกสารแบบพึ่งพาตัวเองได้มากขึ้น
    มันไม่มี CSS แต่มีตัวเลือกการจัดสไตล์ที่เตรียมไว้ล่วงหน้าเยอะ เลยทำให้นึกถึง HTML ยุคแรก ๆ อยู่เรื่อย
    HTML 1 ไม่มีสีและแทบไม่มีการจัดรูปแบบ จึงคล้าย Markdown แต่พอถึงประมาณ HTML 3 ก็เริ่มใส่นั่นใส่นี่เยอะขึ้น ซึ่งโปรเจ็กต์นี้ก็ดูคล้ายพัฒนาการแบบนั้น