Theppitak's blog

My personal blog.

11 กุมภาพันธ์ 2557

Thanks, and the November-January Diary

เร่งงานตามสัญญาโครงการอยู่หลายเดือน ไม่ได้เขียน blog จึงขอขอบคุณย้อนหลัง สำหรับผู้สนับสนุนงานพัฒนาของผมในเดือนพฤศจิกายน 2556 ถึงเดือนมกราคม 2557ที่ผ่านมาดังนี้ครับ:

ขออวยพรปีใหม่สากลและตรุษจีนย้อนหลังแด่ผู้สนับสนุนทุกท่าน ขอให้เจริญอายุ วรรณะ สุขะ พละ พร้อมทั้งมั่งมีศรีสุขครับ และที่สำคัญคือ 願源碼與你同在。[หงวงหง่วงแบ้อื่อลื่อตั่งต๋อ] May the Source be with you!

สามเดือนที่ผ่านมา นอกจากงานโครงการอักษรอีสานที่เป็นงานหลักแล้ว ก็มีงานพัฒนาอื่น ๆ เช่น

  • swath 0.5.2
    • แก้ปัญหา infinite loop ใน LaTeX filter ซึ่ง นิวตรอน รายงานมาทาง G+ (เป็น private share) พร้อมแพตช์แก้
    • แก้ปัญหาอักขระหายใน token ยาว ๆ ใน HTML filter ซึ่งคุณ Nicolas Brouard จากโครงการ ดีโมพีเดีย ได้พบขณะใช้ swath ช่วยเตรียมเอกสารฉบับพิมพ์ จากการใช้ base-64 encode รูปภาพในแท็ก <img src="data:image/png;base64,...> ซึ่งทำให้ token ยาวพอจะทำให้พบบั๊กได้ ถือเป็น use case ที่น่าสนใจมาก และทำให้รู้ว่ายังมีผู้ใช้ที่ใช้ HTML filter อยู่ ไม่ใช่แค่ LaTeX
    บั๊กทั้งสองนี้ เกิดจากความพยายามในการป้องกัน buffer overflow ใน swath 0.5.1 แต่แก้ไม่สมบูรณ์ (รุ่นก่อนหน้านั้นจะ segfault ในบั๊กหลังเลยทีเดียว ซึ่งเป็นช่องทางของ buffer overflow exploit ได้)
  • libdatrie 0.2.8
    • แก้ warning ใน test suite
    • แก้ปัญหาที่พบในการใช้ datrie เก็บคีย์ที่เป็นข้อมูล binary ซึ่งจะใช้ alphabet เต็มช่วงตั้งแต่ 1 ถึง 255 ทำให้พบปัญหาคีย์ซ้ำสำหรับอักขระ 255 อันเนื่องมาจากค่าสิ้นสุดการวนลูปที่ไม่ถูกต้อง รายงานโดยคุณ Naoki Youshinaga
    • แก้ให้ trie ล้มเหลวเมื่อเดินด้วยอักขระนอกช่วง alphabet แทนที่จะยอมให้อักขระดังกล่าวเดินได้ด้วยค่า 255 แล้วทำให้เกิดคีย์ปลอม ๆ ขึ้น แนะนำโดยคุณ Naoki Youshinaga เช่นกัน
    • เพิ่มเติมรายละเอียดในเอกสารประกอบ ตามที่ทักท้วงโดยคุณ Naoki Youshinaga
  • ปรับแพกเกจใน Debian โดยการเปลี่ยนแปลงที่น่าสนใจคือ
    • libdatrie-dev และ libthai-dev รองรับ multi-arch แล้ว หลังจากที่รองรับแค่ตัว lib package มาก่อนหน้านี้ ขณะนี้ dpkg รองรับการใช้แฟ้มร่วมกันระหว่างหลายแพกเกจแล้ว ทำให้สามารถใช้ header file ร่วมกันระหว่าง architecture ที่ต่างกันได้
    • รัน test suite ในการ build ทั้งใน libdatrie และ libthai ซึ่งทำให้พบ warning เพิ่มเติมใน libthai และแก้ที่ต้นน้ำแล้ว
  • ร่วมแปล VLC หลังจากพบคำสะกดผิดใน UI ก็ได้แปลเพิ่มเติมด้วยพอสมควร โดยเฉพาะชื่อภาษาต่าง ๆ ทำให้ได้ไปสอบทานกับคำแปล ISO 639 และ ISO 639-3 ในแพกเกจ iso-codes ควบคู่กันไปด้วย (ออกมาในรุ่น 3.50)
  • ตรวจทาน คำแปล GNOME ตามที่มีผู้ส่งคำแปลเข้ามา
  • งานแปล Xfce ขณะนี้แปลได้ 70% แล้ว

ป้ายกำกับ: , , , , , , ,

24 พฤศจิกายน 2556

My GNOME Escape

หนึ่งปีเต็มที่ผมได้เปลี่ยนมาใช้ Xfce เต็มตัว (บันทึกการทดลองใช้ E17, LXDE และ Xfce ก่อนจะตกลงปลงใจที่ Xfce) รู้สึกว่าได้เดสก์ท็อปที่ลงตัว ไม่พยายามวิ่งตามแพลตฟอร์มอื่นมากเกินไป ไม่ว่าจะวินโดวส์หรือแมคหรือแอนดรอยด์ ขณะเดียวกันก็ไม่ได้อนุรักษ์นิยมกับยูนิกซ์จ๋าจนดูตกยุค เรื่อง usability ถือว่าสอบผ่าน ความยืดหยุ่นในการปรับแต่งก็มีเหนือ GNOME โปรแกรมต่าง ๆ ที่จำเป็นก็มีให้เกือบครบ บางตัวที่ไม่มี (เช่น PDF viewer) ผมก็ยืมใช้จาก GNOME ไปพลางก่อน แต่ก็ทยอยถอดถอนตัวที่ไม่จำเป็นออกไปเรื่อย ๆ และคงรุ่น GNOME app ส่วนใหญ่ไว้ที่ 3.4

สาเหตุที่ยังคงรุ่น GNOME app ไว้ที่ 3.4 ก็เพราะการอัปเกรดเกินรุ่นนี้จะทำให้เกิดความเปลี่ยนแปลงของระบบอย่างใหญ่หลวง เช่น GDM 3.8 จะลากเอา systemd มาลง (ผ่านทาง gnome-settings-daemon) ซึ่ง systemd นี้ จะเป็นดีมอนสำหรับบูตระบบซึ่งจะมาแทนที่ sysvinit ที่ Debian ใช้อยู่ และ เป็นที่ถกเถียงกันอยู่ ในหมู่นักพัฒนาแพลตฟอร์มยูนิกซ์อื่น ๆ ที่ไม่ใช่ลินุกซ์ (เช่น OpenBSD, FreeBSD, Solaris) เพราะเป็นระบบบูตที่จำเพาะเจาะจงกับลินุกซ์เท่านั้น และยังมีข้อสังเกตว่ามัน ออกแบบขัดกับปรัชญาของยูนิกซ์อย่างแรง

ไม่ใช่แต่เท่านั้น GDM 3.8 ยังใช้ GNOME Shell ทำงานเป็นหน้าล็อกอินอีกด้วย คุณอาจจะคิดว่าผมใช้ความรังเกียจ GNOME Shell มาตัดสิน แต่ถ้าคุณมองความเหมาะสมในทางเทคนิคแล้ว จะเห็นว่ามีอะไรมากกว่านั้น ในเมื่อ GDM ต้องใช้ GNOME Shell และ GNOME Shell ก็ต้องใช้แทบทุกสิ่งทุกอย่างของ GNOME เพราะ GNOME Shell เองก็ออกแบบมาให้รวมทุกสิ่งทุกอย่างของ GNOME เข้ามาในตัว ไม่ว่าจะเป็นการจัดการพลังงาน การใช้พาเนล การจัดการเครือข่าย ไปจนถึง instant messenger และ video call! (ในฐานะนักแปล ผมติดตามเรื่องนี้ได้ไม่ยากครับ ทุกครั้งที่เห็นการย้ายข้อความจากแพกเกจอื่นเข้า GNOME Shell ผมปาดเหงื่อตลอด) ซึ่งก็หมายความว่า คุณไม่สามารถติดตั้ง GDM เพียงลำพังในฐานะ display manager ของระบบเพื่อใช้ล็อกอินเข้าเดสก์ท็อปอื่น (เช่น KDE, Xfce, LXDE, E17, WindowMaker ฯลฯ) โดยไม่แถมพ่วง GNOME เกือบทั้งตัวมาด้วยได้! แล้วนิยามของ display manager คืออะไรกันแน่?

ผมผิดหวังกับ GNOME อีกครั้งที่ออกแบบ GDM ให้ไปรุกล้ำนอกวาระการเข้าระบบ เพียงเพื่อจะเพิ่มประสิทธิภาพของ GNOME โดยไม่แยแสเดสก์ท็อปอื่น ถัดจาก systemd ที่ไปรุกล้ำระบบยูนิกซ์อื่นมาแล้ว พฤติกรรมแบบนี้ ผมว่าผมเคยเห็นมาก่อนนะครับ กับระบบปฏิบัติการบางยี่ห้อ...

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

สำหรับ display manager โชคดีที่โลกนี้มีตัวอื่นให้เลือก เช่น lightdm (ผมใช้ GTK+ Greeter) และ SLiM

แล้ว blog หน้า ผมจะมาเขียนถึงการใช้งาน Xfce ในฐานะ GNOME refugee ต่อไปครับ

ป้ายกำกับ: , ,

08 พฤศจิกายน 2556

Thanks, and the September-October Diary

ขอขอบคุณผู้สนับสนุนงานพัฒนาของผมในเดือนกันยายน-ตุลาคมที่ผ่านมาดังนี้ครับ:

เป็นอีกครั้งหนึ่งที่ต้องเขียน blog แบบรวบสองเดือน เนื่องจากภารกิจต่าง ๆ ค่อนข้างเร่งรัด จนอยากใช้เวลาสะสางงานให้เต็มที่มากกว่า

งานในช่วงสองเดือนที่ผ่านมา แบ่งเป็นหมวด ๆ ดังนี้ครับ:

โครงการอักษรอีสาน

งานพัฒนาที่ LTN และ Debian

