ปัญหาภาษาไทยในระบบดิจิตอล?
fff.fun
จากที่มาร์คคุยมาเรื่อง
คุณขจร
นั่นอาจเป็นสาเหตุทำให้
เว็บเค้าสมัครยากก็เป็น
ได้
(แต่ไม่เกี่ยวกับหัวข้อ
ที่ผมส่งมานะครับ) :p
- - - - -
เว็บ thaiadobeuser.com/board
ส่วนใหญ่เป็นถามตอบเกี่ยว
กับปัญหาการใช้งานโปรแกรม
ทั่วไป
และปัญหาการติดตั้งภาษา
ไทยในโปรแกรม adobe มากกว่า
โดยมากเน้นไปที่โปรแกรม
เกี่ยวกับสิ่งพิมพ์ photoshop
illustrator indesign
แต่หลังๆ เริ่มมีโปรแกรม
ด้านมัลติมีเดียมากขึ้น
(จากการที่ adobe ซื้อกิจการ
macromedia)
ที่ผ่านมา(นานมากแล้ว) การ
จัดหน้าหนังสือด้วย
โปรแกรม pagemaker และ indesign
จะต้องใช้ plug-in ให้สามารถ
แสดง และตัดคำภาษาไทยได้
เช่น TSP (อันนี้ Maccenter เป็นคน
ทำ), Freelock (อันนี้รุ่นใหม่ ผม
ไม่เคยลองใช้)
หรือแม้กระทั่ง "ก.ไก่ 2000"
นิยมมากใน PC แต่ไม่แน่ใจ
ว่าตอนนี้พัฒนาอยู่รึป่าว
ซึ่งที่ผมเข้าใจ คือยังมี
TSP กับ Freelock ที่ยังต้องใช้กัน
อยู่เวลาทำงานกับภาษาไทย
ต่อมาเริ่มมีกระแสว่า
ทำไม adobe ไม่ทำซับพอร์ทภาษา
ไทยไปเสียเลย
ผมเคยได้ฟังการเสวนา
เรื่องนี้มาพอสมควรว่า
จริงๆ แล้ว adobe ได้ส่งคนมาดู
บ้างแล้ว
แต่ติดปัญหาในเรื่อง
มาตรฐาน (ถ้าตามที่เข้าใจ
มาก็คือว่า ไม่รู้จะเอา
มาตรฐานไหน มั้งครับ)
** เรื่อง UT8-16/UTF-8 ผมจะพยายามหา
มาเพิ่มเติม **
คุณขจร คนที่ประสานงานกับ
adobe เคยโพสต์ไว้ใน thaiadobeuser
เรื่องภาษาไทยไว้
- อนาคต Font ของเรา และภาษาไทย
ของเรา ใครควรรับผิดชอบ
(2007-05-21)
- ความจริงกับปัญหาภาษาไทย
(2007-09-19)
เนื่องจากเว็บเค้าดัน
สมัครยากผมเลย save เป็น html, pdf
แนบมากับอีเมลนี้เลยแล้ว
กันนะครับ
ปล. ตำแหน่งของคุณขจร ที่ผม
หาได้ (จากเนต) ตามนี้ครับ
ขจร พีรกิจ: Adobe Evangelist หรือ
เทรนเนอร์ของซอฟต์แวร์ Adobe
ที่ได้รับการแต่งตั้ง
อย่างเป็นทางการ 1 ใน 8 คนของ
เอเชีย
Isriya Paireepairit
=================================
ผมอยากแยกปัญหาเรื่องภาษาไทยบนระบบคอมพิวเตอร์เป็น 2 ระดับ คือ
1. ระดับของมาตรฐาน ข้อกำหนดทางเอกสาร
2. ระดับของการ implementation ของผู้พัฒนาซอฟต์แวร์
สำหรับข้อ 1. นั้น การประมวลผลภาษาไทยบนคอมพิวเตอร์ (ในภาพกว้าง
คือรวมตั้งแต่ฟอนต์, encoding, keyboard layout, การตัดคำ ฯลฯ)
ยึดหลักตามเอกสาร วทท. (เวอร์ชันล่าสุดคือ 2.0)
รู้จักในชื่อภาษาอังกฤษว่า WTT
ลิงก์ประกอบ
http://www2.nectec.or.th/it-standards/
http://www.inet.co.th/cyberclub/trin/thairef/
http://en.wikibooks.org/wiki/FOSS_Localization/Localization_Efforts_in_the_Asia-Pacific#Standardization
เอกสารชุดนี้ออกโดยเนคเทค (โดยมี ดร. ทวีศักดิ์ ผอ.
เนคเทคคนก่อนเป็นหัวหน้าทีม) ในช่วงต้น 90s
ซึ่งแพร่หลายและนิยมในหมู่ผู้ผลิตซอฟต์แวร์ทั่วไป (ไมโครซอฟท์, แอปเปิล,
OpenOfice ฯลฯ)
ปัญหาของมาตรฐานชุดนี้มีสองข้อ อันแรกคือออกมาก่อนมาตรฐานสากลใหม่ๆ
หลายตัว เช่น Unicode 1.0 (1991) หรือ OpenType (1996)
ทำให้ปัจจุบันถือว่าล้าสมัย ส่วนปัญหาข้อที่สองคือ
ในมาตรฐานเองยังขาดรายละเอียดเล็กๆ น้อยๆ อีกหลายจุด (ถ้าผมจำไม่ผิด
อย่างการ sorting วรรณยุกต์จะมีแค่ "ก ก่ ก้ ก๊ ก๋" แต่ไม่ระบุวิธีเรียก
"ก็" หรือ "กั" ทำนองนี้)
ซึ่งพวกนี้ปล่อยให้ผู้ผลิตซอฟต์แวร์ไปนั่งคิดเอาเอง ว่าจะ implement
อย่างไร มันเลยออกมาต่างกัน
ช่วงที่ผมทำงานที่ SIPA เจ้านายของผมคือคุณเจมส์ คลาร์ค
นั้นมองว่าปัญหาเรื่องมาตรฐานล้าสมัย และคิดว่าต้องแก้ไขใหม่เป็น วทท. 3
อันนี้ทาง ดร. ทวีศักดิ์เองก็เห็นด้วย แต่สุดท้ายแล้วไม่มีคนผลักให้เกิด
สาเหตุหนึ่งเป็นเพราะยุคนี้มีกระทรวง ICT เกิดขึ้นมา
ซึ่งทำให้เกิดปัญหาการแบ่งแยกหน้าที่กับเนคเทค (ซึ่งสังกัด สวทช.
และสังกัดกระทรวงวิทย์อีกที)
ไม่เหมือนแต่ก่อนที่พูดถึงคอมพิวเตอร์ในเมืองไทย
ทุกคนมองไปที่เนคเทคเจ้าเดียว ทางกระทรวง ICT เองเป็นกระทรวงตั้งใหม่
บุคคลากรดึงมาจากที่อื่นเสียเยอะ
เรื่องความรู้ความเชี่ยวชาญคงสู้ฝั่งเนคเทคไม่ได้
สรุปว่าปัญหาเรื่องมาตรฐานตามเอกสารนั้น
เราอยู่ระหว่างช่องว่างของมาตรฐานเก่า (ที่ออกมานานมากแล้ว)
และมาตรฐานฉบับใหม่ที่ยังไม่เกิดขึ้น (และยังไม่มีทีท่าว่าจะเกิด)
ส่วนข้อ 2. ในส่วนของ implementation นั้น ผมก็แยกเป็นปัญหาย่อยได้อีก 2 ส่วน
ส่วนแรกคือความจริงจังของผู้ผลิตซอฟต์แวร์ต่อตลาดเมืองไทย
ถ้าลองดูเคสของไมโครซอฟท์ ไอบีเอ็ม หรือแอปเปิล
จะเห็นว่าภาษาไทยใช้งานได้ดี (อย่างน้อยก็ในระดับหนึ่ง)
เป็นเพราะผู้ผลิตเหล่านี้มองว่าตลาดเมืองไทยใหญ่พอที่จะลงทุน
(จะเป็นด้วยสาเหตุอันใดก็แล้วแต่เค้ามอง)
คือถึงไม่มีมาตรฐานหรือทีมงานอะไรใดๆ ถ้าผู้ผลิตซอฟต์แวร์เห็นความสำคัญ
เขาก็จะดิ้นรนเอง ตัวอย่างที่ชัดเจนคือไมโครซอฟท์เคยจ้างทีมของคุณนุสสรณ์
ไปพัฒนาภาษาไทยให้กับ Office 97 (หรือ 2000 อันนี้ไม่แน่ใจ)
ซึ่งผมมองว่านับจากอดีตถึงปัจจุบัน ทาง Adobe ไม่ได้สนใจตรงนี้
(ซึ่งเค้าก็มีเหตุผลของเค้า ไม่ว่าจะคืออะไรก็ตาม)
คนไทยเลยต้องอยู่ในสุญญากาศความสนใจของ Adobe
สำหรับซอฟต์แวร์โอเพนซอร์สจะมีความพร้อมด้านภาษาไทยที่ดีกว่า
เพราะเราสามารถเข้าไปพัฒนาได้โดยตรง ไม่ต้องรอทางผู้ผลิต
(ซึ่งถือเป็นข้อดีที่สำคัญข้อหนึ่งของโอเพนซอร์ส)
แต่ด้วยส่วนแบ่งตลาดที่น้อยกว่า ผลกระทบจึงน้อยตามไปด้วย
ส่วนที่สองคือเรื่องของ code base
คือการพัฒนาซอฟต์แวร์ขนาดใหญ่นั้นซับซ้อน และมีช่วงเทคโนโลยีของมันเอง
ไม่ใช่ว่ามาตรฐานออกวันนี้แล้วซอฟต์แวร์ที่ออกในปีนี้จะเปลี่ยนตามทันที
ต้องรอการเปลี่ยนช่วงของเทคโนโลยีด้วย (เช่น Mac OS 9 --> Mac OS X หรือ
Windows XP --> Vista หรือที่ชัดๆ เลยคือการตัดคำภาษาไทยทำได้ใน Firefox
3 เพราะใช้ text engine ตัวใหม่ที่พร้อมกับภาษานานาชาติมากกว่า)
มันเลยจะมีดีเลย์ในการปรับเทคโนโลยีตามมาตรฐานใหม่ๆ ด้วย
แถมผู้ผลิตซอฟต์แวร์ยังต้องตามเอาใจผู้ใช้รุ่นเดิมอีกเช่นกัน
(ตัวอย่างง่ายๆ เช่น Windows XP ยังไม่ได้ใช้ Unicode อย่างเต็มรูปแบบ
ในขณะที่ฝั่งลินุกซ์เป็น Unicode กันหมดแล้ว)
พอเกิดวงรอบเทคโนโลยีแบบนี้
ผู้พัฒนาอิสระเลยต้องรอตามผู้ผลิตซอฟต์แวร์รายใหญ่ เช่น
ถึงแม้ว่าผู้พัฒนาฟอนต์อยากจะทำฟอนต์แบบ OpenType แต่ถ้า Windows
ยังไม่สนับสนุน ก็ไม่เกิดประโยชน์อันใด (และถ้า Windows แต่ละรุ่นห่างกัน
5 ปีแบบที่ผ่านมา ก็รอกันนาน) การพัฒนาเลยสะเปะสะปะพอสมควร
หมายเหตุ: ปัญหาย่อยอีกข้อสำหรับเรื่องมาตรฐานภาษาไทย
คือเอกสารส่วนใหญ่มักมีแต่ภาษาไทย
แต่คนทำซอฟต์แวร์ระดับโอเอสส่วนมากเป็นฝรั่ง!
(ผมยืนยันได้ว่าคนทำภาษาไทยใน OS X เป็นฝรั่งและเป็นผู้หญิง)
ซึ่งสุดท้ายลงเอยด้วยฝรั่งเดาเอาเองตามมีตามเกิด (เช่น อาจถามเพื่อนคนไทย
ซึ่งไม่ใช่ผู้เชี่ยวชาญด้านระบบคอมพิวเตอร์ภาษาไทย)
คือถ้ามีเอกสารอย่างเป็นทางการจากหน่วยงานรัฐ และเป็นภาษาอังกฤษอ่านออก
ผู้ผลิตกลุ่มนี้ยินดีจะปฏิบัติตาม (ส่วนมากเป็นนโยบายของบริษัทเลย)
ข้อเสนอของผม
1. หาเจ้าภาพในการสังคายนามาตรฐานภาษาไทยบนคอมพิวเตอร์ให้เป็นปัจจุบัน
(ข้อนี้เหมือนจะยากสุด) และแน่นอนเอกสารฉบับจริงต้องมีเวอร์ชันภาษาอังกฤษ
2. เรียกประชุมผู้ผลิตซอฟต์แวร์รายใหญ่ (IBM, Microsoft, Apple)
สำหรับเรื่องนี้
และมีการทำงานอย่างใกล้ชิดเพื่อการันตีว่าระบบภาษาไทยเวอร์ชันใหม่
จะเข้าไปอยู่ในซอฟต์แวร์เวอร์ชันถัดไป จ้างได้ก็ต้องจ้าง (ของ OpenOffice
นั้น SIPA **จ้าง** Sun เพื่อแก้ปัญหาภาษาไทยให้ได้ตามต้องการ
โดยในสัญญามีระบุว่าต้องการันตีการ checkin เข้าต้นน้ำ) อย่างในกรณีของ
IBM/Microsoft นั้นมีสำนักงานในเมืองไทย (และมี government sector VP
โดยเฉพาะ) ไม่ใช่เรื่องยาก แต่ของ Apple กับ Adobe ผมไม่มีข้อมูล
สรุปสั้นๆ ว่าที่เป็นอยู่นี้ทั้งหมดเพราะไม่มีเจ้าภาพนั่นเองครับ
ส่วนจะหาเจ้าภาพอย่างไรผมก็ตอบไม่ได้เหมือนกัน
Trin Tantsetthi
เรื่องของ วทท.2.0 นั้น ได้ยินมาเหมือนกันว่ามีปัญหา บางจุดในตารางมีความผิดพลาดในการพิมพ์ หรือพลาดไปจริงๆ และตรวจไม่พบในตอนนั้น แต่ก็ไม่เห็นรายละเอียดนะครับ เรื่องนี้ผ่านมานานสิบกว่าปีแล้ว และผมไม่มีเอกสารใดๆเก็บไว้ ทิ้งไว้ที่บริษัทเก่า
วทท.2.0 เป็นมาตรฐานเรื่อง input method/output method ที่จริงแล้วมี 3 โหมด เท่าที่เห็นปรากฏว่าไม่มีใครเลยที่ทำครบ บริษัทคอมพิวเตอร์นำเอาโหมด 2 ไปใช้กันอย่างแพร่หลาย ลักษณะของโหมด 2 มี "incident table" เป็นลักษณะพิเศษ ซึ่งตรวจทานกับพจนานุกรมฉบับราชบัณฑิตยสถาน ปี 2525 "ด้วยคน" (เนื่องจากไม่มี online corpus) แล้วไม่พบสิ่งที่โหมด 2 ไม่สามารถจัดการได้
incident table เป็นตารางสองมิติ ที่แสดงความสัมพันธ์จะหว่าง "อักขระตัวนำ" กับ "อักขระตัวตาม" ว่าจะรับตัวตามหรือไม่ ประเด็นใหญ่ของ incident table เพื่อแสดงกรณีที่เป็นไปได้ในภาษาไทยที่ใช้กันอยู่ในชีวิตประจำวัน เมื่อสิบกว่าปีก่อน แป้นพิมพ์มีคุณภาพดีมาก กดครั้งเดียวมักจะแถมอักขระมาให้ด้วย ถ้าปล่อยผ่านไม่ทำอะไรเลย จะเกิดปัญหากับ text matching ไม่สนุกแน่ถ้าค้นฐานข้อมูล แล้วไม่เจอระเบียนที่รู้ว่ามีอยู่แน่ๆ เนื่องจากตอนป้อนข้อมูลหรือตอนค้นหา พิมพ์วรรณยุกต์หรือสระลอยเบิ้ลไปแล้วมองไม่เห็นว่าเบิ้ล
โหมด 2 ไม่ใช้กับภาษาถิ่นที่ใช้อักขระไทย หรือกรณีพิเศษทางภาษาศาสตร์ (ที่ไม่พบแบบเรียนทั่วไปหรือหนังสือที่วางจำหน่ายในตลาด) ในสองกรณีหลังควรจะเลี่ยงไปใช้โหมด 0 ซึ่งเปิดให้อักขระอะไรตามอักขระอะไรก็ได้
การเรียงลำดับคำ มาจากพจนานุกรมปี 2525 ในขณะนั้น POSIX locale ไม่เก่งพอที่จะเรียงลำดับคำไทย ไม่มีข้อตกลง(นอกจากใช้เรียงตามแบบพจนานุกรม) ไม่มี library มาตรฐานที่จะเรียงลำดับคำไทย มีหลายบริษัทที่อ้างว่าทำได้ แต่ก็ไม่ได้เปิดเผยหลักการ/วิธีการ แม้มีงานวิจัยที่เปิดเผยสู่สาธารณะ เมื่อทดสอบดูแล้ว ก็ยังมีที่ไม่ตรง จึงเป็นเรื่องที่ไม่ได้สรุปไว้อย่างชัดเจน
ได้รับแจ้งว่า วทท.2.0 ได้ประกาศเป็นมาตรฐานอุตสาหกรรมไปแล้ว (ประกาศในราชกิจจานุเบกษาด้วย) ไม่รู้ว่าเมื่อไหร่ จนบัดนี้ ก็ยังไม่เห็นตัวมาตรฐานที่ประกาศไปครับ
เชื่อว่าต้นเรื่องและเจ้าภาพ ควรจะเป็นคณะกรรมการวิชาการคณะที่ 536 (กว.536) ของ สมอ. ซึ่ง กว.536 สามารถระดมสรรพกำลังจากทั้งรัฐและเอกชนได้ ถ้ามีเจ้าภาพรายใดเสนอตัว เชื่อว่า กว.536 จะเป็นผู้พิจารณาก่อนเสนอเลขาธิการ สมอ. เสนอ รมต. เพื่อประกาศใช้
อีกเรื่องที่อยากฝากไว้ คือต้องแยกให้ออกระหว่าง coded character set (รหัสอักขระ) กับ font encoding สองอย่างนี้ดูเหมือนๆกัน แต่แตกต่าง
coded character set เป็นส่วนที่เล็กที่สุด (atomic unit) ของอักขระที่คอมพิวเตอร์เข้าใจ ทาง Unicode มีศัพท์อีกคำ เรียกว่า canonical form ใช้รูป U+xxxx โดย xxxx เป็นรหัส 16 บิต สำหรับ plane 0 (UTF-8/UTF-16/UTF-32 เป็น encoding forms จึงมีความยาวไม่เท่ากันในแต่ละกลุ่มอักขระ)
ส่วน font encoding นั้น เป็นรหัสแบบ "private agreement" ระหว่างฟอนต์กับระบบปฏิบัติการ ฟอนต์ที่ใช้ในระบบปฏิบัติการหนึ่งจึงไม่แน่ว่าจะใช้ในระบบปฏิบัติการอื่นได้ดี จะเห็นฟอนต์ไทยบางตัวแม้มีการวางตำแหน่ง "สระลอย" ไม่ให้ลอย แต่ระบบปฏิบัติการ (ส่วน rendering engine หรือ output method) ไม่ได้ใช้เพราะไม่รู้ว่ามี หรือว่าใช้อย่างไร ปัญหานี้ ไม่ได้มีเฉพาะภาษาไทยเท่านั้น
ตฤณ
Trin Tantsetthi
ผมอยากจะลาออกจาก กว.536 -- จึงอยากฝากการปรับปรุงมาตรฐานไว้กับคนรุ่นหลังด้วย
- xim ถ้ามาจาก DEC เข้าใจว่าหน่วยวิจัยในญี่ปุ่นเป็นคนเริ่มทำมาตั้งแต่ X11R2 หรือ R3 ประมาณนั้นนะครับ X11 ดึกดำบรรพ์รับแต่ ASCII จึงต้องมี widget พิเศษมาจัดการ string encoding และด้วยวิธีการของ x11 ซึ่งใช้ plane switching เราจึงจดทะเบียน มอก.620 กับ ECMA (นายทะเบียนในเวลานั้น) ออกมาเป็น ISO-IR-166 ได้ charset designator ออกมา และเปิดช่องให้ใช้ใน x11 ได้
- OpenType หรือมาตรฐาน font ต่างๆ พยายามจะทำ hinting ที่ฉลาดขึ้น แต่ผมก็ไม่รู้ว่าจะได้แค่ไหนนะครับ เคยดูเรื่อง legature/hinting ใน pdf นานมาแล้ว ปรากฏว่าเพื่อที่จะแก้ปัญหาสระลอยจะทำให้ตารางใหญ่มาก
- ญ ฐ ทั้งที่มีเชิงและไม่มีเชิง เป็นอักขระตัวเดียวกัน ใช้ code point เดียวกัน การเขียนพร้อมเชิงหรือจะตัดเชิงออก เป็นเรื่องของ output method ครับ ถ้าระบบปฏิบัติการเปลี่ยนไปใช้รูป (glyph) อื่นในฟอนต์ ก็เป็นที่ระบบปฏิบัติการ (หรือ rendering widget) เอง -- charset/string encoding สำหรับ data interchange ยังเป็นเหมือนเดิมครับ
ตฤณ
ผมไม่แน่ใจว่ามีสิทธิ์โพสต์ใน googlegroups ที่กำลังคุยกันหรือเปล่านะครับ
แต่เนื่องจากถูก Cc: ถึง ก็เลยขอแสดงความเห็นเพิ่มเติม
ไม่ทราบว่าต้นเรื่องคือเรื่องอะไร แต่ดูเหมือนประเด็นที่สนทนาจะเป็นเรื่อง
มาตรฐานภาษาไทยในคอมพิวเตอร์กับการ implement
ผมขอแยกเป็นเรื่อง output method, input method แล้วก็ วทท นะครับ
* Output Method
ผมคิดว่าแนวโน้มของ output method คงจะไปทาง OpenType กัน
(graphite ของ SIL ถึงจะมีแนวคิดที่ดี แต่ส่วนแบ่งตลาดยังน้อยมาก)
โดยโลกตะวันตกเขาทึกทักกันแล้ว ว่า OS ปัจจุบันนี้รองรับ OpenType
อย่างสมบูรณ์ทั้งหมด จนคิดเลยเถิดถึงกับนึกไม่ออกเอาเลย ว่าภาษาไทยเรา
จะมีปัญหากับ OpenType ได้ยังไง
แต่ปัญหาคือ.. เรายังมีปัญหากับบาง app ที่การรองรับ OpenType
ยังพิกลพิการอยู่ โดยหลัก ๆ ที่พบคือ Mac OSX กับ Adobe ส่วน
Microsoft นั้น เขาเป็นเจ้าของเทคโนโลยีอยู่ แม้แต่ Adobe ที่ทำ spec
ร่วมกัน ปัจจุบันก็ยังชี้เอกสารอ้างอิงไปที่ Microsoft ดังนั้น การ implement
ของ Microsoft เลยไม่น่าเป็นห่วง ยกเว้นเรื่องการไม่มีตัวอย่างฟอนต์
OpenType ภาษาไทยให้นักพัฒนาฟอนต์ได้ใช้เป็นแบบอย่าง หรือให้
vendor อื่นได้ใช้ทดสอบ rendering engine ของตน
พูดสั้น ๆ คือ Microsoft นั้น infrastructure พร้อม แต่ไม่มี content
สำหรับฟอนต์ OpenType ไทย
อย่างไรก็ดี ถ้า OpenType ถูกใช้เต็มที่ ปัญหาการแยก character
encoding กับ font encoding ที่คุณตฤณเป็นห่วง ก็อาจจะหมดไป
เพราะข้อมูลเรื่องการใช้ glyph code ต่าง ๆ ได้ย้ายเข้าไปอยู่ในตัวฟอนต์
ทั้งหมด โดยทำงานผ่าน GSUB rules ในฟอนต์ ไม่ต้องให้ rendering
engine มาละลาบละล้วงข้อมูลภายใน แต่ตราบใดที่ Microsoft ยังไม่ทำ
ฟอนต์ OpenType ภาษาไทยออกมา ปัญหาการแบ่งแยก character/font
encoding ก็ยังคงมีต่อไป ในเมื่อ rendering engine ต่าง ๆ ยังคงต้อง
รองรับ "legacy font" ต่าง ๆ ที่มีอยู่ใน Windows อยู่
* Input Method
ประเด็นเรื่อง input method นั้น open source solution ต่าง ๆ
ที่ออกมา ก็พยายาม implement วทท ทั้ง 3 ระดับนะครับ เช่น XIM
ใน X11R6 (อันนี้ยังไม่ทราบว่าเป็นผลงานของใครทำไว้ ทราบแต่ว่า
Copyright เป็นของ DEC), scim-thai ที่ใช้ libthai เป็นฐาน
แต่บางตัว เช่น gtk-im-libthai ยังไม่มี user interface ให้เลือก
level จึงยังคงใช้ level 1 (BasicCheck) เป็นค่า default
ส่วน proprietary solution ส่วนใหญ่ในตลาด คิดว่าคงมีแต่ level 1
ตามที่คุณตฤณชี้ครับ ยกเว้น Solaris ที่มีครบทั้ง 3 ระดับ
* วทท
ผมคิดว่ามีประเด็นที่ควรเพิ่มคือ
1. การรองรับภาษาชนกลุ่มน้อยที่ใช้อักษรไทย เช่น ภาษากุยของชาวส่วย
(ผมก็รู้แค่ภาษานี้แหละครับ แหะ ๆ แต่ผู้เชี่ยวชาญจาก SIL เคยพูดถึง
ภาษาอื่นด้วย ซึ่งผมไม่มีข้อมูล) ประเด็นนี้เกี่ยวพันกับการ render
ด้วยครับ ไม่ใช่แค่ input method เนื่องจาก วทท กำหนดให้ใช้ตาราง
ร่วมกันระหว่าง input/output method
2. การขยายให้รองรับภาษาลาว โดยในการ implement ภาษาลาวใน
GTK+/Pango นั้น ผมพบว่า แม้จะคล้ายภาษาไทยมาก แต่ภาษาลาว
ก็ยังมีจุดเล็ก ๆ ที่แตกต่างจากภาษาไทย ทำให้ต้องเพิ่ม character class
พิเศษ (รายละเอียดต้องไปแกะจาก source ที่ทำไว้อีกที)
สำหรับมาตรฐานอุตสาหกรรมของ วทท 2.0 ผมค้นที่เว็บ สมอ. ได้ความว่า
เป็น มอก. 1566-2541 (อักขรวิธีภาษาไทยสำหรับคอมพิวเตอร์) ครับ
(ความจริงเคยทราบและเคยเห็นตัวเล่มมาก่อนเหมือนกัน แต่จำไม่ได้ว่า
ไปจดหมายเลขไว้ที่ไหน เลยต้องค้นใหม่)
และตามที่คุณตฤณชี้ไว้นะครับ ว่า วทท เป็นเรื่อง input/output เท่านั้น
ไม่เกี่ยวกับการเรียงลำดับคำหรือตัดคำ ซึ่งสองเรื่องนี้ โดยเฉพาะเรื่อง
การเรียงลำดับคำ ไม่ทราบว่าจะกำหนดเป็นมาตรฐานที่ละเอียดกว่า
พจนานุกรมได้หรือไม่ เช่น ลำดับของเครื่องหมายวรรคตอนต่าง ๆ
(ปัจจุบันที่อาจจะใกล้เคียงความเป็นมาตรฐานที่สุดคือ Annex หนึ่ง
ใน ISO/IEC 14651 ครับ --จำหมายเลข Annex ไม่ได้เหมือนกัน)
อีกประเด็นย่อยที่ผมยังคงหาคำตอบดี ๆ ไม่พบ คือการใช้ ญ ฐ ที่ไม่มีเชิง
ในภาษาบาลี-สันสกฤตครับ ทราบมาว่า OpenType สามารถกำหนด rule
จัดการได้ แต่ดูเหมือนจะต้องอาศัยการ mark ภาษาใน text ด้วย ซึ่งก็ยัง
ไม่ทราบว่าวิธี mark ต้องทำยังไง
เทพ.
--
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/
2008/4/7 Trin Tantsetthi <tants...@gmail.com>:
Arthit Suriyawongkul
ทีมพัฒนาเรื่องพวกนี้ ไม่ว่าจะบริษัทไหน
จะเรียกหาเอกสารมาตรฐานก่อน
เช่น มอก.620 สำหรับ encoding
มอก.820 สำหรับผังแป้นพิมพ์
วทท 2.0 สำหรับการป้อนเข้าและการแสดงผล
อะไรที่ไม่ได้อยู่ในเอกสาร จะคุยลำบากมาก
คือ คนพัฒนาเขาไม่เข้าใจภาษาไทยทั้งหมด (ไม่ว่าคนไทยหรือไม่ไทย ก็เป็นกันได้)
แต่คนพัฒนาเข้าใจอัลกอริธึมเข้าใจกฎ ถ้ามีกฎให้เดินตาม ก็ไม่มีปัญหา
อะไรที่ไม่ได้อยู่ในเอกสารจะทำให้มีลำบากมาก
แม้เราจะยืนยันว่า ที่ถูกมันต้องเป็นแบบนี้ ไม่ใช่ตามเอกสาร
(เช่นกรณีของผังแป้นพิมพ์ไทย ที่ทีมพัฒนาที่เคยทำงานด้วย
จะทำตาม มอก.820 อย่างเดียว แต่ปรากฎว่า แป้นพิมพ์ไทยที่ขาย ๆ กันอยู่ทั่วไป
ตัวอักษรที่เขาสกรีนบนปุ่ม มันไม่ได้ตามนั้น เช่นตำแหน่ง ฃ.ฃวด ฅ.ฅน มันสลับกัน
ก็ต้องถ่ายรูปไปให้เขาดูเลย เฮ้ย ของจริงมันเป็นแบบนี้ว่ะ กี่อัน ๆ ก็เป็นแบบนี้
ช่วยทำหน่อยเหอะ แม้มันจะไม่ได้อยู่ในเอกสารก็เถอะนะ เขาถึงจะยอม)
เรื่องการเรียงลำดับ ถ้าผมจำไม่ผิด วทท. ไม่ได้ระบุ
ที่ผ่านมาสำหรับผม เวลามีคนถาม ก็จะให้ยึดเอกสารที่พี่เทพเขียนเอาไว้ (ภาษาอังกฤษ)
http://linux.thai.net/~thep/
แต่เรื่องเรียงลำดับนี้ ก็เป็นเรื่องที่ Unicode ครอบคลุมด้วย
(ซึ่งเกี่ยวเนื่องกับเรื่อง normalization ด้วย)
แล้ว Unicode ก็มีเรื่องตัดคำ เรื่องอะไรครอบคลุมเยอะมาก
เพราะฉะนั้นทุกวันนี้ นักพัฒนาก็จะยึด Unicode มากกว่า
ถึงเราจะมีเอกสารมาตรฐานอะไรของท้องถิ่น
แต่ถ้ามันขัดกับ Unicode ก็จะถูกตั้งข้อสงสัย อะไรประมาณนี้
สรุปคือ ถ้าไม่มีเอกสารมาตรฐานก็จะลำบาก
และถ้าจะให้ลื่นสุดตอนนี้ ก็คือต้องยัดให้มันลง Unicode ให้ได้
(ซึ่งจะเอาไปยัดได้ ก็จะมีขั้นตอน ซึ่งหลายครั้งเขาก็เรียกหาเอกสารมาตรฐานด้วย)
Arthit Suriyawongkul
--
:: "เอกราช ปลอดภัย เศรษฐกิจ
:: เสมอภาค เสรีภาพ การศึกษา"
:: -- หลัก 6 ประการของคณะราษฎร
:: http://tinyurl.com/34klvq
Arthit Suriyawongkul
> เดียวกัน การเขียนพร้อมเชิงหรือจะตัดเชิงออก เป็นเรื่องของ
> output method ครับ ถ้าระบบปฏิบัติการเปลี่ยนไปใช้รูป (glyph)
กรณีของภาษาไทยปัจจุบันใช่ครับ
แต่ผมไม่แน่ใจกรณีภาษาเก่า เพราะเคยอ่านมาว่า
เชิงของ ญ นั้น เป็นการลดรูปมาจากตัวอักษรอื่น เลยไม่แน่ใจว่า
สำหรับเอกสารภาษาเก่า (ที่อาจไม่ใช่ภาษาไทย)
ญ แบบมีเชิง กับ ญ แบบไม่มีเชิง จะเท่ากันหรือไม่
(คือเราใช้ ตัวอักษรไทย เขียนภาษาอื่นที่ไม่ใช่ภาษาไทยด้วย)
thep:
> โดยเฉพาะเรื่อง การเรียงลำดับคำ
> ไม่ทราบว่าจะกำหนดเป็นมาตรฐานที่ละเอียดกว่า
> พจนานุกรมได้หรือไม่ เช่น ลำดับของเครื่องหมายวรรคตอนต่าง ๆ
> (ปัจจุบันที่อาจจะใกล้เคียงความเป็นมาตรฐานที่สุดคือ Annex หนึ่ง
> ใน ISO/IEC 14651 ครับ --จำหมายเลข Annex ไม่ได้เหมือนกัน)
สำหรับคนที่อยากดูนะครับ มีฉบับร่างอยู่ที่
http://software.thai.net/locale/locale/14651/n537e.pdf
Isriya Paireepairit
> ผมไม่แน่ใจว่ามีสิทธิ์โพสต์ใน googlegroups ที่กำลังคุยกันหรือเปล่านะครับ
> แต่เนื่องจากถูก Cc: ถึง ก็เลยขอแสดงความเห็นเพิ่มเติม
เรื่องสิทธิ์นั้นผม approve ให้ครับ ไม่ต้องเป็นห่วง
>
> ไม่ทราบว่าต้นเรื่องคือเรื่องอะไร แต่ดูเหมือนประเด็นที่สนทนาจะเป็นเรื่อง
> มาตรฐานภาษาไทยในคอมพิวเตอร์กับการ implement
ส่วนต้นเรื่องเผอิญว่า charset ในเมลมันเสีย ผมเลยลบไปทั้งหมด ขอโทษด้วยครับ
ที่มาคือคุณปกป้องได้ยกกระทู้ของ thaiadobeuser เรื่องสาเหตุที่ทาง Adobe
ไม่สนับสนุนภาษาไทยครับ แนบกระทู้เป็น PDF มาให้
fff.fun
ผมประสานงานส่งข้อมูลที่ได้ ไปยังคุณขจร
เผื่อเค้ามีอะไรเพิ่มเติม จะได้แลกเปลี่ยนกัน
ผม invite คุณขจร เข้า groups: youfest ด้วยแล้ว
น่าจะมีความเห็นเพิ่มเติมในเร็วๆ นี้
-----
ปกป้อง
> 2007-09-19.pdf>
Trin Tantsetthi
ขออนุญาตรวบรวมประเด็นหลักตามความเห็นของผมนะครับ
1. รหัสอักขระเป็นแก่นของภาษา ซึ่งจำเป็นต้องมีความเป็นอันหนึ่งอันเดียวกัน เพื่อที่ว่าจะแลกเปลี่ยนข้อมูล/ความคิดเห็นกันได้อย่างอิสระ
ประเด็นเรื่องเชิงของ bact' เป็นประเด็นที่น่าสนใจนะครับ ไม่แน่ใจเหมือนกันว่าอยู่ใน scope ของ มอก.620-2533 หรือไม่ แต่ถ้าต้องใช้ ก็ควรจะเป็น scope ของ Unicode ซึ่งเราต้องการนักภาษาศาสตร์ตัวจริง ที่จะสื่อสารกับนักภาษาศาสตร์ของ Unicode ตลอดกระบวนการการเพิ่มอักขระ หรือเพิ่มกลุ่มภาษา (เช่นอักขระล้านนา)
CJK Unification ดำเนินไปสิบปีนะครับ ทำใจไว้ก่อนเลยว่าไม่ง่ายครับ แต่ถ้าต้องใช้ ก็ต้องทำครับ
2. กรณีของฟอนต์ ด้วยข้อจำกัดที่ผู้สร้า่งแพล็ตฟอร์มหลักสมัยดั้งเดิมไม่เข้าใจ non latin-based script ใช้แต่ concept ที่อักขระสามารถบรรจุได้ในช่อง (bounding box) เท่านั้น; เมื่อชี้แจงไป แนวคิดที่แยก glyph ออกจาก character จึงได้รับการยอมรับมากขึ้น -- character ใช้สำหรับ interchange ส่วน glyph ใช้สำหรับแสดงผล ทั้งสองมักจะใช้รหัสเดียวกัน แต่ก็ไม่จำเป็น และห้ามเอามาปนกัน output method แปลง character เป็น glyph ได้โดยเลือกใช้ทรัพยากรในฟอนต์ที่รู้จัก
ถ้าเป็น ASCII/EBCDIC ง่ายมาก พอมาทางยุโรป เขาก็แก้ด้วยการเติม code point ที่รวมอักขระฐานกับ diacritical marks กลายเป็น 8-bit charsets เมื่อสิบห้าปีก่อนนั้น พอพูดถึง non-spacing character ก็งงกันไปทั้งโลก กลุ่ม "Combining Diacritical Marks" http://www.unicode.org/charts/symbols.html#CombiningDiacriticalMarks เป็นของค่อนข้างใหม่นะครับ เมื่อก่อนแค่บอกว่าจะมีตัวอักษร "รุก" เข้าไปใน bounding box ของอักขระที่เขียนไปแล้วนี่ เป็นเรื่องโกลาหลเลย
ดังนั้นสถานการณ์จึงเป็นแบบที่เทพบอก คือมี hack แปลกๆ ทั้ง kerning pair หรือการใช้ ligature
เรื่องยากสำหรับเมืองไทยคือ hack เหล่านี้ ได้นำไปใช้มานานแล้ว และยัง "ใช้ได้" จนปัจจุบัน ถ้าจะต้องเปลี่ยน จะใช้กำลังมาก
3. มองไปในอนาคต ผมเห็นว่า ISO-10646/Unicode มีโมเมนตัมมากกว่า เนื่องจากแก้แล้วแก้อีกได้ตรงจุดมากกว่า แต่ว่ามีเรื่องที่อาจจะกระทบการใช้คอมพิวเตอร์ในเมืองไทยอย่างใหญ่หลวง คือ phonetic encoding อาจกลับมาอีก
phonetic encoding เกิดขึ้นจากข้อเท็จจริงที่ว่านักภาษาศาสตร์ มักจัดภาษาไทยอยู่ในกลุ่มภาษาอินเดีย (indic) ซึ่งสามารถจะ nomalize ให้อยู่ในรูป พยัญชนะต้น สระ ตัวสะกด และ modifier ต่างๆ มีปัญหาพื้นฐานอยู่สองสามอย่างครับ
- ไม่มีโปรแกรมแปลง visual-order string (แบบที่เราใช้กันอยู่ในปัจจุบัน) ให้เป็น phonetic encoding และเปลี่ยนกลับได้สมบูรณ์
- code point assignment สำหรับ phonetic encoding ที่ Unicode เสนอมาประมาณปี 1990 ก็ไม่ครบ ไม่มีสระประสม อย่างคำว่า เรียน ใช้สระเอีย ถ้าพิมพ์ ร เ ี ย น (ร+{เ-ีย}+น) ปุ่มสระ {เ-ีย} ก็ไม่มีบนคีย์บอร์ด ดังนั้นจึงไม่สามารถ nomalize ให้อยู่ในโครงสร้างพยางค์ง่ายๆอยู่ดี -- หรือไม่เราก็ต้องหัดพิมพ์กันใหม่ เปลี่ยนคีย์บอร์ด (ปุ่มคีย์บอร์ดมาตรฐานไม่พอด้วย) และแก้ไขระบบปฏิบัติการกันอีกที
อนุ กว.536 ชุดที่ 2 ในยุคนั้น ไม่รับ phonetic encoding เพราะว่ามันเป็น half-baked solution แต่จะกระทบกับผู้ใช้ทั้งหมด ทุกคน โดยไม่มีทางออกอื่น ข้อมูลที่คีย์ไปแล้ว ต้องคีย์ใหม่ทั้งหมด ถ้าใครรับข้อเสนอนี้ไปทั้งดุ้น ถ้าไม่ใช่ ไม่รู้เรื่อง ไม่ได้คิด ก็คงเป็นพวกเลือดเย็นล่ะครับ ไม่ใช่ว่ามันไม่ดี แต่ว่ามันดีไม่พอต่างหาก เมื่อไหร่โลกจะเรียนรู้ว่าการทำได้ กับการทำได้ดีนี้ เป็นคนละเรื่องเลยนะ
4. ผมเห็นด้วยกับอาจารย์ทวีศักดิ์เป็นอย่างมาก ที่จะปรับปรุง วทท.3.0 ไปเลยครับ นอกจากสเป็คแล้ว คงจะต้องช่วยกันทำ library ขนาดเล็กที่ใช้ได้ในหลายแพล็ตฟอร์ม เป็น open source เพื่อที่จะได้ฝังตัวลงไปในระบบปฏิบัติการต่างๆ เพื่อที่ผู้ใช้ภาษาไทย จะได้สิ่งเดียวกันบนทุกแพล็ตฟอร์ม บางทีทำเฉพาะภาษาไทย แล้วทำ hook เข้ากับ linguistic library เป็น loadable module บนแต่ละแพล็ตฟอร์มก็ดีนะครับ; ICU ทำได้หมด แต่อ้วนไป
ตฤณ
> ผมอยากจะลาออกจาก กว.536 -- จึงอยากฝากการปรับปรุงมาตรฐานไว้กับคนรุ่นหลังด้วย
คนรุ่นหลังคงต้องช่วยกันรับไม้ต่อ.. แต่ยังไม่ทราบกระบวนการกำหนด
มาตรฐานดีเลยครับ อย่างเช่นการเสนอมาตรฐานใหม่กับ กว. 536
ก็ยังไม่ทราบว่าจะมีขั้นตอนยังไงบ้าง
> - xim ถ้ามาจาก DEC เข้าใจว่าหน่วยวิจัยในญี่ปุ่นเป็นคนเริ่มทำมาตั้งแต่ X11R2
> หรือ R3 ประมาณนั้นนะครับ X11 ดึกดำบรรพ์รับแต่ ASCII จึงต้องมี widget
> พิเศษมาจัดการ string encoding และด้วยวิธีการของ x11 ซึ่งใช้ plane switching
> เราจึงจดทะเบียน มอก.620 กับ ECMA (นายทะเบียนในเวลานั้น) ออกมาเป็น ISO-IR-166
> ได้ charset designator ออกมา และเปิดช่องให้ใช้ใน x11 ได้
พอมายุค unicode เลยขาดตัวเชื่อมโยง ทำให้ XIM เจ๊งไปพักหนึ่งเมื่อมี
patch จาก Mandrake มาเปลี่ยน XKB map ของไทยจาก Latin-1
ให้เป็น keysym ไทยแท้ ๆ แต่สุดท้ายก็ได้รับการซ่อมแซมแล้ว
> - OpenType หรือมาตรฐาน font ต่างๆ พยายามจะทำ hinting ที่ฉลาดขึ้น
> แต่ผมก็ไม่รู้ว่าจะได้แค่ไหนนะครับ เคยดูเรื่อง legature/hinting ใน pdf
> นานมาแล้ว ปรากฏว่าเพื่อที่จะแก้ปัญหาสระลอยจะทำให้ตารางใหญ่มาก
ตารางนั้นผมถือว่าเป็นวิธีที่ hack ครับ คือใช้ ligature ที่ไม่ได้ออกแบบไว้
สำหรับภาษาเรา แต่ด้วยความพิการของ platform ต่าง ๆ เช่น Mac OSX
และ Adobe ทำให้มันกลายเป็นวิธีเดียวที่จะทำให้ฟอนต์ใช้การได้ทุก
platform
บน platform ที่ OpenType สมบูรณ์หน่อย อย่าง Windows และ Linux
จะสามารถใช้ GSUB rule ในการแก้วรรณยุกต์ลอย รวมทั้งใช้ GPOS
anchor ในการหลบหาง ป ฝ ฟ ฬ ฎ ฏ ได้ ทำให้ลดจำนวนชุดของ
เครื่องหมายบน-ล่างลง ตาม spec ที่ Microsoft กำหนด [1] ซึ่งผมได้
เพิ่มรายละเอียดเป็นแนวทางสำหรับคนทำฟอนต์ [2] และได้ implement
แล้วในฟอนต์ชุด thaifonts-scalable [3]
[1] http://www.microsoft.com/typography/otfntdev/thaiot/default.htm
[2] http://linux.thai.net/~thep/th-otf/
[3] http://linux.thai.net/projects/thaifonts-scalable
แต่ปัญหาก็คือ ฟอนต์ที่ทำตาม spec นี้ จะใช้งานได้บน Windows และ
Linux เท่านั้น เนื่องจากการรองรับ OpenType ใน Mac OSX และ Adobe
ยังไม่สมบูรณ์ ทำให้การวางเครื่องหมายผิดพลาดไปหมด ซึ่งเรื่องนี้ ไม่ใช่
ปัญหาของฟอนต์เลย
แต่เรื่องทางเทคนิคอย่างนี้ คงอธิบายให้ผู้ใช้เข้าใจลำบาก สุดท้าย ฟอนต์
ที่ใช้วิธี hack แบบชั่วคราว จะมีการใช้งานแพร่หลายกว่า และคนทำฟอนต์
ก็เริ่มทำตามมากขึ้นเรื่อย ๆ (เข้าใจว่า ฟอนต์ที่ f0nt.com ทั้งหมด ใช้วิธีการนี้
ตามนายพลเทมเพลต)
ปัญหาคือ ถ้ามันกลายเป็น common practice แบบนี้:
- ผู้ผลิต platform ที่มีปัญหา จะรับรู้ปัญหาเมื่อไร ในเมื่อผู้ใช้ส่วนใหญ่
สบายใจกับ solution ที่มีอยู่? หรือจะต้องคาดหวังว่าผู้ใช้ภาษาอื่นที่ใกล้เคียง
กับเรา จะจริงจังกับความถูกต้องทางเทคนิคกว่าเรา (รวมทั้งมีส่วนแบ่งตลาด
ที่ไม่แพ้ของเรา) แล้วรายงานปัญหาไป?
- ในกรณีที่ผู้ผลิตแก้ปัญหาให้แล้ว common practice ที่มีอยู่ ก็คงจะ
ดำเนินต่อไปอีกระยะหนึ่ง ซึ่งจะยาวนานแค่ไหนก็ยังไม่ทราบได้
หรือผู้สร้างฟอนต์บางคน อาจจะต้องการให้ฟอนต์ใช้ได้กับระบบเก่าด้วย
กว่าที่ผู้สร้างฟอนต์จะมาทำฟอนต์ตาม spec จริง ๆ ก็คงอีกนาน
ตามความเห็นของผม ผู้ที่จะเริ่มคลายปมปัญหานี้ได้ดีที่สุด คือ Microsoft
เอง ด้วยการสร้างฟอนต์อ้างอิงขึ้นมา (อาจจะเสนอเข้าไปจากภายนอกก็
ตามแต่) จากนั้น platform ต่าง ๆ ก็จะได้มีวัตถุดิบในการทดสอบและแก้
ปัญหาต่อไป
ใจจริงผมอยากให้ opensource solution เป็นหัวหอกเหมือนกัน แต่ด้วย
ความนิยมที่ยังน้อย ผมเกรงว่าจะไม่มีผลสักเท่าไร
หรืออีกทางหนึ่งคือ ให้หน่วยงานรัฐช่วยผลักดัน โดยกำหนด spec มาตรฐาน
แล้วประสานงานกับผู้ผลิต platform ให้แก้ปัญหาต่าง ๆ
> - ญ ฐ ทั้งที่มีเชิงและไม่มีเชิง เป็นอักขระตัวเดียวกัน ใช้ code point
> เดียวกัน การเขียนพร้อมเชิงหรือจะตัดเชิงออก เป็นเรื่องของ output method ครับ
> ถ้าระบบปฏิบัติการเปลี่ยนไปใช้รูป (glyph) อื่นในฟอนต์ ก็เป็นที่ระบบปฏิบัติการ
> (หรือ rendering widget) เอง -- charset/string encoding สำหรับ data
> interchange ยังเป็นเหมือนเดิมครับ
ผมเห็นด้วยครับ ที่จะใช้ code point เดียวกัน แล้วอาศัย GSUB rule
ใน OpenType font ในการเลือก alternate glyph มาแสดงผล
เพียงแต่ว่า วิธีเลือก alternate glyph ก็มีได้หลายวิธี วิธีหนึ่งคือการ
mark up เอกสาร ว่าข้อความก้อนนี้เป็นภาษาบาลี ก้อนนี้เป็นภาษาไทย
แล้ว GSUB rule ที่จะมีผลก็จะแตกต่างกันไปตามภาษา ซึ่งผมเองก็ยัง
พยายามศึกษาความเป็นไปได้อยู่ ในส่วนของการ mark up
(ส่วนของฟอนต์นั้น ไม่มีปัญหาครับ)
แต่ก็ยังมีจุดโหว่อยู่ ว่าถ้าเป็น plain text ที่ไม่สามารถ mark up ได้ล่ะ?
หรือเป็นไปได้ไหมที่จะกำหนดวิธี encode พิเศษที่จะแยก ญ มีเชิง
กับไม่มีเชิงให้ต่างกันใน encoding เลย เช่น
- ใช้อักขระ variant selector ต่อท้าย
- ใช้อักขระจำพวก ZWJ + ZWNJ โดยใช้ trick ที่ว่า ZWJ จะ เปลี่ยนรูป ญ
ให้เสมือนมีสระล่างมาประสม แล้ว ZWNJ ก็เข้าไปสวมรอยเป็นอักขระ
ที่มาประสมนั้น
- กำหนดอักขระพิเศษเพิ่มเพื่อใช้ตัดเชิง ญ ฐ โดยเฉพาะ
- ฯลฯ
Isriya Paireepairit
> ไม่ทราบว่า youfest/blognone จะเป็น mailing list
> ที่เหมาะสมที่จะปรึกษาหารือกันเรื่องนี้หรือเปล่าครับ
> หากไม่ใช่ขอความกรุณาช่วยแนะนำสถานที่ที่เหมาะสมด้วย
> ผมเชื่อว่าเรื่องนี้เป็นประโยชน์ร่วมกันของทุกคน
> แต่ก็เกรงจะไม่ตรงวัตถุประสงค์เฉพาะของ group ทั้งสอง
> (ขอความเห็นผู้สร้าง/moderator ด้วยนะครับ)
ผมคิดว่า mailing list ของ Thai Linux/FOSS developers
(http://groups.google.com/group/thai-linux-foss-devel)
น่าจะใช้ได้หรือเปล่าครับ? จะได้ไม่ต้องสร้างกลุ่มใหม่
หรือถ้าคิดว่าไม่ตรงวัตถุประสงค์อีกเหมือนกัน เดี๋ยวผมสร้างกลุ่มใหม่ให้ครับ
Hugh/Thaweesak Koanantakool
ขอร่วมสนทนาด้วยคน เมื่อเช้า ผมได้รับ email จากคุณตฤณ
แล้วเข้ามาอ่านที่ youfest จากนั้นก็ลงสมัครเป็นสมาชิกเลย
วทท ๒ มันอายุมากแล้วครับ และระหว่างช่วงเวลาที่ผ่านมา
ในวงการก็ได้พัฒนาอะไรมาหลายอย่าง แต่ก็ไม่มีใครมีแรงผลักเข้า สมอ.
โชคดีที่คุณตฤณยังมีแรงผลัก ทำให้เรามี 8859-11 ออกมา และคุณเทพพิทักษ์
ได้เขียนออกมาหลายงาน ล้วนแล้วมีประโยชน์ทั้งสิ้น
และมีคนพัฒนาของดีๆออกมามากมาย ยังขาดเวทียกร่างมาตจรฐานอยู่
ผมขอเสนอให้ช่วยกันพัฒนา วทท. ๓ เพื่อให้แก้ไขจุดบกพร่องของ วทท.๒
ที่ทราบทั้งหมด และขยายงานให้รวมถึงสิ่งอื่นๆ นอกเหนือจาก "input/output
method and syntax" ที่เป็น scope ของ วทท.๒
ผมเห็นด้วยกับคุณตฤณ ที่อาจจะกำหนด scope ของ วทท. ๓ ให้ประกอบด้วย
- input/output method and syntax (วทท.๒ ที่มีการปรับปรุง)
- locale
- wordbreak
- sorting algorithm
- any additional characters? (มีความจำเป็นไหม?)
- phonetic mark-up (flexible accuracy) (sound aproximation -
soundex)<-----> (sound precision - text to speech)
- Thai lunar calendar conversion (ปฏิทิน ๑๐๐๐ ปี แปลง Julian Date เป็น
ข้างขึ้นข้างแรม) ?
- T9 input method
ผมแหย่ๆให้ทีเรื่องวิจัยออกมาหลายๆเรื่อง หากทะยอยทำ
ปัญหาง่ายๆก็น่าจะประกาศเป็น มอก.ได้ ภายใน ๑-๒ ปี
ส่วนโจทย์ที่ท้าทายเพิ่มเติม
ก็เป็นงานวิจัยที่อาจขอทุนมาให้นักวิจัยทำออกมาให้ใช้กัน
ท่านผู้ใดเห็นปัญหา น่าจะขอทุนเนคเทคมาวิจัย (เพื่อปล่อยเป็น public
domain) ได้
ผมยังไม่เคยไปเยี่ยมชม (http://groups.google.com/group/thai-linux-foss-
devel) แล้วจะเข้าไปอ่าน ผมเห็นว่างานช่วยกันเขียนเอกสารกลาง
ขนานกับการเขียน blog/discussion น่าจะทำบน wikidot เมื่อบ่ายวันนี้
ลองไปสร้างเล่นดู น่าใช้ดี ผมได้ชื่อhttp://wtt3.wikidot.com
ขณะนี้ยึดมาแล้ว ข้างในมีแต่โจทย์ ยังว่างๆอยู่ หากท่านผู้ใด
อยากไปทำงานในนั้น ขอเชิญได้เลยครับ ต้องการให้เน้นการพัฒนา วทท.๓
อย่างเดียวเลย อยากได้คนที่ active มาช่วยกันร่าง แล้วจะได้นำเสนอต่อ
public และส่งเข้า สมอ.ในอนาคต
เว็บนี้เปิดเสรีครับ สมัครเข้าเขียนได้เลย ไม่จำกัด ข้อเสียมีอย่างเดียว
มันอยู่ต้างประเทศเหมือน googlegroup
สวัสดีครับ
ทวีศักดิ์
On Apr 7, 5:55 pm, "Isriya Paireepairit" <markp...@gmail.com> wrote:
> 2008/4/7 Trin Tantsetthi <tantset...@gmail.com>:
Isriya Paireepairit
> devel) แล้วจะเข้าไปอ่าน ผมเห็นว่างานช่วยกันเขียนเอกสารกลาง
> ขนานกับการเขียน blog/discussion น่าจะทำบน wikidot เมื่อบ่ายวันนี้
> ลองไปสร้างเล่นดู น่าใช้ดี ผมได้ชื่อhttp://wtt3.wikidot.com
> ขณะนี้ยึดมาแล้ว ข้างในมีแต่โจทย์ ยังว่างๆอยู่ หากท่านผู้ใด
> อยากไปทำงานในนั้น ขอเชิญได้เลยครับ ต้องการให้เน้นการพัฒนา วทท.๓
> อย่างเดียวเลย อยากได้คนที่ active มาช่วยกันร่าง แล้วจะได้นำเสนอต่อ
> public และส่งเข้า สมอ.ในอนาคต
คิดว่า wikidot ที่อาจารย์เริ่มไว้ โอเคแล้วครับ
ส่วนสถานที่คุยกัน ไม่ทราบว่าพี่เทพเห็นยังไงครับ เรื่องใช้ thai-linux-foss-devel
Isriya Paireepairit
> > ส่วนสถานที่คุยกัน ไม่ทราบว่าพี่เทพเห็นยังไงครับ เรื่องใช้ thai-linux-foss-devel
>
งั้นสรุปว่าปิด thread ย้ายไปคุยกันต่อใน
http://groups.google.com/group/thai-linux-foss-devel นะครับ
เผื่อมีใครสนใจตามไปสมัคร