Thai Numpad Experiment

จาก กรณีฟอนต์ Sarabun IT9 ที่ผมได้ทิ้งท้ายไว้เรื่องวิธีแก้ปัญหาที่ถูกหลักการ โดยควรแก้ที่ระบบป้อนข้อความ (input method) ผมจึงทดลองดัดแปลงผังแป้นพิมพ์ไทยให้สามารถล็อคแป้นตัวเลข (numpad) ให้เป็นเลขไทยได้

เพื่อกำหนด spec เบื้องต้น ผมจึงได้ขอความเห็นสมาชิก DebianClub Gang ใน Facebook ดู ซึ่งมีความเห็นทั้งแบบที่เห็นว่าควรให้แป้นตัวเลขพิมพ์เลขไทยในโหมดภาษาไทยไปเลย, แบบที่เสนอว่าควรให้มีตัวเลือก config ผังแบบปกติและแบบพิมพ์เลขไทย และแบบที่เสนอว่าควรให้มีปุ่มสำหรับล็อคตัวเลขไทย

ก็ทดลองทำทีละขั้น ได้ผังรุ่นต่าง ๆ ดังนี้:

1. สร้างผังอีกชุดหนึ่งต่างหาก (basic_thaipad, pat_thaipad, tis_thaipad) ซึ่งแป้นตัวเลขจะกดได้เลขไทยเสมอในโหมดภาษาไทย วิธีนี้ผู้ใช้ต้องเลือก layout พิเศษเอาเองตอน config
2. ใช้ XKB option "keypad:aldig" ในการเพิ่มการป้อนเลขไทยเข้าในผังชุดเดิม แทนการเปลี่ยน layout วิธีนี้ผู้ใช้ไม่ต้องแก้ config ส่วน layout แต่ต้องเพิ่ม XKB option เอา
3. กำหนดปุ่ม ScrollLock เพื่อใช้ล็อคแป้นตัวเลขในโหมดภาษาไทยให้กดได้เลขไทย ถ้าไม่ล็อคก็ได้เลขอารบิกเหมือนเดิม (เสนอโดย Dr.Mamazaki J. Kasookie) วิธีนี้ผู้ใช้ไม่ต้อง config อะไรเพิ่มเลย

รุ่นสุดท้ายนี้เอง ที่เป็นรุ่นที่เริ่มเผยแพร่ให้ทดลองใช้เพื่อขอความเห็น โดยได้แปะประกาศไว้ที่ debianclub

รายละเอียดทางเทคนิคของผังนี้ก็คือ ต้องใช้ปุ่มแบบ 8 ระดับ โดยต้องเพิ่ม type ของปุ่มแบบ "EIGHT_LEVEL_KEYPAD" ที่ยังไม่มีข้อกำหนดใน XKB ปัจจุบัน

สาเหตุที่ต้องใช้ปุ่มแบบ 8 ระดับก็เพราะจำเป็นต้องหลบปุ่มระดับ 3 ที่ใช้ในผัง tis ที่ใช้ป้อนอังคั่นคู่ (๚) ซึ่งถ้ากำหนดให้ใช้เลขไทยที่ระดับ 3 แล้วใช้ ScrollLock ล็อคที่ระดับ 3 ก็จะทำให้ปุ่ม [น/ฯ] ถูกล็อคเป็น [๚] ตลอด ทำให้ป้อน น และ ฯ โดยไม่ปลด ScrollLock ไม่ได้ และจะใช้งานในกรณีปกติไม่สะดวก ส่วนระดับ 4 นั้น มีไว้สำหรับระดับ 3 ที่มีการกด Shift ดังนั้นจึงต้องเลื่อนขึ้นไปใช้ระดับ 5 ซึ่งจะมีในข้อกำหนดของปุ่มแบบ 8 ระดับที่เริ่มมีใน X protocol ตั้งแต่ xorg 7.0.8 เป็นต้นมา

และเนื่องจาก XKB มีแต่ข้อกำหนด 8 ระดับสำหรับปุ่มปกติเท่านั้น ยังไม่มีข้อกำหนดสำหรับสำหรับ numpad จึงต้องกำหนดขึ้นเอง ซึ่งผมออกแบบไว้อย่างนี้ ซึ่งอาจตรงตามความต้องการของกรณีเรา แต่ภาษาอื่นจะว่าอย่างไรคงต้องถกกันอีกที:

Shift	NumLock	Level3	Level5	ผลลัพธ์
no	no	no	no	level 1
yes	no	no	no	level 2
no	yes	no	no	level 2
yes	yes	no	no	level 1
no	no	yes	no	level 3
yes	no	yes	no	level 4
no	yes	yes	no	level 3
yes	yes	yes	no	level 4
no	no	no	yes	level 1
yes	no	no	yes	level 5
no	yes	no	yes	level 5
yes	yes	no	yes	level 1
no	no	yes	yes	level 6
yes	no	yes	yes	level 7
no	yes	yes	yes	level 7
yes	yes	yes	yes	level 6

