Tai Tham Updated, Thai Noi Revisited

Update งานอักษรอีสาน

Khottabun กับอักษรธรรมแบบไร้ USE

หลังจากการวิเคราะห์ทางเลือกต่างๆ สำหรับอักษรธรรมไป 2 blog (Lao Tham Font vs USE และ To USE or Not to USE for Lao Tham) และได้ตัดสินใจ หลีกเลี่ยง USE โดยยอมทิ้ง MS Word ไว้ข้างหลัง ก็ได้ implement ใน fonts-khottabun ตามนั้น ตั้งแต่ commit a0389bd จนถึง commit 1c73c80 โดยปรับ major version ของฟอนต์ขึ้นเป็นรุ่น 003 สำหรับอักษรธรรมแบบไม่ใช้ USE

Keyboard Layout อักษรธรรมบน Windows

ถัดมาคือ ผังแป้นพิมพ์อักษรธรรมบน Windows ในรูปของซอร์ส KLC สำหรับสร้างเป็นผังแป้นพิมพ์ด้วย Microsoft Keyboard Layout Creator (MSKLC) 1.4 ซึ่งจะ build เป็น DLL พร้อมโปรแกรม setup

ประเด็นปลีกย่อยของผังนี้คือ Windows กำหนดให้ผังแป้นพิมพ์ต้องผูกติดกับโลแคล (locale) ซึ่งกำหนดด้วยภาษาและดินแดน ตรงนี้เป็นปัญหาโดยนิยามอยู่ เพราะอักษรธรรมสามารถใช้เขียนได้หลายภาษา ไม่ว่าจะไทย ลาว ไทลื้อ ไทขึน หรือคาถาบาลี-สันสกฤต แต่ Windows จะบังคับให้เราเลือกเพียงภาษาเดียวมาประกอบกับดินแดนที่เป็นถิ่นของภาษาที่ใช้ โดยห้ามใช้ซ้ำกับผังอื่นในโลแคลนั้นๆ ด้วย ประเด็นคือ:

• โลแคลต่างๆ มักมีผังแป้นพิมพ์อยู่แล้ว ถ้าไม่ต้องการซ้ำก็ต้องสร้างโลแคลใหม่สำหรับอักษรธรรม แต่จะกำหนดโลแคลด้วยภาษาอะไร ในเมื่ออักษรธรรมสามารถใช้เขียนได้หลายภาษา?
• สมมุติว่าเราเลือกสร้างโลแคลภาษาลาวถิ่นไทย (lo-TH) ด้วย Microsoft Locale Builder แต่ปัญหาคือ เราไม่สามารถเลือกบล็อคยูนิโคดของอักษรธรรมให้กับโลแคลใหม่นี้ได้ เนื่องจาก Microsoft กำหนดตัวเลข enum ให้กับบล็อคยูนิโคดต่างๆ แต่ยังไม่ได้กำหนดเลขสำหรับอ้างให้กับบล็อคอักษรธรรม!
• ในเมื่อสร้างโลแคลเองไม่ได้ วิธีแก้ขัดจึงเป็นการเลือกโลแคลอะไรก็ได้ที่ไม่ซ้ำกับชุดผังแป้นพิมพ์ที่เราใช้ เช่น ใช้ th, en ไม่ได้ เพราะจะซ้ำกับสองผังหลักที่เราใช้ และผมก็จิ้มเอาโลแคลมลยาฬัมในอินเดีย (ml-IN) โดยไม่มีเหตุผลใดๆ มากไปกว่าการแก้ขัด เวลาจะป้อนอักษรธรรมบน Windows ผู้ใช้ก็สลับแป้นพิมพ์ไปที่ภาษามลยาฬัม
• อันที่จริง สิ่งที่เราต้องการมากกว่าในกรณีนี้คือการอ้างถึง อักษร (script) ตรงๆ ไปเลย แต่การออกแบบของ Windows ยังไม่เอื้อขนาดนั้น

อย่างไรก็ดี เราก็ได้ผังแป้นพิมพ์อักษรธรรมที่ทำงานได้บน Windows โดยเป็นเพียงผังปุ่มจริงๆ ยังไม่มีการตรวจหรือสลับลำดับอะไร ผู้ใช้ต้องป้อนตามลำดับยูนิโคดเป๊ะๆ เช่น ᨸᩮᩢ᩠ᨶ (เป็น) ก็ต้องป้อนเป็น ป + เอ + ไม้ซัด + SAKOT + น

อักษรไทยน้อย

แม้อักษรไทยน้อยจะเรียบง่ายกว่าอักษรธรรม แต่กลับมีรายละเอียดปลีกย่อยมากกว่า ทั้งเรื่องความหลากหลายของชุดอักษรที่ใช้ การควบอักษรติดกัน การยืมตัวห้อยตัวเฟื้องจากอักษรธรรมตามแต่ผู้จารึกจะเลือกใช้ ดังที่ผมได้เคย สรุปประเด็น ไว้ โดยยังไม่ตกลงว่าจะเลือก implement แบบไหน

เมื่อหลายปีก่อน ในระหว่างที่ทำไปศึกษาไปนั้น ผมเลือกที่จะเติมอักขระลงในช่องที่ยังว่างอยู่ของบล็อคยูนิโคดอักษรลาว ไม่ว่าจะเป็นตัวเฟื้องหรือตัวควบต่างๆ แต่ยิ่งพบอักขระที่ต้องเพิ่มรหัสมากขึ้นจากการอ่านจารึก ก็ยิ่งเห็นว่ามันไม่ใช่วิธีที่ดีในระยะยาว

ตอนนี้ได้โอกาสมาปัดฝุ่น โดยบล็อคยูนิโคดลาวเองก็มีมีการเพิ่มอักขระสำหรับเขียนภาษาบาลีตามแบบพุทธบัณฑิตสภา จึงได้พิจารณาทางเลือกต่างๆ ใหม่

เริ่มจากตรวจสอบความคืบหน้าใน Unicode ของอักษรไทยน้อย ซึ่ง ข้อมูลใน ScriptSource ของ SIL ได้บันทึกรายละเอียดไว้ โดยสถานะล่าสุดคือ ยังไม่กำหนดใน Unicode ส่วนกระบวนการเท่าที่ผ่านมาคือ

2018-01-02 Request to Add Thai Characters — Nitaya Kanchanawan (WG2 N4927, L2/18-041)

เป็นข้อเสนอขอเพิ่มอักขระไทยน้อยลงในบล็อคอักษรไทย! โดยเป็นงานที่เกี่ยวเนื่องกับการกำหนดมาตรฐานการถอดอักษรไทยน้อยเป็นอักษรโรมันที่ราชบัณฑิตยสภาได้เสนอเข้าสู่ ISO/IEC โดยได้รับความเห็นว่าควรกำหนดรหัสอักขระก่อน แต่ไม่ทราบว่าด้วยเหตุผลใด ราชบัณฑิตยสภาถึงได้เสนอให้เพิ่มอักขระในบล็อคอักษรไทยแทนที่จะเป็นบล็อคอักษรลาวที่อยู่ในสายวิวัฒนาการโดยตรง

2018-01-19 Information and documentation - Transliteration of scripts in use in Thailand - Part 1: Transliteration of Akson-Thai-Noi — TC46 / WG3 (WG2 N4927A, L2/18-042)

เป็นร่างมาตรฐานการถอดอักษรไทยน้อยเป็นอักษรโรมันที่เป็นต้นเรื่อง ตัวเอกสารต้องใช้รหัสผ่านในการเข้าถึง และไม่เกี่ยวข้องกับเรื่องรหัสอักขระโดยตรง ผมจึงไม่ใส่ลิงก์ไว้

2018-01-19 Results on ISO CD 20674-1: Information and documentation - Transliteration of scripts in use in Thailand - Part 1: Transliteration of Akson-Thai-Noi — TC46 Secretatriat (WG2 N4927B, L2/18-043)

ผลการโหวตร่างมาตรฐานการถอดอักษรไทยน้อยของคณะกรรมการ เห็นชอบ 16, เห็นชอบโดยมีข้อคิดเห็น 2, ไม่เห็นชอบ 1, งดออกเสียง 19

2018-02-20 Thai-Noi Transliteration — Martin Hosken (WG2 N4939, L2/18-068)

เป็นความเห็นจากคุณ Martin Hosken ผู้เชี่ยวชาญจาก SIL โดยสรุปเห็นว่าอักษรไทยน้อยเข้ากันได้กับอักษรธรรมมากกว่าอักษรไทย

2018-02-28 Towards a comprehensive proposal for Thai Noi / Lao Buhan script — Ben Mitchell (L2/18-072)

เป็นความเห็นจากคุณ Ben Mitchell ผู้เชี่ยวชาญอีกท่านหนึ่ง โดยมีผู้ร่วมให้ข้อมูลคือ Patrick Chew, ผมเอง และ อ.ประพันธ์ เอี่ยมวิริยะกุล โดยสรุปเห็นว่าควรเพิ่มอักขระไทยน้อยในบล็อคอักษรลาว โดยเพิ่มเติมจากอักษรลาวบาลีของพุทธบัณฑิตสภาอีกที และได้เสนอทางเลือกต่างๆ ดังที่ผมได้สรุปไว้ แต่ยังไม่ระบุว่าจะเลือกวิธีการไหน

