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

Thanks

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

Double-Array Trie Has Got Java Implementation

ไม่ใช่ผมทำเองหรอกครับ แต่ได้รับแจ้งจากคุณ Chris Gioran นักพัฒนาชาวกรีก ว่าได้พัฒนา double-array trie ในฉบับ Java แล้ว โดยโฮสต์ไว้ที่ github โดยอาศัยหลักการจากหน้าเว็บที่ผมเขียนไว้ สัญญาอนุญาตที่ใช้ เป็น LGPL เหมือน libdatrie ครับ

รายละเอียด มีบันทึกไว้ใน blog ของเขา

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

ThaiLaTeX Now Supports Pali-Sanskrit

ขณะนี้ ThaiLaTeX ใน SVN รองรับการสร้างเอกสารภาษาบาลี-สันสกฤตแล้ว

เรื่องของเรื่องคือ กำลังเตรียม presentation สำหรับงาน OSSFest 2010 แล้วเจอบั๊กใน ThaiLaTeX เกี่ยวกับทัณฑฆาตบน ป ปลา ก็เลยแก้บั๊กก่อน พอแก้แล้วก็ดันเกิดไอเดียเรื่องการรองรับภาษาบาลี-สันสกฤตขึ้นมาทีละเรื่อง จนในที่สุดก็ครบจนได้

ประเด็นที่ต้องทำเพิ่มจากภาษาไทยปกติมี 2 เรื่อง:

• ใช้ ญ ฐ ไม่มีเชิง ตรงนี้ทำโดยเพิ่มแมโครสำหรับเรียกอักขระ ญ ฐ ไม่มีเชิงก่อน แล้วกำหนดแมโคร \textpali{} ซึ่งจะสแกนข้อความแล้วแทนที่ ญ ฐ ด้วยอักขระไม่มีเชิง
• รองรับนิคหิตที่ซ้อนบนสระอิ ตรงนี้ในหนังสือสวดมนต์ทั่วไปไม่สามารถพิมพ์ได้ ก็มักจะใช้สระอึแทน แต่เนื่องจากเราได้เตรียมฟอนต์บนลินุกซ์ให้รองรับมานานแล้ว จึงทำเพิ่มได้ไม่ยาก เพียงแต่เพิ่มแมโครสำหรับเรียกนิคหิตสูง แล้วเพิ่มกฎ ligkern มาแปลงนิคหิตบนสระอิให้เป็นนิคหิตสูงเท่านั้น พร้อมกันนี้ก็ทำแบบเดียวกันกับไม้ไต่คู้สูงสำหรับเขียนบนสระอีและอือในภาษากุย/ส่วยด้วย

เวลาจะใช้ภาษาบาลีก็เพียงแต่ใช้คำสั่ง \textpali{ข้อความ} เช่น:

  \textpali{กิจฺฉิสฺมิํ สติ, ชิฆจฺฉาปิปาสา ปญฺญายติ}

ตัวอย่างผลการจัดหน้า:

ตัวแฟ้มตัวอย่าง: pali-sample.tex และ PDF ผลลัพธ์

The DIP-SIPA 13 Postscardware Fonts

ถึงจะช้าไปหน่อย (ทราบข่าวหลายวันแล้ว แต่เพิ่งมีเวลาเขียน) แต่ก็ขอเขียนถึง ฟอนต์สารบรรณและ ๑๓ ฟอนต์ "แห่งชาติ" ของ SIPA และกรมทรัพย์สินทางปัญญา ที่ ครม. ได้มีมติเห็นชอบให้หน่วยงานภาครัฐติดตั้งเพื่อใช้เป็นฟอนต์มาตรฐาน

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

ข้อแรก คือการทำแบนเนอร์ "๑๓ ฟอนท์แห่งชาติ" นั้น ทำให้เกิดความสับสนกับโครงการเดิมที่มีอยู่ คือ โครงการฟอนต์แห่งชาติ ของเนคเทค ซึ่งปัจจุบัน TLWG กำลังดูแลอยู่ในฐานะส่วนหนึ่งของโครงการ ThaiFonts-Scalable ผมคิดว่าถ้าโครงการใหม่นี้ไม่ใช่การสานต่อโครงการเก่า ก็ไม่ควรจะใช้ชื่อซ้ำกันให้เป็นที่สับสน น่าจะใช้ชื่ออื่น เช่น ชื่อที่จั่วหัวในเว็บ f0nt.com ว่า ฟอนต์มาตรฐาน ก็เป็นชื่อที่ดีครับ

ข้อสอง คือปัญหาเรื่อง license ของฟอนต์ชุดนี้ ซึ่งผมเคยเขียนถึงไปหลายครั้งแล้ว (เช่น DIP-SIPA Fonts License, Thai Fonts Siampradesh (non-free), Postcardware) จะทำให้ฟอนต์ชุดนี้ไม่สามารถผลักดันให้เข้าสู่ distro กระแสหลักได้ กล่าวคือ มันจะเป็นได้อย่างดีที่สุดก็ national ไม่มีทางไปสู่ international หรือ "worldwide development" ตามเจตน์จำนงของ license ได้ และมันก็จะต้องติดแหง็กอยู่ที่ ThaiOS ของ SIPA ไปตราบชั่วฟ้า SIPA สลาย คือโครงการปิดเมื่อไรก็จบกัน ไม่มีใครสามารถจะแก้ไขปรับปรุงฟอนต์ชุดนี้ต่อไปได้อีก

ขอทบทวนปัญหาของ license อีกครั้ง เพื่อเตือนความจำว่าทำไมมันถึงจะเป็นเช่นนั้น

