mozlibthai

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

โดยอาศัยความเห็นของ Mike Hommey จากเดเบียนคนเดิม ที่ว่าควรจะแยกออกมาเป็น component โดยหลังจากดูตัวอย่างของ mozgnome component ที่เขาชี้ ก็เริ่มเห็นด้วย ว่าเป็นวิธีที่เหมาะเจาะที่สุด แต่ครั้นจะทำแบบ generic เพื่อเสียบเข้าใน line breaker framework ที่มีอยู่หรือ ก็ยังไม่มีกลไกแยกภาษาอย่างที่ว่า ก็เลยตกลงใจ เสนอทำเป็น component อย่างที่ Mike แนะนำ แต่ใช้เฉพาะกิจสำหรับภาษาไทยภาษาเดียวไปก่อน จนกว่าจะมีการปรับปรุง framework ให้มีกลไกคล้าย Pango

แนวคิดก็คือ กำหนด interface ขึ้นมาใช้เรียกจากภายใน line breaker กลางของ Gecko ผ่าน XPCOM จากนั้น ก็ทำส่วนที่จะเชื่อมกับ libthai เป็น component มารองรับ (พูดง่ายๆ ก็คือ ใช้ Dependency Inversion Principle นั่นเอง) ซึ่ง component นี้ จะติดตั้งหรือไม่ก็ได้ โดยถ้าไม่ติดตั้ง ก็จะ fallback ไปใช้ rule base ที่พี่สัมพันธ์เคยทำไว้เมื่อนานมาแล้ว

component นี้ จะลิงก์กับ libthai ในแบบปกติ จึงสามารถปล่อยให้เป็นหน้าที่ของ loader ของระบบตามปกติได้ โดยไม่ต้องกำหนด absolute path ตามแบบ PR_LoadLibrary และปัญหาเรื่องการบังคับ dependency กับ libthai ก็หมดไป โดย distro สามารถ build แพกเกจแบบใช้ libthai แล้วแยก mozlibthai component ออกไปเป็นแพกเกจย่อยต่างหากได้ ไม่ต้องรวมกับแพกเกจ firefox หลัก ใครอยากใช้ libthai ตัดคำ ก็แค่ติดตั้งแพกเกจที่ว่าเพิ่มเอา เรียกว่าแก้ปัญหาที่มีในทางเลือกเดิมได้หมด วู้! มันยอดมากเลยจอร์จ..

หลังจากเสนอแพตช์เข้าใน bug ไปแล้ว ต่อไปก็คือ รอรีวิวแพตช์ (หวังว่าจะใช้เวลาเหมือนกามนิตภาคพื้นดิน ไม่ใช่ภาคสวรรค์) แล้วก็ พยายามแต่งองค์ทรงเครื่อง libthai ให้ใช้บนวินโดวส์ได้ จะได้ใช้ solution เดียวกันนี้บนนั้นได้ด้วย ทั้งนี้ รวมถึง Linux distro ต่างๆ นอกเหนือจาก Debian และ Ubuntu ที่ยังไม่มี libthai ด้วย!

ความจริงแล้ว การแยก component แบบนี้ มีประโยชน์อีกอย่าง ตรงที่สามารถมี engine แบบอื่นได้อีก เช่น ใครชอบ icu ก็ทำ component mozicu หรืออะไรทำนองนี้ มาเสียบใน interface นี้แทน mozlibthai ก็ได้ (โดยซอร์สจะอยู่ที่ต้นน้ำหรือไม่ก็ได้) แต่อีกเรื่องที่ควรทำก็คือ generalize interface นี้ ให้ใช้กับภาษาอื่นได้ด้วยเสียก่อน (เช่น ลาว เขมร พม่า)

ฝันซะไกล.. ขอให้แพตช์ผ่านรีวิวทีเถิด.. สาธุ! ^_^'

Firefox Revisited