Recommendations to UTC #155 April-May 2018 on Script Proposals (L2/18-168) (อยู่ที่ข้อ 6.) และบันทึกการประชุมของ UTC #155 (L2/18-115) (อยู่ที่ข้อ D.8.1 และ D.8.3)

สรุปข้อแนะนำของคณะกรรมการว่าอักษรไทยน้อยไม่ใข่ส่วนขยายของอักษรไทย และผู้เสนอร่างอักษรไทยน้อย (หมายถึง อ.นิตยา กาญจนวรรณ จากราชบัณฑิตยสภา) ควรนำข้อมูลในเอกสารของคุณ Ben Mitchell ข้างต้นไปใช้ประกอบการร่างด้วย โดยมอบให้ Deborah Anderson ร่างเอกสารแจ้งเจ้าของร่าง ซึ่งก็คือเอกสาร L2/18-070

แล้วกระบวนการทั้งหมดก็หยุดอยู่ที่รอการดำเนินการของราชบัณฑิตยสภาต่อจากนั้น

สรุปว่ายังไม่มีมาตรฐาน Unicode อักษรไทยน้อยเกิดขึ้น ถ้าจะ implement ตอนนี้ก็เป็นเพียงตุ๊กตาเท่านั้น

จากทางเลือกต่างๆ ที่มี ผมพิจารณาเลือกเองไปก่อนอย่างนี้:

• Conjunct หรือการสังโยคพยัญชนะด้วยตัวห้อย/ตัวเฟื้อง ใช้พินทุ (U+0EBA LAO SIGN PALI VIRAMA) ตามด้วยพยัญชนะที่จะสังโยค ยกเว้นกรณีที่มีรหัสอยู่แล้ว คือ ล ห้อย (U+0EBC) และ ย เฟื้อง (U+0EBD) ก็ใช้รหัสนั้นๆ ไปเลย
• Ligature หรือตัวแฝด หรืออักษรควบ ใช้ U+200D ZERO WIDTH JOINER (ZWJ) เชื่อมพยัญชนะ ยกเว้นกรณีที่มีรหัสอยู่แล้ว คือ U+0EDC (ໜ), U+0EDD (ໝ) ก็ใช้รหัสนั้นๆ ไปเลย
• สระออย กำหนดอักขระใหม่ในช่องที่ยังว่างอยู่ คือ U+0EBE เพื่อให้เป็นวิธีที่สอดคล้องกับอักษรธรรม (อีกวิธีที่ไม่ต้องกำหนดอักขระใหม่คือใช้ พินทุ + ຢ แต่จะเป็นวิธีที่แปลกแยกจากอักษรธรรม)

เมื่อเลือกวิธีนี้แล้ว ก็ปรับเปลี่ยนทั้งในฟอนต์ Khottabun และในระบบป้อนข้อความ Lanxang ดังนี้:

• fonts-khottabun: detach glyph ตัวห้อย/ตัวเฟื้องและตัวควบทั้งหมดจากรหัสอักขระ แล้วสร้างกฎ 'ccmp' TN conjuncts และ 'ccmp' TN subjoins เพื่อเข้าถึง glyph เหล่านี้ผ่านพินทุและ ZWJ ตามลำดับ พร้อมกับปรับรุ่น major ของฟอนต์เป็นรุ่น 004 (commit cc4935a)
• lanxang: ตัดกระบวนการแปลง พินทุ + พยัญชนะ เป็นอักขระตัวห้อย/ตัวเฟื้อง และ พยัญชนะ + ZWJ + พยัญชนะ เป็นอักขระตัวควบ ทั้งหมด (ทิ้ง sequence ประกอบไว้อย่างนั้นในข้อความเลย แล้วให้ฟอนต์จัดการตอน render) ยกเว้นการควบ ໜ,ໝ เพื่ออำนวยความสะดวก (commit f0645b1) แต่ก็ยังป้อน ໜ, ໝ โดยตรงได้ด้วย level 3 เช่นกัน
• lanxang: เพิ่มผังแป้นพิมพ์อักษรไทยน้อยสำหรับ Windows ด้วย (commit cce81cd)

พร้อมกันนี้ก็แปลงวิธีลงรหัสอักขระไทยน้อยในตัวอย่างการปริวรรตทั้งหลายด้วย (พญาคันคาก, ฮีตคองคะลำ, บูชาพญานาค, นกกระจอก)

To USE or Not to USE for Lao Tham

จาก blog ที่แล้ว ผมได้เล่าถึงการรองรับอักษรธรรมในปัจจุบันที่ text shaping engine ต่างๆ หันมาใช้ Universal Shaping Engine (USE) ตามข้อกำหนดของไมโครซอฟท์ โดย USE เองเป็น engine ครอบจักรวาลที่มีการจัดการภายในตามคุณสมบัติของอักขระ Unicode เช่น การสลับสระหน้ากับพยัญชนะต้นสำหรับอักษรตระกูลพราหมี และเรียกใช้ OpenType feature ต่างๆ ในฟอนต์ตามลำดับที่กำหนดไว้

และการจัดการภายในของ USE ก็ทำให้มีข้อเสนอที่จะปรับโครงสร้างการลงรหัสข้อความอักษรธรรมเพื่อให้ทำงานกับ USE ได้ แต่มันก็ยังไม่เข้าที่เข้าทางนัก จึงเกิดแนวคิดที่จะหลบเลี่ยง USE แล้วทำทุกอย่างเองในฟอนต์ แต่ไปติดปัญหาที่ MS Word ที่ไม่ยอมให้หลบได้ง่ายๆ ทำให้เราอยู่บนทางแยกที่ต้องเลือกว่าจะใช้ USE ที่ยังไม่เข้าที่ หรือจะเลี่ยง USE ไปทำทุกอย่างเองโดยทิ้ง MS Word ไว้ข้างหลัง

blog นี้ก็จะวิเคราะห์ต่อ ว่าทางเลือกแต่ละทางมีข้อดีข้อเสียอย่างไร

Encoding แบบใหม่

ตามข้อเสนอในเอกสาร Structuring Tai Tham Unicode เมื่อตัดรายละเอียดที่อักษรธรรมลาว/อีสานไม่ใช้ออกไป ก็พอจะสรุปลำดับอักขระในข้อความได้เป็น:

  S ::= CC (Vs | Vf)?

โดยที่ CC คือ consonant cluster พร้อมสระหน้า/ล่าง/บน วรรณยุกต์ สระหรือตัวสะกดปิดท้าย

  CC ::= C M? V? T? F?

  C ::= [<ก>-<ฮ><อิลอย>-<โอลอย><แล><ส_สองห้อง><ตัวเลข>] | <ห><SAKOT>[<ก>-<ม>]

  M ::= <ระวง>? <ล_ล่าง>? (<SAKOT><ว>)? (<SAKOT><ย>)?

  V ::= Vp? Vb? Va? 
  Vp ::= [<เอ>-<ไม้ม้วน>] // สระหน้า
  Vb ::= [<อุ>-<อู><ออ_ล่าง>] // สระล่าง
  Va ::= [<อิ>-<อือ><ไม้กง><ไม้เก๋าห่อนึ่ง>][<ไม้ซัด><ไม้กั๋ง>]? // สระบน

  T ::= [<ไม้เอก>-<ไม้โท>]

  F ::= Fs? [<ละทั้งหลาย><ไม้กั๋งไหล><ง_บน><ม_ล่าง><บ_ล่าง><ส_ล่าง><ไม้กั๋ง>]? (<SAKOT> S)?
  Fs ::= [<อ><ส_สองห้อง><ออย>] | <SAKOT>[<ก>-<ฬ>] // อ ของสระเอือ หรือ ตัวสะกด

สังเกตว่ามี recursion ใน F เพื่อแทนลูกโซ่ของพยางค์ในคำบาลีด้วย

ต่อจาก CC ก็จะตามด้วยสระกินที่ (spacing vowels) ซึ่งแบ่งเป็นสระมีตัวสะกด (Vs) และสระไม่มีตัวสะกด (Vf)

สำหรับสระมีตัวสะกด Vs คือสระอาหรือสระอำ (สระอำในอักษรธรรมไม่ได้มีรหัสอักขระเฉพาะเหมือนอักษรไทย แต่แทนด้วยสระอาตามด้วยไม้กั๋ง (นิคหิต) ความจริงอาจนับไม้กั๋งเป็นตัวสะกดในสระอำก็ได้ แต่กฎนี้พยายามจัดการสระอากับสระอำไปด้วยกัน กลายเป็นว่าสระอำก็ยังมีตัวสะกดได้อีก) พร้อมตัวสะกด Fs (ถ้ามี)

  Vs ::= AV Fs?
  AV ::= [<อา><อาสูง>] <ไม้กั๋ง>? // สระอา สระอำ

ส่วนสระไม่มีตัวสะกด Vf ในตัวเนื้อหาของร่างฯ ได้บรรยายถึงสระเอาะและสระเอือะ แต่ในสรุปส่วนท้ายดูจะลืมสระเอาะไป และยังจัดการ อ ของสระเอือะซ้ำซ้อนกับใน Fs อีก

  Vf ::= <อ>? <อะ> // วิสรรชนีย์ของสระเอือะ

Encoding แบบ USE

