GNU Unifont

• แบบอักษรเสรีที่มี glyph (รูปทรงตัวอักษร) สำหรับอักขระ Unicode ทั่วโลก และเป็นแบบอักษรสาธารณะที่ดูแลในฐานะส่วนหนึ่งของ โครงการ GNU
• ตั้งแต่เวอร์ชัน 15.1.01 เป็นต้นมา มีการนำ encoding แบบประกอบใหม่ (วิธี 6/3/1) มาใช้จากผลงานของ Minseo Lee และ Ho-Seok Ee เพื่อปรับใช้ระบบ glyph ภาษาเกาหลีที่ดีขึ้น
• ในเวอร์ชันล่าสุด 17.0.03 ได้มีการแก้ไขและเพิ่ม glyph จำนวนมากสำหรับอักษรจีน/ญี่ปุ่นแบบฮัน, อาหรับ, สัญลักษณ์ดนตรี และอื่น ๆ
• รองรับ BMP (Basic Multilingual Plane) ทั้งหมด 65,536 code point และกำลังขยายไปยังพื้นที่ SMP (Supplementary Multilingual Plane) และ CSUR (ConScript Unicode Registry) อย่างต่อเนื่อง
• เผยแพร่ภายใต้ dual license คือ GNU GPLv2+ พร้อมข้อยกเว้นการฝังฟอนต์ และ SIL Open Font License 1.1 จึงสามารถใช้งานในซอฟต์แวร์เชิงพาณิชย์ได้อย่างเสรี
• เป็นโครงการฟอนต์ Unicode โอเพนซอร์สตัวแทนที่มีเป้าหมาย ครอบคลุมระบบอักษรทั่วโลกอย่างสมบูรณ์

---

ภาพรวมของ GNU Unifont

• GNU Unifont เป็นแบบอักษรที่มี glyph สำหรับ ทุก code point ของ Unicode ที่พิมพ์ได้ และได้รับการดูแลในฐานะส่วนหนึ่งของโครงการ GNU
  • รองรับ Basic Multilingual Plane (BMP, U+0000~U+FFFF) อย่างสมบูรณ์
  • และยังขยายครอบคลุม Supplementary Multilingual Plane (SMP, U+010000~U+01FFFF) รวมถึงพื้นที่ CSUR/Under-CSUR อย่างต่อเนื่อง
• สามารถใช้งานในซอฟต์แวร์เชิงพาณิชย์ได้ แต่ฟอนต์ดัดแปลงต้องเผยแพร่ภายใต้สัญญาอนุญาตเดียวกัน
  • สัญญาอนุญาตคือ GNU GPLv2+ (พร้อมข้อยกเว้นการฝังฟอนต์) และ SIL Open Font License 1.1
  • การเปิดเผยฟอนต์ดัดแปลงช่วยรับประกันประโยชน์สาธารณะ

ลิขสิทธิ์และสัญญาอนุญาต

• glyph หลายพันรายการเป็น ผลงานสร้างสรรค์ของผู้มีส่วนร่วมแต่ละราย และได้รับความคุ้มครองตามกฎหมายลิขสิทธิ์ของแต่ละประเทศ
  • บางส่วนเป็นรูปแบบตัวอักษรเดิม ขณะที่บางส่วนเป็น การออกแบบไอคอนและสัญลักษณ์ ซึ่งได้รับการคุ้มครองในระดับสากลที่สูงกว่า
• มีการเผยแพร่บันทึกทางกฎหมายที่เกี่ยวข้องกับกฎหมายลิขสิทธิ์ของเยอรมนี
• ตั้งแต่ Unifont 13.0.04 เป็นต้นมา มีการเผยแพร่ภายใต้ GPL 2+ / SIL OFL 1.1 แบบ dual license
  • การฝังแบบอักษร (embed) ลงในเอกสารไม่ถือเป็นการละเมิด GPL

ดาวน์โหลดและรูปแบบของฟอนต์

• มีทั้งชุด build มาตรฐานและ เวอร์ชันที่รวม glyph ของ CSUR/Under-CSUR PUA
  • รองรับหลายรูปแบบ เช่น OpenType(.otf) , PCF, BDF, PSF, HEX
  • ติดตั้งได้บน Windows และ macOS โดยบน macOS Terminal ต้องเปิดตัวเลือก Antialias เพื่อให้อ่านได้ชัดเจน
