Mozilla IME Surrounding Patch

Firefox 3.5 ก็ออกไปแล้ว ก็ได้เวลามาทำงานกับ Mozilla ต่อ เดิมเคย blog ไว้ หลายรอบแล้ว ว่าบั๊กต่อไปที่จะดู คือ Mozilla #353776 คือเรื่องการรองรับการป้อนข้อความแบบตรวจลำดับภาษาไทยโดยอาศัยบริบท แต่จำเป็นต้องรอทำหลัง Firefox 3.5 เพราะบั๊กเดิมเรื่องปุ่ม Delete ลบทีละเซลล์นั้น มีผลข้างเคียงเยอะกว่าที่คิดไว้ ต้องตามแก้อีกหลายระลอก ตามที่เคยเล่าไปแล้วใน blog ที่ว่า

มาที่บั๊กใหม่ ปัจจุบันนี้ ถ้าใช้ Firefox/xulrunner บนโลแคลไทยในลินุกซ์ มันจะตรวจลำดับการป้อนภาษาไทยให้แบบชั่วคราว คือจะจำอักขระล่าสุดไว้ แล้วดูว่าอักขระถัดไปสามารถประสมได้หรือเปล่า แต่ถ้ามีการเลื่อนเคอร์เซอร์เกิดขึ้น ก็จะเลิกตรวจทันที โดยจะปฏิเสธสระบน/ล่างและวรรณยุกต์เสมอ จนกว่าจะเริ่มพิมพ์พยัญชนะก่อน ทั้งนี้เพราะระบบป้อนข้อความยังไม่ได้เชื่อมต่อกับโปรแกรมเพื่อขออ่าน/เขียนบัฟเฟอร์ข้อความนั่นเอง

สำหรับคนที่กำลังจะค้านว่า Firefox ที่ใช้ไม่เคยตรวจลำดับเลย นั่นเป็นเพราะคุณใช้โลแคลอังกฤษ ไม่ใช่โลแคลไทย ลองอ่าน blog เก่า ประกอบครับ (อันนี้พูดถึงผู้ใช้ลินุกซ์นะครับ บนแพลตฟอร์มอื่นผมไม่ทราบ)

Mozilla #353776 นี้ จะเสนอให้ทำทางเชื่อมต่อระหว่างระบบป้อนข้อความกับตัว editor ใน xulrunner เพื่อให้การตรวจสอบลำดับสามารถทำกับบริบทได้ทุกเมื่อ ไม่ว่าเคอร์เซอร์จะเลื่อนไปไหน

ในบั๊กนั้น Akira Tagoh ได้เสนอแพตช์ไว้เมื่อสามปีก่อน แต่ยังไม่มีการตรวจรับแพตช์ ปัจจุบันแพตช์ก็ใช้กับโค้ดใน trunk ไม่ได้เสียแล้ว ผมจึงต้องปรับแพตช์เสียก่อนจึงจะนำมาใช้ได้

แพตช์ค่อนข้างซับซ้อนกว่าบั๊กก่อน ๆ ที่เคยทำมา เพราะต้องมีการเชื่อมโยงในที่ต่าง ๆ หลายที่ ปรับไปปรับมา ผลก็คือ แพตช์ถัดมา สำหรับบั๊กนี้ ซึ่งผมทดสอบแล้ว ใช้การได้ดีครับ ทั้งใน text box และใน HTML editor

ตอนนี้ build ใช้เองจากใน hg ไปก่อน ไว้สักพัก xulrunner deb ของ Debian ได้เข้า sid แล้วค่อยเอามาแพตช์ให้ลองกันอีกทีครับ แล้วก็อาจจะต้องขอแรงผู้ใช้วินโดวส์และแมคให้ช่วยทดสอบแพตช์บนแพลตฟอร์มดังกล่าวด้วย

Purisa also Emboldened

พัฒนาฟอนต์ที่ต้นน้ำที่ LTN ไป ก็มักจะแก้เฉพาะปัญหาที่ตัวเองเจอ หรือมีผู้รายงานผ่านเมลตรงหรือ IRC บ้างเป็นครั้งคราว ลองไปสำรวจตาม distro ที่นำไปใช้บ้าง ถ้าเป็น Debian นั้น ผมก็จะได้รับเมลจากระบบบั๊กอยู่แล้ว หรือดูจาก หน้า PTS เป็นครั้งคราวได้ ที่ผ่านมาก็ได้แก้บั๊กที่ Debian พบอยู่ คราวนี้ลองไปสำรวจที่ Ubuntu บ้าง ก็พบบั๊กที่เกี่ยวข้องกับต้นน้ำอยู่สองรายการ ซึ่งมีผู้รายงานไว้นานแล้ว:

• LP #387872 90-ttf-thai-tlwg-synthetic.conf is not valid against fonts.dtd schema
• LP #313427 [jaunty] some font cannot show characters with diacritics

LP #387872 นั้น แก้ไม่ยาก แค่แฟ้มค่าตั้ง fontconfig ไม่สอดคล้องกับ DTD อันเนื่องมาจากการใช้ attribute ผิดชื่อนั่นเอง ก็แก้ไปแล้วใน SVN

ส่วน LP #313427 ซึ่งเกี่ยวกับฟอนต์ Purisa นั้น อาการคือตัว accent ของตัวอักษรละตินหายไปเมื่อใช้ตัวหนา ซึ่งปัญหาน่าจะมาจากการสังเคราะห์ฟอนต์ของ fontconfig เอง ซึ่งจะมีกฎใน 90-synthetic.conf ในการสังเคราะห์ตัวหนาหรือตัวเอียงที่ขาดหาย แล้วบังเอิญ Purisa เรามีแค่ตัวธรรมดา จึงไปผ่านการสังเคราะห์นี้

วิธีแก้ ก็เพียงแต่เพิ่มตัวหนาและตัวเอียงให้กับ Purisa ก็ทยอยทำมาวันละนิดละหน่อย เนื่องจากตาไม่สามารถสู้แสงมอนิเตอร์ต่อเนื่องได้นาน ประกอบกับสลับไปเซ็ตเซิร์ฟเวอร์ที่โรงเรียนด้วย เลยใช้เวลาหลายวันหน่อย ตอนนี้ก็อยู่ใน SVN เรียบร้อยแล้วครับ

กะว่า ก่อน Karmic จะ feature freeze น่าจะต้องออก thaifonts-scalable อีกรุ่นหนึ่ง แล้วขอ update ผ่าน Debian sync ก็คิดว่าคงดูความเรียบร้อยเกี่ยวกับฟอนต์ TlwgTypo/TlwgTypist และ Purisa ที่แก้ไปในรุ่นนี้ แล้วออกรุ่นใหม่ภายในสิ้นเดือนนี้ ระหว่างนี้ ถ้าใครพบปัญหาในฟอนต์ชุด ttf-thai-tlwg ก็อาจรายงานเข้ามาเพื่อแก้ไขก่อนออกได้ครับ

TlwgTypo Bold Emboldened

ใน ThaiFonts-Scalable 0.4.12 ที่ออกไปเมื่อสัปดาห์ที่แล้วนั้น การเปลี่ยนแปลงส่วนหนึ่งคือเอาการแทนที่จุดสามจุดด้วยจุดไข่ปลาตัวเดียวออกในฟอนต์ monospace เนื่องจากมักสร้างความรำคาญ และทำให้ความกว้างข้อความสั้นลง ผิดธรรมชาติของฟอนต์ monospace

ตอนนี้ก็มาปรับเพิ่มอีกหน่อย โดยปรับไปปรับมาก็พบว่า fontforge รุ่นใหม่กลับมาทำ diagonal hint ได้อีก โดยมีคำแนะนำเพิ่มด้วย ว่า ควรเปิดใช้ diagonal hint ถ้าจะทำ AutoInstr สำหรับฟอนต์ TrueType ว่าแล้วเลยจัดการตามที่เขาแนะนำ ปรากฏว่าสามารถช่วยลดปัญหา ฟอนต์จางเมื่อใช้พื้นหลังดำ ลงได้บ้าง

ก่อน:

หลัง (สังเกตความเปลี่ยนแปลงที่เลข 4, ตัว M, x, X เป็นต้น):

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

ดูเหมือนคุณวิทยาก็ พบปัญหานี้ แต่ก็ได้แก้ด้วยการออกแบบ glyph ภาษาไทยใหม่หมด