หลักการคือ:

• ปุ่ม NumLock จะใช้สลับโหมดระหว่างตัวเลข (level 2-7) กับลูกศร (level 1) ถ้า NumLock ล็อคอยู่ ปุ่ม numpad จะได้ตัวเลข แต่ถ้า NumLock ไม่ล็อค numpad จะกลายเป็นปุ่มลูกศร
• ปุ่ม Shift ใช้เปลี่ยนปุ่ม numpad ให้เป็นโหมดตัวเลข มีค่าเท่ากับการล็อค NumLock แต่ถ้า NumLock กำลังล็อคอยู่ ปุ่ม Shift จะมีผลยกเลิก NumLock ซึ่งนี่เป็นพฤติกรรมปกติของ XKB
• ปุ่ม Level3 (ปกติจะใช้ Right_Alt) จะยกแคร่ปุ่ม numpad ขึ้นสู่ระดับ 3 และถ้ามีการกด Shift ร่วมด้วย ก็จะยกแคร่ขึ้นสูร่ะดับ 4 ส่วนปุ่ม NumLock ไม่มีผลใด ๆ กับระดับ 3 ซึ่งนี่ก็เป็นพฤติกรรมปกติของ XKB เช่นกัน (นัยว่าระดับ 3 มักเป็นการยกแคร่ชั่วคราว ไม่ใช่การล็อค จึงมีผลทับการล็อคของ NumLock)
• ปุ่ม Level5 (ในกรณีของเราใช้ ScrollLock) จะล็อคปุ่ม numpad ไว้ที่ระดับ 5 แต่จะมีผลหลังพิจารณา NumLock/Shift แล้วเท่านั้น การให้ NumLock มีความสำคัญสูงกว่าก็เพื่อความสะดวกในการสลับไปมาระหว่างการป้อนตัวเลขกับการใช้ปุ่มลูกศรนั่นเอง
• ในระดับ 5 นี้ ปุ่ม Level3 จะมีผลในการยกแคร่ปุ่ม numpad จากระดับ 1 (NumLock ไม่ล็อค) ขึ้นสู่ระดับ 6 และจากระดับ 5 (NumLock ล็อคอยู่) ขึ้นสู่ระดับ 7 ตามลำดับ
• ระดับ 8 ยังไม่มีที่ใช้

การกำหนด XKB type ของปุ่ม ต้องกำหนดไว้ละเอียดเพื่อ (พยายาม) ให้ครอบคลุมกรณีของภาษาต่าง ๆ แต่ในการกำหนดผังของเรา เราก็เพียงกำหนดระดับการยกแคร่ของปุ่ม numpad ง่าย ๆ แบบนี้:

• ระดับ 1: เป็นปุ่มลูกศร, Home, End, PgUp, PgDn, Ins, Del
• ระดับ 2: เป็นเลขอารบิก, จุดทศนิยม
• ระดับ 3-8: เป็นเลขไทย, จุดทศนิยม

แต่ปุ่ม 8 ระดับนี้ จะมีผลเฉพาะเมื่ออยู่ในโหมดภาษาไทยเท่านั้น ส่วนเมื่ออยู่ในโหมดภาษาอังกฤษ ก็จะมีเพียง 2 ระดับแรกเท่านั้นตามปกติ

ดังนั้น โดยสรุปสำหรับผู้ใช้ในกรณีใช้งานปกติก็คือ:

NumLock	ภาษา	ScrollLock	ผลลัพธ์
ไม่ล็อค	*	*	ลูกศร
ล็อค	US	*	เลขอารบิก
ล็อค	TH	ไม่ล็อค	เลขอารบิก
ล็อค	TH	ล็อค	เลขไทย

หากต้องการทดสอบ ผม build deb สำหรับ xkb-dataเอาไว้ที่ debclub repository โดยอ่านข้อมูลสรุปสำหรับผู้ใช้ได้ที่ บทความที่ debianclub

อย่างไรก็ดี การใช้งานอาจเกิดปัญหากับการใช้งาน IM module ของ GTK+ บางตัว กล่าวคือ:

