scim-thai 0.1.2

scim-thai 0.1.2 ออกไปแล้วเมื่อวานนี้ ก็คงเป็นตัวสุดท้ายในการปรับรุ่นแพกเกจต่าง ๆ ใน linux.thai.net ระลอกนี้ (แต่ไม่ใช่หมดแค่นี้ อาจมีการออกรุ่นตัวอื่นที่ได้ปรับรุ่นไปแล้วอีกถ้าจำเป็น)

สำหรับ scim-thai รุ่นนี้ ถือเป็น maintenance release คือไม่ได้มีการเพิ่มความสามารถใหม่อะไร แต่เป็นการแก้ปัญหาเล็ก ๆ น้อย ๆ เกี่ยวกับระบบ build ที่ตรวจพบในช่วง 3 ปีที่ผ่านมา กล่าวคือ

• ปรับการ config การแปลข้อความด้วย gettext จาก gettextize ให้มาใช้ autopoint แทน ซึ่งทำให้ปรับข้อมูล PO ได้แนบเนียนไร้ร่องรอยมากขึ้น
• แก้ปัญหาการคอมไพล์ในกรณีที่ libthai ไม่ได้ติดตั้งไว้ในพาธมาตรฐาน เป็นปัญหาที่พบในระหว่างพัฒนา libthai ซึ่งต้องติดตั้งแยกต่างหากจาก libthai ของระบบ แล้วทำให้พบว่า make rule ของ scim-thai ยังติดปัญหาการคอมไพล์กับ libthai ที่แยกติดตั้งต่างหากนี้อยู่ กลายเป็นกรณีตัวอย่างให้อุดรูรั่ว
• แก้ปัญหาเรื่องการกำหนด LDFLAGS ซึ่งพบระหว่างที่จะ build แพกเกจ Debian รุ่นใหม่โดยปรับการ build ให้ใช้แฟล็ก "-Wl,--as-needed" แล้วพบว่าแฟล็กนี้ไม่มีผล ตรวจสอบแล้วพบว่าเป็นปัญหาการใช้ target *_LDFLAGS ใน Makefile.am ในการเพิ่มไลบรารีให้กับมอดูล ซึ่งพอสคริปต์ configure กำหนด LDFLAGS=-Wl,--as-needed แล้ว แฟล็กนี้มันจะไปต่อท้ายค่าใน target *_LDFLAGS อีกที ซึ่งผมดันไปลิสต์ไลบรารีในนั้นเสียแล้ว ค่า LDFLAGS จากการ configure ก็เลยไปต่อท้ายอยู่หลังรายชื่อไลบรารี จึงไม่มีผลกับไลบรารี ที่ถูกแล้ว ต้องใช้ target *_LIBADD ในการเพิ่มไลบรารีแทน ชื่อไลบรารีจึงจะมาอยู่หลัง LDFLAGS ในคำสั่งคอมไพล์ เป็นปัญหาที่มาดูทีหลังก็งง ว่าตอนนั้นผมทำแบบนั้นไปได้อย่างไร ทำให้ต้องมางมอยู่นานกว่าจะเจอ

สำหรับผู้ที่สนใจเรื่องการใช้แฟล็ก --as-needed ของลิงเกอร์ ก็ขออธิบายสักหน่อย

แฟล็ก --as-needed ใช้เพื่อให้ object file ที่ได้นั้น ลิงก์เฉพาะกับไลบรารีที่มีการใช้ symbol โดยตรงเท่านั้น (ตรวจสอบการลิงก์ได้ด้วยคำสั่ง objdump -p {so/exe-file} แล้วดูที่บรรทัด NEEDED ทั้งหลายใน Dynamic Section)

กล่าวคือ สมมติว่า object file ของเรามีการเรียกใช้ libA และ libB โดย libA ไปลิงก์กับ libP, libQ อีกที เวลาลิงก์จะต้องใส่ไลบรารีทั้งหมดที่ใช้ คือเป็น "-lA -lB -lP -lQ" และลิงเกอร์ก็จะลิงก์ทุกไลบรารีเข้ามาใน object file ของเรา นี่คือกรณีปกติ

