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 ผมใช้คำว่า วันนี้ แต่ด้วยงานต่าง ๆ ที่อิรุงตุงนังรอบตัว กว่าจะเขียนเสร็จมันก็กลายเป็น เมื่อวานนี้ ไปเรียบร้อย
ป้ายกำกับ: debianclub, firefox, iceweasel, localization, mozilla, xulrunner
8 ความเห็น:
ณ 13 กันยายน 2552 เวลา 06:58 , Unknown แถลง…
คุณเทพถนัดการใช้ "ก๊" ด้วยไม้ตรีหรือครับ รู้สึกแปลกตานิดหน่อย
ณ 13 กันยายน 2552 เวลา 09:27 , Thep แถลง…
จริงหรือครับ? ผมลอง search ดูทั้งหน้าก็ไม่เจอนะครับ ผมใช้ไม้ไต่คู้ตลอดครับ
ณ 13 กันยายน 2552 เวลา 11:07 , Unknown แถลง…
ถึงกับ หือ! เลยเหมือนกันนะครับ สรุปผมต้องตรวจสอบ Browser ของผมดูใหม่ ก็ต้องร้องอ๋อ คือผมเปิดด้วย Chrome 4 บน Ubuntu Set Font เป็น Lomaputta ขนาด 14 ระดับการ Zoom ปกติ ก็จะเห็นแบบที่แจ้งไว้จริงๆ แต่ลอง Zoom ให้ใหญ่ขึ้นก็เป็นปกติครับ อ้อ! ใน Firefox ก็ไม่เป็นครับปกติดี ขอโทษที่ทำให้เพิ่มงานนะครับ :)
ณ 13 กันยายน 2552 เวลา 23:47 , นายต้มยำ แถลง…
ได้ความรู้ "ใหม่" เยอะเลยครับ ขอบคุณมากครับที่ให้โอกาสได้มาเก็บเกี่ยว
ณ 14 กันยายน 2552 เวลา 16:39 , CrazyHOrse แถลง…
ลำดับการพิมพ์ที่ถูกต้อง?
ผมไม่แน่ใจว่าเราเริ่มใช้ วรรณยุกต์ แล้วตามด้วยสระอำเมื่อไหร่ และทำไม แต่ผมไม่คิดว่านี่คือลำดับการพิมพ์ที่ถูกต้องนะครับ เพราะมันสร้างปัญหามากกว่า
ไม่รู้ว่าจะสายเกินไปหรือเปล่าที่จะเปลี่ยนลำดับการพิมพืที่ถูกต้องเป็น สระอำ แล้วตามด้วยวรรณยุกต์
ณ 14 กันยายน 2552 เวลา 17:08 , Thep แถลง…
ลำดับการพิมพ์ที่ถูกต้อง อ้างอิงจาก canonical order ของ วทท 2.0 ครับ คำว่า "น้ำ" จะเก็บใน text buffer เป็น "น, ไม้โท, สระอำ" ดังนั้น ลำดับการพิมพ์ที่ถูกต้องจึงเป็นตามนี้
ลำดับนี้ น่าจะมาจากพิมพ์ดีดครับ เนื่องจากไม้โทจะไม่เลื่อนแท่นพิมพ์ ทำให้ไม้โทยังอยู่เหนือ น หนู อยู่ จากนั้น สระอำจึงตามมาในเซลล์ถัดไป กลับกัน ถ้าพิมพ์สระอำก่อน ไม้โทจะปรากฏบนสระอำ ไม่ใช่บน น หนู ซึ่งผิดรูปแบบครับ
ณ 14 กันยายน 2552 เวลา 17:15 , Thep แถลง…
มองในแง่การ implement ในคอมพิวเตอร์ ลำดับแบบนี้ก็เหมาะกับการแสดงผลมากกว่า และเนื่องจากภาษาไทยเรา encode แบบ visual order ก็จะไม่มีการเปลี่ยนลำดับระหว่าง keystroke กับข้อความที่ encode ด้วย ยกเว้นกรณีที่อำนวยความสะดวกครับ
ณ 14 กันยายน 2552 เวลา 17:28 , Thep แถลง…
หมายเหตุ: ในความเห็นของผม และคนทำภาษาไทยหลาย ๆ คน เราไม่ควรมีอักขระสระอำเลยด้วยซ้ำ เพราะมันได้สร้างข้อยกเว้นหลายอย่างในข้อกำหนด
เรื่องลำดับการพิมพ์นี่ก็เป็นเรื่องหนึ่งที่ทำให้มีข้อกังขา ถ้าไม่มีสระอำ ทุกคนคงเห็นพ้องกับการพิมพ์เป็น "น + นิคหิต + ไม้โท + สระอา" จริงไหมครับ?
แต่ในเมื่อเราสืบทอดระบบนี้มาจากพิมพ์ดีดที่มีแป้นสระอำ เราก็ยังต้องคงมันไว้ แม้มันจะสร้างปัญหายุ่งยากก็ตาม
แสดงความเห็น (มีการกลั่นกรองสำหรับ blog ที่เก่ากว่า 14 วัน)
<< กลับหน้าแรก