หลังจากทำ scim-thai ไป พร้อมกับอัปโหลดขึ้น sid ไปแล้ว ก็หันไปแก้ผังแป้นพิมพ์ไทยใน scim-tables และ scim-m17n ที่ผิดอยู่ คุยไปคุยมา กำลังจะได้ IM ภาษาไทยเจ๋งๆ ใน m17n (คุณ Takahashi ทำให้ ผ่านการอธิบายของผม) ก็ปรากฏว่า มีการตอบมาจาก Jungshik Shin ใน Mozilla Bug #7969 เกี่ยวกับ libthai patch ที่เสนอไป เลยต้องวางมือจาก m17n มาทำ firefox ซะก่อน

ทำไปทำมา ก็ปรับ patch โดยเพิ่มประสิทธิภาพในการตัดคำขึ้นอีก แล้วก็โพสต์เข้าไป

เกี่ยวกับเรื่องการตัดคำไทยใน firefox เรื่องมันช่างยาวจริงๆ ถ้านับอายุบั๊ก ตอนนี้ก็ครบ 7 ปีเต็มไปหมาดๆ เมื่อเดือนที่แล้ว มีแพตช์เสนอเข้าไปมากมายหลายรุ่น ผมเองก็ไม่คิดว่าจะได้เข้าไปเกี่ยวข้องหรอก ถ้าไม่ใช่เพราะ Ubuntu Localisation Sprint ที่ผมเอาแพตช์ของอ๊อท (ที่ปรับมาจากแพตช์ของพี่สัมพันธ์อีกที) ส่งเข้า Ubuntu แล้วมีการปรับแพตช์ ส่งเข้า bugzilla แล้วก็เลยติดตามต่อมาตลอด

หลังจากส่งเข้า Ubuntu ได้แล้ว มาร์ค ก็ สานต่อ โดยพยายามติดต่อ distro ต่างๆ ทั้ง Fedora, SuSE ส่วนผมก็ติดต่อ Debian โดยติดเงื่อนไขว่า Firefox 2.0 ได้ freeze ไปแล้ว ต้องไล่ตาม patch ที่ distro ต่างๆ ที่ 1.8 branch เอา แต่ปรากฏว่า Debian มีการตอบสนองด้วยการไม่รับแพตช์ที่ใช้วิธีโหลดไลบรารีขณะ run-time โดยเสนอว่าควรทำเป็น add-on แทน หรือถ้าจะลิงก์ก็ลิงก์ตรงๆ เลย แล้วก็ forward bug กลับมาที่ upstream ซึ่งผมก็ปรับแพตช์ที่ 1.8 branch สำหรับเดเบียนมาโพสต์ที่ Mozilla โดยใช้วิธีลิงก์ตรงๆ ด้วย configure option --enable-libthai เพราะการทำ add-on นั้น เป็นไปไม่ได้ เนื่องจากโค้ดปัจจุบันยังไม่มีการวิเคราะห์ข้อความ Unicode แยกเป็นภาษาต่างๆ เหมือน Pango ทำให้มี line breaker engine ได้ทีละตัวเท่านั้น

ระหว่างนั้น ผมได้รับคำแนะนำจากมาร์คและพี่สัมพันธ์ ว่าควรร้องขอให้นักพัฒนา review patch (เป็นธรรมเนียมที่ผมไม่เคยเจอใน GNOME) ก็เลยได้ขอให้ Jungshik Shin ช่วย review ให้ และคำตอบที่เขาตอบมาก็คือ ให้ไปทำที่ trunk!

เออแฮะ.. ด้วยความที่ช่วงที่ผ่านมา โฟกัสไม่ได้อยู่ที่ firefox เท่าไร (ติดงานอื่นซะเยอะ) กลับมาดูทีไร ก็ง่วนติดตามแต่ agenda เดิม ที่พยายาม patch 1.8 branch จนไม่รู้ตัวว่า เราได้ย้ายที่สนทนามาที่ upstream แล้ว และธรรมเนียมปฏิบัติที่ควร ก็คือการทำงานที่ trunk!

ก่อนหน้านี้ เคยทำงานที่ trunk มาแล้วครั้งหนึ่ง แต่พอโพสต์ patch แล้ว ไม่มีคนไทยช่วยทดสอบได้ ต่างคนต่าง request ให้ไปที่ 1.8 branch โดนติงมาคราวนี้ เหมือนโดนเคาะหัวให้ตื่นจากภวังค์ กลับมาทำงานที่ trunk อีกครั้ง