• เอนจินเรนเดอร์บางตัวอาจมองข้ามข้อมูลระยะห่างระหว่าง glyph ทำให้ เอนจินที่รองรับเฉพาะ monospace อาจแสดงผลผิดพลาดได้

ข้อจำกัดของ Unifont

• เก็บ เพียงหนึ่ง glyph ต่อหนึ่ง code point ที่พิมพ์ได้
  • อักษรตระกูลอินเดีย (เช่น เทวนาครี เบงกาลี ทมิฬ) หรือ อักษรที่รูปทรงเปลี่ยนตามตำแหน่ง (เช่น อาหรับ) จึงอาจไม่ถูกเรนเดอร์ได้อย่างแม่นยำ
  • สำหรับสคริปต์ที่ซับซ้อน แนะนำให้ใช้ ฟอนต์ OpenType เฉพาะทาง

การร่วมสร้าง glyph ใหม่

• หากต้องการเพิ่ม glyph ใหม่ ต้อง ติดต่อทางอีเมลล่วงหน้า
  • เพื่อหลีกเลี่ยงงานซ้ำซ้อน จึงควรหารือก่อนเข้าร่วม
• glyph ฮันจาขนาด 15×16 พิกเซล (Plane 2, 3) ที่รัฐบาลจีนถือครองลิขสิทธิ์ ไม่สามารถรวมไว้ในฟอนต์เสรีได้

รุ่นล่าสุด — Unifont 17.0

• เวอร์ชัน 17.0.03 วันที่ 1 พฤศจิกายน 2025
  • แก้ไขอักษรฮั่นมากกว่า 100 รายการ รวมถึงอักษรที่มีราก ‘馬(ม้า)’ และ ‘鳥(นก)’
  • สะท้อน รายการมาตรฐานอักษรจีนตัวย่อ ระหว่างปี 1935~2013
  • รวม มาตรฐานรากอักษรสำหรับการใช้งานสมัยใหม่ ที่ประกาศในปี 2009
• เวอร์ชัน 17.0.02 วันที่ 18 ตุลาคม 2025
  • มีผู้ร่วมพัฒนาหลายรายใน Plane 0~3 เช่น Paul Hardy, David Corbett, Xiaoxiao Akatsuki, Boris Zhang
  • แก้ไขจำนวนมากในอาหรับ สัญลักษณ์หมากรุก CJK extensions และอื่น ๆ
• เวอร์ชัน 17.0.01 วันที่ 9 กันยายน 2025
  • เพิ่ม Arabic Extended-B, สัญลักษณ์สกุลเงิน, อักษร Telugu และ Kannada เป็นต้น
  • เพิ่มสคริปต์จำนวนมากใน Plane 1~3 เช่น Arabic Extended-C, Sidetic, Tolong Siki, Beria Erfe, Adlam

เวอร์ชันสำคัญก่อนหน้า

• Unifont 16.0 (ครึ่งแรกของปี 2025)
  • แก้ไขจำนวนมากในอาหรับ กรีก เกาหลี สัญลักษณ์ดนตรี และอื่น ๆ
  • เพิ่มสคริปต์ CSUR เช่น Sitelen Pona และ Zbalermorna
• Unifont 15.1 (ปี 2024)
  • นำ Johab encoding แบบฮันกึล 6/3/1 ของ Ho-seok Ee มาใช้
  • เปลี่ยน build หลักจาก TrueType เป็น OpenType
  • ปรับปรุงครั้งใหญ่สำหรับ ฮันกึล, CJK extensions และ glyph ของ Wen Quan Yi

ความครอบคลุมของ glyph

• รองรับ Unicode plane อย่างกว้างขวางตั้งแต่ Plane 0~3, Plane 14 และ Plane 15
  • Plane 0: Basic Multilingual Plane (ครอบคลุมอักษรหลักทั้งหมดอย่างสมบูรณ์)
  • Plane 1: Supplementary Multilingual Plane (สัญลักษณ์ดนตรี อักษรภาพ อักษรโบราณ ฯลฯ)
  • Plane 2~3: อักษร CJK extension
  • Plane 14: tag และ variation selector
  • Plane 15: พื้นที่ส่วนตัว CSUR/Under-CSUR

สคริปต์ CSUR และ UCSUR

• เช่น Tengwar, Cirth, Aurebesh, Klingon, Sitelen Pona, Sadalian
  • รวมอักษรประดิษฐ์ (conlang script) หลากหลายประเภท
  • บางส่วนยังถูกระบุว่าไม่สมบูรณ์