แม้ encoding แบบใหม่ที่เสนอมีจุดมุ่งหมายเพื่อให้วาดแสดงด้วย USE แต่เมื่อลองใช้กับ USE จริงกลับยังมี dotted circle เกิดขึ้นในหลายกรณี ซึ่งจากการทดลองก็พอจะสังเกตลักษณะของ USE ที่ต่างจากโครงสร้างที่เสนอในร่างดังนี้:

• ลำดับสระใน V สระบนมาก่อนสระล่าง ไม่ใช่ตามหลังสระล่างอย่างในร่างฯ ดังนั้นจึงอาจปรับกฎเป็น:

    V ::= Vp? Va? Vb?
  

• วรรณยุกต์อยู่หน้าสระกินที่ไม่ได้ แต่ตามหลังได้ และต้องอยู่ก่อนตัวสะกด ดูเหมือน USE จะนับ Vs เป็นส่วนหนึ่งของ V:

    V ::= Vp? Va? Vb? Vs?
  

  ซึ่งถ้าเป็นเช่นนั้น ก็หมายความว่า USE ก็ยังต้องการการ reorder ให้วรรณยุกต์ไปอยู่ในตำแหน่งก่อนหน้าสระกินที่เพื่อให้สามารถซ้อนบนพยัญชนะได้ด้วย มันจะกลายเป็นความซับซ้อนเกินจำเป็นน่ะสิ

หลักการสำหรับการป้อนข้อความ

สมมติว่าเราใช้ encoding แบบ USE เราจะมีหลักในใจอย่างไร? เราจะใช้ลำดับการพิมพ์แบบที่เราเคยใช้กับอักษรไทยไม่ได้อีกแล้ว เพราะมันคือการ encode แบบกึ่ง visual ไม่ว่าเขาจะยืนยันที่จะเรียกว่า logical order ยังไงก็ตาม แต่ลำดับการ encode นี้จะไม่ตรงกับลำดับการสะกดคำเสมอไป มันเน้นให้เรียงพิมพ์ได้เป็นหลัก! โดยมีลำดับแบบที่เรียกว่า logical order มาหลอกให้งงเล่น

หลักการคือ

0. ละทิ้งลำดับการสะกดในใจไว้ก่อน พิจารณารูปร่างของข้อความที่ต้องการ แล้ว encode ตามกฎในข้อถัดๆ ไป
1. ผสมตัวห้อย ตัวเฟื้อง หรือระวง กับพยัญชนะต้นก่อน โดยมากเป็นตัวควบกล้ำ
2. ตามด้วยสระ โดยถ้ามีสระหลายตัว ให้วางสระตามลำดับ หน้า, บน, ล่าง, ขวา
3. ตามด้วยวรรณยุกต์
4. ตามด้วยตัวสะกด ซึ่งอาจเป็นตัวห้อย, ตัวเฟื้อง, ไม้กั๋ง, ง สะกดบน, หรือไม้กั๋งไหล
5. ถ้ามีการเชื่อมพยางค์เป็นลูกโซ่แบบบาลี ก็นับตัวสะกดเป็นพยัญชนะต้นของพยางค์ถัดไปแล้วใส่สระตามได้เลย

ความไม่ปกติของลำดับ

หลักการที่ว่าไปก็ดูปกติดีนี่? แต่ความซับซ้อนของอักษรธรรมทำให้มันไม่ตรงไปตรงมาอย่างนั้น ต่อไปนี้คือกรณีต่างๆ ที่ฝืนความรู้สึก อย่างน้อยก็ในระยะแรก

การสะกดแม่กกด้วยไม้ซัด

ไม้ซัดถือว่าเป็นสระบน (Va) ในกฎ ซึ่ง encoding ในร่างฯ สามารถตามหลังสระล่าง (Vb) ได้ แต่ตาม encoding ของ USE ต้องมาก่อนสระล่าง ดังนั้น เมื่อไม้ซัดทำหน้าที่เป็นตัวสะกดแม่กก จึงต้องใช้ลำดับที่ตัวสะกดมาก่อนสระ ไม่ใช่สระมาก่อนตัวสะกด

แต่ก็จะมีกรณีที่ไม่สามารถ encode ได้ ไม่ว่าจะตามร่างฯ หรือตาม USE คือเมื่อเป็นตัวสะกดของสระอา

อาจจะยกเว้นคำว่า นาค ที่สามารถซ่อนลำดับไว้ภายใต้รูปเขียนพิเศษได้

เมื่อมีตัวห้อย/ตัวเฟื้องหรือสระระหว่าง cluster

การเขียนอักษรธรรมในหลายกรณีมีการใช้ตัวห้อย/ตัวเฟื้องเป็นพยัญชนะต้นของพยางค์ถัดไป แทนที่จะใช้ตัวเต็ม ซึ่งในกรณีเหล่านี้ ถ้าวางตัวห้อย/ตัวเฟื้องในตำแหน่งของตัวสะกด ก็จะไม่สามารถวางสระต่อได้อีก เพราะดูเหมือน USE ไม่ได้รองรับ recursion ใน F ตามกฎในร่างฯ และเมื่อแจงต่อไป CC ของพยางค์ถัดไปก็ขาดพยัญชนะต้นตัวเต็ม (C) มาขึ้นต้น CC แต่ถ้า encode โดยเลี่ยงให้ตัวห้อย/ตัวเฟื้องดังกล่าวเป็นส่วนหนึ่งของ CC ของพยางค์ก่อนหน้าก็จะสามารถวางสระต่อได้ แต่ลำดับก็จะดูขัดสามัญสำนึกสักหน่อย

แต่ในบางกรณีก็ไม่เอื้อให้ทำเช่นนั้น เช่น เมื่อมีสระมาคั่นในแบบที่ไม่สามารถสลับลำดับได้

ในคำย่อที่มีการยืมพยัญชนะต้น

บ่อยครั้งที่อักษรธรรมมีการใช้รูปเขียนย่อในลักษณะที่ใช้พยัญชนะต้นตัวเดียวซ้ำในพยางค์มากกว่าหนึ่งพยางค์ ในจำนวนนั้น บางคำอาจสามารถยังจัดลำดับอักขระจนเข้ากับกฎเกณฑ์ของ USE ได้ แม้จะดูเหมือนการเปลี่ยนหน้าที่อักขระ เช่น เปลี่ยนตัวสะกดมาเป็นตัวควบ หรืออาจมีการสลับลำดับสระของพยางค์ต่างๆ

แต่บางกรณีก็ไม่สามารถจัดลำดับให้เข้าเกณฑ์ได้

วิธีหลบเลี่ยง?

อย่างไรก็ดี ปัญหาทั้งหมดนี้สามารถหลบเลี่ยงได้ โดยลบ glyph DOTTED CIRCLE (uni25CC) ออกจากฟอนต์เสีย แล้ว USE ก็จะไม่แสดง dotted circle อีกเลย!

ที่กล่าวมาทั้งหมดนี้คือการทดสอบกับแอปที่ใช้ Harfbuzz แต่สุดท้าย เมื่อนำไปทดสอบกับ MS Word ปรากฏว่ามันก็ยังไม่ยอมง่ายๆ อยู่ดี โดยปัญหาหลักที่พบมีสองข้อ ข้อแรกคือกฎของตัวห้อย/ตัวเฟื้องจะไม่ทำงานถ้าไม่ได้ตามหลังพยัญชนะต้นทันที เช่น เป็นตัวสะกดของสระอา หรือมีสระอื่นมาคั่นกลาง กล่าวคือ blwf ดูจะถูกเรียกเฉพาะในตำแหน่งพยัญชนะซ้อนกันเท่านั้น ไม่เรียกในตำแหน่งตัวสะกด และอีกข้อหนึ่งคือกฎ ligature สำหรับ นา ไม่ทำงานเมื่อมีอักขระซ้อนบน/ล่าง

สรุป

ประเด็นต่างๆ ที่พบ พอจะสรุปได้ตังตาราง

ประเด็น	ใช้ USE	เลี่ยง USE
วิธีการ	lana script tag GSUB ตาม USE ตัด dotted circle	DFLT script tag GSUB อย่างละเอียด อาจมี dotted circle ได้
การ encode ข้อความ	กึ่ง visual (ขัดสามัญสำนึกนิดหน่อย)	ตามหลักการสะกดคำ
แอปที่รองรับ	Harfbuzz app*, MS Word (บางส่วน)	Harfbuzz app*, Notepad
อาการเมื่อไม่รองรับ	MS Word กฎ blwf ในตำแหน่งตัวสะกดไม่ทำงาน กฎ ligature นา ไม่ทำงานถ้ามีอักขระบน/ล่างแทรก Notepad และแอปที่รองรับ OpenType แบบผิวเผิน ไม่มีกฎไหนทำงานเลย ทุกแอป ไม้กั๋งไหลไม่ไหล	MS Word ccmp: การ reorder สระหน้า, ระวง ไม่ทำงาน liga: reorder สระหน้าซ้ำสองตำแหน่ง

^*Harfbuzz app เช่น LibreOffice, Firefox, Gedit, Mousepad ฯลฯ

จึงพอสรุปได้ว่ายังมีความแตกต่างระหว่างข้อกำหนดในร่างฯ กับสิ่งที่ USE รองรับจริง ทำให้ไม่ว่าจะพยายามอย่างไรก็จะมีข้อบกพร่องเกิดขึ้นเสมอ และแอปที่มีปัญหาเสมอๆ ก็คือ MS Word

