Unicode 6.1 and Thai-Lao Scripts

Blognone ออกข่าว Unicode 6.1 ออกแล้ว โดยมีการกล่าวถึงการแก้ปัญหา Grapheme Cluster Boundaries ซึ่งเป็นปัญหาภาษาไทยใน UAX #29 ผมได้พูดถึงเรื่องนี้ประปรายใน blog เก่า (เช่น เมื่อ 16 มี.ค. 2552 และ 6 ต.ค. 2553) แต่ไม่เคยเขียนถึงเป็นเรื่องเป็นราวโดยตรง

ปัญหาของ UAX #29 ในส่วนของ grapheme cluster boundary นี้ก็คือ มันได้กำหนด cluster ซึ่งเป็นหน่วยที่เล็กที่สุดของการตัดบรรทัดและเลื่อนเคอร์เซอร์ โดยให้สระหน้าและสระหลังของอักษรไทยและลาวถูกนับรวมไปใน cluster เดียวกับพยัญชนะที่มันเกาะ แทนที่จะแยกเป็น cluster อิสระ เช่น:

|เป็|น|เรื่|อ|ง|เป็|น|รา|ว|

แทนที่จะเป็น:

|เ|ป็|น|เ|รื่|อ|ง|เ|ป็|น|ร|า|ว|

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

• GNOME #576156 (Pango)
• Mozilla #474068
• Chromium #3523
• ICU #6774

เรื่องนี้เกิดจากข้อกำหนดเรื่อง extended grapheme cluster ซึ่งใน UAX #29 ฉบับเดิมกำหนดให้สระหน้าของไทย-ลาว (เอ, แอ, โอ, ใอ, ไอ, ເອ, ແອ, ໂອ, ໃອ, ໄອ) มีคุณสมบัติ Grapheme_Cluster_Break เป็นแบบ Prepend และสระหลังของไทย-ลาว (อะ, อา, อำ, ອະ, ອາ, ອຳ) มีคุณสมบัติเป็นแบบ Extend ซึ่งอักษรที่มีคุณสมบัติเหล่านี้จะไม่สามารถยืนเป็น cluster เดี่ยว ๆ ได้ ต้องเกาะไปกับพยัญชนะ โดยแบบ Prepend ต้องเกาะไปกับพยัญชนะที่ตามมา และแบบ Extend ต้องเกาะไปกับพยัญชนะที่มาก่อนหน้า ซึ่งตรงนี้เป็นพฤติกรรมปกติในอักษรตระกูล Indic ซึ่งรวมถึงอักษรพม่าและเขมรด้วย แต่เผอิญเขาอาจจะลืมว่าอักษรไทย-ลาวเป็นอักษร Indic ที่แหกคอก

ความจริงแล้ว UAX #29 ฉบับเดิมได้กำหนดว่า นี่เป็นเพียงพฤติกรรม ปริยาย เท่านั้น ระบบต่าง ๆ สามารถ ดัดแปลง (tailor) ไปตามที่เห็นสมควรได้ แต่นั่นก็ไม่น่าสนใจเพียงพอให้นักพัฒนาระบบต่าง ๆ ดัดแปลง ตามที่ผู้ใช้คาดหวังโดยพร้อมเพรียงได้

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

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

ความจริงก็ได้ยินมาว่ามีตัวแทนจาก Apple ที่อเมริกาเสนอแก้เรื่องนี้ไปรอบหนึ่งแล้วเหมือนกัน แต่ก็ตกไป นั่นยิ่งทำให้เราต้องหาหลักฐานที่หนักแน่นยิ่งขึ้น รายงานบั๊กต่าง ๆ ในโลกโอเพนซอร์สช่วยยืนยันได้ในระดับหนึ่ง แต่หลักฐานในเอกสารจริงว่าไม่มีใครแบ่ง cluster แบบนั้นเลยจะช่วยตีประเด็นได้ผลกว่า ผมได้ขอร้องให้เพื่อน ๆ ช่วยหาตัวอย่างป้ายข้อความแนวดิ่งที่แสดงตัวอักษรทีละช่องโดยเห็นสระหน้า-หลังแยกจากพยัญชนะ ก็ปรากฎว่าหายากเหลือเกิน ส่วนมากป้ายแนวดิ่งจะเขียนทีละพยางค์มากกว่า ในเวลาเดียวกันก็พยายามหาหลักฐานแนวอื่น จนกระทั่งไปเจอ การทำ drop cap ในวารสารที่แสดงให้เห็นการแบ่ง cluster ในเอกสารจริง

ด้วยการประสานงานของคุณ Martin การแก้ข้อกำหนดในครั้งแรก เขาแก้เป็น clustering สองแบบ คือแบบ extended กับแบบ legacy โดยแนะนำให้ใช้แบบ extended ยกเว้นภาษาไทย-ลาวที่อาจจะใช้แบบ legacy แทนได้ ฟังดูเหมือนเริ่มโอนอ่อนลงบ้าง แต่ก็ยังไม่กระตุ้นนักพัฒนามากพออยู่ดี จนกระทั่งคุณ Martin ได้ยื่นหลักฐานภาพ drop cap ของผมเข้าไป ผมเองก็คิดว่าคงได้แค่นั้นแหละ จนกระทั่งมาได้ข่าวจาก Blognone จึงตรวจสอบดู ก็ปรากฏว่าเขาแก้โดยตัดเรื่อง Prepend และ Extend ในส่วนภาษาไทย-ลาวออกไปหมดแล้ว ยกเว้นสระอำ โดยย้ายมาอยู่ในหมวด SpacingMark ซึ่งผลคือจะยังคงให้สระอำเกาะไปกับพยัญชนะนำหน้าต่อไป โดยจะอยู่ในโหมด extended grapheme cluster เท่านั้น ถ้าเป็นโหมด legacy ก็จะให้เคอร์เซอร์ตกหน้าสระอำได้ ส่วนสระหน้า-หลังอื่น ๆ จะแยกเป็น cluster ได้อย่างอิสระตามความคาดหวังของผู้ใช้

งานนี้ต้องให้เครดิตคุณ Martin Hosken เต็ม ๆ ครับ ที่ช่วยประสานงานและชี้แนะแนวทางต่าง ๆ ให้

ขั้นต่อไปคือขอแก้ GNOME #576156 ตามข้อกำหนดใหม่นี้ หรือไม่ก็รอนักพัฒนา Pango ปรับโค้ดใหม่ตามข้อกำหนดใหม่ก็อาจจะเพียงพอ ส่วนในที่อื่น ๆ เช่น ICU และ Chromium เข้าใจว่าเขาแก้ไปนานแล้ว

Mozilla Surrounding Text Support Missing for Mac

ใน blog ที่แล้ว ผมได้รายงานว่าได้ปิด Mozilla #353776 ซึ่งเพิ่มการรองรับ surrounding text สำหรับ input method ไปแล้ว มีผลทำให้ Mozilla รองรับการตรวจลำดับการป้อนภาษาไทยอย่างเต็มที่

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

bact' ได้ตรวจสอบ nightly-built บน Mac แล้ว พบว่ายังไม่รองรับจริง เพราะฉะนั้น คงต้องรายงานบั๊กตัวใหม่ต่างหากเพื่อขอเพิ่มความสามารถนี้ใน Mac และก็คงต้องรอคนที่มี Mac มาช่วยทำให้ครับ

Mozilla IME Surrounding Text Support Checked-in

Mozilla #353776 ซึ่งเป็นบั๊กเสนอเพิ่มการรองรับ surrounding text สำหรับ input method ใน Mozilla ปิดแล้ว ซึ่งหมายความว่า Mozilla ได้รองรับการป้อนภาษาไทยแบบตรวจลำดับตามบริบทอย่างเต็มที่แล้ว

ใน blog ก่อน เกี่ยวกับเรื่องนี้ ผมได้บอกไว้ว่า ต้องรอเขาปิด Mozilla #528396 เพื่อ refactor โค้ดเกี่ยวกับ GTK+ IM Module ก่อน จึงจะกลับมาทำต่อ ปรากฏว่า ในระหว่างงาน Mini-DebCamp ได้รับ ข้อความ จาก Masayuki Nakano (Mozilla Japan) ว่าบั๊กดังกล่าวได้ปิดไปแล้ว และผมสามารถเริ่มทำงานต่อได้แล้ว

ในงาน Mini-DebCamp นั้น ผมยัง present ว่าบั๊กนี้ยังอยู่ระหว่างดำเนินการ…

รอจน Mini-DebCamp เลิก และสร่างจากอาการอดนอนติดต่อกันหลายคืนได้ จึงได้เริ่มมาทำงานต่อ โดยแก้แพตช์ใหม่ตามโครงสร้างโค้ดที่เปลี่ยนไป แล้วเสนอกลับเข้าไปใหม่ ปรากฏว่าเขารีวิวแพตช์ให้อย่างรวดเร็วมาก ภายใน 2 วัน รีวิวและแก้ไป 2 รอบ พร้อม commit ปิดบั๊กเรียบร้อย