การลิงก์ดังกล่าวมีปัญหาในทางปฏิบัติ เพราะไลบรารีต่าง ๆ มีการต่อยอดกันเป็นทอด ๆ หลายชั้น เช่น เฉพาะ GTK+ ก็มีไลบรารีลูกต่อพ่วงมาอีกถึง 44 ตัว:

$ ldd /usr/lib/libgtk-3.so.0.0.10 | wc -l
44

ในนี้ก็มีตั้งแต่ pango, glib, ati, cairo, freetype, libxcb และพรรคพวกอีกมากมาย และการลิงก์เฉพาะ GTK+ เข้ามาในโปรแกรมของเรา ก็จะต้องลิงก์ไลบรารีเหล่านี้เข้ามาทั้งหมด ทั้งที่ไม่มีการเรียกใช้ฟังก์ชันโดยตรงเลยก็ตาม

ความจริง ตอน run-time ก็จะต้องโหลดไลบรารีเหล่านี้เข้ามาทั้งหมดอยู่แล้ว ไม่งั้น GTK+ ก็ทำงานไม่ได้ อ้าว แล้วถ้างั้นมีปัญหาอะไร?

ปัญหาก็คือ การลิงก์ตรงกับไลบรารีใด ๆ จะหมายถึงการเกิด dependency ระหว่างแพกเกจของไลบรารีที่ลิงก์กันนั้น ทำให้ระบบแพกเกจโดยรวมมี dependency จำนวนมโหฬารเกินความจำเป็น และจะเป็นอุปสรรคต่อการขยับไลบรารีหนึ่ง ๆ ขึ้นสู่ major version ใหม่ (ซึ่งอาจไม่ ABI compatible กับรุ่นเก่า) เพราะจะต้องตามไป rebuild แพกเกจทั้งหมดที่ลิงก์ตรงกับมันอยู่ กลายเป็นปริมาณงานที่มากเกินจำเป็น ในเมื่อโปรแกรมคุณแค่ใช้ฟังก์ชันของ GTK+ เท่านั้น ทำไมจะต้องไป rebuild เมื่อมีการปรับ major version ของ cairo หรือ freetype ด้วย? สู้ให้เรื่องพวกนี้มัน encapsulate อยู่ในแพกเกจ GTK+ เท่านั้นไม่ดีหรือ?

นี่จึงเป็นที่มาของการใช้แฟล็ก --as-needed ในการ build แพกเกจของ distro ต่าง ๆ เพื่อให้มีการลิงก์เฉพาะกับไลบรารีที่มีการใช้ symbol โดยตรงเท่านั้น แล้วเวลาโหลดหรือติดตั้ง มันก็จะทำงานเป็นทอด ๆ ตามลำดับ dependency เอง ถ้ามีการปรับ major version ก็จะ rebuild เฉพาะแพกเกจที่มีการเรียกใช้ symbol โดยตรงเท่านั้น

บางคนอาจถามว่า แล้วทำไมไม่แค่ลิงก์แบบ "-lgtk-3-0" กับแพกเกจที่ใช้ GTK+ ก็พอล่ะ? ไม่ต้องแถมพ่วงพวก pango, glib ฯลฯ มาด้วยก็ได้ คำตอบคือการลิงก์แบบนี้ไม่ portable ครับ ลิงเกอร์ของ GNU อาจทำได้ แต่ยูนิกซ์ทั่วไปทำไม่ได้ ต้องใส่ library ที่ต้องการตามลำดับให้ครบด้วยจึงจะลิงก์ผ่าน (เข้าใจว่ามาจากวิธีลิงก์แบบ static ที่ต้องมีไลบรารีครบ) ดังนั้น พวก link flags ที่ได้จาก pkg-config จึงมีไลบรารีที่ต้องใช้แถมพ่วงมาทั้งหมดเสมอ แล้วลิงเกอร์ของ GNU สามารถมาคัดออกอีกทีด้วยตัวเลือก --as-needed ได้

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 ต่อไป