เป็นการปล่อยสิ่งที่พัฒนาสะสมมาตั้งแต่ระลอกที่แล้วเมื่อต้นปี โดยทยอยตรวจสอบความเรียบร้อยและออกรุ่นซอฟต์แวร์ต่าง ๆ ดังนี้:

  • libdatrie 0.2.7
    • แก้ไขประเด็นเรื่อง portability เกี่ยวกับ void pointer arithmatics ซึ่งจะมีปัญหากับคอมไพเลอร์ที่ไม่ใช่ GCC โดยได้รับรายงานจากคุณ Mikhail Korobov ว่าคุณ Gabi Daver ได้พบปัญหานี้ขณะคอมไพล์ด้วย Visual C++ พร้อมแพตช์แก้
    • ระหว่างแก้ ได้ทดลองคอมไพล์ด้วยตัวเลือก -Wall ทำให้เจอ warning เพิ่มเติม และแก้ไขจนหมด
    • เขียน test case เพื่อให้สามารถตรวจสอบความถูกต้องเวลาแก้โค้ดได้ในอนาคต ที่ผ่านมาจะทดสอบผ่าน libthai เป็นหลัก แต่เขียน test case เป็นเรื่องเป็นราวน่าจะสะดวกกว่า ซึ่งในระหว่างที่เขียน test case ก็ทำให้ได้อ่านเอกสารประกอบและแก้ไขที่ผิด พร้อมกับได้เพิ่ม API เพื่อความสะดวกในการใช้งานด้วย
    • ปรับ Doxyfile ที่ใช้สร้างเอกสาร เพื่อตัดสิ่งที่เลิกใช้แล้วใน doxygen 1.8.4
    • ออก libdatrie 0.2.7.1 ตามมา หลังจากพบว่าลืมปรับค่า library version เพื่อให้ SONAME สะท้อนการเพิ่ม API ที่เกิดขึ้น
    • อัปโหลด 0.2.7.1-1 เข้า Debian sid
  • thaixfonts 1.2.6
    • มีการปรับระบบ build ตาม autoconf รุ่นใหม่ และเปลี่ยนมาใช้ XZ tarball แทน GZ tarball ซึ่งเป็นสิ่งที่ทำไว้นานแล้ว ก็ออกรุ่นมาเพื่อปรับตามซอฟต์แวร์อื่นเท่านั้น ส่วนตัวเนื้อหาฟอนต์ไม่มีการเปลี่ยนแปลงอะไร
    • อัปโหลด 1:1.2.6-1 เข้า Debian sid
  • LibThai 0.1.20
    • ปรับข้อมูลพจนานุกรมตัดคำตามที่พบกรณีต่าง ๆ ในช่วงที่ผ่านมา [เกร็ด: รุ่นนี้รู้จักอำเภอขนอมที่ไม่ใช่ ขน-อม แล้ว ;-)]
    • แก้ compiler warning ที่พบใน test case ต่าง ๆ
    • อัปโหลด 0.1.20-1 เข้า Debian sid
  • TeX hyphenation patterns
    • sync ข้อมูลพจนานุกรมตัดคำจาก libthai เข้าไปที่ ThaiLaTeX SVN พร้อมกับปรับแก้ hyphenation patterns ตามข้อมูลใหม่
    • แจ้งไปที่โครงการ tex-hyphen ว่าขอปรับข้อมูล hyphenation patterns ภาษาไทย พร้อมกับรายงานปัญหาของสคริปต์บางตัวที่ใช้สร้างข้อมูลอัตโนมัติ คุณ Mojca Miklavec ก็ได้ช่วยแก้สคริปต์ให้ (rev 652, 653) และรับแพตช์ปรับข้อมูลภาษาไทยไปรวมให้ (rev 654)
    • สอบถามและขอ import source ของ hyphenation patterns ภาษาไทยเข้าใน tex-hyphen โดยตรง เพื่อที่ต่อไปจะได้ไปทำงานที่นั่นแทนที่จะต้องผ่าน ThaiLaTeX แบบนี้ ทั้งนี้เพื่อให้เป็นไปตามแผน ที่เคยคุยกันไว้ จนกระทั่งได้ import source ใน rev 655
    • ไม่มีการอัปโหลดอะไรใน Debian แค่รอ Debian อัปเดตแพกเกจ texlive-base เท่านั้น
    • request ขอลบ thailatex ออกจาก Debian unstable เพื่อไม่ให้มีซอร์สตกค้างอยู่ (ลบแล้ว)
  • swath 0.5.1
    • แก้รหัสตัดคำของ Lambda จาก U+200C (ZWNJ) เป็น U+200B (ZWSP) ...ว่าแต่มีใครใช้ฟีเจอร์นี้ไหมเนี่ย?
    • sync ข้อมูลพจนานุกรมตัดคำจาก ThaiLaTeX/hyph-utf8 (ซึ่ง sync มาจาก LibThai อีกที) เพื่อให้ตัวตัดคำ LaTeX ทำงานสอดคล้องกับ hyphenation patterns
    • ก่อนออกก็ปรับซอร์สโค้ดของ swath เพื่อให้แต่ละรุ่นมีการปรับปรุงด้านความปลอดภัยไปทีละน้อย โดยในรุ่นนี้ได้ป้องกัน buffer overflow ใน file filter ต่าง ๆ (ยังมีให้แก้อีกเยอะในรุ่นถัด ๆ ไป :-P )
    • อัปโหลด 0.5.1-1 เข้า Debian sid
  • IBus-LibThai 0.1.2
    • แก้ปัญหาการกด shortcut (เช่น Ctrl-C) ใน IBus 1.5 อันเนื่องมาจากการเชื่อมรวมกับ XKB ของ IBus รุ่นนี้ ทำให้ผังแป้นพิมพ์ที่ระบุใน metadata ของ IBus-LibThai ว่าเป็น th ทำให้กด Ctrl-C ได้เป็น Ctrl-แ เสมอ แก้ไขโดยปรับผังแป้นพิมพ์เป็น us เท่านั้น
    • อย่างไรก็ดี การแก้ปัญหาในรายการที่แล้วทำให้เกิดปัญหาใหม่ คือทำให้กด accelerator ใน GUI ที่แปลเป็นไทย (เช่น Alt-ฟ เพื่อเรียกเมนู แฟ้ม) ไม่ได้ วิธีแก้ที่เหมาะสมจึงควรให้ IBus-LibThai พยายามแปลง key event ที่มีการกดปุ่มประกอบให้เป็นภาษาไทย แต่ปรากฏว่าไม่สามารถส่ง event ที่แปลงแล้วกลับไปหา event queue ได้ เนื่องจากฟังก์ชัน ibus_engine_forward_key_event() ไม่ทำงานอย่างที่คาด งมอยู่นานก็ไม่สามารถแก้ได้ เวลามีจำกัดจึงใช้วิธีกำหนดผังแป้นพิมพ์เป็น us,th เพื่อให้ GTK+ กับ XKB ไปคุยกันเอง ซึ่งก็ได้ผล แต่ปัญหาคือ มันจะแปลงอักขระตามผังเกษมณีเท่านั้น ใครใช้ผังปัตตะโชติใน IBus-LibThai ก็จะงง ไว้หาวิธีแก้ต่อไปในรุ่นหน้า
    • เพิ่มการรองรับการป้อนเลขไทยด้วยแป้นตัวเลข โดยอาศัยการกด CapsLock ล็อคไว้ หรือใช้การยกแคร่ระดับ 3 (Alt ขวา) อนึ่ง ตามที่เคยได้ ออกแบบไว้ เมื่อสองปีก่อนนั้น จะใช้ ScrollLock ไม่ใช่ CapsLock เนื่องจาก CapsLock จะไปเพิ่มขั้นตอนขณะสลับภาษาไปเป็นภาษาอังกฤษที่จะต้องปลด CapsLock อีกขั้นหนึ่งด้วย แต่ในครั้งนี้ได้ตัดสินใจเปลี่ยนเป็น CapsLock ด้วยเหตุผลสองประการ ประการแรกคือการตรวจสอบสถานะของ ScrollLock ด้วย API ของ IBus เป็นไปได้ยาก เพราะไม่มีการเตรียมการรองรับไว้ ประการที่สองคือในแป้นพิมพ์ย่อส่วน เช่นแป้นพิมพ์โน้ตบุ๊ก หลายรุ่นได้ตัดปุ่ม ScrollLock ออกไปแล้ว ตามที่ วิกิพีเดียว่าไว้ (โน้ตบุ๊กผมก็ไม่มี)
    • อัปโหลด 0.1.2-1 เข้า Debian sid

งานแปล

  • ตรวจทาน คำแปล GNOME ตามที่มีผู้ส่งคำแปลเข้ามา โดยที่ผมไม่ได้แอคทีฟตามแปลเองอีกต่อไปแล้ว
  • แปล Xfce เป็นไทย เพิ่มเติม โดยล่าสุด ได้แปล core package ต่าง ๆ ครบแล้ว พร้อมกับปรับคำแปลทั้งหมดจาก master กลับไปที่ branch xfce-4.10 ด้วย และแปลปลั๊กอินที่ผมใช้อีกนิดหน่อยเพิ่มเติม ทำให้ขณะนี้อัตราการแปลของภาษาไทยอยู่ที่ 54% แล้ว

blog นี้ก็เลยยาวหน่อย ขอขอบคุณทุกท่านที่ติดตามครับ

ป้ายกำกับ: , , , , , , , , , ,

31 สิงหาคม 2556

Thanks, and the July-August Diary

ผู้หย่อนสตางค์ลงหมวกเพื่อสนับสนุนงานพัฒนาของผมในเดือนกรฎาคม-สิงหาคมที่ผ่านมา คือ อ.พฤษภ์ บุญมา และคุณวิทยา ไตรสารวัฒนะ โดยทั้งสองท่านได้หย่อนสตางค์ทั้งสองเดือน ขอขอบคุณอีกครั้งครับ May the Source be with you!

สองเดือนที่ผ่านมา มีกิจธุระบางอย่างทำให้ไม่มีเวลาเขียน blog ทำให้ต้องยกยอดมาเขียนสองเดือนรวมกัน สำหรับกิจกรรมที่เกิดขึ้นระหว่างนี้ ก็ได้แก่:

  • ปรับวิธีการเพื่อแก้ขัดสำหรับการรองรับอักษรไทน้อยในระหว่างที่ยังไม่กำหนดมาตรฐาน โดยจากการทดลองเมื่อเดือน มิ.ย. พบว่า วิธีวิรามยังต้องการการรองรับในเบราว์เซอร์เพิ่มเติม แต่ในช่วงของการบันทึกการปริวรรตเพื่อสำรวจข้อมูลในช่วงนี้ จำเป็นต้องทำให้มันทำงานได้ไปก่อน จึงปรับมาใช้การกำหนดรหัสอักขระแบบ pre-composed ไปก่อน กล่าวคือ
    • สระออย แทนด้วย U+0EBE
    • บ เฟื้อง แทนด้วย U+0EE0
    • ม เฟื้อง แทนด้วย U+0EE1
    • ล เฟื้องข้าง แทนด้วย U+0EE2
    • ส เฟื้อง แทนด้วย U+0EE3
    • พ เฟื้อง แทนด้วย U+0EE4
    • ธ เฟื้อง แทนด้วย U+0EE5
    • ด เฟื้อง แทนด้วย U+0EE6
    • ตัวควบ ขฺน แทนด้วย U+0EF0
    • ตัวควบ ขฺม แทนด้วย U+0EF1
    • ตัวควบ คฺน แทนด้วย U+0EF2
    • ตัวควบ คฺม แทนด้วย U+0EF3
    • ตัวควบ ถฺน แทนด้วย U+0EF4
    • ตัวควบ ถฺล แทนด้วย U+0EF5
    • ตัวควบ สฺน แทนด้วย U+0EF6
    • ตัวควบ สฺม แทนด้วย U+0EF7
    ทั้งนี้ ได้ทดลองใช้กับการปริวรรตใบลานเรื่อง พญาคันคาก และ ฮีตคองคะลำ เป็นตัวอย่าง โดยได้ปรับโครงสร้างของ ระบบป้อนข้อความล้านช้าง เพื่อเพิ่ม engine สำหรับอักษรไทน้อย เพื่ออำนวยความสะดวกในการเตรียมข้อมูลด้วย
  • เซ็นสัญญากับเนคเทคเพื่อเป็นที่ปรึกษาโครงการร่างมาตรฐานภาษาไทย โดยมีเรื่องอักษรอีสานอยู่ในวาระด้วย
  • เริ่มโครงการ แปล Xfce ให้เป็นภาษาไทย โดยในขณะนี้ ผมเริ่มแปลไปได้สองตัว คือ Xfce4-panel และ Xfwm4 ด้วยสิทธิ์ของ translator ธรรมดา ยังไม่ใช่ moderator โดยหวังว่าจะเรียนรู้ระบบและค่อยขยับเป็น reviewer หรือ coordinator ในที่สุด ระบบแปลของ Xfce ใช้ Transifex ซึ่งหลักการคล้าย rosetta บน launchpad ของ Ubuntu ระบบนี้จำเป็นอย่างยิ่งที่จะต้องมี reviewer ที่แอคทีฟ เพื่อควบคุมคุณภาพและความสม่ำเสมอของคำแปลให้ไปในทางเดียวกันแบบ GNOME ปัจจุบันผมจึงยังไม่ประสานงานกับนักแปลอื่นจนกว่าจะมีสิทธิ์ทำอะไรได้มากกว่านี้
  • ตรวจทานคำแปล GNOME ตามที่มีผู้ส่งคำแปลเข้ามา สำหรับ GNOME นี้ ผมเลิกแอคทีฟไปแล้ว หลังจากเปลี่ยนมาใช้ Xfce แทน แต่ผมจะยังแปลเฉพาะในส่วนที่เป็นประโยชน์ต่อ Xfce (เช่น GLib, GTK+, Evince, Zenity) เท่านั้น ส่วนอื่น ๆ นั้น หากมีผู้ส่งคำแปลเข้ามา ผมก็ยังยินดีตรวจทานและ commit ให้ครับ เพียงแต่ผมจะไม่ไปไล่แปลเองอย่างเคยเท่านั้น

