ลองส่งมาอีกทีครับ

จากที่มาร์คคุยมาเรื่อง
คุณขจร
นั่นอาจเป็นสาเหตุทำให้
เว็บเค้าสมัครยากก็เป็น
ได้
(แต่ไม่เกี่ยวกับหัวข้อ
ที่ผมส่งมานะครับ) :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 คนของ
เอเชีย

Thai language problem 2007-05-21.html 149K Download

Thai language problem 2007-09-19.html 155K Download

Thai language problem 2007-05-21.pdf 348K Download

Thai language problem 2007-09-19.pdf 337K Download

- - - - -
ปกป้อง

ผมขอตอบในนี้ละกันนะครับ ส่วนคุณปกป้องจะนำไปใช้ต่อยังไงก็ตามแต่เห็นสมควร

=================================
ผมอยากแยกปัญหาเรื่องภาษาไทยบนระบบคอมพิวเตอร์เป็น 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_i...

เอกสารชุดนี้ออกโดยเนคเทค (โดยมี ดร. ทวีศักดิ์ ผอ.
เนคเทคคนก่อนเป็นหัวหน้าทีม) ในช่วงต้น 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 ปีแบบที่ผ่านมา ก็รอกันนาน) การพัฒนาเลยสะเปะสะปะพอสมควร

หมายเหตุ: ปัญหาย่อยอีกข้อสำหรับเรื่องมาตรฐานภาษาไทย
คือเอกสารส่วนใหญ่มักมีแต่ภาษาไทย ...

read more »

ขอให้ข้อมูลเพิ่มเติมเนื่องจากเป็นหนึ่งในคนปรับปรุง วทท.1.0 เป็น วทท.2.0 ครับ

เรื่องของ วทท.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) ไม่ได้ใช้เพราะไม่รู้ว่ามี
หรือว่าใช้อย่างไร ปัญหานี้ ไม่ได้มีเฉพาะภาษาไทยเท่านั้น

ตฤณ

2008/4/7 Isriya Paireepairit <markp...@gmail.com>:

...

read more »

ขอบคุณเทพนะครับ

ผมอยากจะลาออกจาก กว.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 ยังเป็นเหมือนเดิมครับ

ตฤณ

2008/4/7 Theppitak Karoonboonyanan <t...@linux.thai.net>:

...

read more »

จากประสบการณ์ส่วนตัว
ทีมพัฒนาเรื่องพวกนี้ ไม่ว่าจะบริษัทไหน
จะเรียกหาเอกสารมาตรฐานก่อน
เช่น มอก.620 สำหรับ encoding
มอก.820 สำหรับผังแป้นพิมพ์
วทท 2.0 สำหรับการป้อนเข้าและการแสดงผล
อะไรที่ไม่ได้อยู่ในเอกสาร จะคุยลำบากมาก
คือ คนพัฒนาเขาไม่เข้าใจภาษาไทยทั้งหมด (ไม่ว่าคนไทยหรือไม่ไทย ก็เป็นกันได้)
แต่คนพัฒนาเข้าใจอัลกอริธึมเข้าใจกฎ ถ้ามีกฎให้เดินตาม ก็ไม่มีปัญหา
อะไรที่ไม่ได้อยู่ในเอกสารจะทำให้มีลำบากมาก
แม้เราจะยืนยันว่า ที่ถูกมันต้องเป็นแบบนี้ ไม่ใช่ตามเอกสาร
(เช่นกรณีของผังแป้นพิมพ์ไทย ที่ทีมพัฒนาที่เคยทำงานด้วย
จะทำตาม มอก.820 อย่างเดียว แต่ปรากฎว่า แป้นพิมพ์ไทยที่ขาย ๆ กันอยู่ทั่วไป
ตัวอักษรที่เขาสกรีนบนปุ่ม มันไม่ได้ตามนั้น เช่นตำแหน่ง ฃ.ฃวด ฅ.ฅน มันสลับกัน
ก็ต้องถ่ายรูปไปให้เขาดูเลย เฮ้ย ของจริงมันเป็นแบบนี้ว่ะ กี่อัน ๆ ก็เป็นแบบนี้
ช่วยทำหน่อยเหอะ แม้มันจะไม่ได้อยู่ในเอกสารก็เถอะนะ เขาถึงจะยอม)