หากเลือกใช้ข้อกำหนด USE ทุกแอปที่รองรับ USE ก็จะได้การรองรับแบบ เกือบๆ ครบถ้วน (โดย MS Word จะมีปัญหามากกว่าเพื่อนสักหน่อย) โดยแลกกับลำดับการ encode ที่ผิดธรรมชาติของผู้ใช้ ซึ่งเป็นการแลกที่ผมคิดว่าไม่คุ้ม เพราะจะมีผลให้เกิดเอกสารที่ encode แปลกๆ เกิดขึ้นในระหว่างที่ USE ยังไม่พร้อม แถมสิ่งที่ได้คืนมาก็ยังไม่ใช่สิ่งที่สมบูรณ์เสียด้วย

ในขณะที่หากเลือกหลีกเลี่ยง USE แอปส่วนใหญ่ยกเว้น MS Word ก็จะสามารถจัดแสดงอักษรธรรมได้สมบูรณ์ (ดังกล่าวไว้ใน blog ที่แล้ว) โดยที่ผู้ใช้ก็ยังคงใช้ encoding แบบเก่าได้เช่นเดิม และเมื่อไรที่ USE พร้อม ก็เพียงแปลง encoding ไปเป็นแบบใหม่ (ซึ่งอาจจะอัตโนมัติหรือ manual ก็ค่อยว่ากัน) โดยไม่ต้องมี encoding ชั่วคราวของ USE มาแทรกกลางเป็นชนิดที่สามให้เกิดความสับสนเพิ่ม โดยแลกกับการทิ้ง MS Word ที่ยังไงก็ไม่สมบูรณ์อยู่แล้ว และแนะนำให้ผู้ใช้อักษรธรรมใช้ LibreOffice หรือ Notepad (ซึ่งเป็นผลพลอยได้) ในการเตรียมเอกสารแทน ส่วนเว็บเบราว์เซอร์นั้นไม่เป็นปัญหา เพราะเบราว์เซอร์ส่วนใหญ่ก็ใช้ Harfbuzz เป็นฐานกันอยู่แล้ว การรองรับก็จะเหมือนๆ กับใน LibreOffice นั่นแล

ด้วยเหตุนี้ ผมจึงเลือกที่จะสร้างฟอนต์อักษรธรรมที่ หลีกเลี่ยง USE ต่อไป จนกว่า USE จะพร้อมจริงๆ

Lao Tham Font vs USE

บันทึกการกลับมาทำฟอนต์อักษรธรรมอีกครั้ง หลังจาก commit ล่าสุด 4 ปีที่แล้ว โดยในช่วงหลังของการทำงานรอบนั้น มีความเปลี่ยนแปลงสำคัญใน Harfbuzz ก่อนที่ผมจะวางมือไปทำอย่างอื่น คือ มีการใช้ Universal Shaping Engine (USE) ตามข้อกำหนดของไมโครซอฟท์ ทำให้กฎบางข้อหยุดทำงาน เช่น การจัดการไม้กั๋งไหล (ลาวเรียก ไม้อังแล่น) แต่ผมก็ไม่ได้ไปติดตาม

ในเอกสาร Creating and supporting OpenType fonts for the Universal Shaping Engine ของไมโครซอฟท์ ได้อธิบายขั้นตอนต่างๆ ที่ USE จะเรียกใช้กฎในฟอนต์ โดยที่ USE เองก็มีการประมวลผลภายในเองบางส่วนด้วย ตามแต่อักษรที่รองรับ โดยสำหรับอักษรธรรมก็มีเชิงอรรถให้ปวดใจว่า

Note: Tai Tham support is currently limited. Additional encoding work is required for full text representation to be possible.

การรองรับอักษรธรรมยังคงจำกัดอยู่ในตอนนี้ ยังต้องทำงานด้านการกำหนดรหัสกันต่อไปเพื่อจะให้ได้รหัสที่สามารถแทนข้อความได้เต็มที่

ซึ่งเมื่อไปตรวจสอบเอกสารที่เกี่ยวข้อง ก็พบเอกสาร Structuring Tai Tham Unicode (L2/19-365) โดย Martin Hosken ซึ่งเป็นร่างข้อเสนอที่จะปรับลำดับการลงรหัสอักขระอักษรธรรมจาก แบบเริ่มแรก (L2/05-095R) เพื่อการวาดแสดงด้วย USE ซึ่งลำดับแบบใหม่ค่อนข้างแตกต่างจากลำดับการสะกดในใจพอสมควร และข้อเสนอใหม่ก็ยังคงเป็นฉบับร่าง จึงเกิดความไม่แน่นอนว่าแนวทางการลงรหัสปัจจุบันจะเป็นแบบไหน

เนื่องจากพระอาจารย์ชยสิริ ชยสาโร ประสงค์จะให้ผมเพิ่มอักษรธรรมลงในฟอนต์ Laobuhan ของท่าน ผมจึงถือโอกาสทดลองทำตามข้อกำหนดของ USE อันใหม่เสียเลย โดยพยายามทดสอบบน Windows 11 ด้วย นอกเหนือจากที่เคยทดสอบเฉพาะบนลินุกซ์ โดยในข้อกำหนดใหม่ USE มีการ reorder สระหน้าให้ จึงไม่ต้องทำในฟอนต์เองอีกต่อไป สิ่งที่ควรทำ (เรียงตามลำดับการเรียกใช้โดย USE) จึงเป็น:

• pref (Pre-base forms) เพื่อระบุตำแหน่งของระวง เพื่อที่ USE จะ reorder ไปไว้หน้าพยัญชนะต้นให้ในภายหลัง
• rphf (Reph forms) ความจริงเป็นกฎสำหรับ reorder เรผะ ของอักษรอินเดีย ที่ดูแล้วน่าจะใช้กับ ไม้กั๋งไหล ของอักษรธรรมได้ แต่เมื่อทดลองทำจริงแล้วไม่เป็นผล ซึ่งในเอกสารของไมโครซอฟท์เองก็ระบุไว้ว่า:

  Note that the category REPHA is not currently supported by USE.

  ซึ่งหมายความว่า rphf เองก็จะยังไม่ทำงาน
• blwf (Below-base forms) เพื่อทำตัวห้อย ตัวเฟื้อง
• liga (Standard ligatures) เพื่อทำรูปเขียนพิเศษ เช่น นา

ผลการทดสอบคือ แอปที่ใช้ Harfbuzz (GTK, LibreOffice, Firefox) และ MS Word วาดแสดงอักษรธรรมได้ดี ยกเว้นในบางกรณี เช่น สระอาที่ตามหลังวรรณยุกต์จะมี dotted circle แทรกเข้ามา และตัว ล ห้อย (ที่ไม่ใช้ SAKOT) ที่ใช้ร่วมกับสระหน้าจะแสดงถูกต้องเฉพาะเมื่อลงรหัสด้วยลำดับที่เหมาะสมเท่านั้น กล่าวคือ ถ้าใช้ structure ข้อความแบบใหม่ที่ออกแบบให้รองรับ USE ก็ น่าจะ แสดงได้ถูกต้องเป็นส่วนมาก

อักษรธรรมบน LibreOffice Writer แบบใช้ USE

อักษรธรรมบน MS Word แบบใช้ USE

แต่กับ Notepad บน Windows ดูเหมือนกฎต่างๆ จะไม่ทำงานเลย! สถานการณ์อาจต่างจากลินุกซ์ที่แอปแทบทุกตัวใช้ Harfbuzz กันหมด แต่บน Windows ยังแยก implement กันอยู่

อักษรธรรมบน Windows Notepad แบบใช้ USE

อักษรธรรมบน Linux Mousepad แบบใช้ USE

แต่ปัญหา dotted circle ในบางกรณีของ USE ก็ยังทำให้ผมต้องค้นหาข้อมูลต่อ ทั้งไล่ซอร์สโค้ดของ Harfbuzz ทั้งค้นเว็บ จนไปเจอ โพสต์ของ Richard Wordingham เล่าปัญหาเดียวกันที่เขาเจอ โดยได้พูดถึงวิธีหลบเลี่ยง USE ด้วย โดยในทุกกฎ GSUB, GPOS ไม่ต้องระบุรหัสอักษรเป็น lana เลย เพียงใช้รหัสอักษร DFLT ก็พอ ซึ่งถ้าเป็น Harfbuzz ก็จะไปเรียก default engine แทน USE ซึ่งฟอนต์ก็ต้องเตรียมกฎ GSUB ให้มันทำงานทุกอย่างแทน USE ทั้งหมด ผ่าน OpenType feature เท่าที่ใช้รองรับ Standard Scripts ซึ่งก็จะมี feature จำนวนจำกัดให้ใช้ เช่น ccmp และ liga เป็นต้น

เรื่องกฎไม่ใช่เรื่องยาก เพราะฟอนต์ Khottabun ที่ผมสร้างตั้งแต่ก่อนที่ Harfbuzz จะใช้ USE ก็ทำทุกอย่างเองหมดอยู่แล้ว ก็เลยหยิบมาทดลองได้ทันที โดยตัดรหัสอักษร lana ออกจากกฎ ccmp ที่ใช้ทั้งหมด