แต่ก็ยังมีหลายวิธีให้ตัดสินใจอยู่ดี ว่าการตัดคำไทยจะใช้วิธีไหน

วิธีแรก ใช้ PR_LoadLibrary โหลด libthai ขณะ run-time แล้วเรียกฟังก์ชันแบบ dynamic เอา ตามแพตช์ของอ๊อท มีข้อดีคือ ไม่ต้อง build firefox ใหม่ถ้าจะตัดคำไทย แค่ติดตั้ง libthai ลงในระบบก็เป็นอันใช้ได้ แต่ข้อเสียคือ การโหลดไลบรารีต้องกำหนด full path ของไลบรารี ซึ่งแพลตฟอร์มต่างๆ เรียกชื่อไฟล์ของ dynamic library ไม่เหมือนกัน .so ของยูนิกซ์, .dll ของวินโดวส์ รวมทั้งไลบรารีที่ติดตั้งก็อยู่ได้หลายแห่ง ของวินโดวส์นั้น เข้าใจว่าไม่มีที่อยู่ตายตัวสำหรับติดตั้งไลบรารี อีกทั้งชื่อไลบรารี ก็มีการระบุเลขเวอร์ชัน เช่น .so.0 ถ้าเราออก .so.1 เราจะต้องมาตาม patch firefox อยู่ดี

วิธีที่สอง ใช้ configure option --enable-libthai เอา ใครมี libthai ให้ลิงก์ ก็เปิด option นี้ แล้วก็ให้ linker/loader ของระบบทำงานให้ ก็เป็นอันว่า ไม่ต้องพยายามจัดการเรื่องแพลตฟอร์มต่างๆ ในซอร์สอีก แต่ข้อเสียก็คือ distro ต่างๆ จะยอมเปิด option นี้ไหม ในเมื่อกว่า 99% ของผู้ใช้ในโลกนี้ ไม่จำเป็นต้องใช้ feature นี้เลย? รวมทั้งบนวินโดวส์ เราก็ต้องพยายามให้ libthai พร้อมใช้บนนั้นด้วย (เช่น ทำ installer)

วิธีที่สาม ซึ่งยากที่สุด แต่ดีที่สุด คือเพิ่มกลไกวิเคราะห์แยกภาษาข้อความแบบ Pango ใน Mozilla แล้วเรียก line break engine แยกภาษาให้ได้ จากนั้น จึงสร้าง component สำหรับภาษาไทยเสียบเข้าไป วิธีนี้ อาจจะยืมมือ Pango ตามที่เสนอใน Mozilla Bug #336959 แต่ปัญหาคือ performance แย่มากๆ และอีกอย่าง หลาย distro เริ่มปิดตัวเลือก --enable-pango กันแล้ว -_-' จึงมีวิธีย่อยอีกวิธีหนึ่ง คือทำ framework ขึ้นเองใน Mozilla เสียเลย ซึ่งที่แน่ๆ คือ คงไม่เห็นผลให้คนไทยได้ใช้ในระยะอันใกล้

ปวดหัวใช่ย่อย.. สองวิธีแรกนั้น เลือกแบบไหนก็ทำแพตช์ได้ไม่ยาก แต่วิธีที่สามนี่ เดินทางไกล.. :-/

scim-thai 0.1.0

หลังจากที่ทำส่วน engine ของ scim-thai เสร็จไป ก็นั่งทำส่วนจัดการค่า config พร้อมทั้ง GUI setup เพิ่ม ก็คิดว่าพร้อม release ให้ทดสอบกันละ

การคอมไพล์จาก source ต้องลง scim และ libthai-dev ก่อนนะครับ และถ้ามี GTK+ อยู่ในระบบ ก็จะ build GUI setup ด้วย

ส่วนพี่น้องที่ไม่อยากคอมไพล์เอง รอสักพัก ไว้ข้าพเจ้าจะ build deb ให้อีกที

scim-thai alpha

จากที่ เขียนถึง SCIM เมื่ออาทิตย์ที่แล้ว ก็ตั้งเป้าไว้ว่าจะทำ SCIM Thai module ละ พอเสร็จจากประชุมทีมแปล ก็เลยสลับมาทำ SCIM โดยแวะไปแช็ตที่ IRC ของ SCIM นิดหน่อย บอกกล่าวเขาและขอคำแนะนำ