เรื่องการเรียงลำดับ ถ้าผมจำไม่ผิด วทท. ไม่ได้ระบุ
ที่ผ่านมาสำหรับผม เวลามีคนถาม ก็จะให้ยึดเอกสารที่พี่เทพเขียนเอาไว้ (ภาษาอังกฤษ)
http://linux.thai.net/~thep/
แต่เรื่องเรียงลำดับนี้ ก็เป็นเรื่องที่ Unicode ครอบคลุมด้วย
(ซึ่งเกี่ยวเนื่องกับเรื่อง normalization ด้วย)
แล้ว Unicode ก็มีเรื่องตัดคำ เรื่องอะไรครอบคลุมเยอะมาก

เพราะฉะนั้นทุกวันนี้ นักพัฒนาก็จะยึด Unicode มากกว่า
ถึงเราจะมีเอกสารมาตรฐานอะไรของท้องถิ่น
แต่ถ้ามันขัดกับ Unicode ก็จะถูกตั้งข้อสงสัย อะไรประมาณนี้

สรุปคือ ถ้าไม่มีเอกสารมาตรฐานก็จะลำบาก
และถ้าจะให้ลื่นสุดตอนนี้ ก็คือต้องยัดให้มันลง Unicode ให้ได้
(ซึ่งจะเอาไปยัดได้ ก็จะมีขั้นตอน ซึ่งหลายครั้งเขาก็เรียกหาเอกสารมาตรฐานด้วย)

จากประสบการณ์ส่วนตัว
 ทีมพัฒนาเรื่องพวกนี้ ไม่ว่าจะบริษัทไหน
 จะเรียกหาเอกสารมาตรฐานก่อน
 เช่น มอก.620 สำหรับ encoding
 มอก.820 สำหรับผังแป้นพิมพ์
 วทท 2.0 สำหรับการป้อนเข้าและการแสดงผล
 อะไรที่ไม่ได้อยู่ในเอกสาร จะคุยลำบากมาก
 คือ คนพัฒนาเขาไม่เข้าใจภาษาไทยทั้งหมด (ไม่ว่าคนไทยหรือไม่ไทย ก็เป็นกันได้)
 แต่คนพัฒนาเข้าใจอัลกอริธึมเข้าใจกฎ ถ้ามีกฎให้เดินตาม ก็ไม่มีปัญหา
 อะไรที่ไม่ได้อยู่ในเอกสารจะทำให้มีลำบากมาก
 แม้เราจะยืนยันว่า ที่ถูกมันต้องเป็นแบบนี้ ไม่ใช่ตามเอกสาร
 (เช่นกรณีของผังแป้นพิมพ์ไทย ที่ทีมพัฒนาที่เคยทำงานด้วย
 จะทำตาม มอก.820 อย่างเดียว แต่ปรากฎว่า แป้นพิมพ์ไทยที่ขาย ๆ กันอยู่ทั่วไป
 ตัวอักษรที่เขาสกรีนบนปุ่ม มันไม่ได้ตามนั้น เช่นตำแหน่ง ฃ.ฃวด ฅ.ฅน มันสลับกัน
 ก็ต้องถ่ายรูปไปให้เขาดูเลย เฮ้ย ของจริงมันเป็นแบบนี้ว่ะ กี่อัน ๆ ก็เป็นแบบนี้
 ช่วยทำหน่อยเหอะ แม้มันจะไม่ได้อยู่ในเอกสารก็เถอะนะ เขาถึงจะยอม)

 เรื่องการเรียงลำดับ ถ้าผมจำไม่ผิด วทท. ไม่ได้ระบุ
 ที่ผ่านมาสำหรับผม เวลามีคนถาม ก็จะให้ยึดเอกสารที่พี่เทพเขียนเอาไว้ (ภาษาอังกฤษ)

http://linux.thai.net/~thep/