รูปแบบญี่ปุ่นและจีน

• มีเวอร์ชัน unifont_jp ที่รองรับมาตรฐาน JIS X 0213 อย่างสมบูรณ์
  • ช่วงแรกใช้ Jiskan16 ก่อนจะเปลี่ยนเป็น glyph สาธารณะของ Izumi16
• เวอร์ชันภาษาจีนครอบคลุม ตารางอักษรมาตรฐานทั่วไป อย่างครบถ้วน
  • อ้างอิงจาก glyph สาธารณะของโครงการ Wen Quan Yi(文泉驛)

รายละเอียดทางเทคนิค

• การแปลงเป็น TrueType อ้างอิงจากสคริปต์ของ Luis Alejandro González Miranda
  • ทำกระบวนการแปลง .hex → .sfd → .ttf แบบอัตโนมัติ
• ใช้ กริด 16×16 พิกเซล เป็นพื้นฐาน และมีแผนรองรับ glyph ขนาด 32×32 พิกเซล ในอนาคต

แผนในอนาคต

• glyph ขนาด 16×16 พิกเซลใน SMP ทั้งหมดเสร็จสมบูรณ์แล้ว
• สคริปต์ที่ซับซ้อน เช่น Tangut จะถูกสร้างในขนาด 32×32 พิกเซลในอนาคต
• ยังดำเนินการ เพิ่มสคริปต์ CSUR อย่างต่อเนื่อง
• ผลงานใหม่ทั้งหมดต้องเผยแพร่ภายใต้เงื่อนไข GPL 2+ / SIL OFL 1.1

ความสำคัญของโครงการ

• GNU Unifont เป็นฟอนต์เสรีสำคัญที่มีเป้าหมาย ทำให้ระบบอักษรทั่วโลกเข้าถึงได้ในรูปแบบดิจิทัล
• มีบทบาทเป็นโครงสร้างพื้นฐานหลักในด้าน ระบบนิเวศโอเพนซอร์ส, internationalization (i18n), และวิศวกรรมฟอนต์
• เป็นโครงการที่ยกระดับ ความสมบูรณ์ด้านภาพของมาตรฐาน Unicode ผ่านการมีส่วนร่วมของชุมชนอย่างต่อเนื่อง

---

หน้าฟอนต์ภาษาเกาหลีของ Unifont - Hangul(Hangeul) Font

ที่มาและโครงสร้างของฮันกึล

• ฮันกึลถูกประดิษฐ์ขึ้นโดย พระเจ้าเซจงมหาราช ระหว่างปี 1443~1446 และประกาศใช้อย่างเป็นทางการในปี 1446 ผ่าน Hunminjeongeum Haerye
  • จุดประสงค์ของการประดิษฐ์ถูกระบุว่า “เพื่อให้ประชาชนเรียนรู้ได้ง่ายและใช้ได้สะดวกทุกวัน”
  • Haerye เป็นคำอธิบายหลักการสร้างอักษร และฉบับที่ค้นพบระหว่าง สงครามโลกครั้งที่สอง ซึ่งเป็นฉบับเดียวที่เหลืออยู่ยังคงได้รับการเก็บรักษาไว้
• ฮันกึลมี โครงสร้างบล็อกพยางค์ ที่ประกอบด้วยสามองค์ประกอบคือ พยัญชนะต้น, สระ, และพยัญชนะท้าย
  • ตัวอย่าง: “ฮันกึล” ประกอบจากการรวม ‘h + a + n’ และ ‘g + eu + l’
  • สระและกึ่งสระ (y, w) จะถูกวางไว้ทางขวาหรือด้านล่างของพยัญชนะต้น

หลักการสร้างพยัญชนะ

• พยัญชนะเริ่มต้นจาก พยัญชนะพื้นฐานห้าตัว (g, n, m, s, ng) ที่เลียนรูปอวัยวะออกเสียง
  • จากนั้นจึงเพิ่มเส้นขีดจนเกิดเป็นพยัญชนะดั้งเดิม 17 ตัว
  • พยัญชนะบางตัวใช้ รูปพยัญชนะซ้อน เพื่อแสดงการเน้นเสียง
• Compatibility Jamo แบบประกอบก็รวมอยู่ใน Unicode เช่นกัน และ jamo โบราณบางตัวไม่ได้ใช้งานแล้วในปัจจุบัน