ได้คำชี้แนะว่าควรไปดูที่ m17n, scim-tables และ KMFL ก่อน ซึ่งก็ไม่ผิดจากที่คาดเท่าไรนัก อย่าง m17n ก็คุ้นหน้าคุ้นตา แต่พบว่าการสนับสนุนภาษาไทยในนั้นยังขาดการเช็กลำดับ รวมทั้ง scim-tables ด้วย ส่วน kmfl ยังหาภาษาไทยไม่เจอ

ในบรรดา IME ที่เขาชี้ให้ไปดู ดูเหมือน m17n จะมีแนวโน้มสนับสนุนภาษาไทยแบบเต็มๆ ได้ ส่วนตัวอื่นๆ ดูเหมือนไม่ได้ออกแบบไว้รองรับกลไกที่ภาษาไทยต้องการ แต่กระนั้นก็ตาม ก็ยังรู้สึกว่า เราต้องการอะไรที่มากกว่าที่ m17n มีให้ ประกอบกับเรามี libthai ที่มีโค้ดพร้อมอยู่แล้ว การเขียน IME ขึ้นมาโดยเรียกใช้รูทีนใน libthai น่าจะไม่กินเวลามาก รวมทั้งสามารถดูแลโค้ดให้ทำงานสอดคล้องกับ IM อื่นๆ ที่เคยทำไว้ (คือ gtk-im-libthai) น่าจะสะดวกกว่าในระยะยาว ก็เลยยังคงยืนยันว่าจะเขียน SCIM Thai module โดยเฉพาะอยู่ ซึ่งเขาก็แนะให้ไปดูตัวอย่างโค้ดใน IME ต่างๆ รวมทั้งภาษาสิงหล ซึ่งต้อง retrieve context เหมือนเราด้วย

ซึ่งก็ปรากฏว่าใช้เวลาไม่นานจริงๆ ในการสร้าง scim-thai ที่สามารถป้อนข้อความโดยตรวจ-แก้ลำดับการพิมพ์ได้ ทั้งนี้ ก็อาศัยทั้ง libthai และ gtk-im-libthai ที่มีอยู่แล้วนั่นเอง

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

ปัญหาเลยตกอยู่ที่ว่า แล้วสำหรับระบบที่ตั้ง XKB map ไทยไว้ด้วยล่ะ? จะทำยังไง? ไม่ตีกันแย่เหรอ? วันที่สองที่ทำ (หลังจากสร้าง project และทำระบบ build ระบบแปลในวันแรก) ก็เลยเป็นการสร้าง keymap สำหรับแปลง US keysym เป็น keysym ไทยในผังแป้นพิมพ์ 3 แบบ (เกษมณี, มอก., ปัตตะโชติ) โดยพยายามให้ครอบคลุมกรณีที่ใช้ XKB map ไทยด้วย ซึ่งเรื่องการครอบคลุมกรณีที่ตั้ง XKB ไทย ก็ยังไม่ครบเท่าไร มีบางกรณียังหลุดรอด เพราะ SCIM มันอยู่ในชั้นที่เหนือ XKB ขึ้นมาแล้ว เลยลงไปยุ่งกับชั้น XKB ได้ไม่มาก เรียกได้ว่า SCIM ออกแบบมาให้ใช้กับการตั้ง keymap เป็น US โดยเฉพาะ ถ้าคุณตั้ง XKB ไทยพร้อมกับใช้ SCIM ด้วย ก็ไม่รับประกันการใช้งานละครับ

วันที่สาม คือวันนี้ ก็เพิ่มโค้ดส่วนตรวจสอบ-แก้ลำดับด้วย libthai ก็พอทำงานได้ระดับหนึ่งละ สนใจทดสอบเชิญดาวน์โหลด ซอร์สโค้ด (GPL-2) ไปคอมไพล์ได้ แต่นี่ยังไม่ release นะครับ ยังต้องตกแต่งอีกพอประมาณ

GNOME Movements