• ถ้าใช้ X Input Method (ค่าปริยาย) จะใช้ผังแป้นพิมพ์ใหม่นี้ได้ทันที
• ถ้าใช้ Thai-Lao input method (มีมาใน GTK+ ให้เลือกได้) จะต้องใช้ GTK+ 2 และ GTK+ 3 ที่แพตช์แก้บั๊กแล้วจาก debclub repo จนกว่าบั๊ก GNOME #652720 จะแก้ไขที่ต้นน้ำ
• ถ้าใช้ Thai (libthai) จากแพกเกจ gtk-im-libthai หรือ gtk3-im-libthai จะต้องเป็นรุ่น 0.2.0 ขึ้นไป ขณะที่เขียนนี้ได้ upload เข้า unstable (sid) แล้ว แต่ยังต้องรอครบกำหนดจึงจะย้ายเข้า testing (wheezy)

ดังนั้น สำหรับตอนนี้จึงขอแนะนำให้ติดตั้งผ่าน debclub repository จะสะดวกที่สุดครับ ทดลองแล้วต้องการปรับแก้อะไรก็แนะนำเข้ามาได้ครับ ถ้าใช้การได้ดี ก็จะได้ผลักดันแพตช์ต่าง ๆ เข้าที่ต้นน้ำเพื่อให้มีผลกับทุก distro ต่อไป

Xlib updates

ความคืบหน้าอีกอย่าง คือเรื่องของภาษาไทยใน Xlib ที่ได้เคย รายงานไว้ เมื่อคืนนี้ debian มีการปรับรุ่น libx11 จาก 1.2 เป็น 1.2.1 โดยได้รับแพตช์หนึ่งในสี่ที่ได้เสนอไว้ใน Debian #520509 ส่วนอีกสามแพตช์นั้น เขารับว่าจะช่วยผลักดันเข้า upstream ให้ เย้! โดยบอกให้ผมปรับรูปแบบของแพตช์ให้เป็นไปตาม Guidelines ของ X.Org ก่อน

ทำไมตอนนั้นถึงหาหน้านี้ไม่เจอนะ.. สับสนกับกระบวนการของ X.Org เหมือนกัน เดี๋ยวต้องดูที่ x.org เดี๋ยวต้องไปที่ freedesktop.org วุ่นวายพิลึก ถ้าไม่นับช่องทางการส่งแพตช์ว่ามีทั้ง bugzilla และ mailing list อีก เคยเจอแนวนี้กับ evolution ก็เซ็งสุด ๆ ยิ่งถ้าเป็นโครงการที่เกี่ยวกับ mono แล้ว ยังต้องไปดูที่ novell.com อีกจุดหนึ่งด้วย ไม่ชอบโครงการสไตล์นี้เลย แบบ GNOME นี่แหละชัวร์ดี bugzilla ที่เดียวเลย ใครสะเออะไปคุยใน mail ก็โดนไล่มา bugzilla หมด แบบนี้สิ ค่อย contribute ง่ายหน่อย

อย่างไรก็ดี บ่นกับตัวเองเสร็จแล้วก็ไปปรับแพตช์ตามที่เขาแนะ แล้วก็ตอบเขากลับไป (ไม่ว่าอะไรคร้าบ ขอบคุณอย่างสูงที่เสนอจะช่วยผลักดันแพตช์ให้) พร้อมกันนี้ ก็เอาแพตช์ใหม่มา build deb แล้ว upload เข้า debclub "ก้านกล้วย" เสียเลย update กันได้ครับผม เพื่อการใช้งานภาษาไทยที่ราบรื่น

Thai X locale, Extended Grapheme Cluster in Pango

หลังจากที่ GNOME 2.26 ออกไปแล้ว ก่อนที่จะเริ่มเคลียร์ TODO list ก็แปล Rhythmbox ที่มีการ แจ้งการออกรุ่นล่วงหน้า ให้กับนักแปลไว้เสียก่อน ดูเหมือนจะทันนาทีสุดท้ายก่อน 0.12.0 จะออกพอดี (วันพฤหัสที่ผ่านมา)

จากนั้น ก็มีอีกรายการหนึ่งที่ผมลืมใส่ไว้ใน TODO list คือการ update libx11 deb ซึ่งมีการปรับรุ่นเป็น 1.2 ใน sid โดยเพิ่มแพตช์ภาษาไทยเข้าไปใหม่ (ตามรายการสรุปใน blog เก่า) แต่พร้อมกันนั้น ก็ไปพบเพิ่มเติม ว่า X locale ไทยมีแฟ้ม Compose เปล่า ๆ โผล่มาด้วย ไม่แน่ใจว่ามีมาตั้งแต่รุ่นไหน แต่ผลของมันก็คือ การกำหนดโลแคล LC_CTYPE ให้เป็นไทยจะไม่เพียงพออีกต่อไปที่จะเปิดใช้ XIM ไทย แต่จะต้องกำหนด locale modifier ใน XMODIFIERS แบบเฉพาะเจาะจงด้วย (ดูรายละเอียดการกำหนด XMODIFIERS ใน บทความใน homepage) มิฉะนั้น แฟ้ม Compose จะทำให้ XIM ของยุโรปที่ชื่อ "local" ถูกเรียกขึ้นมาใช้แทน