คิดว่าสำหรับเดือนกันยายน ก็คงจะดำเนินการวาระข้างต้นนี้ต่อไป รวมถึงงานดูแลแพกเกจใน Debian ตามแต่โอกาสจะอำนวย

ป้ายกำกับ: , , , ,

26 พฤศจิกายน 2555

My Alternative Desktops (1) - E17

สองเดือนก่อน ผมได้ซ้อมหนีภัย GNOME Fallback ถูกกำจัด ด้วยการพยายามปรับแต่ง GNOME Shell จนสามารถทนใช้มันได้ แต่หลังจากนั้นไม่นาน (ตั้ง 20 วันแน่ะ) ผมก็ต้องยกธงขาว และ กลับไปใช้ Fallback ตามเดิม เพราะยังคงรำคาญ animation เงาดำ และความหน่วงต่าง ๆ ที่เกิดขึ้นใน GNOME Shell จนกระทั่งไฟมาลนก้นอีกครั้ง เมื่อทีม GNOME ได้ผลสรุปว่าจะตัด Fallback mode ทิ้งจริง ๆ แม้ต่อมาจะมีข่าวว่า จะยังคงจัดเตรียม "Classic mode" ใน GNOME Shell ให้ โดยผ่าน extension ต่าง ๆ ที่จะออกพร้อม GNOME อย่างเป็นทางการโดยไม่ให้มีช่วงรออัปเกรดก็ตาม มันก็ไม่ได้แก้ปัญหาความรำคาญของผมได้อยู่ดี

เพราะฉะนั้น ก็ได้เวลาลงมือปฏิบัติจริงแล้ว ไม่ใช่แค่ทดลองอีกต่อไป ทางเลือกต่าง ๆ ที่ผมทดลองก็มี E17, LXDE และ Xfce ก็เลยจะบันทึกการทดลองเป็นรายตัวไป

ก่อนอื่น problem definition ของผมคือ:

  • การใช้สองจอ ผมเสียบจอเพิ่มเมื่ออยู่บ้าน ใช้จอเดียวเมื่อออกไปข้างนอก และหลายครั้งต้องต่อโปรเจกเตอร์เพื่อนำเสนองาน ดังนั้น เดสก์ท็อปต้องรองรับการใช้สองจอสลับกับจอเดียวอย่างสะดวกสบาย
  • การแสดงสถานะการใช้งานต่าง ๆ เช่น เครือข่าย ซีพียู หน่วยความจำ อุณหภูมิของเครื่องที่จุดต่าง ๆ ซึ่งอันหลังสุดนี่สำคัญมาก เนื่องจากเครื่องผมร้อนง่าย และระบบมักจะปิดตัวเมื่อเครื่องร้อน
  • นาฬิกาและปฏิทิน เป็นแอพเพล็ตที่ขาดไม่ได้เวลาทำงาน
  • flash drive ควรสามารถเสียบแล้วเมานท์ให้ทันที
  • ไม่มี animation หวือหวา ไม่มี edge tiling ไม่มี top-left hot corner งี่เง่าเหมือน GNOME Shell
  • มีพาเนลสำหรับวางแอพเพล็ตและ launcher เป็นแถบเล็ก ๆ และ launcher ต้องไม่เป็น dock (กล่าวคือ ทำให้ตัด WindowMaker และเหล่า GNUstep ออกจากจอเรดาร์ไปได้ รวมทั้ง GNOME Shell และ Unity ด้วย)

E17

เริ่มที่ตัวแรก คือ E17 เพื่อนเก่าสมัยเตาะแตะกับลินุกซ์ เดสก์ท็อปแบบสองจอที่ผมปรับแต่งแล้วเป็นอย่างนี้ (ซีกซ้ายคือจอนอก ซีกขวาคือจอโน้ตบุ๊ก):

E17 dual monitor screenshot

การปรับแต่งทั่วไป

ในการเรียกครั้งแรก จะมี wizard ให้ตั้งค่าเริ่มต้น เช่น จะใช้ compositing หรือไม่ เลือกภาษาที่จะใช้ (ยังไม่มีภาษาไทย) ฯลฯ ซึ่งเมื่อเซ็ตเสร็จแล้ว มันจะสร้างไดเรกทอรี ~/.e/ ที่เก็บค่า config ต่าง ๆ ให้ ดังนั้น ถ้าอยากให้เริ่ม wizard ใหม่ ก็เพียงแต่ลบไดเรกทอรีนี้ หรือเปลี่ยนชื่อหลบ แล้วเข้าระบบใหม่

ผมลองเปิดโหมด composition ใช้อยู่พักหนึ่ง แรก ๆ ก็ตื่นเต้นดีตามปกติน่ะแหละ แต่พอใช้งานทุกวัน ก็คิดว่าปิดก่อนดีกว่า ถึงแม้จะชอบที่หน้าต่างที่ไม่ได้โฟกัสจะโปร่งแสงมองทะลุได้ ช่วยให้วางหน้าต่างซ้อนทับกันโดยยังเทียบเนื้อหาข้ามหน้าต่างได้ก็ตามที แต่ยังไงก็ตาม ผมทน E17 ได้มากกว่า compiz นะ อาจเป็นเพราะ animation มันทำในปริมาณพอเหมาะกว่า บางที ผมอาจจะกลับมาใช้ compositing อีกในอนาคตก็ได้

การปิด compisiting ทำได้โดย unload มอดูล Composite โดยเรียกเมนู Settings > Modules เลือกแท็บ Look ก็จะเห็นรายการมอดูล Composite อยู่ในนั้น

E17 Compositing setting

โหมดการโฟกัส อันนี้แล้วแต่ถนัด ผมเคยชอบการโฟกัสแบบ sloppy คือตามหน้าต่างล่าสุดที่เมาส์เคลื่อนไปวาง ไม่ใช่การคลิกเพื่อโฟกัสพร้อมกับยกหน้าต่างขึ้น ซึ่งทำให้สะดวกกับการทำงานในหน้าต่างที่วางก่ายกันหลายบานได้สะดวก โดยไม่ต้องยกหน้าต่างขึ้นมาทับกันเสมอไป แต่พอไปใช้ GNOME ก็ติดนิสัยคลิกเพื่อโฟกัสเสียแล้ว ตอนนี้ก็เลยลองกลับมาใช้ sloppy ดู โดยไม่เอามาเป็นเกณฑ์ตัดสินเลือกเดสก์ท็อปถ้ามันทำให้เกิดความไม่สะดวก เพราะการตั้งให้เป็นการคลิกเพื่อโฟกัสนั้นทำได้ไม่ยาก (เมนู Settings > Settings Panel แท็บ Windows รายการ Window Focus)

E17 เปล่า ๆ จะได้โปรแกรม GTK+ ที่เปล่าเปลือย ไม่มีธีม ควรกำหนดธีมเสียก่อนโดยเลือกเมนู Main > Settings > Settings Panel และที่แท็บ Look หัวข้อ Applications ก็เลือกธีม Adwaita

E17 application theme setting

สิ่งจำเป็นอีกอย่างคือ system tray หรือ notification area ซึ่งโปรแกรมใหม่ ๆ จะใช้กันเป็นปกติ ก็ควรจะเปิดใช้ โดยโหลดมอดูล Systray ก่อน แล้วจะสามารถเพิ่ม Systray ใน shelf (ศัพท์ที่ E17 ใช้เรียก panel) ได้

E17 systray module loading

การเพิ่ม system tray ใน shelf ก็เพียงคลิกขวาที่ shelf ที่ต้องการ เลือกเมนู Contents แล้วก็เลือกแอพเพล็ตเพิ่มตามปกติ

E17 (LXDE และ Xfce ด้วย) มีความน่ารักกว่า GNOME ตรงที่เวลาต้องการ context menu ของพาเนล ไม่จำเป็นต้องไปเล็งหาที่ว่างระหว่างแอพเพล็ต โดยถ้าเราคลิกขวาโดนแอพเพล็ต GNOME จะให้แต่ context menu ของแอพเพล็ต แต่ E17 (และ LXDE, Xfce) จะเพิ่มเมนูของ shelf ต่อท้ายให้ด้วย

default ของ E17 นั้น วางพาเนลไว้ด้านล่างตรงกลาง แต่ผมชอบให้มันติดมุมมากกว่า ก็จัดตำแหน่งได้โดยคลิกขวาที่ shelf เลือกเมนู Settings แล้วก็ไปเลือกตำแหน่งในแท็บ Position

E17 shelf position setting

ส่วนถ้าต้องการ shelf ที่พาดยาวตลอดขอบจอ ก็ไปที่แท็บ Size แล้วปิดตัวเลือก Shrink to Content Width แต่ตอนนี้ผมแอบปล่อยไว้เฉย ๆ ให้ shelf มันสั้นจู๋อยู่ที่มุมจอไปก่อน

launcher ใน shelf ของ E17 จะบรรจุอยู่ในสิ่งที่เรียกว่า IBar การเพิ่ม launcher ก็ทำได้โดยคลิกขวาในกรอบ IBar แล้วเลือกเมนู IBar > Contents ก็จะได้กล่องโต้ตอบสำหรับเพิ่ม application ต่าง ๆ พร้อมกับจัดลำดับได้ด้วย

มีสิ่งที่ชื่อคล้ายกับ IBar อยู่บน shelf ด้วย คือ IBox ซึ่งจะเป็นพื้นที่เก็บหน้าต่างที่ย่อเก็บ โดยจะแสดงเป็นไอคอนให้คลิกเพื่อเรียกหน้าต่างคืน

E17 มีรายการ config ที่ละเอียดมากมาย จนเขาบอกว่า ทำเสร็จหมดจะได้ดิสโทรใหม่เลย ดังนั้น จะขอพูดถึงเท่านี้ก่อน แล้วมาวิจารณ์กัน

  • เรื่องการใช้สองจอ E17 ทำได้ดีทีเดียว แค่เสียบจอเข้ามา มันก็จัดการเอาพื้นที่สองจอมาเชื่อมกันให้เลย โดยให้จอนอกอยู่ด้านซ้าย ซึ่งตรงกับความต้องการของผมพอดี และเมื่อถอดจอนอกออก ก็จะปรับพื้นที่เหลือจอเดียวโดยอัตโนมัติ
  • การแสดงสถานะการใช้งานเครื่อง E17 ไม่ค่อยมีอะไรให้ นอกจาก cpufreq gadget ที่เป็นหน้าปัดเข็มแสดงความถี่ซีพียู กับ gadget แสดงประจุไฟของแบตเตอรี่เท่านั้น โดยมี gadget แสดงอุณหภูมิเครื่องที่อ่านค่า sensor ไม่ได้ ถ้าต้องการสิ่งเหล่านี้อาจต้องติดตั้งอย่างอื่นเพิ่มเอง เช่น GKrellM
  • นาฬิกาและปฏิทินของ E17 ถือว่าโอเค ตัว gadget สามารถเอามาวางบนพื้นโต๊ะแบบ desklet ได้ด้วย แต่เนื่องจากผมไม่ค่อยใช้ desklet ก็เลยใช้แต่บน shelf เท่านั้น
  • thumb drive เสียบแล้วมีไอคอนขึ้นที่พื้นโต๊ะทันที

ปัญหาจุกจิกที่พบ:

  • มี system monitor น้อย ทำให้ไม่ค่อยรู้สถานะการทำงานของเครื่อง
  • suspend โน้ตบุ๊กไม่ได้ พยายามแก้ปัญหาจากข้อมูลใน Debian #538091 อยู่เหมือนกัน แต่ยังไม่มีวี่แววว่าจะได้ จะใช้วิธีระดับต่ำก็ต้องเป็น root เสียก่อน ซึ่งอันตรายถ้าระหว่างนั้นโน้ตบุ๊กตกไปอยู่ในมือคนอื่น
  • workspace เปลี่ยนด้วยแป้นพิมพ์ได้แบบเป็นลำดับเส้นตรง 1, 2, 3, 4 เท่านั้น แม้จะจัด virtual desktop ให้เป็น 2x2 แล้วก็ตาม
  • การจัด virtual desktop เป็น 2x2 จะทำให้มีการเลื่อนไป workspace บน/ล่างเมื่อลากเมาส์ไปชนขอบบน/ล่าง ซึ่งบ่อยครั้งไม่ใช่เจตนา เช่น เจตนาจะลากกรอบล่างของหน้าต่างเพื่อปรับขนาดเท่านั้น (สรุปว่า E17 ไม่เหมาะกับการใช้ virtual desktop แบบเรียงหลายแถว)