GNOME 2.15.4 ออกแล้ว การออกรุ่นนี้ จะนำ GNOME เข้าสู่ช่วง string announcement หมายความว่า โปรแกรมไหนจะเพิ่มข้อความ ต้องประกาศให้นักแปลทราบใน mailing list ก่อนจะเข้าสู่ช่วง string freeze ในวันที่ 7 สิงหาคม คือห้ามเพิ่มข้อความใหม่ในโปรแกรม เพื่อให้โอกาสนักแปลได้ปรับคำแปลอย่างเต็มที่

แต่ที่มา blog นี่ ก็เพราะได้อ่าน NEWS ของแพกเกจต่างๆ แล้ว มีเรื่องน่าสนใจ กล่าวคือ:

• gnome-vfs ในรุ่นนี้ เลิกใช้ bonobo และไปใช้ dbus ในการสื่อสารระหว่างโพรเซสแทน ทำให้ตัด dependency ของ bonobo ได้จำนวนหนึ่ง
• gtk-engines หลายตัว ได้ย้ายไปใช้ cairo แล้ว และ theme engine ไหนที่ไม่มีใครอาสาย้ายไป cairo ก็ถูกตัดออก (คือ Lighthouseblue และ Metal)
• โปรแกรมหลายตัวเริ่มใช้ dbus ในการสื่อสารมากขึ้น เช่น gnome-screensaver รองรับการขอระงับ screensaver ผ่าน dbus โดยโปรแกรมต่างๆ ตามเงื่อนไข (เช่น ปิด screensaver ขณะเล่นหนัง), gnome-power-manager ก็รองรับการขอระงับการจัดการพลังงานในทำนองเดียวกัน (เช่น ระงับการพักเครื่องขณะเขียนซีดี)
• หลายโปรแกรม ยังคงดำเนินการกำจัด dependency ในไลบรารีเก่าต่อไป โดยใช้ feature ที่ได้ย้ายมา gtk+ แทน
• ใน mailing list ของ GTK+ มีการพูดถึงการ modularize GTK+ เพื่อจำกัดขนาดของ GTK+ ในการใช้งานต่างๆ เช่น การตัดวิดเจ็ตที่ปลดระวางแล้ว หรือวิดเจ็ตเฉพาะทาง ฯลฯ
• GNOME เริ่มย้ายจาก CVS ไปใช้ subversion แล้ววันนี้ โดยในตอนนี้ GNOME CVS จะเป็น read-only เพื่อให้เนื้อหาอยู่นิ่งๆ ให้ทีมงาน import เข้า subversion ได้สะดวก

ไม่ได้ตาม GNOME เสียนาน เพราะมัวแต่ติดงานโน่นนี่ โผล่มาอีกทีก็เกือบ freeze แล้ว หวังว่าต่อไปนี้จะมีเวลาทำงานมากขึ้น :P

ปล. วันนี้ประชุมทีมแปลที่ห้อง #tlwg เด้อ เพื่อช่วยกันเคลียร์ OSS Glossary

New squid and Transparent Proxy

squid 2.6.1 มาถึง sid แล้ว ปรากฏว่า มีการเปลี่ยน statement ใน config file ซึ่งจะมีผลต่อเซิร์ฟเวอร์ที่ตั้งเป็น transparent proxy จากเดิมที่กำหนดทำนองนี้:

  http_port                    8080
  httpd_accel_host             virtual
  httpd_accel_port             80
  httpd_accel_with_proxy       on
  httpd_accel_uses_host_header on

ก็ลดเหลือแค่นี้:

  http_port                    8080 transparent

โดยคำหลัก httpd_accel* ทั้งหลายแหล่ จะเลิกใช้

Embarrassment in Debian Translation

ช่วงนี้ งานแปลภาษาไทยใน debian เริ่มมีผล เมื่อมีการ config แพกเกจต่างๆ ข้อความก็เริ่มเป็นภาษาไทย แต่ในบางระบบอาจเจอขยะแทน ถ้ากำหนดโลแคลไว้ไม่ตรงกับการสนับสนุนของเทอร์มินัล เช่น ถ้าใช้ xiterm+thai ที่สนับสนุนแค่ TIS-620 แต่ตั้งโลแคลไว้เป็น th_TH.UTF-8 ก็จะอ่านไม่ออก และถ้าใช้ uxterm ที่ใช้ UTF-8 เป็นหลัก แต่ตั้งโลแคลไว้เป็น th_TH ธรรมดา ก็จะเจอแต่เครื่องหมายคำถามเช่นกัน แต่ถ้าตั้งไว้สอดคล้องกัน ก็ไม่มีปัญหา