หลักการสร้างสระ

• สระมีที่มาจากแนวคิดไตรภาคของ ฟ้า(หยาง), มนุษย์(กลาง), ดิน(หยิน)
  • องค์ประกอบพื้นฐานคือ จุด(arae-a), เส้นแนวนอน(eu), เส้นแนวตั้ง(i)
• เดิมมีสระ 11 ตัว โดย arae-a หายไปจากภาษาเกาหลีมาตรฐานสมัยใหม่แล้ว แต่ยังคงอยู่ใน สำเนียงเชจู
• การรวมสระทำให้เกิด สระประสม (diphthong) และบางรูปไม่ถูกใช้ในฮันกึลสมัยใหม่
• ชุด jamo ของ Unifont Hangul รองรับสระและสระประสมทั้งหมดทั้งแบบโบราณและสมัยใหม่

พื้นที่ฮันกึลใน Unicode

• ฮันกึลรวมอยู่ใน ช่วง Unicode ต่อไปนี้
  • U+1100–U+11FF: Hangul Jamo
  • U+3130–U+318F: Hangul Compatibility Jamo
  • U+A960–U+A97F: Hangul Jamo Extended–A
  • U+AC00–U+D7A3: Hangul Syllables
  • U+D7B0–U+D7FF: Hangul Jamo Extended–B
  • U+FFA0–U+FFDF: Half-width Compatibility Jamo
• การปรับตำแหน่งการผสมของพยัญชนะต้น สระ และพยัญชนะท้าย คือหัวใจของการออกแบบฟอนต์ และ แม้แต่ฟอนต์บิตแมปก็สามารถแสดงพยางค์แบบประกอบได้

ฟอนต์ Johab บน X11 และ Unifont

• ฟอนต์ที่เข้ารหัสแบบ Johab สร้าง glyph พยางค์จากการรวมพยัญชนะต้น สระ และพยัญชนะท้าย
  • ใช้ในเทอร์มินัล Hanterm บนสภาพแวดล้อม Unix X11
• เนื่องจาก ฟอนต์ฟรีสำหรับ Hanterm ไม่เข้ากันกับ GPL ทำให้ Unifont ต้อง สร้าง glyph พยางค์ฮันกึลใหม่ขึ้นเองโดยตรง
  • กระบวนการแปลง: Perl script johab2ucs2.pl → .hex → .bdf
  • ฟอนต์เดิม (เช่น iyagi16, johabg16) ถูกจำกัดด้วย สัญญาอนุญาตสำหรับ Hanterm เท่านั้น
• หลังจากนั้นได้สร้าง ชุด Hangul Syllables ใหม่ ต่อเนื่องหลายปีและรวมเข้าใน Unifont

ผลงานล่าสุดและการปรับปรุง encoding

• Minseo Lee : ในปี 2023 ได้มอบ glyph สมัยใหม่ตามลำดับของ Hanterm และชุดแก้ไข glyph โบราณ
  • ปรับปรุง Perl script และแก้ไขความสอดคล้องของ jamo ภายในช่วง Unicode
• Ho-Seok Ee : เสนอ Johab 6/3/1 encoding
  • ใช้โครงสร้างการประกอบแบบ พยัญชนะต้น 6, สระ 3, พยัญชนะท้าย 1 ทำให้ การสร้าง glyph ง่ายขึ้นกว่าระบบเดิม
  • เสนอให้ย้าย code point ไปยัง Private Use Area(U+E000–U+E8FF)
  • เริ่มใช้วิธี encoding นี้ตั้งแต่ Unifont 15.1.01

บล็อกพยางค์ฮันกึลใน Unicode (U+AC00–U+D7A3)

• ประกอบด้วย glyph พยางค์ทั้งหมด 11,172 รายการ
  • พยัญชนะต้น 19 ตัว (หรือ filler 1 ตัว), สระ 21 ตัว, พยัญชนะท้าย 27 ตัว (หรือไม่มี)
  • สูตรการประกอบ: (19×21)×28 = 11,172
• คำที่ขึ้นต้นด้วยสระจะใช้ พยัญชนะต้น ‘ng (ieung)’ เป็น filler
• ตั้งแต่ Unifont 5.1 เป็นต้นมา กระบวนการสร้างบล็อกพยางค์ใหม่ถูกอธิบายอย่างละเอียดในเอกสาร Generating Hangul Syllables