ผลปรากฏว่า มันยังคงวาดแสดงได้อย่างสมบูรณ์บน Harfbuzz แต่คราวนี้มันทำงานบน Notepad บน Windows ด้วย! โดยในทั้งสองกรณี กฎที่เขียนไว้สำหรับไม้กั๋งไหลที่เคยไม่ทำงานบน Harfbuzz ก็กลับทำงานเรียบร้อย! (ดูตัวอย่างคำว่า มงฺคล แบบแรก)

อักษรธรรมบน LibreOffice Writer แบบใช้รหัสอักษร DFLT

อักษรธรรมบน Windows Notepad แบบใช้รหัสอักษร DFLT

แต่ข่าวร้ายคือ มันเละบน MS Word

อักษรธรรมบน MS Word แบบใช้รหัสอักษร DFLT

ซึ่งจากการทดลองก็สรุปได้ว่ามันเกิดจาก:

• ข้อจำกัดของ ccmp บน engine ของ MS Word ที่ดูจะไม่รองรับ contextual substitution ที่ซับซ้อน (เข้าใจว่าทำได้แค่ multiple substitution และ ligature substitution อย่างง่ายเท่านั้น)
• engine ของ MS Word ยังคงใช้ USE เช่นเดิม ทำให้ถึงแม้จะเปลี่ยนไปใช้ liga ที่สามารถทำ contextual substitution ซับซ้อนได้ ก็จะเกิดการ reorder สระหน้าซ้ำซ้อนกันระหว่างโดยตัว engine เองก้บโดยกฎในฟอนต์จนสระหน้าสามารถเลื่อนข้ามพยัญชนะไปได้ถึง 2 ตำแหน่ง

ถ้าคิดตามหลักเหตุผลแล้ว ถ้า ccmp ที่ USE เรียกใช้ในขั้น preprocessing สามารถทำงานได้อย่างถูกต้อง โดยให้กฎแทรก glyph ผีสักตัว (เช่น ZWNJ) ไว้หน้าสระหน้าที่สลับลำดับแล้ว เพื่อให้มันคั่นระหว่างสระหน้ากับพยัญชนะที่อยู่ก่อนหน้าไว้ ก็ควรจะสามารถป้องกัน USE ไม่ให้ reorder ซ้ำอีกได้ แต่ในเมื่อ DirectWrite engine ที่ MS Word ใช้ไม่รองรับ ccmp ที่ซับซ้อน (แบบที่ Harfbuzz ทำ) มันก็จบเห่ตั้งแต่ต้น ส่วน liga หรือ clig ที่รองรับ contextual substitution แบบซับซ้อนได้ ก็ถูกเรียกทำงานหลังการ reorder ภายในของ USE ไปแล้ว จึงไม่สามารถควบคุมอะไรได้ทันการณ์

ในเมื่อ USE ก็ไม่สมบูรณ์ จะเลี่ยง USE ก็ติดปัญหากับ MS Word ผมจึงอยู่บนทางเลือก:

1. ใช้ USE ไปเลย แล้วรอให้มีการแก้ปัญหาของ USE อีกที
2. เลี่ยง USE ต่อไป โดยได้การทำงานของไม้กั๋งไหลเพิ่มมาด้วย แต่ยอมทิ้งการรองรับบน MS Word
3. เลี่ยง USE แบบต้องปรับฟอนต์ขนานใหญ่ให้ใช้ ccmp ในการ reorder ให้ได้ ผ่าน ligature glyph แล้วค่อยรื้อกลับใหม่อีกทีเมื่อ USE พร้อม

การเลือกครั้งนี้จะไม่ยากเลยถ้าการรองรับอักษรธรรมใน Unicode มีทิศทางที่ชัดเจน แต่ปัญหาคือมันไม่ขยับมา 6 ปีแล้ว

แอปที่ใช้ Harfbuzz นั้นทำงานได้กับทุกทางเลือก ปัญหาอยู่ที่แอปนอกเหนือจากนั้น โดยในที่นี้คือ MS Word กับ Notepad ซึ่งเราต้องเลือกเอาอย่างใดอย่างหนึ่ง ถ้าใช้ USE ก็จะได้ MS Word ที่ทำงานได้เท่าที่ USE รองรับ ถ้าไม่ใช้ USE ก็จะได้ Notepad ที่ทำงานเต็มรูปแบบ

โดย Notepad เองก็ถือเป็นตัวแทนของแอปอื่นๆ ที่รองรับ OpenType แบบผิวเผินด้วย ในขณะที่ MS Word ก็น่าจะเป็นแอปหลักแอปหนึ่งที่ผู้ใช้ฟอนต์จะใช้เตรียมเอกสาร (แต่จะให้ดี LibreOffice เป็นทางเลือกที่เปิดกว้างต่อ solution ต่างๆ มากกว่า)

ผมจะวิเคราะห์ใน blog หน้าว่าจะพิจารณาชั่งน้ำหนักอย่างไรต่อไป

Thanks, and the September-October Diary

ขอขอบคุณผู้สนับสนุนงานพัฒนาของผมในเดือนกันยายน-ตุลาคมที่ผ่านมาดังนี้ครับ:

• เดือนกันยายน: อ.พฤษภ์ บุญมา
• เดือนตุลาคม: อ.พฤษภ์ บุญมา, คุณวิทยา ไตรสารวัฒนะ, คุณปฏิพัทธ์ สุสำเภา

เป็นอีกครั้งหนึ่งที่ต้องเขียน blog แบบรวบสองเดือน เนื่องจากภารกิจต่าง ๆ ค่อนข้างเร่งรัด จนอยากใช้เวลาสะสางงานให้เต็มที่มากกว่า

งานในช่วงสองเดือนที่ผ่านมา แบ่งเป็นหมวด ๆ ดังนี้ครับ:

โครงการอักษรอีสาน

• ไปพบผู้เชี่ยวชาญด้านอักษรอีสาน ที่ สถาบันวิจัยศิลปะและวัฒนธรรมอีสาน มหาวิทยาลัยมหาสารคาม เพื่อเรียนให้ทราบเกี่ยวกับความคืบหน้าในการใช้อักษรอีสานในยูนิโค้ด และขอคำแนะนำเพื่อปรับปรุงเพิ่มเติม
  
• แก้ไข ระบบป้อนข้อความ Lanxang ในประเด็นที่พบระหว่างการหารือ คือเรื่อง การป้อนตัวเฟื้องอักษรธรรมบางตัวที่เป็นรูปเหมือนตัวเต็ม
• ปริวรรตใบลานอักษรไทน้อยเรื่อง พญาคันคาก ต่อ และได้เริ่มปริวรรต ตำนานวัดสีสะเกด (โดยคุณอันธิฌา)

งานพัฒนาที่ LTN และ Debian

เป็นการปล่อยสิ่งที่พัฒนาสะสมมาตั้งแต่ระลอกที่แล้วเมื่อต้นปี โดยทยอยตรวจสอบความเรียบร้อยและออกรุ่นซอฟต์แวร์ต่าง ๆ ดังนี้:

• libdatrie 0.2.7
  • แก้ไขประเด็นเรื่อง portability เกี่ยวกับ void pointer arithmatics ซึ่งจะมีปัญหากับคอมไพเลอร์ที่ไม่ใช่ GCC โดยได้รับรายงานจากคุณ Mikhail Korobov ว่าคุณ Gabi Daver ได้พบปัญหานี้ขณะคอมไพล์ด้วย Visual C++ พร้อมแพตช์แก้
  • ระหว่างแก้ ได้ทดลองคอมไพล์ด้วยตัวเลือก -Wall ทำให้เจอ warning เพิ่มเติม และแก้ไขจนหมด
  • เขียน test case เพื่อให้สามารถตรวจสอบความถูกต้องเวลาแก้โค้ดได้ในอนาคต ที่ผ่านมาจะทดสอบผ่าน libthai เป็นหลัก แต่เขียน test case เป็นเรื่องเป็นราวน่าจะสะดวกกว่า ซึ่งในระหว่างที่เขียน test case ก็ทำให้ได้อ่านเอกสารประกอบและแก้ไขที่ผิด พร้อมกับได้เพิ่ม API เพื่อความสะดวกในการใช้งานด้วย
  • ปรับ Doxyfile ที่ใช้สร้างเอกสาร เพื่อตัดสิ่งที่เลิกใช้แล้วใน doxygen 1.8.4
  • ออก libdatrie 0.2.7.1 ตามมา หลังจากพบว่าลืมปรับค่า library version เพื่อให้ SONAME สะท้อนการเพิ่ม API ที่เกิดขึ้น
  • อัปโหลด 0.2.7.1-1 เข้า Debian sid
• thaixfonts 1.2.6
  • มีการปรับระบบ build ตาม autoconf รุ่นใหม่ และเปลี่ยนมาใช้ XZ tarball แทน GZ tarball ซึ่งเป็นสิ่งที่ทำไว้นานแล้ว ก็ออกรุ่นมาเพื่อปรับตามซอฟต์แวร์อื่นเท่านั้น ส่วนตัวเนื้อหาฟอนต์ไม่มีการเปลี่ยนแปลงอะไร
  • อัปโหลด 1:1.2.6-1 เข้า Debian sid
• LibThai 0.1.20
  • ปรับข้อมูลพจนานุกรมตัดคำตามที่พบกรณีต่าง ๆ ในช่วงที่ผ่านมา [เกร็ด: รุ่นนี้รู้จักอำเภอขนอมที่ไม่ใช่ ขน-อม แล้ว ;-)]
  • แก้ compiler warning ที่พบใน test case ต่าง ๆ
  • อัปโหลด 0.1.20-1 เข้า Debian sid