การใช้ Compose นี้ นักพัฒนา Xandros ที่เคยรายงานบั๊กเข้ามา (ตามที่ เล่าไว้ใน blog เก่า) ได้บอกไว้ตอนนั้นว่า เขาแก้ขัดปัญหา SCIM บนโลแคลไทยไป ด้วยการคัดลอกข้อมูล X locale ของ en_US เข้ามาทับของไทย ..ซะงั้น ผมไม่แน่ใจว่าตรงนี้ได้มีการติดต่ออะไรไปที่ต้นน้ำจนมีการใส่ Compose มาใน X locale ไทยตั้งแต่ต้นน้ำหรือเปล่า หรือที่เป็นไปได้อีกอย่าง คือระบบ Makefile ของ libx11 ต้นน้ำนั้น ใช้วิธี include common rule ในทุกโลแคล โดยต้องการให้ทุกโลแคลมีแฟ้ม Compose ทั้งหมด!

จะยังไงก็ตามแต่.. ผมได้รายงานบั๊ก Debian #520509 พร้อมชี้แจงว่า upstream ได้เพิกเฉยต่อบั๊กและแพตช์ต่าง ๆ ที่รายงานไป แต่วิธีแก้แบบนี้ไม่น่าจะถูกต้อง พร้อมกันนั้น ก็ได้ update deb ที่ debclub เอาไว้ด้วย