ครั้งนี้ ผมคิดว่าควรจะพยายามปรับดูจริง ๆ จัง ๆ ละ โดยเริ่มลองกับ TlwgTypist ก่อน ด้วยการขยาย stroke อัตโนมัติแบบไม่แยแสการเกยทับกันของเส้น แล้วก็สั่ง merge overlap ซะ แต่พอจะมาทำกับ TlwgTypo ก็เกิดไอเดียว่า แล้วถ้าลองดัดเส้นไม่ให้มันเกยทับกันล่ะ? อาจจะแอบหดบางเส้น ดัดบางเส้นหลบออกไป อย่างละนิดละหน่อย จัดไปจัดมาก็ได้ glyph ตัวหนาแบบที่สองที่โครงสร้างตัวอักษรเดิมยังอยู่ครบ

สังเกตความเปลี่ยนแปลงได้จากรูป ซึ่งแสดงสี่ฟอนต์เทียบกัน คือ TlwgTypewriter ของคุณพูลลาภ ซึ่งไม่มีปัญหาเรื่องตัวหนา, TlwgTypo ก่อนแก้, TlwgTypist ที่ขยาย stroke แบบอัตโนมัติ และ TlwgTypo ที่ขยาย stroke แบบทำมือ:

จะเห็นว่า:

• TlwgTypo ก่อนแก้ ภาษาไทยตัวหนานั้นจะบางกว่าภาษาอังกฤษอย่างเห็นได้ชัด และแตกต่างจากตัวธรรมดาน้อยมากที่ขนาดเล็ก ๆ
• TlwgTypist ที่ขยาย stroke แบบอัตโนมัติ รูปร่างจะไม่เพี้ยนมาก แต่มีจุดดำทึบหลายจุด เช่น ที่ ฑ นางมณโฑ, ฒ ผู้เฒ่า
• TlwgTypo ที่ขยาย stroke แบบทำมือ รูปร่างผิดเพี้ยนบ้างจากการขยับเส้น แต่ไม่น่าเป็นที่สังเกตนัก และฟอนต์ตัวหนาโดยทั่วไปก็ไม่ได้เหมือนตัวธรรมดาเป๊ะ ๆ อยู่แล้ว แต่ตัว rasterize ฟอนต์จะมีอิสระมากขึ้นในการ hint เส้น แทนที่จะต้องเชื่อมติดกันเป็นพืดเสมอ

ต้องทดลองใช้ฟอนต์ไปสักพัก ถึงจะตัดสินใจเลือกเอาแบบไหน แต่ความเห็นเบื้องต้นนั้นมีแนวโน้มจะเลือกแบบทำมือมากกว่า เมื่อเลือกแล้ว ก็คงจะ merge เข้าไปทับในอีกฟอนต์หนึ่ง ถ้าสนใจจะลองทดสอบดู ก็มีใน TLWG SVN แล้วครับ

LibThai 0.1.12 and libthai.la Dropping

ในที่สุดก็ ปล่อย libthai 0.1.12 ออกมาแล้ว โดยในรุ่นนี้ เน้นเรื่องการจัดการ unknown word เป็นพิเศษ นอกเหนือจากเรื่อง การใช้กฎอักขรวิธีเข้าช่วย แล้ว ก็ยังมีการแก้บั๊กจิปาถะที่เกี่ยวข้องที่ไม่ได้ตรวจละเอียดมาก่อน เช่น การ recover จากจุด error ที่เริ่มจากตำแหน่งไกลไปหน่อย ทำให้บางครั้ง unknown word ยาวกว่าที่ควรจะเป็น ก็เป็นอาการที่เคยสังเกตพบตอนท่องเว็บมาบ้าง แต่ก็เพิ่งได้ตรวจสอบจริงจังกับกรณีตัวอย่างคราวนี้เอง

เรื่องถัดมาคือการทำ symbol versioning แบบที่ เคยทำกับ libdatrie มาก่อน ไว้รองรับการเปลี่ยน API ในอนาคต

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