• TeX hyphenation patterns
  • sync ข้อมูลพจนานุกรมตัดคำจาก libthai เข้าไปที่ ThaiLaTeX SVN พร้อมกับปรับแก้ hyphenation patterns ตามข้อมูลใหม่
  • แจ้งไปที่โครงการ tex-hyphen ว่าขอปรับข้อมูล hyphenation patterns ภาษาไทย พร้อมกับรายงานปัญหาของสคริปต์บางตัวที่ใช้สร้างข้อมูลอัตโนมัติ คุณ Mojca Miklavec ก็ได้ช่วยแก้สคริปต์ให้ (rev 652, 653) และรับแพตช์ปรับข้อมูลภาษาไทยไปรวมให้ (rev 654)
  • สอบถามและขอ import source ของ hyphenation patterns ภาษาไทยเข้าใน tex-hyphen โดยตรง เพื่อที่ต่อไปจะได้ไปทำงานที่นั่นแทนที่จะต้องผ่าน ThaiLaTeX แบบนี้ ทั้งนี้เพื่อให้เป็นไปตามแผน ที่เคยคุยกันไว้ จนกระทั่งได้ import source ใน rev 655
  • ไม่มีการอัปโหลดอะไรใน Debian แค่รอ Debian อัปเดตแพกเกจ texlive-base เท่านั้น
  • request ขอลบ thailatex ออกจาก Debian unstable เพื่อไม่ให้มีซอร์สตกค้างอยู่ (ลบแล้ว)
• swath 0.5.1
  • แก้รหัสตัดคำของ Lambda จาก U+200C (ZWNJ) เป็น U+200B (ZWSP) ...ว่าแต่มีใครใช้ฟีเจอร์นี้ไหมเนี่ย?
  • sync ข้อมูลพจนานุกรมตัดคำจาก ThaiLaTeX/hyph-utf8 (ซึ่ง sync มาจาก LibThai อีกที) เพื่อให้ตัวตัดคำ LaTeX ทำงานสอดคล้องกับ hyphenation patterns
  • ก่อนออกก็ปรับซอร์สโค้ดของ swath เพื่อให้แต่ละรุ่นมีการปรับปรุงด้านความปลอดภัยไปทีละน้อย โดยในรุ่นนี้ได้ป้องกัน buffer overflow ใน file filter ต่าง ๆ (ยังมีให้แก้อีกเยอะในรุ่นถัด ๆ ไป :-P )
  • อัปโหลด 0.5.1-1 เข้า Debian sid
• IBus-LibThai 0.1.2
  • แก้ปัญหาการกด shortcut (เช่น Ctrl-C) ใน IBus 1.5 อันเนื่องมาจากการเชื่อมรวมกับ XKB ของ IBus รุ่นนี้ ทำให้ผังแป้นพิมพ์ที่ระบุใน metadata ของ IBus-LibThai ว่าเป็น th ทำให้กด Ctrl-C ได้เป็น Ctrl-แ เสมอ แก้ไขโดยปรับผังแป้นพิมพ์เป็น us เท่านั้น
  • อย่างไรก็ดี การแก้ปัญหาในรายการที่แล้วทำให้เกิดปัญหาใหม่ คือทำให้กด accelerator ใน GUI ที่แปลเป็นไทย (เช่น Alt-ฟ เพื่อเรียกเมนู แฟ้ม) ไม่ได้ วิธีแก้ที่เหมาะสมจึงควรให้ IBus-LibThai พยายามแปลง key event ที่มีการกดปุ่มประกอบให้เป็นภาษาไทย แต่ปรากฏว่าไม่สามารถส่ง event ที่แปลงแล้วกลับไปหา event queue ได้ เนื่องจากฟังก์ชัน ibus_engine_forward_key_event() ไม่ทำงานอย่างที่คาด งมอยู่นานก็ไม่สามารถแก้ได้ เวลามีจำกัดจึงใช้วิธีกำหนดผังแป้นพิมพ์เป็น us,th เพื่อให้ GTK+ กับ XKB ไปคุยกันเอง ซึ่งก็ได้ผล แต่ปัญหาคือ มันจะแปลงอักขระตามผังเกษมณีเท่านั้น ใครใช้ผังปัตตะโชติใน IBus-LibThai ก็จะงง ไว้หาวิธีแก้ต่อไปในรุ่นหน้า
  • เพิ่มการรองรับการป้อนเลขไทยด้วยแป้นตัวเลข โดยอาศัยการกด CapsLock ล็อคไว้ หรือใช้การยกแคร่ระดับ 3 (Alt ขวา) อนึ่ง ตามที่เคยได้ ออกแบบไว้ เมื่อสองปีก่อนนั้น จะใช้ ScrollLock ไม่ใช่ CapsLock เนื่องจาก CapsLock จะไปเพิ่มขั้นตอนขณะสลับภาษาไปเป็นภาษาอังกฤษที่จะต้องปลด CapsLock อีกขั้นหนึ่งด้วย แต่ในครั้งนี้ได้ตัดสินใจเปลี่ยนเป็น CapsLock ด้วยเหตุผลสองประการ ประการแรกคือการตรวจสอบสถานะของ ScrollLock ด้วย API ของ IBus เป็นไปได้ยาก เพราะไม่มีการเตรียมการรองรับไว้ ประการที่สองคือในแป้นพิมพ์ย่อส่วน เช่นแป้นพิมพ์โน้ตบุ๊ก หลายรุ่นได้ตัดปุ่ม ScrollLock ออกไปแล้ว ตามที่ วิกิพีเดียว่าไว้ (โน้ตบุ๊กผมก็ไม่มี)
  • อัปโหลด 0.1.2-1 เข้า Debian sid

งานแปล

• ตรวจทาน คำแปล GNOME ตามที่มีผู้ส่งคำแปลเข้ามา โดยที่ผมไม่ได้แอคทีฟตามแปลเองอีกต่อไปแล้ว
• แปล Xfce เป็นไทย เพิ่มเติม โดยล่าสุด ได้แปล core package ต่าง ๆ ครบแล้ว พร้อมกับปรับคำแปลทั้งหมดจาก master กลับไปที่ branch xfce-4.10 ด้วย และแปลปลั๊กอินที่ผมใช้อีกนิดหน่อยเพิ่มเติม ทำให้ขณะนี้อัตราการแปลของภาษาไทยอยู่ที่ 54% แล้ว

blog นี้ก็เลยยาวหน่อย ขอขอบคุณทุกท่านที่ติดตามครับ

Thanks, and the June Diary

เดือนมิถุนายนที่ผ่านมา อ.พฤษภ์ บุญมา ได้หย่อนสตางค์ลงหมวกเพื่อสนับสนุนงานพัฒนาของผม ขอขอบคุณอีกครั้งครับ

สำหรับเดือนมิถุนายนที่ผ่านมา งานหลักก็ยังคงเป็นโครงการอักษรอีสานยืนพื้น โดยมีการตัดสินใจลงมือกระทำบางอย่าง คือ

• ตั้งกลุ่มอักษรอีสานใน Facebook เพื่อเรียนเชิญอาจารย์ผู้เชี่ยวชาญอักษรอีสานมาช่วยให้ข้อแนะนำ หลังจากที่ผมได้พบผู้รู้ทาง Facebook มาหลายท่านก่อนหน้านี้
• ตัดสินใจใช้รหัสยูนิโค้ด U+0324 COMBINING DIAERESIS BELOW แทนตัวสะกดแม่กกจุดคู่ในอักษรธรรมอีสานไปพลางก่อน โดยปรับเพิ่มทั้งในฟอนต์โคตรบูรณ์ และ ระบบป้อนข้อความล้านช้าง พร้อมกันนี้ก็ได้ปรับปรุงร่างข้อเสนอขอเพิ่มอักขระอักษรธรรมเพื่อให้อ้างอิงได้สะดวกในตัวเองด้วย
• ทดลองใช้ระบบวิราม (virama) สำหรับตัวเฟื้องของอักษรไทน้อยที่ยืมมาจากอักษรธรรม โดยทดลองใช้กับการปริวรรตหนังสือใบลานเรื่อง พญาคันคาก ปรากฏว่า Pango/Harfbuzz มันวาดให้ใน GTK+ ขณะเตรียมข้อมูลก็จริง แต่ Firefox ไม่ยอมวาดตัวเฟื้องบนเว็บให้ คาดว่าระบบจัดแสดงข้อความของ Firefox คงมีการกลั่นกรองอักขระยูนิโค้ดเข้มงวด ทำให้ได้แนวทางว่าควรจะถอยมาใช้วิธีกำหนดอักษรเป็นตัว ๆ ตามแนวทางเดิมของอักษรไทย-ลาวไปพลางก่อน เมื่อได้ข้อกำหนดที่เป็นมาตรฐานสุดท้ายแล้วค่อยมาปรับแก้ตามมาตรฐานทีหลัง
• ตัดลำดับ SAKOT + อ อักษรธรรมออกจากฟอนต์โคตรบูรณ์ เพราะเป็นลำดับที่ไม่ถูกต้อง แต่ผู้ใช้มักจะชอบใช้มากกว่าจะใช้สระออล่าง (U+1A6C) ที่ถูกต้อง เพื่อป้องกันการเกิดข้อมูลที่ผิดมาตรฐาน จึงตัด fallback นี้ออก
• ปรับวิธี map ปุ่มในระบบป้อนข้อมูลล้านช้าง จากเดิมที่ map อักขระ ASCII ไปเป็นอักษรธรรม มาเป็นการ map จากตำแหน่งปุ่มโดยตรง เนื่องจากการ map จาก ASCII จะมีปัญหาเมื่อผู้ใช้พยายามสลับผังแป้นพิมพ์ด้วย XKB แทนการสลับ IBus engine โดยในผังแป้นพิมพ์ไทยจะยังมีบางปุ่มที่เป็นอักขระ ASCII อยู่ เช่น / - , . ? แต่พอผู้ใช้พยายามกดอักขระเหล่านี้ในผังแป้นพิมพ์ไทย ล้านช้างจะแปลงอักขระเหล่านี้เป็นอักษรธรรมเสีย ซึ่งไม่ใช่สิ่งที่ผู้ใช้ต้องการ
• ปรับโค้ดใน IBus-LibThai ในทำนองเดียวกันด้วย (ผมเคย blog ไปแล้ว ว่า IBus-LibThai สำหรับภาษาไทยนั้น เกิดขึ้นได้ด้วยแรงกระตุ้นจากโครงการอักษรอีสาน แม้การพัฒนาในระยะต่อมาก็ยังเป็นจริงอยู่ IBus-LibThai นั้น เข้า Debian และ Ubuntu ไปแล้ว แต่ IBus-Lanxang ยังต้องรอความชัดเจนอีกสักหน่อยเกี่ยวกับตัวมาตรฐาน)