เรื่องถัดมาที่ทำไป คือเรื่อง extended grapheme cluster ใน Pango กับการเลื่อนเคอร์เซอร์และการลบเซลล์ด้วย Delete (เช่น ใน Mozilla #474068) หลังจากได้ทราบรายละเอียดจาก comment ใน Mozilla แล้ว ก็ตรวจสอบโค้ดของ Pango อีกที และได้ file GNOME #576156 พร้อมเสนอแพตช์แฮ็ก ๆ ไปแพตช์หนึ่ง

เรื่องการ file bug นี้ หยิบขึ้นมาทำก่อน เพราะเป็นเรื่องที่ต้องรอคำตอบ เรา file ไว้แล้วไปทำอย่างอื่นระหว่างรอได้

เรื่องต่อไป คิดว่าจะเป็นเรื่องฟอนต์ เกี่ยวกับปัญหาที่ Davide Viti ได้ ตรวสอบ ไว้

A Corollary to Linus's Law

ESR เขียนถึง Linus's Law ไว้ใน บทที่ 4 ของบทความ The Cathedral and the Bazaar (มี ฉบับแปลไทย) ว่า

Given enough eyeballs, all bugs are shallow.

แต่สำหรับประเทศกำลังพัฒนาอย่างเรา ผมอยากจะเพิ่มว่า

Given enough mouths, most bugs catch interests.

ผมได้ file bug พร้อมเสนอแพตช์สำหรับ libx11 ไป 3 bug ที่ Freedesktop.org (สรุปไว้ใน blog เก่า) ซึ่งสองในสามบั๊กนี้ เป็นบั๊กค่อนข้างร้ายแรงสำหรับผู้ใช้ภาษาไทยที่ได้พบ คือถึงกับทำให้ป้อนภาษาไทยไม่ได้ หรือป้อนได้แต่อักขระบนเส้นบรรทัด ป้อนสระบน-ล่างและวรรณยุกต์ไม่ได้เลย แต่สำหรับนักพัฒนาที่ Freedesktop แล้ว เรื่องนี้ไม่ได้สำคัญอะไรมาก หรืออาจจะสำคัญ แต่ไม่รู้จะทดสอบยังไง

ผมห่างเหินจากการทำงานในชั้น Xlib มานาน นับตั้งแต่ X.Org fork ออกมาจาก XFree86 ผมก็ไม่ได้ไปแตะต้องอะไรกับ X อีกเลย จนกระทั่งได้พบปัญหาเหล่านี้ ถึงได้กลับไป ผมจึงเป็นหน้าใหม่โดยสิ้นเชิงสำหรับชุมชนใหม่นี้ ทั้ง ๆ ที่ถ้าเป็นสมัย XFree86 แล้ว แพตช์ต่าง ๆ เกี่ยวกับ I18N จะได้รับความสนใจมากกว่านี้มาก

กับ Debian X Strike Force ก็เช่นกัน ผม file Debian #443800 สำหรับหนึ่งในสามบั๊กนั้นไป ก็ไม่มีเสียงตอบรับใด ๆ นอกจากการ forward bug ไปที่ upstream ซึ่งการ forward bug ของ Debian นี้ เป็นความพยายามที่จะลดความแตกต่างระหว่าง Debian กับ upstream ให้มากที่สุด คืออะไรที่พบโดยผู้ใช้ Debian แต่เป็นปัญหาที่ต้องแก้ที่ upstream ก็จะ forward รายงานให้ แต่ในกรณีของผมนี้ ผมได้ถอยลงมาจาก upstream เพื่อหวังว่า distro จะช่วยผลักดันแพตช์ให้ เหมือนกับที่ผมเคยได้รับจากกรณีแพตช์ตัดคำไทยใน Gecko ซึ่งในขณะนั้น นักพัฒนาของ Debian ได้ forward bug กลับไปที่ Mozilla พร้อมกับย้ายไปคุยเกี่ยวกับแพตช์ที่นั่นให้ด้วย แต่ในกรณีของ libx11 กลับไม่ใช่ คือ forward แล้วเงียบ อาจเป็นเพราะเขาไม่มีข้อมูลเพียงพอเรื่องภาษาไทย หรือไม่เห็นมีคนไทยอื่น ๆ บ่น หรือยังมีงานอื่นที่สำคัญกว่าต้องทำก็ได้ นั่นทำให้ผมเลิกล้มที่จะ file อีกสองบั๊กที่เหลือ แล้วไปพยายามผลักดันที่ upstream ด้วยตัวเอง

แต่สำหรับ Ubuntu แล้ว เรื่องมันต่างกัน เพราะเรื่องไม่ได้เริ่มจากมุมมองของนักพัฒนา แต่มาจากมุมมองของผู้ใช้ ใน LP #273856 โดยคุณ DArKer ได้รายงานว่า "Thai language input not work correctly" พร้อมกับมีความเห็นของผู้ใช้อื่น ๆ ตามมาอีกเป็นพรวน ทุกคนช่วยกันสาธยายอาการต่าง ๆ พร้อมวิธีแก้ขัดของตัวเอง การที่มีผู้ใช้หลายคนยืนยันจึงต่างจากการบุกเดี่ยวของผมในดินแดนแปลกหน้าราวฟ้ากับดิน และส่วนหนึ่งที่ต้องยอมรับคือ ท่าทีที่สนใจปัญหา I18N ของ Ubuntu เองด้วย หลังจากที่นักพัฒนามารับเรื่องและวิเคราะห์ปัญหาร่วมกับผู้ใช้ พอผมซึ่งมาสาย เข้าไปพูดถึงแพตช์ที่เคยทำไว้ เขาซึ่งพอรู้รายละเอียดของปัญหาระดับหนึ่งมาแล้ว ก็ทดสอบและรับแพตช์ได้อย่างรวดเร็ว

นี่คือสิ่งที่ ESR ได้กล่าวถึง The Importance of Having Users เสียงของผู้ใช้ มีส่วนช่วยแก้ปัญหาพอสมควร สำหรับสาขาของปัญหาที่อยู่นอกความสนใจของกระแสหลัก โดยเฉพาะเรื่องภาษาของประเทศกำลังพัฒนาอย่างเรา

จริงอยู่ ว่าการมีจำนวนผู้ใช้ปลายทาง (end-user) ที่มาก มีส่วนช่วยกดดันทางอ้อม ให้นักพัฒนาต้องสนใจ แต่ผลจะชัดเจนกว่ามาก ถ้าผู้ใช้ลงมือ "ส่งเสียง" ต่อปัญหาต่าง ๆ โดยตรง ตามแนวทางที่ซอฟต์แวร์เสรีและโอเพนซอร์สเปิดไว้ให้

Thai XIM and Conversion Bug on UTF-8 Locale

อีกบั๊กหนึ่งที่ทีมสุริยันจับได้ คือ XIM ไทยไม่รับสระบน-ล่างใน UTF-8 locale ซึ่งมีสาเหตุมาจากโค้ดของผมใน Xlib ที่ทำไว้ตั้งแต่สมัยที่ยังไม่มี UTF-8 locale เกิดขึ้น โดยไปทึกทักเอาว่า ถ้า string conversion callback ที่ไปอ่าน text input buffer ของ app มานั้น ได้ string มาในรูป multi-byte ก็แปลว่าเป็น TIS-620 เสมอ ซึ่งใช้ไม่ได้กับ UTF-8 locale

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

ยังต้องรอรีวิวเพื่อ check-in ต่อไปครับ แต่โพสต์ไว้เผื่อใครจะเอาไปใช้หรือช่วยทดสอบในระหว่างนี้

ก่อนหน้าจะ file bug นั้น ก็ได้ file GNOME #484653 เพื่อแก้ให้ imxim immodule ของ GTK+ ส่ง surrounding text กลับให้ XIM ในรูป wide char แทน multi-byte ไปพลาง แต่ปรากฏว่า การใช้ wide char เองก็มีปัญหาของมัน เนื่องจากขนาด wide char เองก็เริ่มไม่คงที่ คือเป็น multi-word ในบางแพลตฟอร์มที่ใช้ wide char 16 บิต โดย encode ในรูป UTF-16 แทนที่จะเป็น UCS ตรง ๆ หลังจากคิดตลบสอง ก็คิดว่าแก้ที่ XIM เองให้อ่าน multi-byte ให้ถูกต้อง น่าจะตรงประเด็นกว่า แล้วก็ใช้ multi-byte เหมือนเดิมต่อไป

สรุปบั๊กใน Xlib ที่ผ่านมา:

• #12517: XIM ไทยไม่ตรวจลำดับเมื่อ NumLock/CapsLock ติด พบโดยทีมสุริยัน
• #12759: XIM ไทยไม่รับสระบน-ล่างเมื่อใช้โลแคล UTF-8 (blog นี้) พบโดยทีมสุริยัน
• #15719: SCIM และ XIM server อื่น ๆ เรียกไม่ขึ้นในโลแคลไทย พบโดย Xandros
• #16475: SCIM โหลดขึ้นแล้ว แต่ไม่รับอักขระใด ๆ เนื่องจากปัญหาการแปลงรหัส พบโดย Xandros

เพิ่งได้ check-in แค่หนึ่งในสี่แพตช์ครับ

Thai XIM and NumLock/CapsLock Bug

บั๊กที่เกิดจากปุ่ม CapsLock/NumLock ใน input method ภาษาไทยนี่ ผมตามแก้โค้ดตัวเองมาหลายที่ละ ทั้งใน gtk-im-libthai, ใน GTK+ stock immodule แล้วก็ล่าสุด ใน Xlib เอง ทั้งนี้เพราะผมใช้โค้ดเดิม ๆ ซ้ำในแพตช์ที่ส่งไป โดยในระหว่างทำแพตช์นั้น ผมใช้แป้นพิมพ์ของโน้ตบุ๊ก เลยไม่เคยใช้ NumLock/CapsLock เลย จนกระทั่ง MrChoke รายงานมาเป็นครั้งแรกใน gtk-im-libthai เมื่อนานมาแล้ว

ล่าสุด (ก็หลายเดือนมาแล้วเหมือนกัน) ทีมสุริยันเจอบั๊กนี้อีกใน XIM คือถ้า NumLock/CapsLock ติดอยู่ XIM ภาษาไทยจะไม่กรองลำดับอักขระเลย ผมเคยเจอปัญหาและทางแก้จาก GTK+ immodule แล้ว ก็เลยเสนอแพตช์ลักษณะเดียวกันเข้า Xlib แต่ปรากฏว่า มันไม่ง่ายอย่างที่คิด

CapsLock นั้น ไม่มีปัญหา แป้นพิมพ์แทบทุกระบบจะใช้ modifier mask ตรงกัน คือใช้แมโคร LockMask ใน <X11/X.h> ได้เลย แต่สำหรับ NumLock นั้น ไม่ได้มีในแป้นพิมพ์ทุกรุ่น แถมแต่ละรุ่นก็ยัง map modifier แตกต่างกันไป การที่ผมใช้ xev จับ keyboard event ได้ mask เป็น Mod2Mask นั้น บังเอิญใช้ได้แค่บนลินุกซ์เท่านั้น แต่ในระบบอื่น เช่น AIX มีคนบอกว่า map เป็น Mod5 และวิธีที่ปลอดภัยที่สุด คือ ตรวจสอบกับ X server ด้วย XkbGetVirtualMods

อ่าน man page ก็แล้ว อ่าน spec และ โพรโทคอล ของ XKB ก็แล้ว นั่งทดลองไปมาก็ไม่สำเร็จซะที ดูเหมือนจะมีปัญหาเกี่ยวกับ config บางอย่างของ XKB ที่ทำให้ฟังก์ชันมัน return BadAlloc มาตลอด ราวกับ X server ไม่รองรับ XKB เลย สุดท้าย เลยโกงนิดหน่อย ด้วยการแอบดูโค้ดของชาวบ้าน คือ NumLockX และ gkleds (Debian: gkrellm-leds)

แกะไปแกะมา NumLockX นั้น เขามีสองวิธี คือใช้ XKB ก่อน ถ้าเหลวก็มาใช้ XGetModifierMapping แทน ซึ่งหลังจาก trace ดูแล้ว มันทำงานได้ผลด้วยวิธีหลัง ไม่ใช่เพราะ XKB ส่วน gkleds นั้น ไม่มีอะไรเกี่ยวกับ modifier mask เลย เพราะมันมีหน้าที่แค่แสดง indicator เท่านั้น ไม่ใช่เซ็ต NumLock ด้วยเหมือน NumLockX ก็เลยไม่มีโค้ดอะไรที่เกี่ยวข้อง

ก็เลยดัดแปลงวิธีของ NumLockX มาใช้ แล้ว update patch ใน Freedesktop #12517 เสีย

หุ ๆ โอเพนซอร์สก็ดียังงี้แหละ ขัดสนอะไรก็หยิบยืม/ต่อยอดกันได้ (โดยไม่ต้องแจ้งเป็นลายลักษณ์อักษร :P) ต้องขอบคุณ NumLockX ที่ทำให้ได้ solution

ตอนนี้ xorg เขายังไม่รับแพตช์ครับ รอรีวิวต่อไป..

A Bug a Day

ช่วงที่ผ่านมา ได้ทำตัวเป็นผู้ใช้ซอฟต์แวร์เสรีที่ดี คือได้ file bug เกือบทุกวัน..

17 มิ.ย.

Debian #486614 update คำแปลไทยสำหรับ debconf ของ samba4

ที่มาของบั๊ก: ได้รับแจ้งจาก maintainer

19 มิ.ย.

รายงานบั๊กที่พบใน fontforge เกี่ยวกับเรื่องค่าขยะใน strikeout และ sub/superscript (thread ใน thai-linux-foss-devel list) โดยแจ้งไปที่ fontforge-devel mailing list (แต่ไม่โดน archive) วันถัดมาเขาก็แก้ให้ใน CVS เรียบร้อย

ที่มาของบั๊ก: จาก ข่าวเรื่อง Plutoid ทักท้วงไปหลายที่ โดยที่ blognone แก้ด้วยการขีดฆ่าข้อความเดิมทิ้ง ซึ่งบังเอิญมันเละในเครื่องผม ซึ่ง gen ฟอนต์จากรุ่นพัฒนา

21 มิ.ย.

ไม่ได้รายงานบั๊ก แต่ follow up Debian #473508 เกี่ยวกับเรื่อง AbiWord 2.6

ที่มาของบั๊ก: บั๊กเก่า รอนานแล้ว

23 มิ.ย.

Freedesktop #16475 ว่าด้วยเรื่อง SCIM ไม่ทำงานบนโลแคลไทย เพราะปัญหาใน Xlib

ที่มาของบั๊ก: จาก รายงานเดิม จากนักพัฒนา Xandros

Debian #487664 คำผิดใน Debian Developer's Reference ใน 6.7.9 ว่าด้วยเรื่องของ debug package

ที่มาของบั๊ก: ระหว่างหาที่ผิดใน xlib โดยติดตั้ง libx11-6-dbg ซึ่งเป็น debug package ของ libx11-6 แล้วหาวิธีตั้งค่าก่อนดีบั๊ก ซึ่งสุดท้ายก็พบว่าไม่ต้องตั้งอะไรเลย แค่ติดตั้งก็ใช้ได้แล้ว รายละเอียดอ่านจาก reference ก็เข้าใจ เพียงแต่เจอที่ผิดในเนื้อหา โดยที่ยังไม่มีใครรายงาน เลยรายงานซะ

24 มิ.ย.

ไม่ได้ file bug อะไร แต่เป็นกิจกรรมการ upload deb คือแพกเกจที่ติดต่อ sponsor ไว้นานแล้ว (gtk-im-libthai, libdatrie, libthai) พอดี sponsor ว่างมา upload ให้แล้ว ก็เลยจัดการ update CVS ตามนั้นด้วย

ที่มาของบั๊ก: lintian

25 มิ.ย.

Debian #487912 ขอกำจัด conflict กับ xiterm+thai ใน xiterm (openi18n) deb

ที่มาของบั๊ก: xiterm+thai 1.07 เปลี่ยนชื่อ binary program หลบ xiterm ของ openi18n แล้ว และ xiterm+thai 1.07-1 ใน debian (โดย นิวตรอน) ก็ได้ตัด conflict ออกแล้ว เหลือแต่ที่ xiterm เท่านั้น

26 มิ.ย.

Debian #488090 update คำแปลของ dpkg พร้อมกันนั้นก็ update คำแปลของ debian-installer ด้วย

ที่มาของบั๊ก: ติดค้างงานแปลไว้นานแล้ว

28 มิ.ย.

รายงานบั๊ก GPeriodic ซึ่งไม่ได้ update ชื่อธาตุที่ 110, 111 ซึ่งได้ชื่ออย่างเป็นทางการแล้ว (Darmstadtium และ Roentgenium ตามลำดับ) พร้อมทั้ง mark ข้อความสำหรับแปลเพิ่มอีกหนึ่งข้อความด้วย (ส่งบั๊กทางเมลส่วนตัว ไม่มี archive)

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

29 มิ.ย.

Debian #488461 เกี่ยวกับบั๊ก GPeriodic นั่นแล แต่รายงานที่ Debian ด้วย

มีแต่บั๊กตอดเล็กตอดน้อย.. แต่ก็ด้วยการรายงานบั๊กไม่ใช่หรือ ซอฟต์แวร์เสรี/โอเพนซอร์สถึงมีการพัฒนา :-)