เรื่องอาจจะซับซ้อนขึ้นอีกนิด สำหรับการ config ที่ text console คือต้องเซ็ต console font เอาไว้อย่างเหมาะสม และตั้งโลแคลให้สอดคล้องกันด้วย คือถ้าตั้งเทอร์มินัลไว้ในโหมด 8-bit (โดยระบุตัวเลือก -m tis620 ให้กับคำสั่ง consolechars หรือ setfont) ก็ต้องกำหนดโลแคลให้เป็น th_TH.TIS-620 หรือถ้าตั้งเทอร์มินัลไว้เป็น unicode (โดยไม่ได้ระบุตัวเลือก -m หรือโดยใช้คำสั่ง unicode_start) ก็ต้องกำหนดโลแคลให้เป็น th_TH.UTF-8

เรื่องนี้ค่อนข้างเข้าใจง่าย ถ้ารู้หลักการ แต่สำหรับผู้ใช้ที่ไม่รู้ ก็อาจทำเอาตกอกตกใจได้เหมือนกัน เรื่องนี้ ทำให้ผมที่กำลังทำงานแปลให้เดเบียนอยู่ ต้องชะลอการแปลในบางแพกเกจ ยังไม่กล้าผลีผลามมาก แต่พยายามมุ่งไปเฉพาะที่แพกเกจที่จำเป็นสำหรับ debian-installer ตัวใหม่ที่สามารถใช้ GTK+ ในโหมดกราฟิกได้เท่านั้น (ทดสอบ daily image ได้ ถ้าสนใจช่วยหาบั๊ก) และระหว่างนี้ ก็พยายามมุ่งไปตรวจสอบโครงสร้างพื้นฐานของ console ให้แน่ใจได้ว่า จะสามารถใช้ภาษาไทยใน text console ได้แน่ๆ รวมทั้งค่า config ปริยายใน installer ที่เหมาะสมด้วย เพื่อเตรียมรองรับงานแปล พักนี้เลย file bug เข้าไปหลายตัวเหมือนกัน

ปล. ตรวจสอบสถานะของงานแปลไทยในเดเบียนได้ที่หน้า Central Debian translation statistics

SCIM Merge

ท่าทาง SCIM จะมาแรง ตอนไป Ubuntu ก็เห็นภาษาต่างๆ โดยเฉพาะ CJK พูดถึงแต่ SCIM กัน หรือแม้แต่ตอนที่พบคนทำ IIIMF เองในอีกงานหนึ่ง เขาก็ยังเป็นห่วง ว่า SCIM จะมาแทน IIIMF ที่เป็นมาตรฐานใหม่ แต่พัฒนาต้วมเตี้ยมไม่ทันใจ

จนเมื่อวันก่อน พบข้อความใน mailing list ของ GNOME ว่าจะมีประชุมตกลงเรื่องอนาคตของ gswitchit applet ใน GNOME (ซึ่งตอนนี้ถูกแยกร่างไปเป็น gnome-keyboard-properties capplet, gnome-keyboard-applet บนพาเนล, และบางส่วนเข้าไปอยู่ใน gnome-settings-daemon) โดยประเด็นหนึ่งคือการรวมกับ SCIM!

เขาประชุมกันตีสองบ้านเรา (ยังกะรอดูบอลโลก) เลยไม่ได้ไปสังเกตการณ์ แต่ก็ตามอ่านใน IRC log ได้ โดยสรุปก็คือ ขณะนี้ GNOME และ KDE ใช้โครงสร้างการติดตามสถานะผังแป้นพิมพ์ร่วมกันแล้ว ผ่าน libxklavier ซึ่งแตกออกไปจาก gswitchit ไปอยู่ใน freedesktop.org และมีความพยายามที่จะรวม SCIM เข้ากับ libxklavier ดังกล่าว อ่าน log ดู แม้จะเป็น hacker คุยกัน แต่แต่ละคนก็รู้รายละเอียดของฝ่ายอื่นค่อนข้างน้อย อ่านๆ ไปก็ตามทันได้ไม่ยาก นัยว่า ต่อไป SCIM อาจจะกลายเป็น input method framework หลักแทน XIM ตัดหน้า IIIMF จริงๆ และอาจจะแทนที่ XKB ในบางส่วนด้วย