งานอื่นที่เกิดขึ้นในเดือนมิถุนายน:

• ปรับคำแปล ISO 3166-2 ในโครงการ iso-codes โดยอ้างอิงหนังสือแผนที่ภูมิศาสตร์ ทำให้คำแปลปรับจาก (732 translated, 218 fuzzy, 3749 untranslated) ไปเป็น (1829 translated, 58 fuzzy, 2812 untranslated)
• edit แผนที่ OSM ในกรุงเทพฯ และขอนแก่น อันเป็นควันหลงจากงาน INET Bangkok 2013 และ Netizen Meetup โดยได้รับความร่วมมือจากสมาชิก KKLUG ด้วย

สำหรับเดือนกรกฎาคมนี้ ก็คงจะเดินหน้าโครงการอักษรอีสานต่อไปครับ โดยจะไปเน้นที่อักษรไทน้อยมากขึ้น

Esaan Scripts as Learned

ย้อนกลับมาเขียนถึงกิจกรรมใน โครงการอักษรอีสาน สักหน่อย ซึ่งขณะนี้ได้กลายเป็น กิจกรรมกลุ่ม มาระยะหนึ่งแล้ว ทุกคนอาศัยเวลาว่างมาช่วยกันศึกษาจนเริ่มจะเกิดองค์ความรู้ขึ้นบ้างแล้ว

ที่ดูจะคืบหน้ามากกว่าก็จะเป็นอักษรธรรม ซึ่งผิดคาด เดิมนั้นนึกว่าอักษรไทน้อยจะง่ายกว่า เนื่องจากอักขรวิธีใกล้เคียงกับอักษรลาวและไทยปัจจุบันมากกว่า แต่พอลงมือศึกษาจากใบลานจริงกลับพบความแปรปรวนของอักษรสูงมาก รูปร่างตัวอักษรเดียวกันจะมีรูปแบบหลากหลาย รวมทั้งลายมือส่วนใหญ่จะหวัดอ่านยากเมื่อเทียบกับอักษรธรรม

เรื่องความแปรปรวนนั้น อักษรธรรมมีน้อยกว่า อาจเป็นเพราะความเป็นอักษรศักดิ์สิทธิ์ และมักจดจารโดยผู้คงแก่เรียน จึงเคร่งครัดกฎระเบียบมากกว่า ทำให้รูปร่างอักษรเปลี่ยนแปลงตามกาลเวลาน้อยกว่าด้วย

ที่ผ่านมา เราได้ทดลองปริวรรตใบลาน ดังนี้:

อักษรธรรม

• บทสูดขวัญ จารึกเป็นภาษาลาว พบในประเทศไทย (ผู้ปริวรรตหลักคือผมเอง)
• โวหารโพธิ (โพธิปักขิยธรรม) จารึกเป็นภาษาลาวปนบาลี พบที่หลวงพระบาง (ผู้ปริวรรตหลักคือคุณอันธิฌา)

อักษรไทน้อย

• พญาคันคาก พบที่เวียงจันทน์ (ปริวรรตร่วมกัน)
• ฮีตคองคะลำ พบที่ประเทศไทย (ปริวรรตร่วมกัน)
• ปาบู่ทอง พบที่เวียงจันทน์ (ผู้ปริวรรตหลักคือคุณกัลยา)

จะเห็นว่าใบลานอักษรไทน้อยมีความคืบหน้าน้อยกว่า เพราะแกะยากกว่า แกะไปต้องพลิกตำราไป ซึ่งบางทีก็ไม่ช่วยอะไร จึงมาเริ่มหาใบลานที่แกะง่ายก่อน ซึ่งก็พบเรื่องปาบู่ทองที่อักขรวิธีคล้ายอักษรลาวปัจจุบันมาก มีการใช้วรรณยุกต์เอก-โทแล้ว และลายมือก็เป็นระเบียบอ่านง่าย

เรื่องขององค์ความรู้ ขณะนี้จึงถือได้ว่าเราได้องค์ความรู้อักษรธรรมมากกว่า กล่าวคือ:

• เริ่มแกะใบลานได้คล่องแคล่วขึ้น สามารถปริวรรตได้วันละหลายแผ่น สามารถดึงบริบทมาวิเคราะห์คำที่อ่านยากได้
• ได้พบตัวอย่างอักขรวิธีซึ่งช่วยคลี่คลายข้อสงสัยต่าง ๆ ที่เคยลิสต์ไว้ ทั้งในบล็อก และในสมุดจด เช่น:
  • ได้พบการใช้สระอาสูงกับอักขระอื่นที่ไม่ใช่ ว ใน โวหารโพธิ
  • ได้พบการใช้ ช เฟื้องที่รูปคล้ายสระออล่างใน โวหารโพธิ ซึ่งเป็นหลักฐานที่สอดคล้องกับ พระยาหลวงมหาเสนา (ผูย) จาก ส.ป.ป. ลาว และตำราของ อ.เพ็ญพักตร์ ลิ้มสัมพันธ์ จาก ม.ศิลปากร แต่ขัดกับตำราอื่นในภาคอีสานของไทย (เช่น จาก อ.วัฒน ศรีสว่าง จาก ร.ร. สว่างวีระวงศ์ อุบลฯ, อ.ยุทธพงศ์ มาตย์วิเศษ จาก มรภ. กาฬสินธุ์, โครงการอนุรักษ์ใบลานฯ จาก ม.มหาสารคาม)
  • ได้พบตัวอย่างการใช้ ส เฟื้อง สะกดแม่กด (ไม่ใช่แค่การใช้ ฑ สะกด) ใน บทสูดขวัญ นับเป็นการคลี่คลายประเด็นการใช้ ส เฟื้องสะกดที่พูดถึงในเอกสารของ อ.วัฒน ศรีสว่าง ในหน้า ๑๗ ที่กล่าวถึงวิธีเขียนของ อ.มนัส สุขสาย
  • ได้พบความแตกต่างระหว่างสระแอย่อกับไม้กงในทั้ง บทสูดขวัญ และ โวหารโพธิ ซึ่ง ตารางรหัสยูนิโค้ด ปัจจุบันยังไม่สามารถแยกแยะได้ ถือว่าได้พบหลักฐานที่สามารถใช้อ้างอิงได้
  • ได้พบตัวอย่างของตัวสะกดแม่กกโดยใช้จุดคู่ใต้พยัญชนะใน บทสูดขวัญ ซึ่ง ตารางยูนิโค้ด ปัจจุบันก็ยังไม่รองรับ แต่ตำราต่าง ๆ ในภาคอีสานล้วนกล่าวถึงตัวสะกดรูปนี้ทั้งสิ้น ถึงแม้ในการประชุมครั้งหนึ่ง ผู้เชี่ยวชาญอย่าง อ.ธวัช ปุณโณทก จะไม่ยอมรับว่ามีก็ตาม โดยท่านมองว่าคือ cryptogrammic dot (U+1A7F) แต่จากตัวอย่างการใช้จุดเข้ารหัสคำในใบลานล้านนาที่ผมเคยพบ ก็คิดว่าเป็นคนละเรื่องกัน หลักฐานที่พบนี้น่าจะสามารถใช้อ้างอิงได้
  • ได้พบตัวอย่างการเขียนพยัญชนะไว้เหนือพยัญชนะฐานอีกมากใน บทสูดขวัญ ไม่ใช่แค่ TAI THAM CONSONANT SIGN LOW PA (U+1A5A) ที่กล่าวถึงใน ตารางยูนิโค้ด ปัจจุบัน ซึ่งตรงนี้คงต้องถกกับผู้เชี่ยวชาญต่อไป