ปัญหาที่หนักที่สุดอยู่ที่เงื่อนไขข้อ 2 ของ license ของฟอนต์:

2. If you wish to adapt this Font Computer Program, you must notify copyright owners (DIP & SIPA) in writing.

ปัญหาคือ:

• ใน license บอกให้เขียนแจ้งเป็นลายลักษณ์อักษร แต่ไม่ได้ระบุที่อยู่ที่จะให้แจ้งเลย ว่าจะให้ติดต่อไปที่ไหน บอกเพียงชื่อ "DIP & SIPA" เท่านั้น อย่าลืมว่าเมื่อฟอนต์นี้ go worldwide แล้ว การติดต่อหน่วยงานราชการไทยจากต่างประเทศไม่ใช่เรื่องง่าย จะไปทึกทักว่านักพัฒนาฟอนต์อิสระที่แอฟริกาจะสามารถค้นหาที่อยู่ทางไปรษณีย์ของหน่วยงานรัฐของไทยได้เองแล้วส่งมาอย่างถูกต้องนั้นไม่ได้
• แม้กระนั้น การต้องแจ้งเป็นลายลักษณ์อักษรนั้น วัฒนธรรมเสรี (free culture) เขาถือว่าเป็นอุปสรรคที่ทำให้เลิกล้มความตั้งใจแล้วไปหาตัวเลือกอื่นได้ง่าย ๆ เพราะในทางปฏิบัติแล้ว การแจ้งเป็นลายลักษณ์อักษรจะต้องการคำตอบรับจากเจ้าของ เพื่อให้มีหลักฐานยืนยันในภายหลังว่าได้แจ้งเป็นลายลักษณ์อักษรตามเงื่อนไขของ license แล้ว และหากเจ้าของไม่ตอบรับ ก็จะไม่มีอะไรรับประกันได้เลยว่าจะสามารถเริ่มแก้ไขได้ การตอบรับหรือไม่ตอบรับจึงไม่ต่างอะไรกับการอนุญาตหรือไม่อนุญาตให้แก้ไข ดังนั้น ไม่ว่า license จะให้เสรีในการแก้ไขอย่างไรก็ตาม ถ้ามันเป็นเสรีภาพที่ต้องได้รับการอนุญาต มันก็ไม่ต่างกับการเจรจาขอใช้ license ของซอฟต์แวร์ proprietary ทั่วไปเลย
• license นี้ขาดความยั่งยืน จะเกิดอะไรขึ้นถ้าโครงการนี้ถูกปิดไปจากแผนงานของ DIP และ SIPA คนที่เขียนเข้ามาจะได้รับการตอบสนองหรือไม่? ฟอนต์ชุดนี้คงจะตายไปพร้อมกับการปิดโครงการในหน่วยงานทั้งสองโดยไม่มีใครปรับปรุงแก้ไขต่อได้

ปัญหาของ license ข้อนี้ มีคนทำผิดพลาดบ่อยจนเขามีศัพท์เฉพาะสำหรับเรียก ว่า Postcardware และไม่ถือเป็นซอฟต์แวร์เสรีหรือโอเพนซอร์สครับ ถ้าเป็นไปได้ก็ขอเสนอให้ตัดข้อนี้ออก

ปัญหาอีกข้อหนึ่งของ license นี้คือเงื่อนไขที่ไม่ตรงกันระหว่างฉบับภาษาอังกฤษกับภาษาไทยในเงื่อนไขข้อ 3:

No adapted version of Font Computer Program may use the Reserved Font Name(s), ...

ซึ่งฉบับไทยได้แปลไว้ว่า:

เมื่อดัดแปลงโปรแกรมคอมพิวเตอร์ฟอนต์นี้แล้ว ห้ามผู้ดัดแปลงใช้ชื่อฟอนต์เดิม ...

กล่าวคือ ฉบับภาษาอังกฤษบอกว่า เมื่อดัดแปลงฟอนต์แล้ว "ห้ามใช้ชื่อที่สงวนไว้" แต่ฉบับไทยแปลว่า "ห้ามใช้ชื่อฟอนต์เดิม" ซึ่งความหมายต่างกัน และมีนัยสำคัญในทางปฏิบัติ เช่น ฟอนต์เริ่มแรกชื่อ A นายสมชายดัดแปลงแล้วเปลี่ยนชื่อเป็น B ต่อมานายสมศักดิ์เอาฟอนต์ B ของนายสมชายไปดัดแปลงต่อ ถ้า "ห้ามใช้ชื่อที่สงวนไว้" นายสมศักดิ์จะยังสามารถใช้ชื่อฟอนต์ B ต่อไปได้ เพราะไม่ใช่ชื่อที่สงวนไว้ แต่ถ้า "ห้ามใช้ชื่อฟอนต์เดิม" นายสมศักดิ์จะใช้ชื่อฟอนต์ B อีกไม่ได้ เพราะเป็นชื่อฟอนต์เดิมที่มีการคุ้มครองไว้โดย license และถ้าใครดัดแปลงต่อจากนายสมศักดิ์อีก (เช่น อาจจะเป็นโครงการ Fedora ที่จำเป็นต้องสามารถแก้บั๊กให้ผู้ใช้ได้) ก็จะต้องใช้ชื่อที่ต่างจากนายสมศักดิ์อีก เป็นอย่างนี้ทุกครั้งไป

การแก้ไข: ควรแก้คำแปลภาษาไทยให้เป็น "ห้ามผู้ดัดแปลงใช้ชื่อที่สงวนไว้" ให้เหมือนฉบับภาษาอังกฤษ

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