เรื่องถัดไป คือ upload deb เข้า Debian โดยในรุ่นนี้ ผมเริ่มพิจารณาที่จะตัด libthai.la ออกจาก deb package แล้ว เนื่องจากเจ้าเดียวที่ต้องการไฟล์นี้ คือ kdelibs 3.x ตอนนี้ก็ได้ถูกแทนที่ด้วย KDE 4 เป็นที่เรียบร้อยแล้ว แต่ก็ยังคงมีซอฟต์แวร์อีกหลายตัวที่ยังไม่ได้พอร์ตไปยัง KDE 4 ดังมีรายชื่อที่ได้ ประกาศใน mailing list ดังนั้น ถ้าคุณเป็นผู้ใช้ KDE บน Debian หรือ Kubuntu ก็กรุณาสำรวจแพกเกจในรายการดังกล่าว ว่าถ้าถอดถอนแพกเกจ libthai-dev ออกแล้ว ยังทำงานผิดเพี้ยนอย่างไรหรือไม่ เช่น มีจุดที่ตัดบรรทัดภาษาไทยไม่ถูกต้อง ถ้ามี ก็กรุณาแจ้งให้ผมทราบ จะทาง blog นี้ หรือทาง mailing list ก็ได้ครับ ผมจะได้คง libthai.la ใน libthai-dev ไว้ให้

ถ้าถึงเย็นวันเสาร์ (20 มิ.ย. 2552) ที่จะถึงนี้ ยังไม่มีการแจ้งเข้ามา ผมก็จะถือว่าไม่มีความต้องการใช้ libthai กับโปรแกรม KDE 3.x ใน Debian หรือ Kubuntu อีกต่อไป แล้วก็จะตัด libthai.la ออกในแพกเกจใหม่นะครับ

ที่ต้องขีดเส้นตายก็เพราะ ต้องการให้แพกเกจใหม่ที่ upload เข้าสู่ Debian ได้ผ่านเข้าไปยัง Ubuntu Karmic ทันทีด้วย ซึ่งการ sync อัตโนมัติดังกล่าว จะปิดลงในวันที่ 25 มิ.ย. ตาม กำหนดเวลาของ Karmic ครับ

Improved Unknown-Word Boundaries in LibThai

เมื่อตอนที่ออกแบบอัลกอริทึมตัดคำใน libthai นั้น การจัดการคำที่ไม่อยู่ในพจนานุกรม (unknown word) จะไม่เน้นละเอียดมากนัก โดยจะอาศัยการตรวจสอบจุดตั้งต้นพยางค์ถัดไปที่เป็นไปได้อย่างคร่าว ๆ แล้วพยายาม recover ด้วยการหาจุดแรกที่สามารถเริ่มตัดคำต่อได้

การตรวจสอบที่ว่านั้นก็เขียนง่าย ๆ คือถ้าเจอสระหน้า พยัญชนะที่ไม่ได้ต่อท้ายสระหน้า หรือตัว ฤ ฦ ก็ถือเป็นจุดเริ่มพยางค์ให้ทดลองตัดคำเพื่อ recover ได้แล้ว เพราะฉะนั้น ผลลัพธ์จึงอาจดูโง่ ๆ ในบางกรณี เช่น ลองแกล้งมันดูแบบนี้:

> เชล็งบดลนที
เชล็|งบ|ดล|นที

ซึ่งจะดูฉลาดกว่าถ้าจะพยายามเดาว่าคำว่า "เชล็ง" อาจเป็นคำที่ไม่อยู่ในพจนานุกรม มากกว่าจะเดาว่า "เชล็" โดยไม่มีตัวสะกด มีตัวอย่างอื่นที่คุณ cwt เคยทำให้ดูขณะคุยกันทางห้อง #tlwg อีก

การตรวจสอบนั้น ถ้าพยายามใช้กฎละเอียดมาก ก็ต้องชั่งน้ำหนักระหว่างความถูกต้องกับประสิทธิภาพ ถ้าตรวจสอบละเอียดเกินไป อาจเสียเวลาคำนวณนานได้ โดยเฉพาะในอัลกอริทึมของ libthai ที่ใช้วิธีเรียกฟังก์ชันตรวจสอบ isleadable() ทุกรอบที่จะตรวจสอบจุดแบ่งพยางค์ ก็เลยยังชะลอความคิดนี้ไว้ก่อน

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

ก็ดูเป็นทางออกที่ดี ปรากฏว่าสามารถตรวจสอบกรณีซับซ้อนได้ โดยไม่ทำให้ช้าลง กรณีที่ตรวจสอบไปก็คือ:

• พยัญชนะที่มีทัณฑฆาตตามหลังในระยะไม่เกิน 2 อักขระ เป็นจุดตั้งต้นพยางค์ไม่ได้ เช่น ธ์ ธุ์ ธิ์ มณ์
• พยัญชนะที่ตามหลังไม้หันอากาศหรือสระอือโดยอาจมีวรรณยุกต์คั่นหรือไม่ก็ได้ เป็นจุดตั้งต้นพยางค์ไม่ได้ เช่น ขัน ตั้ง มือ ซื้อ ฟื้น
• พยัญชนะที่ตามด้วยไม้ไต่คู้ แล้วตามด้วย อ อ่าง หรือ ว แหวน ตัวพยัญชนะแรกสามารถเป็นจุดตั้งต้นพยางค์ได้ แต่อักขระที่ตามหลังอีก 3 ตัว ไม่สามารถเป็นจุดตั้งต้นพยางค์ได้ทั้งหมด เช่น ช็อก ช็วก
• หากพบสระเอ/แอ:
  • ตัวสระเอ/แอ สามารถเป็นจุดตั้งต้นพยางค์ได้
  • พยัญชนะที่ตามมาเป็นจุดตั้งต้นพยางค์ไม่ได้ เช่น เก แข
  • และถ้าพบต่อไปว่ามีไม้ไต่คู้หรือสระบนต่อท้ายพยัญชนะ (โดยอาจมีวรรณยุกต์ร่วมด้วยหรือไม่ก็ได้) พยัญชนะที่ตามหลังไม้ไต่คู้หรือสระบนนั้นก็ไม่สามารถเป็นจุดตั้งต้นพยางค์ได้เช่นกัน เช่น เก็ง แข็ง เสีย เสือ เสี่ย เสื่อ
  • ถ้าพบว่าอักขระที่สามถัดจากสระเอ/แอ เป็นไม้ไต่คู้ โดยที่อักขระก่อนไม้ไต่คู้ไม่ใช่ ก ไก่ (ถ้าเป็น ก ไก่ จะกลายเป็นคำว่า "ก็") และอักขระถัดจากไม้ไต่คู้ไม่ใช่ อ อ่าง หรือ ว แหวน (ถ้าเป็น จะกลายเป็นพยางค์ใหม่ เช่น "ช็อก") อักขระถัดจากสระเอ/แอ 4 ตัวรวด ไม่สามารถเป็นจุดตั้งต้นพยางค์ได้ทั้งหมด เช่น เขบ็ด เมล็ด
• หากพบสระ โ ใ ไ พยัญชนะถัดไปไม่สามารถเป็นจุดตั้งต้นพยางค์ได้ เช่น โต ใต้ ไท้
• พยัญชนะกรณีอื่น ๆ มีโอกาสเป็นจุดตั้งต้นพยางค์ได้ทั้งหมด
• ฤ ฦ มีโอกาสเป็นจุดตั้งต้นพยางค์ได้
• อักขระอื่น ๆ ที่เหลือ ไม่สามารถเป็นจุดตั้งต้นพยางค์ได้ เช่น สระบน/ล่าง/ข้าง วรรณยุกต์ ทัณฑฆาต ไม้ไต่คู้ นิคหิต

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

ด้วยการตรวจสอบนี้ libthai รุ่นล่าสุดใน SVN จะตัดกรณีตัวอย่างข้างต้นเป็นอย่างนี้แทน:

> เชล็งบดลนที
เชล็ง|บด|ลน|ที

ซึ่งน่าจะให้ขอบเขตของ unknown word ในกรณีทั่วไปได้สมเหตุสมผลกว่า

นอกจากเรื่องนี้แล้ว อีกทางหนึ่งก็ทยอยปรับพจนานุกรมอยู่เรื่อย ๆ ครับ การเพิ่มคำที่พบในชีวิตประจำวันก็จะช่วยลดจำนวน unknown word ลงได้ ทำให้ตัดคำได้ถูกต้องยิ่งขึ้น ถ้าพบ libthai ตัดคำผิดตรงไหน ก็แจ้งเข้ามาได้ทุกเมื่อนะครับ

Update (5 มิ.ย. 2552 21.32 น.): ปรับแก้กฎเกี่ยวกับไม้ไต่คู้ เมื่อมี อ อ่าง หรือ ว แหวน ตามหลัง

Elongation of Some Thai Words

วันนี้ไปเจอกระทู้เก่าใน Pantip ที่มี backlink มายัง blog เก่าเรื่อง ก เอ๋ย ก ไก่ หัวข้อกระทู้คือ เสียงสั้น-เสียงยาวในคำไทยบางคำ

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

ผมเองก็ไม่คิดว่าจะหาหลักการได้ แต่เห็นเป็นประเด็นน่าสนใจ น่าเอามาคิดต่อ