[joyfui]

นี่แหละตัวจริงของฟอนต์เกาหลีหน้าตาไม่สวยใน Minecraft...

[GN⁺]

ความคิดเห็นจาก Hacker News

• เราใช้ GNU Unifont ในหน้าต่างข้อความและ property browser ของ Solvespace
  มันมีประโยชน์มากเพราะฝังมากับไฟล์ executable โดยตรง ผู้ใช้บางคนใส่อักขระ CJK ลงในแบบออกแบบด้วย และมันก็ใช้งานได้เลยบนทุกแพลตฟอร์ม
  ตอนกำลังดูคำอธิบายรูเจาะใน CAD ก็แปลกใจที่พบว่าสัญลักษณ์ counter-bore และ counter-sink มีอยู่ใน Unifont แล้ว
  เวอร์ชันเว็บสำหรับทดลองดูได้ที่นี่
  • ความเรียบง่ายของเวอร์ชันเว็บนี่เจ๋งมาก Solvespace เป็น โปรแกรม MCAD ที่ฉันชอบที่สุด และเป็นเครื่องมือแรกที่หยิบมาใช้เสมอเวลาต้องทำ jig สำหรับทดสอบ PCB แบบเร็ว ๆ
    ถ้า geometry ไม่ซับซ้อน ประสบการณ์ใช้งานจะลื่นไหลมาก
  • น่าทึ่งที่แค่เลือกฟอนต์ก็ได้ผลลัพธ์เท่ ๆ แบบนี้ แน่นอนว่า Unifont และ Unicode ทั้งหมดคงรวมเวลาของมนุษยชาติไปมหาศาล แต่ฉันชอบแนวคิดที่ว่าแม้แต่ วิศวกร CAD ยุคสำริด ก็ยังเขียนชื่อตัวเองเป็น Linear A ได้โดยไม่มีปัญหา
  • เวอร์ชันเว็บสะอาดตามาก Solvespace แม้ฟีเจอร์จะมีจำกัด แต่ ความยืดหยุ่นและความสนุกในการแสดงข้อกำหนด constraint นั้นโดดเด่นมาก
    สักวันหนึ่งฉันอยากเข้าไปดูโค้ดแล้วแทนที่กล่องโต้ตอบโมดัลที่บอกว่า “ไม่สามารถสร้าง constraint ได้”
• สรุปไว้ให้คนอื่นก็คือ GNU Unifont เป็นฟอนต์แบบบิตแมป
  มันมี glyph แบบคงที่สำหรับทุก code point ใน BMP และยังรวม code point ของบาง plane อื่นด้วย
  จึงมีประโยชน์สำหรับ editor ที่ต้องแก้ไขข้อความ Unicode โดยไม่ต้องมีความรู้เรื่องการเรนเดอร์ตามภาษา
  แต่เมื่อใช้สคริปต์ซับซ้อนอย่าง Devanagari ก็จะไม่มี shaping จึงไม่แสดงผลเหมือนข้อความจริง
  • ตรงนี้ BMP ไม่ได้หมายถึง BitMap แต่หมายถึง Unicode Basic Multilingual Plane หรือพื้นที่ 65,536 code point แรก
  • งั้นก็สงสัยว่ามีไฟล์แยกตามขนาด point แต่ละขนาดหรือเปล่า ยิ่งรู้สึกเลยว่าตัวเองแทบไม่รู้อะไรเกี่ยวกับฟอนต์เลย
• ประโยคแรกของเว็บไซต์นั้นน่าจะ อธิบายก่อนว่ามันคืออะไร ไหม ดูเหมือนจะเป็นฟอนต์ copyleft เดียวที่รวมเกือบทุก Unicode code point
  • จริง ๆ แล้วประโยคที่สองกับสามก็อธิบายได้ตรงมากอยู่แล้ว มันมี glyph สำหรับทุก code point ที่พิมพ์ได้ใน BMP และเหมาะจะเป็น ฟอนต์ทางเลือกสุดท้าย
    คือเอาไว้แสดงอักขระเมื่อฟอนต์อื่นหา glyph ไม่เจอ
  • “เกือบทุก” ก็ไม่ใช่ “ทั้งหมด” ฉันมีโปรเจกต์ที่ต้องเรนเดอร์อักษร CJK หายาก และ Unifont แสดงผลได้ไม่ถูกต้อง
    สุดท้ายเลยใช้ Jigmo ฟอนต์ ซึ่งมี glyph CJK ครบที่สุด
  • ตอนแรกฉันก็งงเหมือนกัน แต่พอกด “Home” ก็ถึงได้รู้ว่าลิงก์นั้นไม่ใช่หน้า landing page
  • มี โปรเจกต์โอเพนซอร์ส จำนวนมากจริง ๆ ที่อธิบายไม่พอในประโยคแรกแบบนี้
  • ฉันคิดว่าประโยค “GNU Unifont เป็นส่วนหนึ่งของโครงการ GNU และมี glyph สำหรับทุก code point ที่พิมพ์ได้ใน BMP” ก็ชัดเจนพอแล้ว