ปัญหาเหล่านี้พอมีทางแก้ไข เช่น ขาด system monitor ก็ใช้ GKrellM, ใช้ workspace 2x2 ไม่ถนัดก็ใช้แบบเส้นตรงแทน โดยเริ่มใช้ที่ workspace ที่ 2 จากนั้นจะมี workspace ซ้าย-ขวาให้เลื่อนใช้ได้ ยังคงเหลือเฉพาะปัญหาการ suspend เครื่องเท่านั้นที่เป็นอุปสรรค

โดยภาพรวมแล้ว E17 นับว่าเป็นมืออาชีพทีเดียว memory footprint ก็ถือว่าต่ำเมื่อเทียบกับ GNOME ถ้าแก้ปัญหาเรื่อง suspend โน้ตบุ๊กได้ ก็สามารถใช้แทน GNOME ได้เลยทีเดียว

ไว้ blog หน้าเขียนถึง LXDE และ Xfce ต่อครับ

ป้ายกำกับ: , ,

10 กันยายน 2555

My GNOME Shell Workarounds

จากที่เคยเขียนถึง สารพัดปัญหาของ GNOME Shell ที่ทำให้แม้ปัจจุบันผมก็ยังคงใช้ Fallback หรือที่เรียกว่า GNOME Classic ใน Debian เป็นเดสก์ท็อปหลักอยู่

แต่ในรอบการพัฒนา GNOME 3.8 นี้ เรื่องแรกที่เขาเอาขึ้นโต๊ะคุยก็คือ จะลบหรือจะปรับปรุง Fallback mode ทำให้เริ่มรู้สึกไม่ปลอดภัย เรามันก็แค่เสียงเล็ก ๆ เสียงหนึ่งในโลกกว้างใหญ่ (ยังเข็ดเรื่อง ส้นตีน ไม่หาย) เลยต้องหาทางหนีทีไล่เอาไว้ เร็ว ๆ นี้ไปตามอ่าน thread หนึ่งใน G+ เห็น Alan Cox บอกว่าชอบ E17 รวมทั้งเคยเห็นแฮกเกอร์หลายคนชอบ ตัวเองก็เคยใช้ตั้งแต่สมัยตั้งไข่กับลินุกซ์ เลยกลับมาลองใช้ได้พักหนึ่ง ก็เห็นพัฒนาการเยอะทีเดียว โดยยังคงคอนเซ็ปต์เดิมไว้ คือการดึงความสามารถของ graphics card ออกมาใช้ให้เต็มที่

ทางเลือกให้โดดหนีมีเยอะแยะ ไหนจะ Xfce หรือ LXDE อีก แต่กระนั้นก็ขอลองสู้กับ GNOME Shell อีกสักตั้งน่า

ในบรรดาปัญหาต่าง ๆ ของ GNOME Shell ที่ผมมี คิดว่าที่ทนได้ยากที่สุดมีอยู่สองเรื่อง:

  • hot corner คือมุมบนซ้ายที่เมื่อลากเมาส์ไปชนจะเป็นการเปลี่ยนเข้า activity mode เป็นเรื่องน่ารำคาญอันดับหนึ่ง เพราะเกิดอุบัติเหตุทำให้งานสะดุดได้ง่ายมาก โดยเฉพาะพื้นที่บนซ้ายของหน้าจอมักอยู่ใกล้กับเมนูของโปรแกรมต่าง ๆ โอกาสอุบัติเหตุจึงสูงมาก เรื่องนี้แทบทุกคนในบ้านที่ใช้ GNOME Shell ต่างบ่นอุบทั้งนั้น
  • accidental maximization คือชื่อที่ผมอยากจะเรียกแทนสิ่งที่เขาเรียกกันว่า auto maximization หรือ edge tiling เพราะนิสัยการใช้หน้าต่างของผมนั้น แทบจะไม่เคย maximize หน้าต่างเลย และมักจะเรียง title bar ของหน้าต่างซ้อนลดหลั่นกันลงมาจากบนขวามาทางล่างซ้าย ทำให้เลือกหน้าต่างได้ง่าย แต่พอเจอ GNOME Shell แค่ผมจะเริ่มจัดหน้าต่างแบบนี้ มันก็ maximize ให้ผมเสียแล้ว ต้องชักกะเย่อกับมันไปมา กว่าจะวางหน้าต่างแรกชนขอบบนได้ ทำให้กลายเป็นโรคกลัวขอบบนไปเลย ครั้นจะเลี่ยงมาเรียงจากข้างล่างแทน title bar มันก็อยู่ด้านบน หน้าต่างที่สูงไม่เท่ากันก็กะระยะยากอีก

ลองพยายามแก้ทีละเปลาะ

ปัญหา hot corner นั้น แก้ได้โดยติดตั้งส่วนขยาย No Topleft Hot Corner โดยติดตั้งได้ผ่านเว็บ (ยังไม่มีใน Debian) ติดตั้งแล้ว hot corner ก็ไม่มากวนใจอีกต่อไป

ปัญหา accidental maximization นี่ งมอยู่นาน เพราะเห็น dconf ของ mutter ให้ปิด edge-tiling ได้ แต่แก้ยังไงก็ไม่มีผล เพิ่งมาพบทีหลังว่า GNOME Shell มัน override ค่านี้อีกชั้น

วิธีแก้ก็คือแก้คีย์ edge-tiling ในหัวข้อ org.gnome.shell.overrides ให้เป็น false โดยอาจจะสั่งผ่าน GSettings ดังนี้:

$ gsettings set org.gnome.shell.overrides edge-tiling false

หรือจะแก้ผ่าน dconf-editor ตรง ๆ ก็ได้ ซึ่งจะทำให้เราสามารถไปแก้คีย์อื่นได้ด้วย โดยเฉพาะต้องแก้ button-layout เพื่อให้สามารถ maximize หน้าต่างในกรณีที่ต้องการได้อยู่:

gnome-shell twist with dconf-editor

ถ้าจะสั่งผ่านเทอร์มินัลก็:

$ gsettings set org.gnome.shell.overrides button-layout \
  "menu:minimize,maximize,close"

system monitor นั้น ผมใช้ส่วนขยาย system-monitor ซึ่งจะแสดงกราฟบนพาเนลด้านบน

และเพื่อแก้ความงุ่มง่ามในการเรียกโปรแกรมของ Activities mode ผมเลยติดตั้งส่วนขยาย Frippery Panel Favorites ซึ่งจะเอารายการใน dash ขึ้นมาเป็น launcher บนพาเนล ทำให้เรียกโปรแกรมที่ใช้บ่อยได้ในคลิกเดียวเหมือนใน GNOME 2 แถมยังเปิดหน้าต่างเทอร์มินัลใหม่ได้เรื่อย ๆ อีกด้วย เพราะไม่ได้เป็น dock เหมือน dash

ก็ค่อย ๆ ปรับแต่งไปทีละนิดครับ

Update: (2012-09-11 09:45) เพิ่ม Frippery Panel Favorites

ป้ายกำกับ: ,

27 สิงหาคม 2555

Pango-HarfBuzz Merge and Effects on Thai Script

ความเปลี่ยนแปลงที่สำคัญรายการหนึ่งใน GNOME 3.6 คือ Pango จะเปลี่ยนมาใช้ HarfBuzz ในการวาดข้อความภาษาต่าง ๆ แล้ว โดยได้โละ shaping engine เดิมใน Pango ทิ้งหมด ไปเรียก HarfBuzz แทน ส่วน language engine (ตัวตัดคำ) ยังคงอยู่

ก็เลยต้องมาประเมินใหม่ ว่าหลังจาก merge HarfBuzz มาแล้ว มีความเปลี่ยนแปลงอย่างไรบ้างสำหรับภาษาไทย

จากการไล่โค้ดคร่าว ๆ ถือว่า Behdad ทำการบ้านมาดีมากสำหรับภาษาไทย (ภาษาอื่นก็คงเช่นกัน) โดยได้ถอดแบบการทำงานของ Uniscribe ของวินโดวส์มาให้มากที่สุด เพื่อความเข้ากันได้ รวมถึงการเก็บข้อมูลจากรายงานบั๊กใน Mozilla เกี่ยวกับปัญหาการ hack ของฟอนต์ราชการ 13 ฟอนต์ของ SIPA ที่ไปใช้แท็ก 'latn' ในการ implement ภาษาไทย แทนที่จะเป็น 'thai' ซึ่งผิดสเปค แต่ในโลกซอฟต์แวร์ กฎหมู่มักอยู่เหนือกฎหมายเสมอ ๆ ผิดก็เป็นถูกได้ถ้าเสียงดังพอ

ฟอนต์ที่รองรับ

เมื่อทดลอง Pango ตัวใหม่กับฟอนต์ทั่วไปที่มีการออกแบบ GPOS/GSUB เอาไว้ ก็สามารถแสดงผลได้ดีไม่มีปัญหา

ฟอนต์ Loma ซึ่งใช้ GPOS, GSUB:

Loma on new Pango

ฟอนต์ Arundina Sans ซึ่งใช้ GSUB อย่างเดียว (แต่แท็กภาษามีการแก้ไขให้เป็น 'thai' แล้ว):

Arundina Sans on new Pango

แต่สำหรับฟอนต์ที่ไม่มี OpenType feature เลยล่ะก็.. เละตุ้มเป๊ะ:

Non-OpenType on new Pango

และใน HarfBuzz ยังไม่รองรับการใช้ PUA glyph (ตัวหลบหางทั้งหลาย) ในการจัดแสดงภาษาไทย ซึ่งก็หมายความว่า legacy font ทั้งหลายจะเละบน Pango ตัวใหม่นี้ทั้งหมด ซึ่งหมายถึงฟอนต์ที่ออกแบบมาสำหรับ Windows XP ลงไป ส่วนฟอนต์ใน Windows 7 ได้ข่าวว่ามี OpenType feature สำหรับภาษาไทยเรียบร้อยแล้ว ไม่น่ามีปัญหา

พูดสั้น ๆ ก็คือ Pango/HarfBuzz ได้ deprecate การใช้ตัวหลบไปแล้ว รองรับฟอนต์ OpenType เท่านั้น

บั๊กที่คั่งค้าง

เมื่อ Pango โละ engine เก่าทิ้งหมด ก็เกิดการเปลี่ยนแปลงกับบั๊กต่าง ๆ เป็นธรรมดา มีบางบั๊กที่ปิดไปโดยปริยาย มีบางบั๊กที่ยังเป็นบั๊กอยู่ โดยสรุปก็คือ:

บั๊กที่ปิดไป:

  • GNOME #616495 เกี่ยวกับการแสดงไม้กงของภาษาลาว ซึ่งมอดูลไทยพลาดกรณีนี้ไป ผมได้เสนอแพตช์ไว้ แต่เขายังไม่รับ ตอนนี้ย้ายไป HarfBuzz แล้ว ปัญหาหายไปแล้ว บั๊กจึงปิดโดยปริยาย
  • GNOME #378001 บั๊กที่ Martin Hosken รายงานไว้เมื่อ 6 ปีที่แล้ว เกี่ยวกับการรองรับภาษาชาติพันธุ์ด้วยอักษรไทย ผมรอสเปค วทท. 3.0 อยู่ เลยยังไม่ได้ทำเสียที ตอนนี้ย้ายไป HarfBuzz แล้ว ไม่มีการตรวจลำดับด้วย วทท. 2.0 อีกต่อไป ถ้าฟอนต์รองรับก็จะสามารถแสดงภาษาชาติพันธุ์ต่าง ๆ ได้แล้ว
  • GNOME #393307, #677090 เกี่ยวกับการวาดเครื่องหมายกำกับประเภท zero width ต่าง ๆ ในยูนิโค้ด เช่น ZWJ (U+200D) ซึ่งมอดูลไทยไม่ได้กรองออก บั๊กนี้มีนักพัฒนาอื่นรายงานมา Behdad ตอบมาแล้ว แต่ยังไม่มีใครทำอะไรต่อ แต่ปัญหาหมดไปเมื่อย้ายไป HarfBuzz