ก็เลยมีอีกบั๊กหนึ่งที่เกี่ยวข้อง คือ Mozilla #425900 ที่รายงานว่า ช่องรับข้อความใน Mozilla อนุญาตให้มีสระบน-ล่างภาษาไทยนำหน้าได้ ซึ่งไม่ถูกต้อง แต่ในเมื่อ Mozilla รองรับการตรวจสอบบริบทในการป้อนข้อความแบบนี้แล้ว บั๊กนี้ก็ควรจะหายไปด้วย แต่ทั้งนี้ ผมก็ไม่มีสิทธิ์จัดการกับบั๊กเอง ต้องรอให้คนมีสิทธิ์ หรือเจ้าของบั๊ก (bact') มาตรวจสอบและปิดบั๊กต่อไป

Hardening LibThai

หลังจากผ่าน security update มาแล้ว ก็มีรายการแก้ไขเพิ่มเติมอีกนิดหน่อยจาก การตรวจสอบของทีม RedHat ซึ่งละเอียดน่าประทับใจมาก ก็เป็นการอุดช่องเล็ก ๆ น้อย ๆ เพิ่มเติม พร้อมกับพบ บั๊กใน glib เพิ่มเติมด้วย

แต่อีกประเด็นหนึ่งที่ได้แก้เพิ่ม คืออาการพังที่เคยได้รับรายงานมาหลายครั้งแล้ว แต่ทำซ้ำใหม่ไม่ได้สักที จนกระทั่งมาเจอกรณีที่น่าจะใกล้เคียงที่สุด คือ Debian #569996 ซึ่งพบว่า iceweasel, gedit จะพังถ้าแสดงภาษาไทยโดยแฟ้มพจนานุกรมตัดคำของ libthai เสียหายอยู่

ในบั๊กนั้น ได้ให้ผู้ใช้แก้ปัญหาไปแล้วด้วยการ reinstall libthai-data แต่หลังจากปิดบั๊กไปก็รู้สึกว่าควรจะให้ libthai ยืดหยุ่นกว่านี้ ถ้าพจนานุกรมเสียหายก็ไม่ควรจะพังไปเลย แต่ควรจะแค่ไม่ตัดคำให้เท่านั้น ว่าแล้วก็เข้าไปปรับปรุงส่วน error handling ใน libdatrie และ libthai ตามนั้น

อีกส่วนหนึ่ง ได้รับแจ้งจาก Behdad จาก RedHat ว่าซอร์สโค้ด libthai ไม่ได้แปะสัญญาอนุญาตไว้ที่แฟ้มซอร์สแต่ละแฟ้ม ซึ่งเป็นวิธีที่ชัดเจนที่สุดในการใช้ LGPL ก็เลยแก้เพิ่มด้วยทั้งใน libdatrie และ libthai โดยได้ถือโอกาสจัดแต่งซอร์สโค้ดไปในตัวด้วย

ผลก็คือ libdatrie 0.2.3 และ libthai 0.1.14 ที่ออกไปเมื่อวานและวันนี้ตามลำดับครับ พบได้ใน Debian mirror ใกล้บ้านท่าน

Mozilla Thai IME Support Updated

เข้ากรุงเทพฯ มาหลายวัน ทำตัวเป็นแมลงวันตอมกลิ่น Wi-Fi เพื่อทำงาน เพราะก่อนหน้าที่จะเข้ากรุงนั้น ได้กลับมาทำงานที่ Mozilla #353776 เกี่ยวกับการรองรับการตรวจแก้ลำดับการป้อนภาษาไทยแบบอิงบริบท โดยได้ ส่งแพตช์ที่ยังมีปัญหาอยู่ไป เพื่อขอปรึกษา จากนั้นเลยต้องคอยติดตามความคืบหน้า

เท้าความสักนิด จาก ครั้งล่าสุด ที่ปรับแพตช์จากของ Akira Tagoh จนใช้ได้กับ Mozilla trunk (ซึ่งยังใช้ได้กับ Firefox/Iceweasel 3.5.x และ XULRunner 1.9.1.x) ไปนั้น มีความเห็นจาก Masayuki Nakano (Mozilla Japan) ว่าเป็นวิธีที่ไม่ดีเท่าไร เพราะลงไปแก้หลายจุด หลายเลเยอร์เกินไป ในขณะที่ใน Mozilla trunk นั้น มีการปรับโค้ดในส่วนจัดการ event ของหน้าต่าง ให้รองรับคำสั่งที่จำเป็นสำหรับงานนี้เพียงพอแล้ว สามารถ implement เรื่องนี้ได้ภายในเลเยอร์เดียว

เมื่อลองไล่โค้ดดูก็พบว่าจริง แพตช์เล็กลงเหลือสั้นนิดเดียว แต่พอทดสอบแล้วพบว่ามีปัญหาบางอย่างในการสั่งลบข้อความใน editor buffer เพื่อการแก้ไขลำดับการป้อน จึงได้ส่งแพตช์เข้าไปปรึกษาตามที่กล่าวไปข้างต้น โดยในระหว่างทำงาน ก็เกิดผลพลอยได้ คือพบบั๊กใน gtk-im-libthai และได้ แก้ไปแล้วใน SVN