ผมขอเสริมด้วยกรณีกลับกัน คือคำบางคำออกเสียงเป็นเสียงสั้น ทั้ง ๆ ที่สะกดด้วยสระเสียงยาว เช่น เต้น (คำนี้มีพูดถึงในกระทู้เหมือนกัน แต่ไม่ได้ยกให้เป็นประเด็น) เข่น เค้น เซ่น เร้น เผ่น เฟ้น เว้น เส้น เก่ง เข่ง เขย่ง เบ่ง เป่ง เปล่ง เพ้ง เม้ง เร่ง แจ่ม แช่ม แข่ง แข้ง แต่ง แท่ง แน่ง แบ่ง แปร่ง แพ่ง แล่ง แหว่ง แห่ง ย่อม ข้อง คล่อง จ้อง พร่อง ย่อง น่อง ท่อง ค่อน (ปลา)ช่อน ซ่อน ว่อน ร่อน จ่อม(จม) ซ่อม แจ๋ว เจ๊ง เจ๊ก เล่น เล่ม ก้อง กล้อง ก๊อก ป๊อก เด้ง เม้ม เข้ม

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

มีครั้งหนึ่งที่ผมเจอข้อสังเกตเข้าอย่างจัง ตอนที่ไปสั่ง "บะหมี่แห้ง" ที่ร้านอาหารในกรุงเทพฯ โดยออกเสียง "แห้ง" เป็นเสียงสั้นตามความเคยชิน แล้วก็ถูกคนในโต๊ะที่ไปด้วยกันถามว่า เป็นคนต่างจังหวัดเหรอ เพราะสำเนียงกรุงเทพฯ จะออกเสียง "แห้ง" เป็นเสียงยาว

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

ตามสำเนียงถิ่นอีสานแล้ว ในกรณีของกระทู้นั้น มีคำว่า "น้ำ" คำเดียวที่ออกเสียงสระยาว นอกนั้นเป็นเสียงสั้นหมด คือ ไม้ เก้า (ร้อง)ไห้ ได้ ใต้ เจ้า เช้า เท้า เปล่า เพิ่มอีกสักคำในกรณีเดียวกันคือ "ใช้" ก็ออกเป็นเสียงสั้นเหมือนกัน ส่วนอีกคำที่นึกออกคือ "เกล้า" นั้น ไม่มีในภาษาถิ่นอีสาน ถ้าจะออกเสียงก็คงออกเสียงตามสำเนียงกรุงเทพฯ ในฐานะคำไทยกลางมากกว่า

แล้วทำไมคำเหล่านี้ถึงออกเสียงสระยาวในสำเนียงกรุงเทพฯ โดยหาหลักการรองรับไม่ได้? และอันที่จริง เสียงเหล่านี้สามารถเขียนด้วยสระเสียงยาวได้ทั้งนั้น เช่น ม้าย ก้าว ห้าย ด้าย ต้าย จ้าว ช้าว ท้าว ปล่าว ช้าย กล้าว แล้วทำไมจึงยังเขียนด้วยสระเสียงสั้นเหมือนเดิมแต่ออกเสียงให้ยาวขึ้น? ทั้งนี้ บางคำรูปเขียนเดียวกันออกเสียงสองอย่างก็มี เช่น เช้า ออกเสียงยาว แต่ กระเช้า ออกเสียงสั้น; ร้องไห้ ออกเสียงยาว แต่ คร่ำครวญหวนไห้ ออกเสียงสั้น

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

กรณีคล้ายกันนี้เกิดกับคำว่า "เจ้า" ด้วย โดยมีการเขียนเป็น "จ้าว" ตามเสียงที่ออก แต่คำว่า "จ้าว" ค่อย ๆ ตกยุคไป เหลือคำว่า "เจ้า" ใช้แทน ปัจจุบัน แม้จะยังมีคำว่า "จ้าว" ใช้งานอยู่บ้าง แต่พจนานุกรม ฉบับราชบัณฑิตยสถาน พ.ศ. ๒๕๒๕ และ ๒๕๔๒ ต่างก็ให้คำจำกัดความว่า "(โบ) น. เจ้า" คือเป็นคำที่เหมือน "เจ้า" ทุกประการ แต่เป็นรูปเขียนแบบโบราณ