แต่เรื่องเรียงลำดับนี้ ก็เป็นเรื่องที่ Unicode ครอบคลุมด้วย
 (ซึ่งเกี่ยวเนื่องกับเรื่อง normalization ด้วย)
 แล้ว Unicode ก็มีเรื่องตัดคำ เรื่องอะไรครอบคลุมเยอะมาก

 เพราะฉะนั้นทุกวันนี้ นักพัฒนาก็จะยึด Unicode มากกว่า
 ถึงเราจะมีเอกสารมาตรฐานอะไรของท้องถิ่น
 แต่ถ้ามันขัดกับ Unicode ก็จะถูกตั้งข้อสงสัย อะไรประมาณนี้

 สรุปคือ ถ้าไม่มีเอกสารมาตรฐานก็จะลำบาก
 และถ้าจะให้ลื่นสุดตอนนี้ ก็คือต้องยัดให้มันลง Unicode ให้ได้
 (ซึ่งจะเอาไปยัดได้ ก็จะมีขั้นตอน ซึ่งหลายครั้งเขาก็เรียกหาเอกสารมาตรฐานด้วย)

--
:: "เอกราช ปลอดภัย เศรษฐกิจ
::  เสมอภาค เสรีภาพ การศึกษา"
:: -- หลัก 6 ประการของคณะราษฎร
:: http://tinyurl.com/34klvq

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

thep:

สำหรับคนที่อยากดูนะครับ มีฉบับร่างอยู่ที่
http://software.thai.net/locale/locale/14651/n537e.pdf

2008/4/7 Theppitak Karoonboonyanan <t...@linux.thai.net>:

เรื่องสิทธิ์นั้นผม approve ให้ครับ ไม่ต้องเป็นห่วง

ส่วนต้นเรื่องเผอิญว่า charset ในเมลมันเสีย ผมเลยลบไปทั้งหมด ขอโทษด้วยครับ

ที่มาคือคุณปกป้องได้ยกกระทู้ของ thaiadobeuser เรื่องสาเหตุที่ทาง Adobe
ไม่สนับสนุนภาษาไทยครับ แนบกระทู้เป็น PDF มาให้

Thai language problem 2007-05-21.pdf 348K Download

Thai language problem 2007-09-19.pdf 337K Download

ขอบคุณสำหรับข้อมูลเพิ่มเติมครับ

ผมประสานงานส่งข้อมูลที่ได้ ไปยังคุณขจร
เผื่อเค้ามีอะไรเพิ่มเติม จะได้แลกเปลี่ยนกัน

ผม invite คุณขจร เข้า groups: youfest ด้วยแล้ว

น่าจะมีความเห็นเพิ่มเติมในเร็วๆ นี้

-----
ปกป้อง

On Apr 7, 2008, at 1:49 PM, Isriya Paireepairit wrote:

ไม่ทราบว่า youfest/blognone จะเป็น mailing list
ที่เหมาะสมที่จะปรึกษาหารือกันเรื่องนี้หรือเปล่าครับ
หากไม่ใช่ขอความกรุณาช่วยแนะนำสถานที่ที่เหมาะสมด้วย
ผมเชื่อว่าเรื่องนี้เป็นประโยชน์ร่วมกันของทุกคน
แต่ก็เกรงจะไม่ตรงวัตถุประสงค์เฉพาะของ group ทั้งสอง
(ขอความเห็นผู้สร้าง/moderator ด้วยนะครับ)

ขออนุญาตรวบรวมประเด็นหลักตามความเห็นของผมนะครับ

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 ทำได้หมด แต่อ้วนไป

ตฤณ

2008/4/7 Theppitak Karoonboonyanan <t...@linux.thai.net>:

...

read more »

2008/4/7 Trin Tantsetthi <tantset...@gmail.com>:

ผมคิดว่า mailing list ของ Thai Linux/FOSS developers
(http://groups.google.com/group/thai-linux-foss-devel)
น่าจะใช้ได้หรือเปล่าครับ? จะได้ไม่ต้องสร้างกลุ่มใหม่

หรือถ้าคิดว่าไม่ตรงวัตถุประสงค์อีกเหมือนกัน เดี๋ยวผมสร้างกลุ่มใหม่ให้ครับ

สวัสดีครับ
ขอร่วมสนทนาด้วยคน  เมื่อเช้า ผมได้รับ 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:

คิดว่า wikidot ที่อาจารย์เริ่มไว้ โอเคแล้วครับ

ส่วนสถานที่คุยกัน ไม่ทราบว่าพี่เทพเห็นยังไงครับ เรื่องใช้ thai-linux-foss-devel

งั้นสรุปว่าปิด thread ย้ายไปคุยกันต่อใน
http://groups.google.com/group/thai-linux-foss-devel นะครับ
เผื่อมีใครสนใจตามไปสมัคร