บั๊กที่ยังเป็นคำถาม:

  • GNOME #583718 เกี่ยวกับการวาดสระอำใน VTE และ gnome-terminal ที่จะมี dotted circle แทรกเข้ามา ซึ่งที่ผ่านมาได้ยื้อไปยื้อมากับ Behdad อยู่ว่าควรจะจัดการภาษาไทยแยกต่างหากจากภาษาตระกูลอินเดียหรือไม่ ผมเห็นว่าควรแยก โดยได้เสนอแพตช์ให้วาดฟอนต์ monospace ในแบบพิมพ์ดีด ที่วาดนิคหิตของสระอำไว้ในช่องเดียวกับลากข้าง แต่ Behdad ยืนยันที่จะให้จัดการภาษาไทยในฐานะภาษาตระกูลอินเดีย ซึ่งเรื่องจะยาวมาก ต้องออกแบบโครงสร้างโค้ดใหม่เลยทีเดียว แต่ถ้าดูผลลัพธ์ของ Pango/HarfBuzz แล้ว จะเป็นดังนี้:
    Thai on VTE with new Pango
    คือได้ย้ายนิคหิตมาอยู่ในเซลล์เดียวกับลากข้างแล้ว แต่เลื่อนตำแหน่งไปอยู่ข้างหลัง ถามว่าถูกต้องไหม มันก็ยังไม่ถูก แต่อย่างน้อยปัญหาเรื่อง dotted circle ก็หายไปแล้ว ถือว่าพอทนได้หรือเปล่า? จนกว่าเขาจะออกแบบเทอร์มินัลใหม่ให้รองรับภาษาตระกูลอินเดียทั้งหมด :P

บั๊กที่ยังอยู่:

  • GNOME #576156 เกี่ยวกับการเลื่อนเคอร์เซอร์ในข้อความภาษาไทย ที่จะกระโดดข้ามสระหน้า-สระหลัง แทนที่จะเลื่อนทีละเซลล์ตามปกติ ตรงนี้เป็นการตีขลุมของคณะทำงานยูนิโค้ดว่าภาษาไทย-ลาวจะนับคลัสเตอร์เหมือนภาษาตระกูลอินเดีย เราได้ผลักดันแก้ UAX #29 จนสำเร็จใน Unicode 6.1.0 แต่ Behdad ก็ยังไม่รับแพตช์ ที่ผ่านมาอาจจะยังยุ่งกับ HarfBuzz อยู่ ตอนนี้ก็อาจได้เวลาผลักดันใหม่อีกครั้งหนึ่ง

ป้ายกำกับ:

02 กุมภาพันธ์ 2555

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 ไว้ในที่ต่าง ๆ เช่น:

เรื่องนี้เกิดจากข้อกำหนดเรื่อง 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 เข้าใจว่าเขาแก้ไปนานแล้ว

ป้ายกำกับ: , , ,

10 พฤศจิกายน 2554

My Desktop

หลังจากที่ใช้ GNOME 3 มาพักหนึ่ง พยายามทำความคุ้นเคย ปรับเปลี่ยนไปมา จนในที่สุดก็มาลงตัวที่รูปแบบนี้:

scaled desktop screenshot

กล่าวคือ เป็น GNOME fallback ที่หน้าตาคล้ายกับ ของเดิม แต่ก่อนที่จะมาลงเอยที่แบบนี้ ผมได้ทดลอง GNOME Shell ใน GNOME 3 มาแล้ว พบว่ามีความไม่สะดวกหลายอย่าง:

  • Stateful UI เป็นสิ่งที่ผมมีปัญหามาตลอด ไม่ว่าจะในเว็บ ในสมาร์ทโฟน หรือบนเดสก์ท็อป เพราะมันไม่สามารถใช้ความเคยชินเพียงอย่างเดียวได้ ต้องใช้สายตาสังเกตความเปลี่ยนแปลงบนหน้าจอ โดยเฉพาะ Activity mode ของ GNOME Shell ที่ไปซ่อนอยู่ข้างหลัง ต้องกดปุ่ม logo บนแป้นพิมพ์ หรือแย่กว่านั้นคือต้องเลื่อนเมาส์ไปไกลถึงมุมบนซ้ายของหน้าจอ เพื่อจะเผยสิ่งที่ต้องการขึ้นมาเมื่อต้องการเรียกโปรแกรมหรือแค่สลับหน้าต่าง แทนที่จะให้เห็นได้เลย

    จริงอยู่ว่าในเดสก์ท็อปสุดท้ายของผม ผมใช้ window list แบบเมนูที่มุมบนขวา ซึ่งก็เลื่อนเมาส์ไปหาไกลไม่ต่างกัน แต่มันไม่ได้ทำให้เกิด surprise วูบวาบทั้งหน้าจอ หรือซุกซ่อนไม่ให้ผู้ใช้เห็น แค่แสดงพฤติกรรมปกติของเมนูเท่านั้น และตัวเมนูก็กินเนื้อที่น้อย การเลื่อนเมาส์ต่อจากนั้นเพื่อเลือกหน้าต่างมันลากไม่ไกลเหมือน Activity mode ของ GNOME Shell

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

  • Linear Workspace Layout ใน GNOME Shell ยังคงสามารถสลับ workspace ด้วยแป้นพิมพ์เหมือนเดิมก็จริง แต่ไม่สามารถจัดเรียง workspace แบบหลายแถวให้เป็น 2×2 แบบที่ผมเคยใช้มาก่อนได้ ต้องไล่สลับ workspace เรียงลำดับทีละอัน จากเดิมที่สามารถเปลี่ยนได้ทั้งทางซ้าย-ขวา และบน-ล่าง ทำให้สามารถสลับไป workspace ใด ๆ ก็ได้ภายในไม่เกิน 2 stroke

  • New Terminal Window ด้วยความที่ launcher ของ GNOME Shell เป็นแบบ dock ทำให้เมื่อเปิดเทอร์มินัลไปแล้ว การคลิกที่ launcher อีกครั้งกลายเป็นการโฟกัสไปที่หน้าต่างเดิม ไม่ใช่การเปิดหน้าต่างใหม่ ถ้าต้องการเปิดหน้าต่างใหม่ จะต้องใช้ Ctrl+click ซึ่งไม่ intuitive ถ้าไม่ไปอ่านเจอใน Cheat Sheet ผมคงไม่รู้วิธีเด็ดขาด เพราะการใช้แป้นพิมพ์ร่วมกับเมาส์ไม่ใช่สิ่งที่ใช้กันบ่อยในเดสก์ท็อปทั่วไป

    อย่างไรก็ดี หลังจากพบวิธีการแล้ว มันก็ยังเป็นวิธีที่งุ่มง่ามอยู่ดี เพราะกว่าจะเปิดได้ต้องเข้า Activity mode ก่อน แล้วกวาดสายตาตามหน้าจอที่เปลี่ยนแปลง แล้วต้องกด Ctrl+click อีกชั้น เป็นการทำงานที่มากเกินไปเมื่อเทียบกับการเลื่อนเมาส์ไปคลิก launcher ธรรมดาในแบบเก่า สามารถทำมือเดียวได้เลย

    ผลก็คือ ผมแก้ปัญหานี้ด้วยการสร้าง keyboard shorcut สำหรับเปิดเทอร์มินัล แล้วก็ใช้ keyboard shortcut เป็นหลัก หรือถ้ามีเทอร์มินัลเดิมเปิดอยู่แล้ว ก็ใช้วิธีกด Ctrl+Shift+N ง่ายกว่าใช้วิธีของ GNOME Shell เยอะ

  • Multiload Applet เป็นสิ่งที่ขาดไม่ได้เลย ผมรู้สึกสบายใจที่มีมาตรวัดการทำงานของ CPU และการจราจรเครือข่ายบอกอยู่ตลอดเวลา เพื่อจะได้ประเมินโหลดของเครื่อง หรือเอะใจได้ทันท่วงทีเมื่อมีความผิดปกติในการรับ-ส่งข้อมูลในเครือข่าย แต่พาเนลของ GNOME Shell เป็นพาเนลโง่ ๆ เพิ่มแอพเพล็ตใด ๆ ไม่ได้เลย ต้องรอ GNOME Shell extension ที่จะมาอุดช่องว่างตรงนี้ ในขณะที่พาเนลของ fallback สามารถเพิ่มแอพเพล็ตได้ง่าย ๆ เลย

  • Accidental Maximization การ maximize หน้าต่างด้วยการลากไปชนพาเนลด้านบนนั้นสร้างปัญหาให้ผมอย่างมาก เพราะผมไม่มีนิสัย maximize หน้าต่างเลย โดยเฉพาะกับเทอร์มินัลที่ต้องการรักษาความกว้างไว้ที่ 80 คอลัมน์ และด้วยลักษณะการไม่ maximize ก็ทำให้ผมชอบจัดหน้าต่างให้ชิดขอบ โดยไม่เปลี่ยนขนาด ปรากฏว่าวิธี maximize ของ GNOME Shell ทำให้ผมเสียเวลานานกว่าเดิมในการจัดหน้าต่าง ต้องถอน ๆ ชน ๆ พาเนลบนอยู่นานเพื่อไม่ให้มัน maxmize จนสุดท้ายถึงกับเลี่ยงการจัดหน้าต่างชิดขอบบนไปเลย หันไปชิดขอบล่างแทน

  • Window Shadow เป็นความรำคาญเล็ก ๆ น้อย ๆ คือผมไม่ชอบเงาของหน้าต่าง มันมาบังเนื้อหาหน้าต่างข้างใต้ให้มองไม่ชัด ซึ่งบางทีต้องการจัดวางหน้าต่างหลาย ๆ บานเพื่อดูเทียบข้อมูลก็รู้สึกรำคาญเงา ยังหาวิธีปิดไม่ได้

อย่างไรก็ดี ข้อดีของ GNOME Shell ที่ผมพบก็มีเหมือนกัน:

  • Single-Workspace Secondary Display เขาเรียกว่าอะไรไม่รู้แหละ แต่มันคือการไม่เปลี่ยน workspace ในจอที่สองตามจอหลัก ซึ่งสะดวกมากสำหรับการวางหน้าต่างที่ต้องการให้อยู่อย่างถาวรไม่ว่าจะย้ายไป workspace ไหน เช่น หน้าต่าง chat, หน้าต่างเฝ้าสังเกตระบบ ฯลฯ แต่เรื่องนี้ก็ไม่ใช่ข้อได้เปรียบอะไรมากมาย เพราะในแบบเก่ายังสามารถกำหนดให้ แสดงบนพื้นที่ทำงานเสมอ ได้เหมือนกัน

หลังจากใช้ความพยายามอยู่พักหนึ่ง ผมจึงตัดสินใจทิ้ง GNOME Shell แล้วกลับมาใช้ fallback session แทน ซึ่งก็ไม่ผิดหวัง หลังจากที่พบวิธีจัดการแอพเพล็ตและพาเนลด้วยการใช้ Alt+right-click แทนการใช้ right-click ธรรมดา คราวนี้พาเนลก็กลับมาเป็นของผมเหมือนเดิมละ

ผมปรับแต่งพาเนลดังนี้:

  • ปรับ workspace layout ให้เป็น 2×2
  • ลบ workspace switcher ในพาเนลด้านล่างแล้วมาเพิ่มในพาเนลด้านบนแทน
  • ใช้ window list menu ในพาเนลด้านบนแทน task bar ด้านล่าง
  • ตัดพาเนลด้านล่างทิ้ง
  • ปรับแต่งเวลาให้แสดงรายงานอากาศด้วย เพราะช่วงนี้อากาศเปลี่ยนแปลงบ่อย เริ่มหนาวแล้ว
  • เพิ่ม multiload applet แสดงกราฟการใช้ CPU, หน่วยความจำ, เครือข่าย, ฮาร์ดดิสก์
  • เพิ่ม launcher สำหรับโปรแกรมที่ใช้บ่อย
  • เลื่อน user menu จากมุมบนขวาไปอยู่ถัดจากเมนูที่มุมบนซ้าย ซึ่งจะเข้ากับเมนู ระบบ ของเดิมพอดี และให้มุมบนขวาสำหรับ window list menu เพราะใช้บ่อย
  • เพิ่ม keyboard shortcut สำหรับเรียกโปรแกรมพื้นฐาน เช่น เทอร์มินัล, เว็บเบราว์เซอร์, เครื่องคิดเลข