อักษรธรรม ได้มาถึงขั้นนี้แล้ว ก็คงศึกษาเพื่อความกระจ่างเพิ่มขึ้นต่อไป ส่วนอักษรไทน้อย ได้แต่หวังว่าจะตั้งต้นได้สักที

Lanxang Project

กลับมาพูดถึง โครงการอักษรอีสาน อีกครั้ง โครงการนี้ถ้านับตั้งแต่เริ่มวางแนวคิด ตอนนี้ก็อายุได้ 2 ปีเต็มพอดี ที่ผ่านมาก็ได้ทำ ฟอนต์โคตรบูรณ์ โดยใช้ฟอนต์ อ.สานิตย์ เป็นฐาน เอามาปรับให้เป็นยูนิโค้ด และเพิ่มกฎ GSUB ในระหว่างที่ rendering engine ต่าง ๆ ยังไม่รองรับ

ความคืบหน้าล่าสุด หลังจากที่ได้ตั้งกลุ่มทำงานอักษรอีสานร่วมกับคุณอันธิฌาและคุณเสกสรร ก็ได้เพิ่มความเข้มข้นในการศึกษาจารึกโบราณมากขึ้น โดยในระหว่างปริวรรตจารึกลงเว็บ ก็พบความไม่สะดวกในการป้อนข้อความตาม phonetic order ของยูนิโค้ด และเนื่องจากทีมงานเริ่มมีความเข้าใจอักษรธรรมกันพอสมควรแล้ว จึงได้ประชุมกันออกแบบ input method สำหรับอักษรธรรมลาว/อีสาน

โค้ดอยู่ใน github โดยใช้ชื่อโครงการว่า ล้านช้าง โดย input method นี้จะมีคุณสมบัติดังนี้:

• มีผังแป้นพิมพ์ในตัว โดยดัดแปลงจากผัง มอก. 820-2538
• สลับลำดับการพิมพ์ เพื่อให้ผู้ใช้สามารถป้อนข้อความในลำดับจากซ้ายไปขวาเหมือนอักษรไทย แล้ว input method จะสลับลำดับให้เป็น phonetic order ตามข้อกำหนดยูนิโค้ดให้
• ตรวจลำดับการพิมพ์ คล้าย วทท. 2.0 โดยสามารถปรับแต่งระดับความเข้มงวดของการตรวจสอบได้ 3 ระดับ คือปล่อยผ่าน, ตรวจสอบขั้นพื้นฐาน (สามารถป้อนตัวสะกดแบบพิเศษได้) และตรวจสอบแบบเข้มงวด (ไม่อนุญาตตัวสะกดแบบพิเศษ)

ผังแป้นพิมพ์จะเป็นแบบนี้:

ส่วนตารางการตรวจลำดับที่ได้จากการออกแบบร่วมกันของทีมงาน จะเริ่มจากการแบ่งคลาสของอักขระดังนี้:

1. LV = สระหน้า
2. AV = สระบน (อิ อี อึ อื ไม้กง ไม้เกาห่อนึ่ง)
3. AD1 = ตัวสะกดบน (ไม้ซัด ไม้อังแล่น)
4. AD2 = ตัวสะกดบน/สระบน (นิคหิต)
5. BV1 = สระล่าง 1 (อุ อู)
6. BV2 = สระล่าง 2 (ออล่าง)
7. FV1 = สระหลัง 1 (อะ)
8. FV2 = สระหลัง 2 (อา อาสูง)
9. FV3 = สระหลัง 3 (ออย)
10. IV = สระลอย (อิ อี อุ อู เอ โอ ลอย, ฤ ฦ)
11. C1 = พยัญชนะที่เฟื้องด้วยพินทุได้
12. C2 = พยัญชนะที่เฟื้องด้วยพินทุไม่ได้ (ฃ ฅ ซ ฝ ฟ หยอหยาดน้ำ ร ล ฬ อ ฮ สอสองห้อง)
13. PH = พินทุ (SAKOT)
14. S1 = เฟื้องพิเศษ 1 (ระวง)
15. S2 = เฟื้องพิเศษ 2 (ล เฟื้องล่าง, ล เฟื้องข้าง)
16. T = วรรณยุกต์
17. LG = ตัวประสม (แล)
18. CR = ตัวรหัสลับ (cryptogram)
19. NP = ตัวเลขและเครื่องหมายวรรคตอน

จากนั้น ก็จะพิจารณาการกระทำระหว่างอักขระที่อยู่หน้าเคอร์เซอร์กับอักขระที่กด โดยกำหนดรหัสการกระทำดังนี้:

• P = เข้าสู่ pre-edit mode
• A = รับอักขระ
• W = รับอักขระโดยสลับกับอักขระก่อนหน้า
• R = ไม่รับอักขระ
• S = ไม่รับอักขระในโหมดเข้มงวด รับอักขระในโหมดปกติ

และพิจารณาการกระทำจากตารางนี้:

c0,c1	X	L V	A V	A D 1	A D 2	B V 1	B V 2	F V 1	F V 2	F V 3	I V	C 1	C 2	P H	S 1	S 2	T	L G	C R	N P
X	R	P	R	R	R	R	R	R	R	R	A	A	A	R	R	R	R	A	R	A
LV	R	P	A	A	S	S	S	A	A	S	A	A	A	A	W	A	A	A	A	A
AV	R	P	R	R	A	R	A	S	A	S	A	A	A	A	R	A	A	A	A	A
AD1	R	P	R	R	R	R	R	S	S	S	A	A	A	A	R	A	A	A	A	A
AD2	R	P	R	R	R	R	R	S	A	S	A	A	A	S	R	R	A	A	R	A
BV1	R	P	S	A	A	R	R	S	S	S	A	A	A	S	A	R	A	A	R	A
BV2	R	P	R	A	R	R	R	A	R	R	R	A	A	S	R	R	A	A	R	A
FV1	R	P	R	R	R	R	R	R	R	R	A	A	A	R	R	R	R	A	R	A
FV2	R	P	R	A	R	R	R	A	R	R	A	A	A	A	R	A	R	A	A	A
FV3	R	P	R	R	R	R	R	R	R	R	A	A	A	R	R	R	R	A	R	A
IV	R	P	A	R	R	R	R	R	R	R	R	A	A	R	R	R	R	A	R	A
C1	R	P	A	A	A	A	A	A	A	A	A	A	A	A	A	A	A	A	A	A
C2	R	P	A	A	A	A	A	A	A	A	A	A	A	A	A	A	A	A	A	A
PH	R	P	R	R	R	R	R	R	R	R	R	A	R	R	R	R	R	R	R	R
S1	R	P	A	A	A	A	A	A	A	A	A	A	A	A	R	R	A	A	A	A
S2	R	P	A	A	A	A	S	A	A	A	A	A	A	S	R	R	A	A	A	A
T	R	P	R	R	R	R	R	A	A	A	A	A	A	A	R	R	R	A	A	A
LG	R	P	R	R	R	R	R	A	R	R	A	A	A	A	R	R	A	A	A	A
CR	R	P	A	A	A	A	A	A	A	A	A	A	A	S	A	A	A	A	A	A
NP	R	P	R	R	R	R	R	R	R	R	A	A	A	R	R	R	R	A	R	A

ตารางการกระทำในโหมด pre-edit:

P	X	L V	A V	A D 1	A D 2	B V 1	B V 2	F V 1	F V 2	F V 3	I V	C 1	C 2	P H	S 1	S 2	T	L G	C R	N P
LV	R	R	R	R	R	R	R	R	R	R	R	C	C	R	R	R	R	R	R	R

การกระทำ C = commit อักขระใน pre-edit string โดยกลับลำดับจากหลังมาหน้า

ขณะนี้ engine สำหรับ IBus เริ่มใช้การได้แล้ว โดยกำลังอยู่ระหว่างทำ GUI สำหรับตั้งค่า:

สำหรับตอนนี้อาจใช้ IBus เป็นหลัก แต่ในอนาคตก็อาจพิจารณาเพิ่ม engine สำหรับ framework อื่นตามความจำเป็น

ว่าแล้วก็ทดสอบ input method สักหน่อย:

ᨹᩲᩅᩣᨾᩮᩨᩬᨦᩎᩈᩣ᩠ᨶᩌᩣ᩠ᨦ ᩈᩥᨧᩪᩙᨡᩯ᩠ᨶᨾᩢ᩠ᨶᨸᩲᨷᩮᩥ᩠ᨦ
ᨠᩫ᩠ᨠᩋᩭᨿᩢ᩠ᨦᩈ᩠ᩅ᩠ᨿᩃ᩠ᩅ᩠ᨿ ᨠᩫ᩠ᨠᨠᩖ᩠ᩅ᩠ᨿᨿᩢ᩠ᨦᩈᩣ᩠ᨿᩃᩣ᩠ᨿ
ᨾᩢ᩠ᨶᩈᩥᩌᩣ᩠ᨦᨷᩬᩁᨧᩢ᩠ᨦᨯᩲ

(จะอ่านได้ ก็ติดตั้งฟอนต์ ก่อนนะครับ และควรเปิดด้วย Firefox หรือ IE9 จึงจะอ่านเป็นคำ ส่วน Chrome และเบราว์เซอร์ที่ใช้ WebKit ทั้งหมดนั้น ยังแสดงผลผิดลำดับ อ่านไม่เป็นคำครับ)