gtk-im-libthai 0.2.0

ออก gtk-im-libthai 0.2.0 ไปแล้วเมื่อวานซืน แต่เพิ่งมีเวลาได้เขียนบันทึกวันนี้เอง

รุ่นนี้มีการเปลี่ยนแปลงที่สำคัญ คือพอร์ตโค้ดไปยัง GTK+ 3 โดยจะ build และติดตั้งมอดูลสำหรับทั้ง GTK+ 2 และ GTK+ 3 ตามแต่จะ configure โดยใช้ซอร์สเดียวกัน ทำให้รุ่นนี้ต้องการ GTK+ 2 รุ่น 2.21.8 ขึ้นไป ที่มี macro ใหม่ของ GTK+ 3 โดยยังคง compatibility กับ GTK+ 2 รุ่นเก่าไว้อยู่

นอกจากนี้ก็ได้ปรับปรุงระบบ build ใหม่ให้จัดการการติดตั้ง/ถอดถอนได้รัดกุมขึ้น และเปลี่ยนมาใช้แมโครรุ่นใหม่ ๆ ของ autotools

การเปลี่ยนแปลงต่าง ๆ เหล่านี้ถือว่าใหญ่พอสมควร จึงได้ออกรุ่นใหม่เป็น 0.2.0 แทนที่จะเป็น 0.1.6

นอกจากนี้ ก่อนออกรุ่นยังได้พบบั๊กอีกตัวหนึ่งในระหว่างพัฒนา solution สำหรับการป้อนเลขไทยด้วย numpad แทนการใช้ ฟอนต์ Sarabun IT9 คือการไม่รับปุ่มที่เป็น level 3 shift จึงได้แก้ไข พร้อมกับรายงานบั๊ก GNOME #652720 ใน Thai-Lao IM module ของ GTK+ ซึ่งมีอาการเดียวกันไว้ด้วย (มี deb ที่แก้แล้วที่ debclub repository [gtk+2.0, gtk+3.0]) ซึ่งหลังจากแก้แล้วก็สามารถใช้ผังแป้นพิมพ์ใหม่ที่ผมดัดแปลงให้ป้อนเลขไทยด้วย numpad ได้ ส่วนรายละเอียดของผังแป้นพิมพ์ใหม่นั้น ขอเขียนแยกใน blog ต่างหากครับ

ผู้ใช้ Debian sid ก็คงได้พบการ upgrade ไปแล้วเมื่อวานนี้ โดยถ้าคุณใช้ GNOME 3 จาก experimental อยู่ ก็อาจจะติดตั้งแพกเกจใหม่เพิ่ม คือ gtk3-im-libthai เพื่อให้ใช้กับ GTK+ 3 ได้ โดยแพกเกจเดิม (gtk-im-libthai) นั้น จะเป็นมอดูลสำหรับ GTK+ 2.x เท่านั้นครับ

Life & Thanks

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

ตอนนี้อาการของแม่ก็ค่อย ๆ ดีขึ้นวันละนิด ๆ เหมือนกัน อีกไม่นานคงหายดีครับ

สำหรับบล็อกนี้ก็ขอเขียนขอบคุณผู้สนับสนุนงานพัฒนาของผมในเดือน พ.ค. และ มิ.ย. นี้ โดยเมื่อปลาย พ.ค. คุณหน่อย SNC ได้ส่งอาหารเสริมมาให้แม่ผมทาน และเมื่อต้น มิ.ย. นี้ คุณโด่ง KDE ได้หย่อนสตางค์ลงหมวกเพื่อสนับสนุนงานพัฒนาของผม

ขอขอบคุณทั้งสองท่านที่ช่วยสนับสนุนงานของผมนะครับ ขอให้รวย ๆ ชีวิตการงานราบรื่น สุขภาพแข็งแรงครับ :-)

The Case of Sarabun IT9