แค่นี้ผมก็กลับมามีความสุขกับการทำงานเหมือนเดิม และถ้าจะไปเซ็ตเครื่องให้ผู้ใช้มือใหม่ใช้ ผมก็คงใช้ fallback session เหมือนกัน ไม่ต้องการเพิ่มภาระในการ support ให้กับตัวเอง :P

GNOME Fallback (หรือกำลังจะถูกเปลี่ยนชื่อเป็น GNOME Classic ใน Debian ในอนาคตอันใกล้) จงเจริญ!

Update (2011-11-11 08:50+0700): เพิ่มข้อมูลที่เพิ่งนึกได้ เรื่อง Accidental Maxmimization และการรองรับ single-workspace secondary display

ป้ายกำกับ: ,

21 มิถุนายน 2554

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 จึงต้องกำหนดขึ้นเอง ซึ่งผมออกแบบไว้อย่างนี้ ซึ่งอาจตรงตามความต้องการของกรณีเรา แต่ภาษาอื่นจะว่าอย่างไรคงต้องถกกันอีกที:

ShiftNumLockLevel3Level5ผลลัพธ์
nonononolevel 1
yesnononolevel 2
noyesnonolevel 2
yesyesnonolevel 1
nonoyesnolevel 3
yesnoyesnolevel 4
noyesyesnolevel 3
yesyesyesnolevel 4
nononoyeslevel 1
yesnonoyeslevel 5
noyesnoyeslevel 5
yesyesnoyeslevel 1
nonoyesyeslevel 6
yesnoyesyeslevel 7
noyesyesyeslevel 7
yesyesyesyeslevel 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 ต่อไป

ป้ายกำกับ: , , , ,

18 มกราคม 2554

th.gnome.org Closed

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

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

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

ด้วยเหตุผลต่าง ๆ ข้างต้น จึงนำมาสู่ข้อสรุปของผมที่จะไม่พยายามกู้เว็บ GNOME ไทย กลับคืน (แม้จะกู้ไม่ยากเท่าไร) ขอขอบคุณ MrChoke สำหรับการสนับสนุน hosting ตลอดเวลาที่ผ่านมาครับ

ป้ายกำกับ: , ,

28 กันยายน 2553

Progress of SARA AM Bug in VTE

เล่าสู่กันฟังครับ เกี่ยวกับความคืบหน้าของการแก้ปัญหาสระอำใน gnome-terminal

ปัญหาคือ สระอำใน VTE ที่ใช้ Pango วาดเพื่อรองรับ combining character นั้น มีปัญหากับสระอำของไทย เนื่องจาก Pango จะแยกสระอำเป็นนิคหิตกับลากข้าง แต่เนื่องจากในเทอร์มินัลจะวาดอักขระทีละเซลล์แยกกัน ทำให้นิคหิตที่แยกตัวไปนั้นไม่มีพยัญชนะรองรับ ก็เลยมี dotted circle มาแทนที่ และทำให้ลากข้างต้องตกไปทับเซลล์ถัดไป

ใน blog เก่า ผมได้บันทึกไว้ว่าได้ทำแพตช์แก้ขัดที่ Pango เพื่อไม่ให้มันแยกสระอำ และอัปโหลด Pango รุ่นที่แพตช์แล้วไว้ให้ใช้ที่ debclub ก้านกล้วย ด้วย

จากนั้น ก็ได้ file GNOME #583718 กับ VTE ไว้เพื่อแจ้งปัญหา โดยได้เสนอทางแก้ไว้สองทาง คือวาดสระอำแบบไม่แยกร่าง กับอีกทางคือวาดแบบแยกร่างโดยพยายามให้ VTE รองรับการวาดอักขระทีละหลายเซลล์ ซึ่งวิธีหลังจะเป็นการคิดเผื่อภาษา CTL อื่นด้วย โดยมองว่าเป็นปัญหาเดียวกับที่ทำให้วาดภาษาตระกูลอินเดียบนเทอร์มินัลไม่ได้ เนื่องจากวิธีวาดที่แยกเซลล์นี้เอง

ปัญหาของภาษาตระกูลอินเดียก็คือ เขา encode ข้อความในแบบที่เขาเรียกว่า "logical order" คือเรียงลำดับ พยัญชนะต้น-สระ-ตัวสะกด เสมอ แม้ว่าสระจะเป็นสระหน้าก็ตาม ถ้าเทียบเป็นภาษาไทยก็ประมาณว่า encode คำว่า "เทพ" เป็น "ทเพ" คำว่า "เทา" เป็น "ท{เา}" โดย "{เา}" หมายถึงอักขระที่กำหนดไว้สำหรับสระเอาโดยเฉพาะ ทำให้เวลาวาดจะต้องมีการจัดลำดับใหม่ก่อน ทำให้วิธีวาดแบบแยกเซลล์ใช้การไม่ได้ ต้องวาดเป็นกลุ่มก้อน พร้อม map ตำแหน่งเคอร์เซอร์ให้ถูกลำดับด้วย

มัน logical ตรงไหน? ผมถามตัวเองอยู่เรื่อย ๆ โดยเฉพาะเวลาที่เจอคนประเทศอื่นมาบอกว่าวิธี encode แบบภาษาไทยนั้นไม่ logical เป็นลำดับที่ผิด และได้สร้างความซับซ้อนในการประมวลผลมากมาย จนต้อง เขียนเอกสารอธิบายไว้ ให้เป็นกิจจะลักษณะ ว่านั่นเป็นความเชื่อที่ผิด

คือผมอาจจะเห็นด้วยว่าแบบของเขาก็ logical ในแบบของเขา แต่ก็ไม่เห็นด้วยถ้าจะบอกว่าของไทยนั้นไม่ logical อย่างน้อย ๆ ภาษาอังกฤษก็ไม่ได้ logical เหมือนกันถ้าจะคิดด้วยหลักเดียวกัน เช่น ไม่ได้ encode คำว่า "game" เป็น "g{ae}m", ไม่ได้ encode "table" เป็น "tabel" ฯลฯ และการ encode แบบตรงตามลำดับการเขียนของภาษาไทยก็ไม่เห็นว่าจะไม่ logical สำหรับมนุษย์ตรงไหน

และการที่ภาษาไทยถูกจัดให้เป็นภาษากลุ่ม Complex Text Layout (CTL) ทำให้เราถูกยัดเยียด implementation ตามแบบภาษาอินเดียอยู่เนือง ๆ (เช่น การทำ virama ด้วยพินทุ) และครั้งนี้ การที่นักพัฒนา VTE เลือกวิธี implement แบบอินเดียด้วยการ resolve bug ว่า duplicate กับ บั๊กของเทวนาครี ก็กลายเป็นการทำให้ภาษาไทยต้องรอการแก้บั๊กแบบซับซ้อนตามภาษาอินเดียไปด้วย

เอ้า รอก็รอ ได้สระอำสวย ๆ ก็ไม่เลว แต่เวลาผ่านไปเป็นปีก็ไม่มีทีท่าว่าจะมีทางแก้ ผมเลยตัดสินใจ reopen บั๊ก และ reassign บั๊กให้ Pango เพื่อขอใช้ทางเลือกที่ไม่ต้องแยกร่างสระอำเมื่อวาดด้วยฟอนต์ monospace

แล้วมันก็ค้างอยู่อย่างนั้น จนกระทั่งมีผู้ใช้ภาษาฮินดีฉุนขาด มากระทุ้งบั๊กภาษาอินเดีย ผมเลยถือโอกาสสนทนาแลกเปลี่ยน พร้อมกับกระทุ้งนักพัฒนาอีกครั้งว่าขอเลือกวิธีการต่างหากจาก Complex Text แต่คำตอบของนักพัฒนาก็คือ "I'm afraid not. I don't have any interest in maintaining a separate shaping system just for the terminal."

เอ.. ภาษาไทยชักจะถูกผูกแน่นเข้ากับภาษาอินเดียมากขึ้นทุกที ทั้งที่เราก็ใช้ภาษาไทยบน text console มาได้ตั้งแต่สมัย MS-DOS ทำไมครั้งนี้มันถึงยุ่งยากนัก? เพราะการเหมารวมว่าภาษาไทยเป็น Complex Text Layout และยัดเยียดว่าภาษาไทยต้อง implement เหมือนภาษาอินเดียอีกใช่หรือไม่?

หรือควรเขียนเอกสารให้มันชัด ๆ ไปเลย ว่า Thai is NOT Complex Text (ว้อย!)

จะติดก็อยู่ที่สระอำเจ้าปัญหาตัวเดียวนี่แหละ งานไหนก็ขอจุ้นมันทุกงาน :-P

ป้ายกำกับ: ,

08 มิถุนายน 2553

OSM Tidbits

เขียนถึง OpenStreetMap ไปสองตอนแล้ว (OpenStreetMap และ Meet OpenStreetMapper) ทำไป ๆ ก็พบเกร็ดเล็กเกร็ดน้อยเพิ่มขึ้น

  • เรื่องแรก ใครเล่น identi.ca อยู่ มีกลุ่มชื่อ openstreetmap สามารถ subscribe ได้ครับ จะได้แลกเปลี่ยนข้อมูลและความเห็นกับคนอื่น ๆ ที่ทำ OSM เหมือนกัน และหลายเรื่องที่เขียนใน blog นี้ ก็ได้มาจากกลุ่มนี้นี่แหละ
  • สำหรับคนที่ไม่มีอุปกรณ์ GPS หรือมี แต่โอกาสไม่เอื้ออำนวยให้ออกไปเก็บข้อมูล (โดยเฉพาะช่วงนี้หน้าฝน ติดฝนกันบ่อย หรือไม่ก็ fix ตำแหน่ง GPS ลำบาก) ก็ยังสามารถช่วยแก้ไขข้อมูลแผนที่ได้ โดย OSM จะมีเครื่องมือควบคุมคุณภาพคือ KeepRight ซึ่งจะคอยตรวจสอบหาจุดบกพร่องในข้อมูลแผนที่อยู่เรื่อย ๆ เช่น มีร้านขายยาที่ไม่มีชื่อ มีถนนที่ขาดลอยออกจากถนนอื่น (ที่ถูกแล้ว ถนนทุกเส้นบนพื้นดินควรจะเชื่อมถึงกันหมด) มีจุดที่ขาด tag บางอย่างไป ฯลฯ พวกนี้บางทีคนที่ลงพื้นที่เก็บข้อมูลก็เก็บมาไม่ครบหรือไม่สามารถหาข้อมูลได้ ถ้าคุณรู้ข้อมูล ก็สามารถเข้าไปช่วยเพิ่มได้ สำหรับผม ผมทำ bookmark สำหรับตัวเมืองขอนแก่น ไว้เลย เพราะกว่าจะเลื่อนแผนที่จากโตเกียวมาถึงได้มันช้าเอามาก ๆ
  • คุณ Willi2006 ฝากมาว่า เขาได้เสนอการจัด administrative level (ลำดับชั้นของการปกครอง) ของประเทศไทยเอาไว้ โดยไล่ลงมาจากประเทศไทย (Kingdom of Thailand), จังหวัด (Province), อำเภอ (District), ตำบล (Subdistrict), หมู่บ้าน (Village), ชุมชน (Community/Hamlet) โดยในระดับตำบลจะมี เทศบาล (Municipality) มาคาบเกี่ยว ถ้าใครมีอะไรเสนอแก้ไขหรือเพิ่มเติม ก็เข้าไปคุยกันที่ลิงก์ข้างต้นได้ครับ รายละเอียดของประเทศไทยจะรวบรวมไว้ที่ ฉบับร่างในวิกิ
  • นอกจากจะดูผ่านเว็บแล้ว บน GNOME ยังมีโปรแกรมดูแผนที่ OSM ชื่อ Emerillon อีกด้วย (มีใน Debian/Ubuntu apt-get ได้เลย)
  • ผมเคยเขียนถึง MapDroyd ไว้ใน blog ก่อน ว่าสามารถใช้ดูแผนที่ OSM แบบออฟไลน์บน Android ได้ แต่ปัญหาคือ ข้อมูลแผนที่จะค่อนข้างเก่า และเราไม่สามารถปรับข้อมูลได้เอง ต้องรอให้ทางผู้พัฒนาเตรียมข้อมูลให้ ก็เลยลองค้นหาตัวอื่นดู ก็ไปพบเครื่องมือชื่อ Mobile Atlas Creator สามารถดึงข้อมูลแผนที่ต่าง ๆ มาทำเป็นข้อมูลไว้ใช้แบบออฟไลน์บนมือถือได้ โดยรองรับแผนที่หลายแหล่ง ทั้ง OSM เอง ทั้ง Google Maps, Microsoft/Bing Maps และ Yahoo Maps ด้วย ดึงมาแล้วสามารถสร้างเป็นข้อมูลสำหรับโปรแกรมได้หลายตัว โดยตัวหนึ่งที่น่าสนใจที่ใช้ข้อมูลจากโปรแกรมนี้ได้คือ AndNav2 ผมจึงทดลองทำดู โดยมี คำอธิบาย ให้ที่วิกิของ AndNav ปรากฏว่าใช้การได้ดีครับ แต่ข้อเสียของวิธีนี้คือ ขนาดของข้อมูลจะใหญ่มากเมื่อเทียบกับของ MapDroyd เพราะ MapDroyd นั้นเขาบอกว่าใช้ฟอร์แมตพิเศษที่เรียกว่า MicroMap ซึ่งมีขนาดเล็ก เล็กไม่เล็กลองเทียบขนาดดู MapDroyd เก็บแผนที่ประเทศไทยทั้งประเทศรวมกับแผนที่โลกโดยรวมแบบไม่ลงรายละเอียดแล้ว ใช้เนื้อที่รวม 13 MB ในขณะที่ AndNav2 เก็บแค่แผนที่ตัวเมืองขอนแก่นเท่านั้น ก็ปาเข้าไป 74 MB แล้ว ลองเช็กข้อมูลดู เล่นเก็บข้อมูลเป็นบิตแมปของทุกมาตราส่วน ก็สมควรอยู่หรอก
  • อย่างไรก็ดี ก็ต้องบอกว่า AndNav2 ไม่ได้ออกแบบมาให้ใช้แบบออฟไลน์เหมือน MapDroyd แต่ก็ได้เตรียมการใช้งานแบบออฟไลน์สำหรับเส้นทางที่คำนวณแล้วได้