สงสัยถึงเวลา hack SCIM ให้ใช้ภาษาไทยได้เต็มที่แล้วมัง ตอนนี้ ภาษาไทยสนับสนุนผ่าน scim-tables อยู่ คือเป็นการแปลงปุ่มในผัง 'us' เป็นอักขระภาษาไทยตรงๆ ไม่มีการตรวจสอบลำดับอะไร ตอนถูกถามที่ Ubuntu ก็เลยตอบไปว่า ยังไม่แนะนำให้ใช้ SCIM กับภาษาไทยในตอนนี้ แต่ให้ใช้ gtk-im-libthai ไปก่อน

/me check out scim CVS ไม่ได้เลยแฮะ เลยดูด tarball release มาแกะแทน :P

thailatex - dtx preparation

เนื่องจากเมื่อวานนี้ GNOME CVS เดี้ยง เข้าไม่ได้ ไม่รู้มีปัญหาอะไรที่ฝั่งเราหรือเปล่า เพราะไม่เห็นมีประกาศปิดเซิร์ฟเวอร์ใน mailing list มาก่อน แต่ก็ไม่เป็นไร ไปหาอย่างอื่นทำ โดย upload swath deb ที่คนใน mailing list เมินมาหลายเดือนเข้า mentors.debian.net รอไว้ (ปรากฏว่า วันนี้ได้เข้า sid แล้ว เร็วดีจัง)

ทำอย่างอื่นยังไม่ได้ ก็เลยสลับเอาอีกงานขึ้นมาทำ คือ thailatex โดยพยายามเขียน thai.dtx เพื่อให้อยู่ในรูปแบบที่เข้า babel ได้ โดยดูตัวอย่างจากภาษาอื่นๆ เอา แนวทางก็คือ เป็น Literate programming ตามแนวคิดของปรมาจารย์ Donald Knuth แต่พอลงมือเขียนจะต่างจากการเขียนโปรแกรมแบบมีคอมเมนต์เยอะๆ ตรงที่ โปรแกรมพวกนั้น จะอาศัยโครงสร้างของโปรแกรมเป็นหลัก แล้วไปเติมคอมเมนต์ตามจุดต่างๆ เอา แต่สำหรับ TeX แล้ว จะใช้โครงร่างเอกสารเป็นหลักในการดำเนินเนื้อหา แล้วแทรกโค้ดประกอบตามลำดับ ซึ่งก็ปรากฏว่า เป็นการบังคับให้จัดลำดับเนื้อหาโค้ดให้เป็นกลุ่มก้อน ให้เรื่องที่เกี่ยวข้องกันอยู่รวมกัน และเล่าเรื่องตามลำดับ หรือบางที ลำดับของโค้ดก็ไปบังคับลำดับการเล่าเรื่องอีกที สรุปว่าทำให้ทุกอย่างสอดคล้องกันดี

เขียนเสร็จแล้ว ก็ โพสต์ถาม เพื่อนๆ ให้ช่วยกันตรวจสอบดู รายละเอียดคร่าวๆ คือ ใช้สองแฟ้ม คือ thai.dtx และ thai.ins โดยเนื้อหาทั้งหมดอยู่ใน thai.dtx แต่ thai.ins จะใช้ช่วย strip เอกสารออก เหลือแต่โค้ดคือ thai.ldf และเมื่อคอมไพล์ thai.dtx ก็จะได้เอกสารประกอบโปรแกรมมาทันที โฮ่ๆ เท่ไม่หยอก

แฟ้มต่างๆ ที่ว่า เอาฝากไว้ที่ homepage ข้าพเจ้าเอง ถ้าพี่น้องช่วยกันตรวจสอบแล้วไม่มีปัญหา ก็จะได้ใส่เข้าใน thailatex และเตรียมส่งเข้า babel ต่อไปครับผม