เป็นเรื่อง.. เมื่อมติ ครม. สองอย่าง คือให้ใช้ฟอนต์สารบรรณและเลขไทยในเอกสารราชการ ได้ผสมกันทำให้เกิดกรณี ฟอนต์ Sarabun IT9 ที่ดัดแปลงฟอนต์สารบรรณในชุด 13 ฟอนต์โพสต์การ์ดแวร์ของ DIP-SIPA ให้ป้อนเลขไทยด้วยแป้นตัวเลข (numpad) ได้ แต่เป็นวิธีที่ไม่ถูกหลักการ คือไปเปลี่ยนรูปร่างของตัวเลขอารบิกให้เป็นเลขไทย ทำให้ข้อมูลที่เก็บลงในแฟ้มแตกต่างจากสิ่งที่แสดงบนหน้าจอ

เรื่องนี้ต้องแยกพูดเป็นสองประเด็น คือประเด็นเรื่องกฎหมาย กับประเด็นเรื่องเทคนิค

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

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

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

ผมพอเข้าใจแนวคิดของ SIPA ได้ ที่ไม่ยอมอนุญาตให้ดัดแปลงแบบนี้ น่าจะเป็นเหตุผลทางเทคนิคเป็นหลัก แต่ในทางกฎหมายแล้ว นี่กลับเป็นการแสดงให้เห็นจริงว่าฟอนต์ชุดนี้ไม่ได้ "ส่งเสริมการร่วมมือในการสร้างสรรค์ฟอนต์ในวงกว้าง" อย่างที่โปรยไว้ที่ต้นสัญญาอนุญาต

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

นี่เป็นปัญหาอีกอย่างของเงื่อนไขข้อ (2) ของสัญญาอนุญาต คือกลายเป็นว่า DIP และ SIPA จะต้องร่วมรับผิดชอบกับความถูกต้องทางเทคนิคของผู้ดัดแปลงด้วย ถ้าไม่ผ่านเกณฑ์ก็ไม่สามารถปล่อยให้ทำได้ แม้จะเปลี่ยนชื่อหลบแล้วก็ตาม แต่ถ้าไม่มีเงื่อนไขข้อนี้ แล้วปล่อยให้มันเป็นซอฟต์แวร์เสรีตามที่ควรจะเป็น DIP และ SIPA ก็ไม่ต้องมารับภาระที่เสี่ยงต่อการทำลายบรรยากาศความเปิดกว้างตรงนี้ แต่สามารถใช้วิธีรณรงค์ชี้แจงผู้ใช้ (อย่างที่ท้ายที่สุดก็ต้องมาทำอยู่ดีแบบตอนนี้) แทนได้

ปัจจุบันมีผู้ใช้หลายคนบ่นว่าฟอนต์สารบรรณเส้นบางเกินไป อยากให้ผู้จัดทำฟอนต์ปรับแก้ ก็น่าสนใจว่าฟอนต์ที่ประกาศเจตนารมณ์ว่าเปิดกว้างต่อการร่วมกันพัฒนา กลับไม่มีใครกล้าแตะต้อง ผมจึงยังยืนยัน ว่าสัญญาอนุญาตของฟอนต์โพสต์การ์ดแวร์ของ DIP และ SIPA ควรได้รับการแก้ไขเพื่อให้เป็นซอฟต์แวร์เสรีตามที่กล่าวอ้างอย่างแท้จริง

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

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

FOSS Why and How

เมื่อวันที่ 7 มิ.ย. ได้รับเกียรติจากศูนย์คอมพิวเตอร์ มข. ให้ไปบรรยายเรื่องโอเพนซอร์สเนื่องในโอกาสครบรอบ 25 ปีของศูนย์ฯ ก็เลยถือโอกาสรวบรวมเกร็ดความคิดต่าง ๆ เกี่ยวกับซอฟต์แวร์เสรีและโอเพนซอร์สที่เคยคิดหรือพูดไว้ในโอกาสต่าง ๆ ของตัวเอง มาเรียบเรียงเป็นเรื่องราว

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

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

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