สำหรับคำถามที่ถามไป ก็ปรากฏว่าได้ คำแนะนำ จาก Masayuki ว่าอาจเป็นบั๊กที่เขาเองก็เจอ (Mozilla #528396) พอเอาแพตช์ของเขามาใช้ร่วมด้วย ก็ปรากฏว่าแพตช์ของผมก็ทำงานได้เลย เพียงแต่ติดปัญหาเรื่องปริมาณการลบที่เราต้องการเจาะจงให้ละเอียดกว่าระดับเซลล์

เขาแนะนำให้ปรับแก้ event ที่เกี่ยวข้อง ก็กลับมาไล่ดู จนได้ แพตช์ที่เวิร์กจริง เป็นอันว่าสำเร็จแล้ว โดยต้องใช้ แพตช์ของ Masayuki ก่อน แล้วจึงตามด้วยแพตช์ของผม พูดอีกอย่างคือ ต้องรอ resolve Mozilla #528396 ก่อน แล้วถึงจะมาดูแพตช์ของผมได้

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

อ้อ.. อาจจะพอเดากันได้ว่าแพตช์นี้ใช้ได้กับ trunk เท่านั้นนะครับ ส่วนถ้าจะเอาไปแพตช์กับ Firefox/Iceweasel 3.5.x หรือ XULRunner 1.9.1.x ก็ต้องใช้ แพตช์เก่า ไปพลางก่อน ซึ่งเป็นแพตช์เดียวกับที่ใช้ใน xulrunner deb ที่ debclub

ทั้งหมดที่ทำมานี้ เล่นเอา Green Wi-Fi ที่ผมสมัครแบบ 1 ชั่วโมง/เดือน เอาไว้ เกือบจะหมดเลยเชียว (ตอนที่สมัครนั้น แบบ unlimited เต็มแล้ว) เลยถาม gumara ดู ว่ามี free Wi-Fi ที่ไหนให้ใช้อีกบ้าง เพื่อจะได้ตามงานต่อ จนวันหนึ่ง ไปนั่งที่จามจุรีสแควร์ เจอ free Wi-Fi แบบอืด ๆ หน่อย และตอน login ต้องเสี่ยงดวงนิด ๆ แต่ก็สามารถทำให้งานลุล่วงไปได้ โดยในระหว่างนั้นก็ใช้ commit งานแปล GNOME ที่ได้ดาวน์โหลด PO มาทำแบบออฟไลน์ตุนเอาไว้ด้วย

เดิมนั้น เวลาเข้ากรุงเทพฯ ผมมักจะออฟไลน์ตลอด แต่คราวนี้เข้ากรุงหลายวัน แถมยังมีงานค้างให้ตามด้วย ก็เลยพยายามดิ้นรนหา Wi-Fi ทำงาน พอดีว่าได้เคยทดลองทำงานผ่าน free Wi-Fi ที่กรุงเทพฯ มาแล้วในครั้งก่อน โดยได้สมัคร Green Wi-Fi เอาไว้ด้วย คราวนี้เลยไม่ต้องเริ่มต้นจากศูนย์ ส่วนตอนนี้ก็กลับมาใช้เน็ตที่บ้านที่ขอนแก่นเรียบร้อยแล้วครับ

เป็นอันว่า บั๊กของ Mozilla ก็เป็นอันเรียบร้อย ต่อจากนี้ก็รอแพตช์เข้ากระบวนการตามขั้นตอนต่อไป

Pango Regression for Thai

ดังที่ได้กล่าวถึงไปใน blog ก่อน ว่า Pango มีการ merge Harfbuzz-ng เข้ามาแล้ว ทำให้มีการแทนที่ OpenType layout engine ด้วยโค้ดที่รื้อเขียนใหม่หมด ซึ่งก็พบว่ามี regression ในส่วนของการวาดภาษาไทย

เดิมนั้น ผมพบจาก GNOME ที่ build ด้วย JHBuild ในเครื่องในระหว่างที่ตรวจคำแปล แต่ยังไม่แน่ใจว่าเป็นโค้ดที่ release หรือยัง ก็เข้าไปถามหาคนที่ใช้ Ubuntu Karmic ในห้อง #tlwg ก็ยังไม่มีใครใช้ (ผมใช้ Debian sid อยู่ เลยยังไม่พบปัญหา) ประกอบกับต้องรีบตรวจคำแปลแข่งกับเวลา ก็เลยเว้นเรื่องนี้ไว้ จนเมื่อวันก่อนได้พบกับ อ.กิตติ์ ที่ใช้ Karmic อยู่ ก็เลยได้คำยืนยัน ว่าปัญหานี้มีใน GNOME รุ่นพัฒนาที่ปล่อยออกมาแล้ว แล้วก็เลยช่วยกันสรุปอาการจาก screenshot ต่าง ๆ จนในที่สุดก็ file GNOME #595539 ไป

อาการเป็นอย่างนี้:

1. cons + tone + vowel จะวาดเป็น cons + NIKHAHIT + tone + vowel
2. cons + tone + whitespace/punct จะวาดเป็น cons + NIKHAHIT + tone + whitespace/punct
3. cons + lower-vowel + tone จะวาดโดยที่ tone ไม่ได้ลดลงต่ำ

นั่งเช็กเมื่อวานนี้ ได้ แพตช์แรก ที่แก้ปัญหานิคหิตเกินมาได้ โดยพบว่าลูปใน Harfbuzz วิ่งขาดไปหนึ่งรอบ มันเลยไป match กับกฎ GSUB ในฟอนต์ที่ใช้จัดแสดงสระอำแบบมีวรรณยุกต์ โดยกฎนั้นเขียนไว้ว่าต้องตามด้วยสระอำด้วย แต่ในเมื่อมันวิ่งลูปขาดไปหนึ่งรอบ มันเลยเช็กไม่ถึงสระอำ แค่มีพยัญชนะตามด้วยวรรณยุกต์มันก็ apply กฎแล้ว โดยแทรกนิคหิตใต้วรรณยุกต์รอไว้ แล้วจะมีอีก substitution หนึ่งที่แปลงสระอำเป็นสระอาตามมา

แต่แพตช์นี้ยังไม่ได้แก้ regression ทั้งหมด ยังขาดเรื่องลดวรรณยุกต์ลงต่ำอีก แต่ผมจะมีเวลาแกะต่อหรือไม่ก็ยังไม่แน่ใจ เพราะต้องรีบเตรียมเนื้อหาสำหรับงานสัมมนาที่จะถึงนี้แล้ว

สำหรับแพตช์แรก ก็ต้องรอเขารีวิวก่อนนะครับ ว่าจะโอเคไหม ถ้ามีใคร file bug ที่ LP ไว้ ก็อาจช่วยกระตุ้นเรื่องนี้ได้

Thai Input Method

เนื่องในโอกาสที่วันนี้ Debian sid มีการ update xulrunner-1.9 เป็นรุ่น 1.9.0.14 (security fix) ทำให้ผมต้อง rebuild deb ของ xulrunner-1.9 เพื่อเพิ่มแพตช์เรื่องการตรวจแก้ลำดับการป้อนภาษาไทย ตามที่เสนอแพตช์ไว้ใน Mozilla #353776 เข้าไปใหม่ โดยเป็น ฉบับ backport เพื่อ upload เข้า debianclub โดยสั่ง build ทิ้งไว้แล้วไปทานข้าว ระหว่างทานข้าวก็เลยนึกถึงเรื่องที่เกี่ยวข้องขึ้นมา

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

ท่านเห็นว่า การตรวจลำดับนั้นสมควรอยู่ แต่การแก้ลำดับไม่ควรเป็นหน้าที่ของ input method แต่ควรให้ spell checker ทำ โดยเฉพาะอย่างยิ่ง การพยายามแก้ไขลำดับของคำว่า "น้ำ" ให้พิมพ์ "น + ไม้โท + สระอำ" หรือ "น + สระอำ + ไม้โท" ก็ได้นั้น เป็นการ spoil ผู้ใช้ ทำให้ผู้ใช้ไม่รู้ลำดับการพิมพ์ที่ถูกต้อง ซึ่งก็รวมถึงการแก้ลำดับของคำว่า "ที่" ที่พิมพ์เป็น "ท + ไม้เอก + สระอี" ให้ถูกต้องด้วย

ความเห็นนี้ เป็นความเห็นในฐานะนักพัฒนาส่วน localization และ standardization จึงเป็นความเห็นที่ควรให้ความสนใจอยู่ โดยเฉพาะเมื่อกรรมการ ISO และยูนิโค้ดชาวญี่ปุ่นที่นั่งฟังอยู่ด้วยแสดงความเห็นด้วยในเวลาต่อมา

ตอนนั้นผมอึ้งอยู่ เพราะไม่คิดว่าจะถูกถามเรื่องที่คิดว่าเป็นเรื่องธรรมดาสำหรับคนไทยแบบนี้ เลยตอบไปในลักษณะว่า มันเป็นเรื่องปกติของโปรแกรมที่มีในตลาด และผู้ใช้ก็คุ้นเคยกับพฤติกรรมแบบนี้ แต่ความจริง คำตอบที่เคลียร์กว่านั้นควรจะเป็นว่า ภาษาไทยตาม วทท 2.0 มีการกำหนด canonical order ไว้ เพื่อประโยชน์ในการเปรียบเทียบสตริงขณะสืบค้น การป้อนตามลำดับให้ถูกต้องจึงเป็นเรื่องสำคัญ แต่การแก้ไขข้อความโดยรักษาลำดับแบบนั้นจะเปลือง key stroke เพิ่มขึ้นในบางกรณี การแก้ไขแบบอัตโนมัตินี้ถือเป็นการอำนวยความสะดวกต่อผู้ใช้

ภาษาอย่างภาษาไทยเรานี้ ก็ไม่ได้มีเพื่อนเยอะนัก เพราะภาษาตระกูลอินเดียที่คล้ายกับเรา แม้กระทั่งพม่าและเขมรที่เป็นเพื่อนบ้านใกล้ชิด เขาก็ encode แบบที่เขาเรียกว่า "logical order" ไม่ใช่ "visual order" แบบภาษาไทยและลาวอยู่แล้ว input method ของเขาจึงต้องมีการจัดลำดับใหม่ จากลำดับพิมพ์ดีดปกติที่ผู้ใช้ป้อน (ซึ่งเป็น visual order) ให้เป็น logical order อยู่แล้ว การสลับลำดับของเขาจึงมีเหตุผลที่ต่างจากเรา มองไปมองมา ก็มีแต่ไทยกับลาวที่อยู่ในกลุ่มเดียวกัน และพอจะอ้างอิงเทียบเคียงกันได้

แต่มองในทางกลับกัน การไม่มีเพื่อนก็ทำให้เรามีอิสระที่จะกำหนดโดยไม่ขึ้นกับภาษาข้างเคียง (ยกเว้นลาว) ในฐานะที่เป็นตัวเขียนประเภท visual order ที่มี combining character ว่าเราจะใช้ความสามารถในการเข้าถึง text buffer ของ application นี้ ในการสลับลำดับให้ถูกต้องได้ โดยอาจจะแบ่งระดับของการรองรับ จากระดับ 0 คือไม่มีการตรวจลำดับเลย ระดับ 1 คือตรวจลำดับแบบชั่วคราวเท่านั้น (เลื่อนเคอร์เซอร์เมื่อไรเป็นเลิกตรวจ) ระดับ 2 คือตรวจลำดับตามบริบท (ตรวจเสมอแม้จะเลื่อนเคอร์เซอร์ไปที่ไหน) และระดับ 3 คือตรวจตามบริบทแล้วแก้ลำดับที่ผิดให้ด้วย

(ปัจจุบัน ถ้ามองตามนี้ Firefox ที่ทำงานในโลแคลอังกฤษ ไม่ว่าจะอย่างไรก็อยู่ที่ระดับ 0; ถ้าอยู่ในโลแคลไทย จะอยู่ระดับ 1 แต่ถ้าแพตช์ตาม Mozilla #353776 และทำงานในโลแคลไทย จะอยู่ที่ระดับ 3)

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

ประเด็นเหล่านี้ ได้ถูกหยิบยกขึ้นมาอภิปรายพอสมควรในการประชุมเพื่อร่าง วทท 3.0 เมื่อปีก่อน แม้เรื่องนี้จะเงียบไปนาน แต่ประเด็นต่าง ๆ ก็ยังคงวนเวียนอยู่ตามโครงการต่าง ๆ อย่างน้อย ๆ โมเดลการวาดภาษาไทยของยูนิโค้ดที่ต่างจาก วทท 2.0 ก็มาจากประเด็นเหล่านี้ด้วย โดยยูนิโค้ดมองอักษรไทยในฐานะอักษรที่ใช้เขียนภาษาทั่วไป ในขณะที่ วทท 2.0 มองเฉพาะการเขียนภาษาไทยเท่านั้น และปัจจุบัน การวาดภาษาไทยของ Qt ที่ต่างจาก GTK+/Pango ก็อยู่บนพื้นฐานของความแตกต่างของข้อกำหนดตรงนี้ด้วยเหมือนกัน โดย Qt จะอิงข้อกำหนดยูนิโค้ด ส่วน Pango จะอิง วทท 2.0

ล่าสุด ดูจะเข้ามาใกล้กันจนเกือบประสานกันแล้ว เมื่อ Behdad ประกาศว่า ได้ merge Harfbuzz-ng เข้าใน Pango master แล้ว โดย Harfbuzz เป็น OpenType layout engine สำหรับจัดเรียงอักขระ (shaping) เพื่อวาดข้อความ โดยเป็น โครงการใน freedesktop เพื่อใช้ร่วมกันระหว่าง GNOME และ KDE (ถ้าสนใจศึกษาหน้าที่และความสัมพันธ์ระหว่างส่วนต่าง ๆ มีบทความ State of Text Rendering ที่ Behdad เขียนไว้ อธิบายละเอียดครบถ้วนพอควร) วันที่ต้องพิจารณาชำระความแตกต่างระหว่าง Unicode และ วทท 2.0 ก็ใกล้เข้ามาทุกที

ในส่วนของ input method นั้น การตรวจลำดับอักขระ ถือได้ว่าเป็นการอำนวยความสะดวกให้กับผู้ใช้ภาษาไทย พร้อม ๆ กับเป็นการปิดกั้นผู้ใช้ภาษาอื่นที่เขียนด้วยอักษรไทยด้วย ยิ่งเป็น output method ที่ยึดอักขรวิธีไทยอย่างแนบแน่น ก็ยิ่งปิดโอกาสการใช้ภาษาที่ไม่ใช่ภาษาไทยไปเลย เรื่องนี้ หลังจากพูดคุยกันใน วทท 3.0 ข้อสรุปจะเป็นประมาณว่า input method จะต้องแยกตามโลแคล (อิง ภาษา โดยใช้ข้อกำหนด วทท 2.0 กับภาษาไทย และผ่อนคลายกับภาษาอื่น) ส่วน output method จะต้องวาดครอบจักรวาลได้ (อิง อักษร ตามแบบยูนิโค้ด)

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

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

Mozilla IME Surrounding Patch Updated

จากที่ได้ backport แพตช์ IME surrounding text ของ Mozilla มา ก็ทำให้ได้ใช้กับ Epiphany แบบหนักกว่าตอนที่ทดสอบแพตช์ที่ build จาก trunk ทำให้เจอกรณีที่ผิดเพี้ยน ป้อนภาษาไทยไม่ได้แบบแปลก ๆ ซึ่งหลังจากตรวจสอบก็พบว่าจะเกิดกับ text area ที่มีข้อความหลายบรรทัด โดยจะป้อนได้ถูกต้องแค่ย่อหน้าแรกเท่านั้น พอลงมาย่อหน้าถัด ๆ มาจะเริ่มเพี้ยน ป้อนสระบน-ล่างได้มั่งไม่ได้มั่ง

สาเหตุคือ ตอนที่อ่านบริบทเพื่อส่งกลับให้ input method นั้น จะส่งข้อมูลกลับอยู่สองส่วน คือข้อความ กับตำแหน่งเคอร์เซอร์ปัจจุบัน ปรากฏว่าข้อความนั้น จะส่งข้อความทั้งหมดใน text area คืนไป แต่ตำแหน่งเคอร์เซอร์ กลับนับเทียบกับต้นย่อหน้าปัจจุบัน พอ input method จะอ่านอักขระ ก็กลายเป็นอ่านจากย่อหน้าแรกเสมอ นั่นจึงเป็นสาเหตุที่ทำให้ทำงานได้ถูกต้องแค่ย่อหน้าแรกเท่านั้น

ก็เลยปรับแพตช์ใหม่ ให้คืนค่าข้อความของย่อหน้าปัจจุบัน แทนที่จะเป็นข้อความทั้งหมด แล้วส่งเข้า Mozilla #353776 [Attachment #389088]

ส่วนแพตช์ที่ backport ก็ปรับด้วยเช่นกัน [ดาวน์โหลดแพตช์ หรือ ดาวน์โหลด deb พร้อมซอร์ส หรือแค่ upgrade ตาม debclub ก้านกล้วย]

ว่าแต่ว่า พอจะมีใครสนใจทดสอบแพตช์บน Windows กับ Mac บ้างไหม?

Mozilla IME Surrounding Patch Backported

ความเดิม blog ที่แล้ว ผมได้ update แพตช์ IME surrounding ที่ Akira Tagoh เสนอไว้ที่ Mozilla #353776 ให้ใช้กับ trunk ได้อีกครั้ง แล้วก็รอ deb ของ xulrunner 1.9.1 ใน sid ก่อนที่จะแพตช์และ build deb อีกที

ความเคลื่อนไหวที่ Debian iceweasel 3.5-1 และ xulrunner 1.9.1-1 ได้เข้าไปอยู่ใน experimental แล้วเมื่ออาทิตย์ก่อน ระหว่างเฝ้ารอให้เข้า unstable ก็ไปพบใน blog ของ Mike Hommey ว่า xulrunner 1.9.1 มีปัญหากับ Epiphany และเบราว์เซอร์อื่นอีกจำนวนหนึ่ง จำเป็นต้องบังคับให้มันใช้ 1.9.0.11

แต่จากข่าวล่าสุดของ Epiphany นั้น รุ่น 2.26.3 กลายเป็นรุ่นสุดท้ายที่จะใช้ Gecko ไปแล้ว โดยใน 2.27 (development) และ 2.28 (stable) นี้ Epiphany จะย้ายไปใช้ WebKit เรียบร้อยแล้ว ดังนั้น คงจะมีโอกาสน้อยมากที่จะได้ใช้ Epiphany กับ xulrunner ตัวใหม่ เพราะคงไม่มีรุ่นใหม่ที่ใช้ Gecko ออกมาอีกแล้ว

ด้วยเงื่อนไขนี้ ก็เลยตัดสินใจไม่รอ xulrunner 1.9.1 เข้า sid ตามที่ตั้งใจไว้ แต่ backport แพตช์มาที่ xulrunner 1.9.0.11 เสียเลย [ดาวน์โหลดแพตช์] แล้วถ้า xulrunner 1.9.1 และ iceweasel 3.5 เข้า sid เมื่อไร ค่อยแพตช์ให้ผู้ใช้ iceweasel ใช้อีกที

พร้อมกันนี้ ก็ได้ build และ upload deb สำหรับ amd64 และ i386 เข้าที่ debclub ก้านกล้วย เรียบร้อยแล้ว [ไดเรกทอรีสำหรับตัว deb พร้อมซอร์ส]

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

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 แล้วค่อยเอามาแพตช์ให้ลองกันอีกทีครับ แล้วก็อาจจะต้องขอแรงผู้ใช้วินโดวส์และแมคให้ช่วยทดสอบแพตช์บนแพลตฟอร์มดังกล่าวด้วย

My (Partial) TODO List

ชักยาวเป็นหางว่าวแล้ว TODO list ของผม.. แค่ช่วงที่ติดงานแปล GNOME 2.26 นี่เท่านั้น จดไว้กันลืมเสียหน่อย 2.26 ออกเมื่อไรต้องรีบทยอยเคลียร์..

• ออก libdatrie, libthai, swath รุ่นใหม่ที่ได้ ทำค้างเอาไว้
• จัดการเรื่องปัญหา extended cluster ของ pango ซึ่งมีผลกับการเลื่อนเคอร์เซอร์ข้าม cluster ในรูป "เก" และ "กะ" (รวมทั้ง "เกะ") -- สิ่งที่เกี่ยวข้อง: Mozilla #474068, Unicode UAX #29
• ออกแบบเรื่อง UI การใช้ภาษาอังกฤษในโลแคลไทย เพื่อแก้ปัญหา ผู้ใช้ไม่ยอมใช้โลแคลไทย จนไปกระทบ feature ภาษาไทยของระบบ และหาที่เสนอแนวคิด
• แก้ปัญหาเรื่องความกว้างของตัวเลข ตามที่ Davide Viti ได้ ตรวจสอบ เอาไว้ แพกเกจที่กระทบคือ ttf-thai-arundina และ ttf-thai-tlwg
• update Debian package ภาษาไทย โดย update ข้อมูล VCS ของแพกเกจที่ host ที่ LTN จาก CVS เป็น SVN, update ตาม Debian policy 3.8.1, update debhelper เป็น level 7
• ผลักดัน Thai Fonts Siampradesh (non-free) เข้าใน Debian

มีรายการอื่นอีก ที่คงไม่สะดวกที่จะเขียนลง blog เนื่องจากเป็นการติดต่อเป็นการส่วนตัวกับคนอื่น

วันนี้เป็นวันสุดท้ายก่อน tarballs due ของ GNOME 2.26 แล้ว คงจะพยายามแปล user guide ให้ได้มากที่สุด จากนั้นก็เป็นคิวของ release notes ที่ควรจะเสร็จภายในวันพุธ (18 มี.ค.) แล้วหลังจากนั้นถึงจะเป็นอิสระจากงานแปล ไปเคลียร์ TODO list ได้..

Mozilla non-source-dir build

เริ่มกระบวนการใช้พลังของ เครื่องตั้งโต๊ะจากคุณ wd ต่อ วันนี้จัดการ checkout mozilla source มาที่เครื่องใหม่ แล้วก็ถือโอกาส config การ build นอก source tree เสียเลย ซึ่งก็ไม่ยากอะไร เนื่องจากระบบ build ของ mozilla ได้ออกแบบมารองรับเรื่องนี้โดยเฉพาะอยู่แล้ว

ก็ ตามคู่มือ เลยครับ:

$ hg clone -r default http://hg.mozilla.org/mozilla-central/
$ cd mozilla-central
$ autoconf
$ cd js/src; autoconf; cd ../..

ตรง autoconf นี่ บน Debian ใช้วิธีติดตั้ง autoconf2.13 แล้วเรียก autoconf wrapper script เอา มันจะไปเลือก autoconf รุ่นที่เหมาะสม ระหว่าง 2.13 กับ 2.50 ให้เอง ซึ่ง manpage ของ Debian แนะนำให้ทำแบบนี้

จากนั้น ผมก็สร้างไดเรกทอรี ~/build เอาไว้ build โปรแกรมโดยเฉพาะ ทั้ง mozilla และ GNOME

จากนั้นก็สร้าง ~/.mozconfig เอาไว้ ตาม คู่มือ เลยครับ ปรับเอาตามสะดวก:

$ vi ~/.mozconfig

. $topsrcdir/browser/config/mozconfig

mk_add_options MOZ_OBJDIR=~/build/mozilla_hg/mozilla-central

ac_add_options --disable-optimize
ac_add_options --disable-debug
ac_add_options --enable-tests

ac_add_options --with-system-bz2
ac_add_options --with-system-jpeg
#ac_add_options --with-system-png
ac_add_options --with-system-zlib

ตรง --with-system-* ทั้งหลายนี่ ก็ลงแพกเกจ lib*-dev ของระบบเอา ไม่ต้อง build ซ้ำซ้อน ยกเว้น libpng ซึ่ง mozilla มันฟ้องว่า libpng ของระบบไม่รองรับ APNG เลยไม่ยอม build ให้ ต้องใช้โค้ดของ mozilla แทน เลย comment ออกไปก่อน

สร้างเสร็จแล้ว ก็มาถึงตอนสำคัญ คือการ build นอก source tree.. แต่นแต๊น..

$ cd ~/build/mozilla_hg/mozilla-central
$ make -f ~/vcs/mozilla_hg/mozilla-central/client.mk \
  build TOPSRCDIR=~/vcs/mozilla_hg/mozilla-central

จุดสำคัญอยู่ที่การกำหนดตัวแปร TOPSRCDIR ให้กับ make

เครื่องตั้งโต๊ะนี้ ผมกะให้เป็น build server อย่างเดียว ไม่ได้ต่อจอ ไม่ลง X server หรือ display manager ใด ๆ โปรแกรมที่ build ได้ ก็จะเป็น X client ซึ่งสามารถเรียกทำงานผ่าน SSH tunnel ได้:

$ ssh -X server
$ cd build/mozilla_hg/mozilla-central
$ dist/bin/firefox

จบละ ลดภาระการคอมไพล์ของเครื่องโน้ตบุ๊กไปได้หนึ่งเรื่อง ต่อไปก็ตา GNOME ไว้ blog ต่อคราวหน้า

ปล. blog ซะละเอียดอย่างนี้ คนที่รู้แล้วอย่าเพิ่งเบื่อนะครับ เขียนบันทึกไว้ให้มีเอกสารเป็นภาษาไทยเสียบ้าง

Mozilla Delete Key Issue Follow-ups

เมื่อ 3 เดือนก่อน ผม blog เกี่ยวกับ การลบภาษาไทยทั้งเซลล์ใน Mozilla ว่าแพตช์ได้ commit ในที่สุด หลังจากที่ถูกถอนเพราะไปทำให้เกิดบั๊กอีกสองตัว ปรากฏว่าเรื่องไม่ได้จบแค่นั้น เพราะมีการพบบั๊กเพิ่มอีกสองตัวที่เกิดจากแพตช์ที่ว่า

บั๊กแรกคือ Mozilla #461816 คือแพตช์ได้ทำให้ตรรกะของโค้ดเปลี่ยนไป แต่เปลี่ยนโค้ดตามไม่ครบทุกกรณี ยังขาดกรณีของการป้อนรหัสผ่าน ทำให้พอพยายามลบทั้งบรรทัดด้วย Ctrl-U แล้วเจอ assertion fail ในรุ่น debug รวมทั้งพอกด Ctrl-W เพื่อลบคำ, Ctrl-K เพื่อลบจนสุดบรรทัด ก็ไม่ทำงาน (โห.. แต่ละปุ่ม ไม่อ่าน Emacs Keybindings for Firefox ไม่มีทางรู้เลย ที่เคยใช้ใน bash ก็แค่ Ctrl-H, Ctrl-W, Ctrl-A, Ctrl-E, Ctrl-F, Ctrl-B, Ctrl-P, Ctrl-N, Ctrl-R ก็ว่าเยอะแล้วนะ แถมจะใช้ปุ่มพวกนี้ได้ ต้องตั้ง GTK+ key theme ให้เป็น Emacs ก่อน ตามคำแนะนำใน Comment #6 ด้วย)

และอีกบั๊กคือ Mozilla #462188 คือกด Ctrl-Delete, Ctrl-Backspace (หรือ Option-Delete และ Option-Backspace ในแมค) เพื่อลบทีละคำแล้วไม่ทำงาน อันนี้ก็เป็นกรณีที่พลาดไปในแพตช์ก่อน เนื่องจากมุ่งเน้นแค่กรณีของปุ่ม Delete, Backspace ธรรมดาเท่านั้น

ทั้งสองบั๊กรายงานในเวลาไล่เลี่ยกัน บั๊กแรกใช้เวลาเดือนเศษก็ได้ check-in เพราะแพตช์ไม่ซับซ้อนมาก ทั้งปัญหาก็รุนแรง คือทำให้ nightly-build พัง ส่วนบั๊กที่สอง รอรีวิวอยู่เป็นนานสองนาน จนได้ commit ครั้งแรกเมื่อช่วงปีใหม่ แต่ก็โดนถอนออกอีก เพราะ mochitest (การทดสอบอัตโนมัติด้วย HTML/Javascript ที่กำหนด --รายละเอียด) บางตัวไม่ผ่านในแพลตฟอร์มอื่น roc มาช่วยปรับให้ ปรับไปปรับมาก็กลับไปใช้แพตช์ผม บวกกับ mochitest ของเขา ในที่สุดก็ได้ commit เมื่อวานซืน (27 ม.ค.) รอดูมาสองวันไม่มีการถอนออกแล้ว น่าจะโอเคแล้วละ แบบนี้..

ใน blog เดิมนั้น บอกว่าจะดู Mozilla #353776 เพื่อแก้ให้ Mozilla รองรับการอ่านบริบทขณะป้อนข้อมูล เพื่อให้สามารถคีย์สระบน-ล่างได้เสมอแม้จะกด Backspace หรือเลื่อนเคอร์เซอร์ไปมา ก็ยังไม่ได้ดู.. นี่เราจะทำได้แค่ปีละบั๊กจริง ๆ หรือนี่ (ปี 2550 ได้เรื่อง ตัดคำ ปี 2551 ได้เรื่อง Delete ลบทีละเซลล์)

Epiphany ยังคงใช้ Gecko ใน 2.26 เพราะฉะนั้น เรื่องดูภาษาไทยใน WebKit ก็ยังสามารถเลื่อนออกไปได้อีกนิด

Mozilla Delete Key Fixed for Thai

หลังจากถูกเลื่อนออกมาจาก Firefox 3.0 / Gecko 1.9.0 ในที่สุด Mozilla #157546 (ปุ่ม <delete> ควรลบภาษาไทยทั้งเซลล์) ก็ปิดแล้วเมื่อเช้านี้ โดยจะเริ่มมีผลใน Firefox 3.1 / Gecko 1.9.1 (รอใน beta 2 เป็นอย่างเร็ว)

ใครจะไปคิด ว่าบั๊กแบบนี้จะใช้เวลาตั้ง 6 ปีในการปิด (สูสีกับ บั๊กตัดคำ ที่ใช้เวลาถึง 8 ปี) และที่ว่าถูกเลื่อนมาจาก Firefox 3.0 / Gecko 1.9.0 ก็เพราะทีแรกนั้น แพตช์ได้ check-in แล้วตั้งแต่ก่อนรุ่นนั้นจะออก แต่มีการพบว่าไปทำให้เกิด regression สองรายการ คือ การลบใน HTML editor ไม่ลบต่อเข้าไปในบล็อค และ การลบที่บริเวณรอยต่อ bi-direction text เป็นการลบทันทีโดยไม่กระโดดไปขวาสุดก่อนเหมือนเคย ซึ่งรายการหลังนี่ไปกระทบภาษาฮีบรูและอารบิกเข้า และเนื่องจาก Firefox/Gecko กำลังอยู่ในช่วง freeze จึงโดนถอนแพตช์ออก แม้จะมีการเสนอแพตช์แก้ต่อมาก็ตาม

หลังจาก Firefox 3.0 / Gecko 1.9.0 ออกแล้ว ผมเลยเริ่มรอบใหม่ โดย merge แพตช์ทั้งหมดแล้วเสนอใหม่ รอมาอีก 3 เดือนจึงมีคนมารีวิวให้ แก้เสร็จก็รออีก 3 เดือนถึงได้รับการรีวิวอีก จนได้ commit เมื่อเช้านี้ นี่ก็ยังต้องรอดูอีกระยะหนึ่ง ว่าจะโดนถอนแพตช์อีกหรือเปล่า

Mozilla เป็นโค้ดที่ซับซ้อนจริง ๆ แก้แค่เรื่องปุ่ม Delete นี่ แพตช์ก็ใหญ่กว่าที่คิด ใช้เวลารอรีวิวนานด้วย.. อาจเป็นสาเหตุที่ทำให้นักพัฒนาหลายคนเริ่มหันไปหา WebKit แทน แม้แต่ Epiphany ของ GNOME เอง

สำหรับ Mozilla บั๊กต่อไปที่คิดว่าจะทำ คือ Mozilla #353776 (surrounding text support ใน input method) แต่ต้องรอว่างจากงานอื่นก่อน

Mozilla Pango-Break Backported

backport Mozilla pango-break patch จาก trunk มา 1.8 branch ละ เพื่อใช้กับ debian ต่อไป โดยทำ xulrunner ก่อน

1.8.1.5-1thai2 deb สำหรับ amd64 พร้อมใช้แล้วที่ LTN Apt ส่วน i386 รวมทั้ง iceweasel รอนิวตรอนมาทำให้

ด้วย patch ใหม่ (ดึงออกมาจาก dpatch ที่เพิ่มใน deb) นี้ xulrunner-libthai จะไม่จำเป็นอีกต่อไป เพราะเรียกผ่าน Pango แทน

ขอเขียนสั้น ๆ นะครับ แสบตา :P

Mozilla Pango-Break (Really) Checked-in!

Mozilla Bug #336959 ปิดแล้วจริง ๆ หลังจากที่ ครั้งที่แล้ว patch ได้ check-in แต่โดนถอนออกมา โดยต้องรอให้ Text Layout ใหม่ถูก enable by default เสียก่อน

รอบใหม่นี้ยังต้องปรับ patch ไปมาหลายตลบกว่าจะได้เข้า (รายละเอียดอ่านได้ใน bug) ซึ่งสุดท้ายก็มาลงเอยที่วิธีที่เรียบง่ายที่สุด คือลิงก์ Pango เข้าไป ผ่าน adapter ง่าย ๆ โดยดัดแปลง nsJISx4051LineBreaker ให้เรียกออกมาเฉพาะช่วงที่มี complex text เพียงแต่ครั้งนี้ได้ล้วงลึกลงไปใน nsJISx4051LineBreaker มากกว่าที่เคย

เป็นอันว่า mozilla บน Linux สนับสนุนการตัดคำไทยผ่าน Pango เรียบร้อยแล้วใน trunk รอผู้สนใจทำโค้ดส่วนที่เรียก Uniscribe, ATSUI ก่อนที่ Firefox 3 จะออก (ใช้วิธีตาม patch ใหม่นะครับ โดย implement ฟังก์ชัน NS_GetComplexLineBreaks() แค่ฟังก์ชันเดียวเท่านั้น แล้วกำหนด build flag เลือกลิงก์เอา) ระหว่างนี้ platform ที่ไม่มี Pango ก็จะ fall back มาที่ rule-based breaker ไปพลาง ๆ

ปล. ตายังไม่หายดีครับ ต้องใช้เวลาหน้าเครื่องกับงานล้วน ๆ เห็นว่าเรื่องนี้สำคัญเลยมา blog ไว้ ขอบคุณทุกความเห็นเรื่องวิธีบำรุงตานะครับ

Mozilla Pango Break Checked-in!

แพตช์ตัดคำด้วย Pango ใน Gecko ได้ check-in แล้ว หลังจากแช่แพตช์รอคอมเมนต์อยู่ใน bug มาเกือบเดือน เห็นว่าโค้ดใน trunk เริ่มเข้าที่เข้าทาง ตัวเองก็เริ่มนั่งทำงานได้นานขึ้น เลย request ขอ review ไปคืนวันที่ 19 ได้รับ review comment ชุดแรกเช้าวันที่ 21 เป็นอันว่าวันนั้นไม่เป็นอันทำอย่างอื่น รีบแก้ patch ตาม roc เองก็ดีใจหาย ตอบอย่างรวดเร็ว แก้ไปแก้มา โค้ดดูสะอาดขึ้นเรื่อย ๆ จนในที่สุดก็ผ่าน review + superreview ภายในเย็นวันนั้น

ผ่านมาวันเศษ เช้าวันที่ 23 roc บอกว่า check-in patch ให้แล้ว!! แต่หลังจากนั้นไม่นานก็เอา patch ออก เนื่องจาก build ไม่ผ่าน เพราะ patch ผมใช้ pango API ที่ต้องการ pango รุ่นใหม่กว่าที่ mozila ใช้ แต่หลังปรับแก้ patch ก็ได้ check-in อีกครั้งในเช้าวันนี้ โดยโค้ดนี้จะมีผลใน Firefox® 3

เป็นอันว่า bug ตัดคำไทย ที่รอมาเกือบ 8 ปี วันนี้ได้ solution แรกที่ต้นน้ำ (โดยไม่ต้องอาศัย extension หรือ local patch) แล้วบน Unix platform นับตั้งแต่ที่ rule-based solution ของพี่สัมพันธ์ถูกตัดออกไป ส่วนแพลตฟอร์มอื่นๆ รอคนทำโค้ดเชื่อม Uniscribe, ATSUI ต่อไปครับผม

Multitasking

เสร็จจากฤดูรับจ้าง ก็กลับมาทำนา เอ่อ.. หมายถึงงานโอเพนซอร์สน่ะ ดูเหมือนจะเข้าสู่โหมดมัลติทาสก์เต็มที่ละ เพื่อไม่ให้งงในการสลับงานไปมา บันทึกไว้เสียหน่อยดีกว่า:

1. Win32 installer สำหรับชุด libthai จากคุณ Taniya

   • I/O: e-mail / LTN CVS
   • รายละเอียด: คุณ Taniya ช่วยเขียน Win32 installer สำหรับ libthai และ libdatrie โดยใช้ NSIS ส่งมาให้ จึงพยายามปรับและ merge เข้า CVS
   • สถานะ: merge installer สำหรับ libdatrie เข้า CVS ไปแล้ว ยังขาดเรื่องการติดตั้งแยก component ส่วน libthai นั้น จะ merge เข้าทีหลัง โดยปรับจากกลไกของ libdatrie หลังจากที่ทุกอย่างเรียบร้อยแล้ว

2. การตัดคำไทยใน upstream Mozilla

   • I/O: Mozilla Bug #336959, Mozilla Bug #7969
   • รายละเอียด: ปรับ patch ตัดคำเพื่อเสนอ check-in เข้า Mozilla trunk เพื่อให้มีผลใน Firefox 3.0
   • สถานะ: คิดต่อจาก blog เก่า เห็นว่าการทำ libthai component ยุ่งยากเกินไป ทั้งวิธีการก็ยังมีจุดบอด คือต้องสร้าง interface สำหรับภาษาไทยขึ้นมาเพื่อเรียกจากใน nsJIS4051LineBreaker อีกทั้งยังไม่มีกลไกสนับสนุนภาษาอื่นที่ชัดเจน จึงย้อนกลับไปหา แนวคิด การแทนที่ LineBreaker ของพี่สัมพันธ์ ที่ใช้ ICU แทน nsJIS4051LineBreaker ไปเลย แทนที่จะเรียกออกมาจาก nsJIS4051LineBreaker โดยพี่เขาทำเป็น extension ต่างหาก แต่ในเมื่อ Mozilla มีตัวเลือกในการลิงก์กับ Pango อยู่แล้ว การแทนที่ด้วย Pango จึงดูเป็นทางเลือกที่ตรงตัวที่สุด และดูมีโอกาสได้ check-in มากที่สุด ก็เลยกลับไปหา Bug #336959 ที่เคยเสนอเรื่อง platform line breaker ไว้ แล้วปรับ patch สำหรับ Pango ใหม่ แทนที่จะเรียกออกมาจาก nsJIS4051LineBreaker ก็แทนที่ nsJIS4051LineBreaker เสียเลย พร้อมกับเปลี่ยนไปใช้ API ของ Pango อีกชุดหนึ่งที่ขั้นตอนน้อยกว่าเดิม ทำให้ patch ดูเรียบง่ายลงเยอะ แล้วก็เสนอใน Bug #7969 (การตัดคำไทย) ว่าขอเสนอทางเลือกใหม่ ผ่าน Pango ก็ปรากฏว่า ได้รับคำแนะนำจาก Robert O'Callahan ซึ่งเป็นผู้ออกแบบ layout engine ของ Gecko ใหม่ ว่าให้ลองโค้ด TextFrame ใหม่ที่กำลังทำอยู่ พอลองแล้วก็พบว่าได้ผลเป็นที่น่าพอใจ ที่สำคัญคือประสิทธิภาพการตัดคำดีขึ้นกว่าเดิมมาก! ดูจะเข้ารูปเข้ารอยแล้วแฮะ ถ้าทุกอย่างเรียบร้อย และเขารับแพตช์ Pango เข้าไป เราอาจไม่ต้องไล่ patch ตัดคำอีกใน Firefox 3 หรือ xulrunner 1.9 เป็นต้นไป แต่ตอนนี้ ยังต้องลุ้นต่อไป

3. ติว Neutron เรื่อง xulrunner-libthai deb

   • I/O: ICQ / LTN APT
   • รายละเอียด: Neutron อาสา patch และ build xulrunner-libthai 1.8.0.11-2thai1 ซึ่งมีการอัปเดตล่าสุดใน Debian ให้ หลังจากที่เขาได้อาสา patch และ build iceweasel-libthai ไปแล้ว ซึ่ง xulrunner ใช้ระบบ dpatch ช่วยอำนวยความสะดวกต่อ maintainer ในการติดตาม patch ต่าง ๆ แต่ก็หมายความว่า ผู้ patch ปลายน้ำอย่างเราก็ต้องเรียนรู้และจัดการระบบ dpatch ให้เป็นด้วย ขั้นตอนจึงมากกว่า iceweasel (แต่ในแง่ maintainer แล้ว การแยก patch แบบ xulrunner ช่วยให้สะดวกในการติดตาม check-in กว่าแบบ patch รวบใน iceweasel มากนัก.. นี่ถ้าตอนนู้น Mozilla ได้เห็น xulrunner ของ Debian คงด่าไม่ออกเรื่องการจัดระเบียบ patch เพียงแต่อาจโชคไม่ดีที่ xulrunner ไม่ได้ใช้เครื่องหมายการค้า firefox® เลยไม่ได้ถูกตรวจตราเหมือน firefox ในตอนนั้น.. และที่ firefox/iceweasel ของ Debian ยังใช้ระบบ patch แบบเก่า ก็คงเป็นเพราะ xulrunner เกิดทีหลัง และ Debian ก็มีแผนที่จะ build firefox ด้วย xulrunner ในอนาคตอยู่แล้ว ก็เลยไม่ได้ปรับแพตช์ใน firefox.. แต่จะว่าไป firefox ของ Ubuntu ที่ Mozilla รับรองว่า "ใช้ได้" ก็เอาไปจาก Debian นั่นแหละ ระบบ patch รวบยอดเหมือนกันทุกประการ แต่ไม่โดนว่าอะไร แปลกดีเหมือนกัน)
   • สถานะ: Neutron แก้ปัญหาต่าง ๆ ที่พบได้หมดแล้ว และ deb ที่ได้ ก็อยู่ใน LTN APT เรียบร้อยแล้ว

4. แก้ RC bug ใน gtk-im-libthai ใน Debian

   • I/O: Debian archive
   • รายละเอียด: ก่อน etch จะออก ก็ยังมี massive RC bug ระลอกสุดท้ายมาจากการทดสอบ piuparts อีก โดย gtk-im-libthai ก็ โดนด้วย จึงต้องแก้อย่างรีบด่วน ไม่ให้ขวางทาง etch release
   • สถานะ: แก้ bug และ upload เข้า sid แล้ว และได้ย้ายเข้า etch เรียบร้อยแล้วเช่นกัน

5. ปรับ pango libthai support ใน Ubuntu feisty

   • I/O: LP #99655, LP #101863, Ubuntu archive
   • รายละเอียด: Mk แจ้งมาว่า gedit ไม่ตัดคำใน feisty ก็ดองไว้วันสองวันจนมีโอกาสบูตเข้า Ubuntu ไปตรวจสอบดู พบว่า pango-libthai กลายเป็นแพกเกจเปล่า มีแต่ doc ไม่มี pango module ซึ่งก็เป็นปัญหาเรื่องการ hard code binary version ใน debian rules ของผมเอง พอเวอร์ชันใน Ubuntu ต่างจากใน Debian ไฟล์ก็เลยหาย ความจริงก็เป็นปัญหาที่เจอระหว่างแก้ Debian RC bug ของ gtk-im-libthai ด้วยแหละ ก็กลับมาแก้ด้วยวิธีเดียวกัน ขณะเดียวกัน เรื่องการตัด pango-libthai ออกจาก Ubuntu แล้วแทนที่ด้วยการ build upstream pango โดยให้ลิงก์กับ libthai ก็ยังคงอยู่ระหว่างเจรจาอยู่ กลายเป็นสองทางเลือกในการแก้ปัญหานี้
   • สถานะ: Mk ช่วยทดสอบ Alexander Sack ช่วยประสานงานต่อให้ จนได้ความว่า Ubuntu จะ build pango ใหม่ให้ลิงก์กับ libthai เพื่อให้สามารถตัดคำไทยได้ตั้งแต่ใน upstream pango แล้วตัด pango-libthai ทิ้งไป.. นับว่าเกินความคาดหมายพอสมควร เดิมยังคิดว่า feisty freeze อยู่อย่างนี้ คงได้ทำหลัง feisty แหง แต่ปรากฏว่า pango-libthai ตายได้สำเร็จแล้วใน Ubuntu!

6. ปรับ OpenType table ใน thaifonts-scalable เพื่อใช้กับ OO.o

   • I/O: #tlwg / LTN CVS
   • รายละเอียด: kitty รายงานมาในห้องแช็ต ว่าฟอนต์ไทยใน Ubuntu มีปัญหากับ OO.o เมื่อใช้สระอำกับวรรณยุกต์ประกอบกัน ทำให้ผมนึกถึงปัญหาที่ทำให้ทีม TLE ต้องปิด OpenType table ในฟอนต์จาก thaifonts-scalable ซึ่งภายหลัง kitty คุยกับ MrChoke แล้ว ยืนยันว่าเป็นบั๊กเดียวกัน
   • สถานะ: ก่อนอื่น ต้องทำความเข้าใจความแตกต่างระหว่าง pango กับ OO.o ซึ่ง pango นั้น มอดูลภาษาไทยจะมี preprocessing รอบหนึ่งก่อน แล้วจึงใช้กฎ GSUB/GPOS ในฟอนต์ ในขณะที่ใน OO.o หลังจากทดลองดูแล้ว ดูเหมือนจะอิงอาศัย OpenType feature ล้วน ๆ ยกเว้นกรณีที่ขาด OpenType feature จึงจะใช้รูทีน shape ด้วย PUA glyph (ไม่ได้แกะโค้ด OO.o จริงนะครับ ใครที่รู้รายละเอียดช่วยยืนยันด้วย) จึงได้เริ่มพยายาม hack 'ccmp' GSUB rule ในฟอนต์ Garuda โดยอ่านเอกสารของ Fontforge แล้วตั้งสมมุติฐานแบบต่าง ๆ จนในที่สุดก็พบวิธีแก้ ด้วยการรวบ GSUB rule ที่จัดการสระอำทั้งหมดไว้ด้วยกัน เพื่อรับประกันว่าจะไม่มีกรณีซ้ำซ้อนและการเสี่ยงต่อลำดับก่อนหลังของการใช้กฎ ทดสอบกฎจนได้ผลแล้ว ก็ไล่แก้ฟอนต์อื่น ๆ ในชุดเดียวกันจนครบ ตอนนี้อยู่ใน CVS แล้ว แต่ยังมีปัญหาที่พบคือ ฟอนต์ที่ใช้ OpenType นี้ จะมีปัญหากับ OO.o เรื่องช่องไฟเมื่อมีการผสมสระอำกับวรรณยุกต์ในบางกรณี ซึ่งวรรณยุกต์ที่มีปัญหาจะต่างกันไปในแต่ละฟอนต์ แต่สำหรับ pango ไม่มีปัญหาอะไร ทำงานเรียบร้อยดี คงต้องพยายามทำความเข้าใจกลไกการจัดการ GPOS ของ OO.o เสียก่อน จึงจะเข้าใจปัญหา ถ้าทุกอย่างเรียบร้อย จึงจะ release ฟอนต์รุ่นใหม่ ออกมา

7. ตามแปล debian-installer

   • I/O: alioth SVN
   • รายละเอียด: ไม่มีอะไรมาก เพียงแต่ได้รับแจ้ง message ใหม่ใน debian-installer (ที่จะใช้ใน etch CD) เล็กน้อย ก็เลยตามแปลเพิ่ม
   • รายละเอียด: เสร็จแล้ว ภาษาไทยครบ 100% ถึง level 4 เหมือนเดิม

ฟังดูเหมือนเยอะจัง แต่สนุกดีน่ะ การที่แต่ละโครงการที่ติดต่อต้องรอ check-in เราก็ใช้วิธี round robin สลับไปทำงานอื่นระหว่างรอได้ งานบางชิ้นก็เป็นการประสานงานเฉย ๆ อาศัยคนอื่นช่วย ซึ่งก็ทำให้ได้บรรยากาศ bazaar แบบย่อม ๆ ช่วงหมดฤดูรับจ้างใหม่ ๆ ผมเองก็ยังเครื่องไม่ร้อนเท่าตอนนี้ ต้องค่อย ๆ อุ่นเครื่องมาเรื่อย ๆ เหมือนกัน

On Mozilla Stuffs

มัวแต่ไล่แพตช์ iceweasel/xulrunner deb เสียนาน โดยไม่ได้ปรับแพตช์อะไรมากมายเลย ทั้งไม่ได้ไปตามดูซอร์สที่ mozilla trunk เลยด้วย ส่งงานชิ้นหนึ่งไปแล้ว เลยถือโอกาสกลับมาดูเสียหน่อย

อย่างที่เกิดกับผมหลายเรื่อง เรื่อง mozilla นี่ พอนานเข้า เรื่องที่ไม่เคยคิดว่าต้องทำก็ชักกลายเป็นเรื่องถาวร ต้องเตือนตัวเองเสียบ้าง ว่าเดิมผมไม่เคยคิดจะเข้ามาดู mozilla เลย เพราะเห็นว่ามีหลายคนทำอยู่แล้ว ทั้งพี่สัมพันธ์ พี่ฮุ้ย อ๊อท ก็ปล่อยให้เขาทำไป แต่ที่ต้องมาจับนี่ก็เพราะ Ubuntu Localisation Sprint ตั้งแต่รุ่น dapper นู่น บังเอิญผมเอาแพตช์ของอ๊อทไปใส่ โดยที่ต้องปรับแก้เพิ่มเติมด้วย

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

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

น่าจะถึงจุดที่ต้องหยุดทบทวนบ้างล่ะ ว่าจะทำยังไงต่อไปกับเรื่องนี้ การไล่ patch และ build ไม่ใช่สิ่งที่พึงปรารถนาแน่ ๆ

mozilla ใน trunk ซึ่งจะออกเป็น firefox 3 นั้น มีการปรับ API และโครงสร้างของตัวตัดคำพอสมควร ดูท่าจะทำงานได้เร็วขึ้น ไม่มีการเรียกรูทีนตัดคำแบบซ้ำซาก แต่ก็ยังไม่มีโครงสร้างสำหรับการต่อเติม engine ในแบบที่ pango ทำเลย จึงดูเหมือนยังไม่มีช่องทางให้เสียบเพิ่ม engine ภาษาไทยเข้าไปได้ง่าย ๆ

เท้าความถึงลักษณะปัญหาและ solution ต่าง ๆ เสียก่อน..

ใน mozilla นั้น มี interface สำหรับตัดบรรทัดคือ ILineBreaker ซึ่งขณะนี้ มี engine เดียวที่ implement interface นี้ คือ nsJISx4051LineBreaker ซึ่ง implement ตาม spec ตัวตัดคำของญี่ปุ่น โดยมีการวิเคราะห์พวกเครื่องหมายวรรคตอนพอประมาณ

พี่สัมพันธ์ เคยทำงานกับ mozilla เมื่อนานมาแล้ว โดยเพิ่มกรณีของภาษาไทยใน nsJISx4051LineBreaker แล้วเรียกตัวตัดคำที่ใช้ rule base ที่พี่เขาเขียน แต่ปรากฏว่า ต่อมาโค้ดนี้ก็ไม่ถูกเรียกอีก ทำให้การตัดคำไทยใน mozilla หายไป

ต่อมา หลังจากพี่สัมพันธ์ check-in โค้ดตัดคำด้วยพจนานุกรมเข้า ICU ได้แล้ว ก็ได้ทำ patch ต่อเติม nsJISx4051LineBreaker อีกครั้ง โดยมาเรียก ICU แทน แต่ปรากฏว่าเขาไม่รับ patch อาจจะด้วยเหตุผลเรื่อง license และขนาดของ ICU ที่ใหญ่มหึมาเกินไป

นั่นทำให้เกิดช่วงสุญญากาศ แล้วก็เกิด solution ต่าง ๆ เป็นดอกเห็ด แต่แพตช์ตัดคำทั้งหลาย ต่างก็อาศัยแพตช์ของพี่สัมพันธ์เป็นฐานทั้งนั้น อาจจะต่างกันที่ engine เช่น ของพี่ฮุ้ยใช้ cttex, ของอ๊อทและของผมใช้ libthai

ล่าสุด พี่สัมพันธ์ได้เสนอว่าจะทำเป็น extension แทน โดยสร้าง component ที่ register service ด้วย contract ID ของ ILineBreaker ซึ่งความหมายก็คือ จะเอาตัวตัดคำไปแทนที่ nsJISx4051LineBreaker นั่นเอง ไม่ใช่การต่อเติมอย่างเดิมอีกต่อไป

วิธีการนี้อาจจะเหมาะสำหรับไลบรารีใหญ่ ๆ อย่าง ICU เพราะถ้าจะให้ mozilla link ตรง ๆ เพียงเพื่อใช้ความสามารถเรื่องการตัดคำภาษาไทย คงสิ้นเปลืองเกินไป แต่ถ้ายอมให้เปลืองเฉพาะสำหรับคนที่อ่านภาษาไทย ก็คงยอมรับได้ อีกทั้ง ICU น่าจะมีความสามารถที่เป็น superset ของ nsJISx4051LineBreaker อยู่แล้ว จึงแทนที่ได้สบายมาก

อีกทางเลือกหนึ่ง คือการพยายามดัน libthai patch ให้เข้าที่ upstream ให้ได้ เพื่อจะได้ไม่ต้องตาม patch ตาม build กันต่อไป ซึ่งวิธีนี้น่าจะเหมาะสำหรับไลบรารีเล็ก ๆ อย่าง libthai เพราะไม่ได้เพิ่มภาระให้กับโปรแกรมมากนัก อาจ check-in ง่ายกว่า แต่ปัญหาของ libthai คือ ยังไม่มีใช้ใน Windows จึงต้องการคน build installer ให้ด้วย ส่วนในลินุกซ์นั้น หลังจากที่ pango 1.16 ลิงก์กับ libthai ก็น่าจะทำให้ libthai เริ่มมีความสำคัญขึ้นบ้างใน distro ต่าง ๆ อย่างน้อยตอนนี้ก็มีใน Debian และ Ubuntu ละ ส่วน Fedora ก็เข้าใจว่าน่าจะมี

และทางเลือกที่สาม ที่ยังวนเวียนในความคิดนักพัฒนาอยู่เสมอ คือการใช้ API ตัดคำของ platform เช่น ใช้ pango บนลินุกซ์, ใช้ Uniscribe บนวินโดวส์, ใช้ ATSUI บน Mac ซึ่งก็ยังคงเป็นทางเลือกที่น่าสนใจ แม้จะประสิทธิภาพต่ำกว่าเพราะต้องเรียกใช้หลายทอด แต่การปรับปรุงโครงสร้างโค้ดใน mozilla เร็ว ๆ นี้ น่าจะช่วยบรรเทาได้บ้าง แต่เขาจะเลือกใช้หรือเปล่าก็ต้องขึ้นอยู่กับ architect ของ mozilla แล้วละ

สำหรับทางเลือก libthai patch นั้น ดูเหมือนขั้นตอนสำคัญที่ขาดอยู่ ก็คือ installer สำหรับ libthai บน Windows ซึ่งถ้ามีแล้ว คงทำให้ผลักดันอะไร ๆ ได้ง่ายเข้า