อย่างไรก็ดี กรณีเดียวกันสำหรับคำว่า "เท้า" นั้น เมื่อยืดเสียงออกกลับไปพ้องเสียงกับคำว่า "ท้าว" ที่มีอยู่แล้ว โดยต่างความหมายกัน คือ "ท้าว" หมายถึงผู้เป็นใหญ่ ส่วน "เท้า" หมายถึงตีน กรณีนี้จึงมีการรักษารูปคำไว้ทั้งสองคำ คำว่า "เก้า" กับ "ก้าว" หรือ "ได้" กับ "ด้าย" ก็ทำนองเดียวกัน

เหลือเพียงคำว่า "น้ำ" คำเดียว ที่ยืดพยางค์ออกเหมือนกันหมด ก็ยังคงเป็นปริศนาต่อไป

การที่ผมสันนิษฐานโดยอิงจากภาษาเหนือ-อีสานออกไปนั้น ก็พอมีเหตุผลอยู่บ้าง เนื่องจากภาษาในถิ่นทั้งสอง โดยเฉพาะในถิ่นอีสานนั้น มีลักษณะใกล้เคียงกับภาษาไทย-ลาวดั้งเดิมอยู่มาก ในขณะที่ภาษาไทยกลางปัจจุบันจะผ่านการวิวัฒน์มามาก โดยรับอิทธิพลมาจากภาษาต่างประเทศ เช่น เขมร มอญ มลายู บาลี สันสกฤต จึงมีโอกาสเป็นฝ่ายเริ่มเพี้ยนได้มากกว่า แต่จะเพี้ยนด้วยเหตุใดนั้น ผมไม่มีข้อมูลพอจะระบุได้มากกว่านี้

Pango Patch for SARA AM in VTE

ด้วยฝีมือของ Behdad Esfabod ใน GNOME #149631 ทำให้ vte widget และ gnome-terminal สามารถวาด combining character ได้ตั้งแต่รุ่น 2.26 เป็นต้นมา ..พูดเป็นภาษาไทยก็คือ มีการจัดระดับสระบน-ล่างและวรรณยุกต์เรียบร้อย

ติดอยู่ที่ปัญหาเล็ก ๆ คือ แพตช์นี้เป็นการใช้ pango วาดเซลล์แต่ละเซลล์บนหน้าจอ ซึ่ง pango จะมีการจัดการ cluster แยกร่างสระอำเป็นนิคหิตและลากข้าง เพื่อนำนิคหิตไปวางบนพยัญชนะอย่างถูกต้องสวยงาม แต่บนเทอร์มินัลนั้น สระอำจำเป็นต้องอยู่ในเซลล์ของตัวเองแยกจากพยัญชนะ เวลาที่ vte สั่งวาดทีละเซลล์ สระอำจึงถูกวาดโดยไม่มีพยัญชนะนำหน้า นิคหิตที่ถูกแยกร่างโดยไม่มีพยัญชนะนำหน้า จึงมี dotted circle มารองรับ ทำให้สระอำเปรอะ และกินเนื้อที่ล้ำไปสู่เซลล์ถัดไปด้วย

ปัญหานี้ ทีมสุริยันก็เคยพบกับ konsole ซึ่งในตอนนั้นผมแนะให้เช็กฟอนต์ว่าเป็น monospace หรือไม่ ถ้าเป็น ก็ยอม render สระอำแบบไม่แยกร่าง (เหมือนพิมพ์ดีด) ถ้าไม่เป็น จึงจะแยก (เหมือนเรียงพิมพ์บนแท่นพิมพ์) ตอนนี้ ก็เลยดัดแปลงวิธีนั้นมาใช้กับ pango ด้วย

ผลคือแพตช์ pango-1.24.2-thai-sara-am-mono.patch ครับ

ก่อน:

หลัง:

พร้อมกันนี้ ก็เลย build เป็น deb ไว้ที่ debclub ก้านกล้วย ด้วย เพื่อความสะดวกในการทดสอบ โดยรวมเอาแพตช์แก้เรื่องการเลื่อนเคอร์เซอร์ (pango-1.24.2-thai-grapheme-cluster.patch) ที่เคยทำไว้ตาม blog เก่า (GNOME #576156) ด้วย

เนื่องจากเพิ่งทำเสร็จใหม่ ๆ ยังต้องทดสอบความเรียบร้อยสักพัก แล้วค่อย file bug อีกที