เสียดายจริงที่ช่วงนี้ติดฝน หรือไม่ก็ fix ตำแหน่ง GPS ลำบาก เลยไม่ค่อยได้ออกไปเก็บ track แต่ถึงกระนั้นก็ยังสามารถเล่นอย่างอื่นไปพลางได้

ป้ายกำกับ: , , ,

28 กุมภาพันธ์ 2553

Hardening LibThai

หลังจากผ่าน security update มาแล้ว ก็มีรายการแก้ไขเพิ่มเติมอีกนิดหน่อยจาก การตรวจสอบของทีม RedHat ซึ่งละเอียดน่าประทับใจมาก ก็เป็นการอุดช่องเล็ก ๆ น้อย ๆ เพิ่มเติม พร้อมกับพบ บั๊กใน glib เพิ่มเติมด้วย

แต่อีกประเด็นหนึ่งที่ได้แก้เพิ่ม คืออาการพังที่เคยได้รับรายงานมาหลายครั้งแล้ว แต่ทำซ้ำใหม่ไม่ได้สักที จนกระทั่งมาเจอกรณีที่น่าจะใกล้เคียงที่สุด คือ Debian #569996 ซึ่งพบว่า iceweasel, gedit จะพังถ้าแสดงภาษาไทยโดยแฟ้มพจนานุกรมตัดคำของ libthai เสียหายอยู่

ในบั๊กนั้น ได้ให้ผู้ใช้แก้ปัญหาไปแล้วด้วยการ reinstall libthai-data แต่หลังจากปิดบั๊กไปก็รู้สึกว่าควรจะให้ libthai ยืดหยุ่นกว่านี้ ถ้าพจนานุกรมเสียหายก็ไม่ควรจะพังไปเลย แต่ควรจะแค่ไม่ตัดคำให้เท่านั้น ว่าแล้วก็เข้าไปปรับปรุงส่วน error handling ใน libdatrie และ libthai ตามนั้น

อีกส่วนหนึ่ง ได้รับแจ้งจาก Behdad จาก RedHat ว่าซอร์สโค้ด libthai ไม่ได้แปะสัญญาอนุญาตไว้ที่แฟ้มซอร์สแต่ละแฟ้ม ซึ่งเป็นวิธีที่ชัดเจนที่สุดในการใช้ LGPL ก็เลยแก้เพิ่มด้วยทั้งใน libdatrie และ libthai โดยได้ถือโอกาสจัดแต่งซอร์สโค้ดไปในตัวด้วย

ผลก็คือ libdatrie 0.2.3 และ libthai 0.1.14 ที่ออกไปเมื่อวานและวันนี้ตามลำดับครับ พบได้ใน Debian mirror ใกล้บ้านท่าน

ป้ายกำกับ: , , , , , , , ,

19 กันยายน 2552

Pango Regression for Thai

ดังที่ได้กล่าวถึงไปใน blog ก่อน ว่า Pango มีการ merge Harfbuzz-ng เข้ามาแล้ว ทำให้มีการแทนที่ OpenType layout engine ด้วยโค้ดที่รื้อเขียนใหม่หมด ซึ่งก็พบว่ามี regression ในส่วนของการวาดภาษาไทย

เดิมนั้น ผมพบจาก GNOME ที่ build ด้วย JHBuild ในเครื่องในระหว่างที่ตรวจคำแปล แต่ยังไม่แน่ใจว่าเป็นโค้ดที่ release หรือยัง ก็เข้าไปถามหาคนที่ใช้ Ubuntu Karmic ในห้อง #tlwg ก็ยังไม่มีใครใช้ (ผมใช้ Debian sid อยู่ เลยยังไม่พบปัญหา) ประกอบกับต้องรีบตรวจคำแปลแข่งกับเวลา ก็เลยเว้นเรื่องนี้ไว้ จนเมื่อวันก่อนได้พบกับ อ.กิตติ์ ที่ใช้ Karmic อยู่ ก็เลยได้คำยืนยัน ว่าปัญหานี้มีใน GNOME รุ่นพัฒนาที่ปล่อยออกมาแล้ว แล้วก็เลยช่วยกันสรุปอาการจาก screenshot ต่าง ๆ จนในที่สุดก็ file GNOME #595539 ไป

อาการเป็นอย่างนี้:

Pango regression cases

  1. cons + tone + vowel จะวาดเป็น cons + NIKHAHIT + tone + vowel
  2. cons + tone + whitespace/punct จะวาดเป็น cons + NIKHAHIT + tone + whitespace/punct
  3. cons + lower-vowel + tone จะวาดโดยที่ tone ไม่ได้ลดลงต่ำ

นั่งเช็กเมื่อวานนี้ ได้ แพตช์แรก ที่แก้ปัญหานิคหิตเกินมาได้ โดยพบว่าลูปใน Harfbuzz วิ่งขาดไปหนึ่งรอบ มันเลยไป match กับกฎ GSUB ในฟอนต์ที่ใช้จัดแสดงสระอำแบบมีวรรณยุกต์ โดยกฎนั้นเขียนไว้ว่าต้องตามด้วยสระอำด้วย แต่ในเมื่อมันวิ่งลูปขาดไปหนึ่งรอบ มันเลยเช็กไม่ถึงสระอำ แค่มีพยัญชนะตามด้วยวรรณยุกต์มันก็ apply กฎแล้ว โดยแทรกนิคหิตใต้วรรณยุกต์รอไว้ แล้วจะมีอีก substitution หนึ่งที่แปลงสระอำเป็นสระอาตามมา

แต่แพตช์นี้ยังไม่ได้แก้ regression ทั้งหมด ยังขาดเรื่องลดวรรณยุกต์ลงต่ำอีก แต่ผมจะมีเวลาแกะต่อหรือไม่ก็ยังไม่แน่ใจ เพราะต้องรีบเตรียมเนื้อหาสำหรับงานสัมมนาที่จะถึงนี้แล้ว

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

ป้ายกำกับ: , , , , , ,

29 สิงหาคม 2552

How Translation is in need

GNOME 2.28 string freeze แล้ว ได้เวลามาคิดเกี่ยวกับเรื่องแปลอีกแล้ว

ผมเคย blog ไว้ ว่า จะลดบทบาทงานแปลใน GNOME ลง ให้เหลือเพียงการประสานงาน (ตรวจทานและ commit และ maintain เล็ก ๆ น้อย ๆ) เท่านั้น โดยไม่ลงมือแปลเองให้มากเหมือนเมื่อก่อน เพราะต้องการเวลาไปทำงานพัฒนาส่วนที่เป็น coding ที่เคยเป็นงานหลักของผมบ้าง

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

เรื่องการปล่อยมือจากงานแปล ก็ทำให้ผมมีเวลาไปให้ความสนใจกับงานพัฒนา ตามที่ได้ blog มาเป็นระยะ ๆ แล้ว และสำหรับ GNOME 2.28 (ทั้ง UI และ doc) นี้ ผมก็พยายามจะทำตามที่ตั้งใจไว้ คือไม่ลงมือแปลเอง ยกเว้นกรณีขาดเล็กขาดน้อย แต่ยินดีรับคำแปลที่นักแปลส่งมาให้

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

ต่อมา GNOME เขาก็มี การสำรวจพฤติกรรมผู้ใช้ GNOME ก็ปรากฏว่าสำหรับคนทั้งโลกแล้ว ประมาณ 70% จะใช้โปรแกรมในภาษาของตัวเอง อีก 30% ที่เหลือจึงจะใช้เมนูที่ไม่ใช่ภาษาตัวเอง (หมายความว่า ผู้ที่พูดภาษาอังกฤษเปิดโปรแกรมภาษาอังกฤษ จะนับรวมอยู่ในกลุ่มเดียวกับผู้ที่พูดภาษาไทยเปิดโปรแกรมฉบับแปลไทย ดังนั้น ตัวเลข 30% จึงเป็นการนับผู้ใช้ที่พูดภาษาอื่นแต่ยังเปิดโปรแกรมเป็นภาษาอังกฤษเท่านั้น โดยอาจเป็นไปได้ที่จะนับรวมคนที่เปิดโปรแกรมฉบับแปลเป็นภาษาอื่นที่ไม่ใช่ทั้งภาษาพูดของตนและภาษาอังกฤษบ้าง แต่คงมีน้อย :P)

อันนั้นผมยังคิดว่าเป็นพฤติกรรมโดยรวมของประชากรโลก ยังไม่ใช่ของคนไทย ก็เลยลองเปิด โพลล์ ที่ debianclub ดู โดยในขณะที่เขียน blog นี้ มีผู้ลงมติ 292 ราย โดย 67% จะเปิดใช้เมนูไทย

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

เป็นอันว่าผมคงเอาไปอ้างกับฝรั่งไม่ได้อีกแล้ว ว่าคนไทยส่วนใหญ่เปิดเมนูอังกฤษ เพราะผลสำรวจไม่เหมือนกับที่คิดไว้ แต่โพลล์นี้ไม่ได้มีเจตนาจะเอามาสนับสนุนความจำเป็นของงานแปล เพราะแม้จะไม่มีโพลล์นี้ ผมก็ยังคงคิดว่างานแปลสำคัญอยู่นั่นเอง ตามที่ได้ว่าไปแล้วใน blog ก่อน ๆ

ป้ายกำกับ: , ,

24 พฤษภาคม 2552

Pango Patch for SARA AM in VTE

