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 เข้าใจว่าเขาแก้ไปนานแล้ว