More Xlib Bug Fix for SCIM

หลังจาก แก้บั๊กของ Xlib เรื่อง การโหลด SCIM และ XIM server อื่นในโลแคลไทย ไปแล้ว นักพัฒนา Xandros คนเดิมรายงานมาว่า SCIM โหลดแล้ว แต่คีย์ภาษาไทยไม่ติด

แว้บไปทำเรื่องอื่นซะนาน เกือบสองเดือนแน่ะ เมื่อวานกับวันนี้เลยหยิบขึ้นมาไล่ดู ก็พบว่า ปัญหาก็คือ SCIM เวลาจะ commit string นั้น จะแปลงจาก wchar ให้อยู่ในรูป compound text ของ X ก่อน commit ซึ่งโลแคลไทยประกาศ character set ที่จะส่งใน compound text ไว้เป็น TIS620-0:GR ดังนี้ (แฟ้ม /usr/share/X11/locale/th_TH.UTF-8/XLC_LOCALE):

cs1 {
    side    GR:Default
    length  1

    wc_encoding \x30000000
    ct_encoding TIS620-0:GR
}

แต่ตอนที่ส่ง patch เกี่ยวกับ ISO8859-11 เมื่อตอนที่ประกาศเป็นมาตรฐานนั้น ไม่ได้แก้ตรงนี้ด้วย เพราะคิดว่ามันเทียบเท่ากัน แต่เผอิญว่าในตาราง compound text ปริยายของ Xlib ได้ตัด TIS620-0:GR ออกไปแล้ว เนื่องจากมี escape sequence ซ้ำกับ ISO8859-11:GR ทีนี้ พอ SCIM พยายามแปลง compound text มันก็เลยหา TIS620-0:GR ตามที่ระบุไม่เจอ