ด้วยฝีมือของ Behdad Esfabod ใน GNOME #149631 ทำให้ vte widget และ gnome-terminal สามารถวาด combining character ได้ตั้งแต่รุ่น 2.26 เป็นต้นมา ..พูดเป็นภาษาไทยก็คือ มีการจัดระดับสระบน-ล่างและวรรณยุกต์เรียบร้อย

ติดอยู่ที่ปัญหาเล็ก ๆ คือ แพตช์นี้เป็นการใช้ pango วาดเซลล์แต่ละเซลล์บนหน้าจอ ซึ่ง pango จะมีการจัดการ cluster แยกร่างสระอำเป็นนิคหิตและลากข้าง เพื่อนำนิคหิตไปวางบนพยัญชนะอย่างถูกต้องสวยงาม แต่บนเทอร์มินัลนั้น สระอำจำเป็นต้องอยู่ในเซลล์ของตัวเองแยกจากพยัญชนะ เวลาที่ vte สั่งวาดทีละเซลล์ สระอำจึงถูกวาดโดยไม่มีพยัญชนะนำหน้า นิคหิตที่ถูกแยกร่างโดยไม่มีพยัญชนะนำหน้า จึงมี dotted circle มารองรับ ทำให้สระอำเปรอะ และกินเนื้อที่ล้ำไปสู่เซลล์ถัดไปด้วย

ปัญหานี้ ทีมสุริยันก็เคยพบกับ konsole ซึ่งในตอนนั้นผมแนะให้เช็กฟอนต์ว่าเป็น monospace หรือไม่ ถ้าเป็น ก็ยอม render สระอำแบบไม่แยกร่าง (เหมือนพิมพ์ดีด) ถ้าไม่เป็น จึงจะแยก (เหมือนเรียงพิมพ์บนแท่นพิมพ์) ตอนนี้ ก็เลยดัดแปลงวิธีนั้นมาใช้กับ pango ด้วย

ผลคือแพตช์ pango-1.24.2-thai-sara-am-mono.patch ครับ

ก่อน:

VTE rendering, before patching

หลัง:

VTE rendering, after patching

พร้อมกันนี้ ก็เลย build เป็น deb ไว้ที่ debclub ก้านกล้วย ด้วย เพื่อความสะดวกในการทดสอบ โดยรวมเอาแพตช์แก้เรื่องการเลื่อนเคอร์เซอร์ (pango-1.24.2-thai-grapheme-cluster.patch) ที่เคยทำไว้ตาม blog เก่า (GNOME #576156) ด้วย

เนื่องจากเพิ่งทำเสร็จใหม่ ๆ ยังต้องทดสอบความเรียบร้อยสักพัก แล้วค่อย file bug อีกที

ป้ายกำกับ:

23 มีนาคม 2552

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 ได้ ตรวสอบ ไว้

ป้ายกำกับ: , , ,

16 มีนาคม 2552

My (Partial) TODO List

ชักยาวเป็นหางว่าวแล้ว TODO list ของผม.. แค่ช่วงที่ติดงานแปล GNOME 2.26 นี่เท่านั้น จดไว้กันลืมเสียหน่อย 2.26 ออกเมื่อไรต้องรีบทยอยเคลียร์..

  • ออก libdatrie, libthai, swath รุ่นใหม่ที่ได้ ทำค้างเอาไว้
  • จัดการเรื่องปัญหา extended cluster ของ pango ซึ่งมีผลกับการเลื่อนเคอร์เซอร์ข้าม cluster ในรูป "เก" และ "กะ" (รวมทั้ง "เกะ") -- สิ่งที่เกี่ยวข้อง: Mozilla #474068, Unicode UAX #29
  • ออกแบบเรื่อง UI การใช้ภาษาอังกฤษในโลแคลไทย เพื่อแก้ปัญหา ผู้ใช้ไม่ยอมใช้โลแคลไทย จนไปกระทบ feature ภาษาไทยของระบบ และหาที่เสนอแนวคิด
  • แก้ปัญหาเรื่องความกว้างของตัวเลข ตามที่ Davide Viti ได้ ตรวจสอบ เอาไว้ แพกเกจที่กระทบคือ ttf-thai-arundina และ ttf-thai-tlwg
  • update Debian package ภาษาไทย โดย update ข้อมูล VCS ของแพกเกจที่ host ที่ LTN จาก CVS เป็น SVN, update ตาม Debian policy 3.8.1, update debhelper เป็น level 7
  • ผลักดัน Thai Fonts Siampradesh (non-free) เข้าใน Debian

มีรายการอื่นอีก ที่คงไม่สะดวกที่จะเขียนลง blog เนื่องจากเป็นการติดต่อเป็นการส่วนตัวกับคนอื่น

วันนี้เป็นวันสุดท้ายก่อน tarballs due ของ GNOME 2.26 แล้ว คงจะพยายามแปล user guide ให้ได้มากที่สุด จากนั้นก็เป็นคิวของ release notes ที่ควรจะเสร็จภายในวันพุธ (18 มี.ค.) แล้วหลังจากนั้นถึงจะเป็นอิสระจากงานแปล ไปเคลียร์ TODO list ได้..

ป้ายกำกับ: , , , , , , , , , ,

25 กุมภาพันธ์ 2552

Fading Out the Translation

เดิมคิดว่าจะรอให้เสร็จงานแปล GNOME 2.26 แล้วค่อยเขียนเรื่องนี้ แต่คิดว่าเขียนตั้งแต่ยังแปลไม่เสร็จน่าจะเป็นประโยชน์กว่า เผื่อว่าจะช่วยเรื่องการส่งต่องานได้

ผมได้ตัดสินใจที่จะทำงานแปล GNOME 2.26 เองเป็นรุ่นสุดท้าย ในรุ่นถัด ๆ ไป ผมคิดว่าจะรับตรวจทานและ commit คำแปลจากอาสาสมัครให้เท่านั้น การตัดสินใจลดบทบาทงานแปลนี้ ก็ด้วยปัจจัยหลาย ๆ อย่าง:

  • ผมคิดว่าผมทำงานแปลมานานเกินไปแล้ว ผมเริ่มเข้าร่วมงานแปลเมื่อประมาณปี 2546 ด้วยเหตุผลที่ เคย blog ไว้ จนถึงตอนนี้ก็เกือบ 6 ปี ผ่านรอบการออกรุ่นของ GNOME มาราว 10 รุ่นในฐานะผู้ประสานงานแปล สมควรที่จะมีผู้รับช่วงต่อได้แล้ว
  • สุขภาพไม่เอื้ออำนวย โดยปกติแล้ว ผมจะไม่โหมแปลหนัก ๆ แต่จะใช้ความสม่ำเสมอ ทำเก็บเล็กผสมน้อยไปเรื่อย ๆ ทำให้เบาแรงในระยะยาว แต่ในระยะหลังนี้ ปัญหาตาแห้งและปวดนิ้ว ทำให้ผมแปลได้น้อยลงอีก ทำให้ไม่สามารถเร่งงานได้แม้ในช่วง string freeze นี้
  • งานแปลได้ทำให้ผมห่างจากงานพัฒนามานาน โดยเฉพาะในช่วงหลัง ๆ ที่นักแปลขาประจำได้ทยอยผละออกไป ทำให้งานแปลมาตกที่ผมมากขึ้น และได้เข้ามากินเวลาการทำงานพัฒนาและงานอื่น ๆ ทำให้ความคืบหน้าของงานเหล่านั้นเป็นไปได้ช้า หรือสะดุดบ่อย ๆ ตัวอย่างเช่น:
    • งานพัฒนาใน GNOME การมายุ่งกับงานแปลทำให้ผมห่างหายจาก bugzilla ของ GNOME ในขณะที่บทบาทของ "translator" ถูกเน้นให้เด่นชัดขึ้น เวลาที่มีบั๊กภาษาไทยหรือบั๊กทั่ว ๆ ไป ผมจึงต้องเริ่มต้นสร้างความคุ้นเคยกับทีมงานซึ่งมีการผลัดเปลี่ยนเข้ามาใหม่ ความเสียหายหนึ่งที่เห็นได้คือ ผมได้เสียสิทธิ์ในการเป็น maintainer ของมอดูลภาษาไทยใน GTK+ และ Pango ไปแล้ว (เช่น ตัวอย่างใน GNOME #457086)
    • งานพัฒนาที่ LTN ไม่ว่าจะเป็นเรื่องฟอนต์, libthai และอื่น ๆ ผมจำต้องพักงานเหล่านี้ตามจังหวะ string freeze ของ GNOME ซึ่งเท่ากับว่า ผมมีเวลาในช่วง 3-4 เดือนเท่านั้นในการทำงานทุกอย่าง รวมถึงงานต่าง ๆ นอก LTN ด้วย (เช่น งานใน Debian, Mozilla) ก่อนที่จะมาอุทิศให้กับงานแปล ทำให้งานพัฒนาเหล่านั้นทำได้ไม่เต็มเม็ดเต็มหน่วยนัก
    • กระบวนการสมัครเป็น Debien Developer มีบางจังหวะที่ได้รับข้อสอบมาในช่วงที่ GNOME กำลัง string freeze ทำให้ผมต้องแจ้งชะลอการทำข้อสอบออกไป เปิดโอกาสให้ Application Manager ของผมไปทำการสอบผู้สมัครคนอื่นไปก่อน แล้วก็รอจนถึงรอบที่เขาว่างอีกทีถึงกลับมาตรวจข้อสอบผม ทำให้กระบวนการต้องยืดเยื้อออกไปเป็นปี
    • งานรับจ้างต่าง ๆ การทำงานอิสระนั้น ไม่ได้อิสระทุกอย่าง สุดท้ายก็ยังมีเรื่องที่ควบคุมไม่ได้ ผมเคยพูดถึง "ฤดูงานเข้า" บ่อย ๆ ซึ่งมักจะมาพ้องกับช่วงก่อน GNOME ออกรุ่นเสมอ ๆ ทำให้จัดตารางงานได้ลำบากในช่วงนี้.. ผมแอบคิดว่า มันต้องไม่บังเอิญแน่ ๆ ที่ทุกอย่างมาประดังพร้อมกันอย่างมีจังหวะ อย่างน้อย รอบการออกรุ่นของสองอย่าง คือ GNOME และ Ubuntu ก็น่าจะมีอิทธิพลไม่มากก็น้อย หรือไม่ ก็อาจจะอยู่ในช่วงจบไตรมาส ซึ่งเป็นจังหวะของธุรกิจก็ได้ ซึ่งถ้าผมเป็นอิสระจากงานแปลมากกว่านี้ ก็อาจจัดการอะไร ๆ ได้ง่ายเข้า งานต่าง ๆ บางงานนั้น เกี่ยวข้องกับงานพัฒนา FOSS เสียด้วยสิ
  • ประโยชน์ที่ได้จากงานแปล ผมยังคงเชื่อว่างานแปลนั้นมีผู้ใช้ประโยชน์ แม้จะไปได้ยินเสียงบ่นต่าง ๆ ว่า "แปลไปทำไม ใคร ๆ ก็ใช้เมนูอังกฤษ" (ลองอ่าน คำอธิบายของ mk เขาเขียนไว้ยาวแล้ว รวมทั้ง เหตุผลที่ผมเข้าร่วมงานแปล ด้วย) เพียงแต่ภาระต่าง ๆ มันหนักเกินไปสำหรับคนตัวเล็ก ๆ อย่างผมจะทำโดยลำพังได้ งานแปลนั้นสำคัญ แต่งานอื่นก็สำคัญไม่แพ้กัน

ทั้งหมดนั้น นำมาสู่การตัดสินใจลดงานแปลของตัวเองลง ให้เหลือเพียงงาน "ประสานงาน" จริง ๆ เท่านั้น โดยสำหรับ GNOME 2.26 นี้ ขอร่วมแปลด้วยเป็นรุ่นสุดท้าย รุ่นหน้า ผมอาจจะร่วมแปลบ้าง แต่จะไม่เน้นมาก เน้นรอรับผู้ร่วมสมทบมากกว่า ไม่มีใครสมทบ ผมก็จะปล่อยวางให้มันเป็นไปตามยถากรรมละ

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

ป้ายกำกับ: , ,

hacker emblem