• ตอนพิมพ์ออกมาก็สวยมากจริง ๆ ฉันทำมันเป็น โปสเตอร์แบบเกลียว แล้วแขวนไว้บนผนัง
  The Mostly Complete Unicode Spiral
  • สวยมาก! อยากรู้ว่าพิมพ์ออกมาขนาดไหน แล้ว ตัวอักษรจีนที่กระจายห่าง ๆ รอบเกลียวหลักนั้นเป็นการจัดวางตามธรรมชาติของ Unicode หรือจงใจจัดองค์ประกอบ?
    ทั้งหมดดูเหมือนกาแล็กซีมาก และการที่อีโมจิเรียงอยู่ขอบนอกก็น่าประทับใจ สนุกดีที่ได้ลองหาอีโมจิโลก
• Unifont เก็บแค่หนึ่ง glyph ต่อหนึ่ง code point
  ดังนั้น สคริปต์ซับซ้อน เช่น Indic หรือ Arabic จึงเรนเดอร์ได้ไม่ถูกต้อง
  ในกรณีแบบนี้ต้องใช้ฟอนต์ OpenType และ Unifont ก็เหมาะเป็นเพียง ฟอนต์ fallback เท่านั้น
• เว็บไซต์ฟอนต์มักมีภาพพรีวิวแบบ type specimen เช่น “Hello World” ถ้าเพิ่มอะไรแบบนั้นในหน้า Unifont ก็น่าจะดี
• พอเห็นชื่อ GNU ก็รู้สึกว่า ถึงจะไม่ได้ดีที่สุดในทุกด้าน แต่ในแง่ การให้ความเคารพผู้ใช้ นั้นแทบจะดีที่สุด
• ฉันใช้ Unifont กับทั้งระบบ และบังคับให้ Firefox ใช้มันเป็น ฟอนต์เดียว
  ปิดการดาวน์โหลดเว็บฟอนต์ด้วย และฉันก็มีตัวอักษรที่สร้างเองอยู่ใน CSUR (ConScript Unicode Registry)
  ใน Qt การตั้งค่า DPI ค่อนข้างจุกจิก แต่แก้ได้ด้วย QT_FONT_DPI=128 แล้วก็อยากให้เกมอย่าง RimWorld ใช้แต่ Unifont เหมือนกัน
  • อยากรู้ว่าใช้แบบนั้นไปทำไม
  • ฉันก็ลองติดตั้งเหมือนกัน แต่ต้อง ซูม HN 200% ถึงจะอ่านได้ ใน XFCE ถือว่าโอเคพอใช้
• ฉันต้องลบ Unifont ออกจาก Firefox ถึงจะใช้ฟอนต์ CJK สวย ๆ ได้
  เพราะระบบ font fallback ดันเลือก Unifont ก่อนอย่างแปลก ๆ
  • ถ้าจะแก้ ต้องเข้าไปที่ Language and Appearance → Fonts → Advanced ในการตั้งค่า Firefox แล้วกำหนดฟอนต์แยกตามสคริปต์
    ไม่อย่างนั้นจะเดาไม่ได้เลยว่าสุดท้ายมันจะเลือกฟอนต์ไหน
  • ฉันก็เคยเจอปัญหา glyph ของ Unifont ไม่แสดงผล ในทั้ง Firefox และ Chrome มีรายงานเรื่องนี้ใน issue tracker ของ nixpkgs ด้วย
    เคยมีอาการคล้ายกันกับ Noto Color Emoji เหมือนกัน โลกของฟอนต์นี่ละเอียดอ่อนจริง ๆ
• ฉันสร้าง ฟอนต์สำหรับ Playdate โดยอิงจาก Unifont
  https://github.com/remysucre/cuniform