วิธีแก้ ก็เปลี่ยนเป็น ISO8859-11:GR แทนเสีย:

cs1 {
    side    GR:Default
    length  1

    wc_encoding \x30000000
    ct_encoding ISO8859-11:GR
}

เสร็จแล้วก็รายงาน Freedesktop Bug #16475 เสีย.. ได้คำแนะนำเพิ่มเติมว่า จะทำ UTF-8 เลยไหม.. เดี๋ยวทำเพิ่มเลย :-)

Xlib Blocks SCIM for Thai

เคยพยายามจะใช้ SCIM ภาษาไทยกับ application ต่าง ๆ ที่ไม่ใช่ GTK+ มาหลายยกแล้ว แต่ไม่เป็นผล แต่ก็ไม่ได้สนใจมาก เพราะไม่ค่อยได้ใช้ SCIM อยู่แล้ว จนวันนี้ ได้รับคำถามจาก Pat Suwalski ซึ่งเป็นนักพัฒนา Xandros ว่าทำไม SCIM ถึงทำงานได้แต่บนโลแคลอื่น ยกเว้นโลแคลไทย

คำถามสั้น ๆ แต่บอกอาการชัดเจนมาก นั่นสิ ผมไม่เคยลองในโลแคลอื่นเลย พอลองบ้างก็พบว่ามันเวิร์ก ยกเว้นโลแคลไทยอย่างที่เขาว่าจริง ๆ

รู้อย่างนี้แล้ว ก็นึกถึงโค้ดใน Xlib ที่เช็กเงื่อนไขการเปิด XIM ไทยที่ อ.พฤษภ์ เป็นคนเจอแล้วมาบอกคนใน TLWG เมื่อนานมาแล้ว ว่ามันเช็กแค่โลแคลว่าเป็นภาษาไทยหรือเปล่าเท่านั้นเอง ลองไล่โค้ดแล้วรันแห้งในใจ ก็พบว่า Xlib จะไม่มีทางเปิด XIM server ภายนอกเลย ถ้าอยู่ในโลแคลไทย! ฉะนั้น จึงไม่สามารถใช้ SCIM ผ่าน XIM server ได้ ที่มันใช้ได้กับ GTK+ app ก็เพราะมันมี GTK+ SCIM bridge ที่เชื่อมตรงกับ GTK+ นั่นเอง

ว่าแล้วก็ file Freedesktop Bug #15719 พร้อมเสนอแพตช์ไว้

หมดไปหลายชั่วโมง สำหรับวันนี้ แต่ก็สนุกดี

แล้วก็กลับมาเคลียร์ TODO ต่อ T_T