Theppitak's blog

My personal blog.

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 ไว้ ก็อาจช่วยกระตุ้นเรื่องนี้ได้

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

16 กันยายน 2552

Academic Document Format

ตรวจคำแปลแบบมาราธอน 2 อาทิตย์เพิ่งเสร็จครับ เลยเขียนเรื่องนี้ช้าไปหน่อย

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

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

ความเปิดกว้าง

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

ในฐานะที่เคยอยู่ในทีม secretariat ของการประชุมวิชาการมาบ้าง ก็จะพบว่าในการประชุมที่รับเอกสารแบบ camera-ready เช่น Postscript หรือ PDF นั้น จะพบสัดส่วนของเอกสารที่เตรียมด้วย LaTeX สูงพอ ๆ กับที่ใช้ MS Word โดยอาจมีเครื่องมืออื่นแซมมาบ้างนิดหน่อย เช่น Pagemaker แต่ก็ไม่มาก

กรณีของ proceedings ที่รับ camera-ready นั้น อาจจะไม่ได้เคร่งครัดถึงขนาดนั่งลงทาบไม้บรรทัดวัด ขอเพียงใช้ฟอนต์ในตระกูลทั่วไปที่กำหนด (เช่น Times หรือ serif font ที่เทียบเคียง) ในขนาดที่กำหนด ความยาวไม่เกินที่กำหนด ก็น่าจะโอเคแล้ว แต่ถ้าเป็นกรณีของบัณฑิตวิทยาลัยที่ต้องการให้วิทยานิพนธ์ออกมาในรูปแบบเดียวกันหมด หรือต้องการนำไปประมวลผลอย่างอื่น ก็อาจต้องขอแฟ้มต้นฉบับเพิ่มเติมจาก camera-ready มาด้วย แต่การจำกัดอยู่เพียง MS Word อย่างเดียวนั้น น่าจะสุดโต่งเกินไป อย่างน้อยก็ควรเตรียมรองรับฟอร์แมตหลัก ๆ อย่าง LaTeX หรือ ODF ด้วย

ฟอนต์และการจัดหน้า

ประเด็นหนึ่งที่กระทู้พูดถึง คือการบังคับใช้ฟอนต์ Angsana เท่านั้น ซึ่งผมก็ยังสับสนอยู่ เพราะบางความเห็นก็บอกว่าให้ใช้ฟอนต์อื่นอย่าง Browallia, Eucrosia ฯลฯ ได้ แต่อย่างไรก็ดี รายชื่อที่แสดงมาทั้งหมดนั้น จัดจำหน่ายโดยผู้ผลิตเพียงเจ้าเดียว คือไมโครซอฟท์ และมีอยู่บนระบบปฏิบัติการเดียว คือวินโดวส์ ผมไม่แน่ใจว่า ในทางปฏิบัติแล้ว ถ้ามีใครใช้ฟอนต์อย่าง DB Narai หรือ Kinnari จะถูกตีกลับมาหรือเปล่า

เรื่องการบังคับฟอนต์แบบเจาะจงชื่อ รวมทั้งการบังคับกั้นหน้าซ้ายขวาอย่างละเอียดนี้ ความจริงเป็นประเด็นที่น่าจะเกิดมาพร้อมกับคำว่า WYSIWYG (What You See Is What You Get) เพราะในระบบอย่าง LaTeX นั้น จะแยก stylesheet ออกจากเนื้อหาอย่างเด็ดขาด ผู้เตรียมเอกสารมีหน้าที่แค่ป้อนเนื้อหาและใส่ markup ต่าง ๆ ไว้เท่านั้น ไม่จำเป็นต้องกังวลถึงฟอนต์และกั้นหน้าที่ใช้เลย และ stylesheet สามารถเปลี่ยนแปลงได้อย่างยืดหยุ่น เช่น สมมุติว่าผู้จัดพิมพ์ต้องการเปลี่ยนฟอนต์จาก serif เป็น sans serif และแปะตรามหาวิทยาลัยไว้ที่หัวกระดาษ ก็แค่เปลี่ยน stylesheet แล้วสั่ง typeset ใหม่โดยไม่จำเป็นต้องไปนั่งจัดหน้าเนื้อหาเอกสารต้นฉบับเลย

แนวคิดเรื่อง stylesheet นี้ ความจริงใน MS Word หรือ OO.o ก็มี โดยการกำหนด template มาล่วงหน้า จากนั้น ผู้ใช้ก็เพียงแต่เตรียมเอกสารโดยใช้ style ต่าง ๆ จาก template ถ้าผู้จัดพิมพ์ต้องการเปลี่ยนรูปเล่ม ก็เพียงแต่มาเปลี่ยน style ต่าง ๆ ใน template เท่านั้น เพียงแต่อาจต้องไล่ทำทีละเอกสาร เนื่องจากข้อมูล stylesheet จะฝังมาในทุกเอกสาร ไม่ใช่แยกต่างหากให้แก้เพียงที่เดียวได้เหมือน LaTeX

แต่ stylesheet ในเวิร์ดโพรเซสเซอร์แบบ WYSIWYG นั้น มีปัญหาในทางปฏิบัติ คือมันกลายเป็นแค่ออปชันหนึ่งที่ผู้ใช้ส่วนน้อยเท่านั้นที่จะใช้ จากการสังเกตพฤติกรรมการใช้เวิร์ดของผู้คนที่ผมพบ ส่วนใหญ่จะใช้เวิร์ดในฐานะของ กระดาษวาดรูป ไม่ใช่ เครื่องมือเตรียมเอกสาร เช่น ขึ้นหัวข้อใหม่ด้วยการป้ายกำหนดฟอนต์ตัวหนาขยายใหญ่ แทนที่จะกำหนด style เป็น Heading, ร่นย่อหน้าด้วยการเคาะ space bar แทนการกำหนด margin ที่ style ของย่อหน้า, เวลาลงท้ายจดหมายก็เคาะ space bar ดันข้อความไปด้านขวา เล็งให้บรรทัด "ขอแสดงความนับถือ" กับบรรทัดลงชื่อ เรียงกันกึ่งกลางพอดี แทนที่จะใช้วิธีกำหนด margin และ alignment ใน style ของย่อหน้า ฯลฯ เอกสารจึงขาดโครงสร้าง เวลาเปลี่ยนขนาดฟอนต์หรือขนาดกระดาษที ก็ต้องมานั่งจัดหน้าใหม่หมด จาก What You See Is What You Get ก็เลยกลายเป็น What You See Is All You Get แทน คือไม่ได้อะไรมากไปกว่าที่เห็นหรอก

นอกจากนี้ ยังมีรายละเอียดปลีกย่อยอย่างอื่นอีกที่อาจจะเฉพาะเจาะจงกับเอกสารวิชาการ เช่น การใช้ cross reference ในการอ้างถึงหัวข้ออื่นและบรรณานุกรม, การทำสารบัญและดัชนีในกรณีที่เป็นหนังสือ ฯลฯ

คนที่พูดว่าเวิร์ดใช้ง่ายนั้น ยังต้องแยกประเภทอีกครับ ว่าใช้เวิร์ดในฐานะเวิร์ดจริง ๆ หรือเปล่า

แม้แต่คนที่ใช้เวิร์ดเป็นจริง ๆ เอง ก็พลาดบ่อยครับ เช่น การตัดแปะเอกสารมาจากหน้าเว็บ มันจะติด style จาก HTML มาด้วย แล้ว WYSIWYG ก็จะ "อำนวยความสะดวก" ด้วยการเพิ่ม style ให้โดยอัตโนมัติ ทำให้เอกสารเกิด customized style ที่แปลกแยกจากส่วนอื่นของเอกสารขึ้นมาโดยไม่รู้ตัว ซึ่งตอนที่ผมโดนแบบนี้ ผมไม่ถือว่ามัน "อำนวยความสะดวก" ให้ผม แต่เรียกว่ามัน "สู่รู้" ครับ และวิธีที่ปลอดภัยที่สุดก็คือ ตัดแปะผ่าน plain text editor อีกที

เพราะ WYSIWYG มีปัญหาที่เอื้อให้ผู้ใช้ทำผิดพลาดต่าง ๆ ได้ง่ายนี่เอง ก็เลยเป็นที่มาของสงครามระหว่างนิสิตกับผู้ตรวจวิทยานิพนธ์ ฟอนต์ผิด ไม่ได้ขนาด ก็แก้ กั้นหน้าไม่ถูก ก็แก้ ร่นย่อหน้าไม่ได้ระยะ ก็แก้ และอื่น ๆ จุกจิกสารพัดจะแก้ ซึ่งถ้าใช้รูปแบบที่เป็น markup อย่าง LaTeX, HTML หรือ DocBook แล้ว ปัญหาจะไม่เยอะขนาดนี้ และบัณฑิตวิทยาลัยก็ไม่จำเป็นต้องบังคับฟอนต์ด้วย อยากได้ฟอนต์อะไร รูปหน้าแบบไหน ก็เปลี่ยนตอนจัดพิมพ์ได้เลย หรือถ้าให้นิสิตจัดพิมพ์เอง ก็เชื่อได้ว่าการจัดหน้าจะได้ตาม template เกือบทั้งหมด เพราะการที่จะเปลี่ยน style อะไรในเอกสาร markup นั้น จะยากและอาศัยความรู้ระดับลึก ผิดกับ WYSIWYG ที่วางกับดักล่อผู้ใช้ไว้แทบทุกส่วนของ UI

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

ไม่เอาละ LaTeX ใช้ยาก.. ไม่มี GUI.. มี LyX พอช่วยได้ครับ แล้วก็เครื่องมืออื่น ๆ อีกหลายอย่าง โดยเฉพาะบนวินโดวส์ มีเยอะเลย (ลองดู LaTeX for Fun and Profit ของคุณ Beamer User ด้วย) แต่เตือนไว้ก่อนว่าถ้าคุณยังคาดหวังว่ามันจะ WYSIWYG เหมือนตอนใช้เวิร์ดอยู่ คุณผิดหวังแน่นอน อย่าง LyX นั้น เขาเป็น WYSIWYM (What You See Is What You Mean) ครับ

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

ฟอร์แมตของแฟ้ม

พูดถึงฟอร์แมตของแฟ้ม เราจะมองง่าย ๆ เพียงว่าฟอร์แมตไหนมีโปรแกรมเปิดได้มากที่สุดเท่านั้นไม่ได้ แต่ต้องดูด้วยว่า ฟอร์แมตนั้นเปิดหรือไม่ เป็นมาตรฐานแค่ไหน

Word DOC

เป็นฟอร์แมตปิด ใช้เฉพาะสำหรับไมโครซอฟท์ออฟฟิศเป็นการภายในเท่านั้น เปรียบเทียบกับรูปภาพก็เหมือนไฟล์ .psd ของ Photoshop ยังไม่ใช่รูปแบบสำหรับเผยแพร่ทันทีอย่าง .jpg หรือ .png เพียงแต่บังเอิญว่ามีผู้ใช้ MS Office กันเยอะ จึงแลกเปลี่ยนกันจนกลายเป็นธรรมเนียมปฏิบัติ แล้วก็เลยบีบให้โปรแกรมค่ายอื่นจำเป็นต้องรองรับด้วยวิธี reverse engineering ซึ่งอาจได้รายละเอียดไม่ครบตามที่ MS Office เปิดเอง และแม้แต่ MS Office เอง แต่ละรุ่นก็ไม่ได้มีฟอร์แมตที่เหมือนกัน เมื่อรุ่นใหม่มีการเพิ่มความสามารถ ก็จะมีข้อมูลแบบใหม่ที่จะเปิดด้วยรุ่นเก่าไม่ได้

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

ฟอร์แมตที่ MS Office ออกแบบไว้สำหรับแลกเปลี่ยนจริง ๆ น่าจะเป็น RTF (Rich Text Format) ซึ่งจะมีฟีเจอร์ที่จำกัด (เช่น ไม่มีแมโคร—ซึ่งหมายถึงปลอดไวรัส) สามารถแลกเปลี่ยนข้ามรุ่นกันได้ หรือแม้แต่ข้ามแพลตฟอร์ม เพราะเนื้อหาจะเป็น markup text ที่รูปแบบคล้าย TeX ไม่ใช่ไบนารี แต่ปัญหาคือมีการใช้งานกันจริง ๆ แค่ในวงจำกัดเท่านั้น และเนื่องจากเอกสารที่ได้จะมีความแตกต่างอยู่บ้างระหว่าง .doc ต้นฉบับในบางกรณี ทำให้ไม่เป็นที่นิยม

ด้วยเหตุที่กล่าวมานี้ Word DOC จึงไม่ใช่ฟอร์แมตมาตรฐานแต่อย่างใด แม้แต่ใน MS Office ด้วยกันเอง ในแง่การแลกเปลี่ยนข้อมูลแล้ว RTF ยังเป็นตัวเลือกที่ปลอดภัยกว่า ถาวรกว่า อ่านได้กว้างขวางกว่า

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

LaTeX

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

LaTeX ไม่ได้เป็นมาตรฐาน ISO อะไร แต่อาศัยความเปิดของเครื่องมือและเอกสาร ทำให้มีปัญหาการข้ามแพลตฟอร์มน้อยกว่า Word DOC และความเป็นมาตรฐานของ LaTeX จะไปอยู่ที่รูปแบบของเอกสารที่เป็นผลลัพธ์มากกว่า โดยจะให้สมการคณิตศาสตร์ที่สวยงามถูกต้อง เป็นที่ยอมรับของสมาคมคณิตศาสตร์ต่าง ๆ รวมทั้งในสาขาอื่น ๆ ก็จะได้เอกสารที่ดูเป็นมืออาชีพ ด้วย stylesheet ที่จัดเตรียมโดยมืออาชีพ

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

OpenDocument (ODF)

เป็นฟอร์แมตเปิดที่พัฒนาโดยองค์กรกลางชื่อ OASIS โดยอิง XML และได้รับการรับรองเป็นมาตรฐาน ISO/IEC 26300:2006 โดยมี OO.o เป็นซอฟต์แวร์ตัวแรกที่รองรับ และมีแนวโน้มที่ซอฟต์แวร์ต่าง ๆ จะรองรับมากขึ้น

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

ปัญหาอีกเรื่องหนึ่งคือ ซอฟต์แวร์หลักที่รองรับในปัจจุบัน คือ OO.o นั้น มีขนาดใหญ่ และใช้ทรัพยากรของเครื่องสูงมาก แต่ก็เริ่มจะมีซอฟต์แวร์อื่น ๆ ที่เล็กกว่ามารองรับ ODF มากขึ้นเรื่อย ๆ หรือแม้กระทั่ง MS Office 2007 SP2 เอง ในแง่นี้ก็มองเห็นทางออกในทางเทคนิคได้

Office Open XML (OOXML)

เป็นการผลักดันจากไมโครซอฟท์เองที่จะให้เป็นฟอร์แมตเปิด และได้รับการรับรองให้เป็นมาตรฐาน ECMA-367 และ ISO/IEC 29500:2008 ในที่สุด ท่ามกลางข้อกังขาของหลาย ๆ ฝ่าย ในเรื่องการซุกซ่อนข้อกำหนดที่อ้างอิง implementation ภายในของ MS Office ไว้ เช่น กำหนดแอตทริบิวต์ว่า autoSpaceLikeWord95, footnoteLayoutLikeWW8, lineWrapLikeWord6, useWord97LineBreakRules ฯลฯ ซึ่งไม่มีมาตรฐานกลางที่ไหนเขาทำกัน เพราะมันเอื้อผู้ผลิตรายใดรายหนึ่งอย่างเห็นได้ชัด แต่ในที่สุด MS ก็เดินเกมล็อบบี้จนผ่าน

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

Portable Document Format (PDF)

เป็นฟอร์แมตเปิดที่สร้างโดย Adobe ที่เป็นมาตรฐานแบบ de facto มานาน ก่อนที่จะกลายเป็น ISO/IEC 32000-1:2008 ในที่สุด

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

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

สรุปแนวทาง

จากที่กล่าวมาทั้งหมด ก็พอสรุปแนวทางว่าอย่างนี้:

แนวทางที่ 1: camera-ready เท่านั้น

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

ประเด็นในทางปฏิบัติ:

  • การตรวจทาน เข้าใจว่าส่วนใหญ่ใช้วิธีตรวจทานผ่านกระดาษ แต่ถ้าจะใช้การ highlight และ annotation ก็มีเครื่องมือที่ทำได้สำหรับ PDF (สำหรับลินุกซ์ก็มี Xournal ส่วนบนวินโดวส์ก็มี Foxit Reader)
  • การสืบค้น มีเครื่องมือสำหรับแปลง PDF เป็น text อยู่บ้าง เช่น Xpdf หรือ Foxit แต่ก็ต้องยอมรับว่า PDF เป็นฟอร์แมตสำหรับจัดพิมพ์ ไม่ใช่สำหรับสืบค้น อาจได้ผลไม่เต็มร้อยสำหรับ PDF บางประเภท
  • การปรับเปลี่ยนแก้ไข ไม่สามารถทำได้โดยสะดวก โดยปกติวิทยานิพนธ์ก็จะพิมพ์ออกมาใหม่ได้ในรูปแบบเดิมนั่นเอง
แนวทางที่ 2: รับฟอร์แมตอื่นเพิ่ม

การรับฟอร์แมตอื่นเพิ่มนี้ ใช้สำหรับกรณีที่มหาวิทยาลัยต้องการที่จะสามารถปรับเปลี่ยนการจัดพิมพ์ หรือต้องการทำ full text search แบบเต็มร้อยกว่าใช้ PDF แต่ก็ไม่ใช่ว่าการเปิดรับจะต้องเปิดรับฟอร์แมตใดก็ได้ เพราะในทางปฏิบัติก็ต้องขึ้นอยู่กับความพร้อมของทางมหาวิทยาลัยเองด้วย ฟอร์แมตที่น่าพิจารณาเพิ่มเติมก็คือ:

  • OOXML น่าจะเป็น migration ที่ต้องทำอยู่แล้ว ถ้าจะรองรับผู้ใช้ MS Office 2007
  • ODF โดยผู้ใช้ MS Office 2007 ก็อาจส่งในรูปแบบนี้ได้ ผู้ใช้ OpenOffice.org บนวินโดวส์หรือลินุกซ์ก็จะสามารถเตรียมเอกสารได้ด้วยเครื่องมือที่โอเพนซอร์ส
  • LaTeX สำหรับแวดวงวิชาการส่วนหนึ่งที่นิยมรูปแบบเอกสารที่เป็นมืออาชีพ อาจารย์ที่ปรึกษาส่วนหนึ่งที่เคยทำวิทยานิพนธ์ด้วย LaTeX น่าจะสามารถให้คำปรึกษาได้ รองรับทั้งผู้ใช้วินโดวส์และลินุกซ์

เมื่อตัดสินใจเลือกแล้ว ก็อาจจะเตรียม template สำหรับแต่ละรูปแบบเอาไว้ เพื่อให้วิทยานิพนธ์ออกมาเป็นรูปแบบเดียวกัน

ประเด็นในทางปฏิบัติ:

  • การตรวจทาน สำหรับ DOC, OOXML, ODF สามารถใช้ annotation ในตัวโปรแกรมได้ ส่วน LaTeX ก็สามารถ highlight และ annotate บน PDF ได้ หรือจะ annotate บน PDF ทั้งหมดให้เหมือนกันก็ได้ หรือจะใช้กระดาษก็ไม่ผิดกติกา
  • การสืบค้น รูปแบบ OOXML, ODF, LaTeX เนื้อหาล้วนเป็นแฟ้มข้อความอยู่แล้ว (แม้ของ OOXML และ ODF จะต้องแตก zip ออกมาก่อน) สามารถทำ index ได้ไม่ยาก
  • การปรับเปลี่ยนแก้ไข ไม่มีปัญหา โดยเฉพาะ LaTeX ปัญหาอาจจะน้อยกว่า

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

12 กันยายน 2552

Thai Input Method

เนื่องในโอกาสที่วันนี้ Debian sid มีการ update xulrunner-1.9 เป็นรุ่น 1.9.0.14 (security fix) ทำให้ผมต้อง rebuild deb ของ xulrunner-1.9 เพื่อเพิ่มแพตช์เรื่องการตรวจแก้ลำดับการป้อนภาษาไทย ตามที่เสนอแพตช์ไว้ใน Mozilla #353776 เข้าไปใหม่ โดยเป็น ฉบับ backport เพื่อ upload เข้า debianclub โดยสั่ง build ทิ้งไว้แล้วไปทานข้าว ระหว่างทานข้าวก็เลยนึกถึงเรื่องที่เกี่ยวข้องขึ้นมา

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

ท่านเห็นว่า การตรวจลำดับนั้นสมควรอยู่ แต่การแก้ลำดับไม่ควรเป็นหน้าที่ของ input method แต่ควรให้ spell checker ทำ โดยเฉพาะอย่างยิ่ง การพยายามแก้ไขลำดับของคำว่า "น้ำ" ให้พิมพ์ "น + ไม้โท + สระอำ" หรือ "น + สระอำ + ไม้โท" ก็ได้นั้น เป็นการ spoil ผู้ใช้ ทำให้ผู้ใช้ไม่รู้ลำดับการพิมพ์ที่ถูกต้อง ซึ่งก็รวมถึงการแก้ลำดับของคำว่า "ที่" ที่พิมพ์เป็น "ท + ไม้เอก + สระอี" ให้ถูกต้องด้วย

ความเห็นนี้ เป็นความเห็นในฐานะนักพัฒนาส่วน localization และ standardization จึงเป็นความเห็นที่ควรให้ความสนใจอยู่ โดยเฉพาะเมื่อกรรมการ ISO และยูนิโค้ดชาวญี่ปุ่นที่นั่งฟังอยู่ด้วยแสดงความเห็นด้วยในเวลาต่อมา

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

ภาษาอย่างภาษาไทยเรานี้ ก็ไม่ได้มีเพื่อนเยอะนัก เพราะภาษาตระกูลอินเดียที่คล้ายกับเรา แม้กระทั่งพม่าและเขมรที่เป็นเพื่อนบ้านใกล้ชิด เขาก็ encode แบบที่เขาเรียกว่า "logical order" ไม่ใช่ "visual order" แบบภาษาไทยและลาวอยู่แล้ว input method ของเขาจึงต้องมีการจัดลำดับใหม่ จากลำดับพิมพ์ดีดปกติที่ผู้ใช้ป้อน (ซึ่งเป็น visual order) ให้เป็น logical order อยู่แล้ว การสลับลำดับของเขาจึงมีเหตุผลที่ต่างจากเรา มองไปมองมา ก็มีแต่ไทยกับลาวที่อยู่ในกลุ่มเดียวกัน และพอจะอ้างอิงเทียบเคียงกันได้

แต่มองในทางกลับกัน การไม่มีเพื่อนก็ทำให้เรามีอิสระที่จะกำหนดโดยไม่ขึ้นกับภาษาข้างเคียง (ยกเว้นลาว) ในฐานะที่เป็นตัวเขียนประเภท visual order ที่มี combining character ว่าเราจะใช้ความสามารถในการเข้าถึง text buffer ของ application นี้ ในการสลับลำดับให้ถูกต้องได้ โดยอาจจะแบ่งระดับของการรองรับ จากระดับ 0 คือไม่มีการตรวจลำดับเลย ระดับ 1 คือตรวจลำดับแบบชั่วคราวเท่านั้น (เลื่อนเคอร์เซอร์เมื่อไรเป็นเลิกตรวจ) ระดับ 2 คือตรวจลำดับตามบริบท (ตรวจเสมอแม้จะเลื่อนเคอร์เซอร์ไปที่ไหน) และระดับ 3 คือตรวจตามบริบทแล้วแก้ลำดับที่ผิดให้ด้วย

(ปัจจุบัน ถ้ามองตามนี้ Firefox ที่ทำงานในโลแคลอังกฤษ ไม่ว่าจะอย่างไรก็อยู่ที่ระดับ 0; ถ้าอยู่ในโลแคลไทย จะอยู่ระดับ 1 แต่ถ้าแพตช์ตาม Mozilla #353776 และทำงานในโลแคลไทย จะอยู่ที่ระดับ 3)

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

ประเด็นเหล่านี้ ได้ถูกหยิบยกขึ้นมาอภิปรายพอสมควรในการประชุมเพื่อร่าง วทท 3.0 เมื่อปีก่อน แม้เรื่องนี้จะเงียบไปนาน แต่ประเด็นต่าง ๆ ก็ยังคงวนเวียนอยู่ตามโครงการต่าง ๆ อย่างน้อย ๆ โมเดลการวาดภาษาไทยของยูนิโค้ดที่ต่างจาก วทท 2.0 ก็มาจากประเด็นเหล่านี้ด้วย โดยยูนิโค้ดมองอักษรไทยในฐานะอักษรที่ใช้เขียนภาษาทั่วไป ในขณะที่ วทท 2.0 มองเฉพาะการเขียนภาษาไทยเท่านั้น และปัจจุบัน การวาดภาษาไทยของ Qt ที่ต่างจาก GTK+/Pango ก็อยู่บนพื้นฐานของความแตกต่างของข้อกำหนดตรงนี้ด้วยเหมือนกัน โดย Qt จะอิงข้อกำหนดยูนิโค้ด ส่วน Pango จะอิง วทท 2.0

ล่าสุด ดูจะเข้ามาใกล้กันจนเกือบประสานกันแล้ว เมื่อ Behdad ประกาศว่า ได้ merge Harfbuzz-ng เข้าใน Pango master แล้ว โดย Harfbuzz เป็น OpenType layout engine สำหรับจัดเรียงอักขระ (shaping) เพื่อวาดข้อความ โดยเป็น โครงการใน freedesktop เพื่อใช้ร่วมกันระหว่าง GNOME และ KDE (ถ้าสนใจศึกษาหน้าที่และความสัมพันธ์ระหว่างส่วนต่าง ๆ มีบทความ State of Text Rendering ที่ Behdad เขียนไว้ อธิบายละเอียดครบถ้วนพอควร) วันที่ต้องพิจารณาชำระความแตกต่างระหว่าง Unicode และ วทท 2.0 ก็ใกล้เข้ามาทุกที

ในส่วนของ input method นั้น การตรวจลำดับอักขระ ถือได้ว่าเป็นการอำนวยความสะดวกให้กับผู้ใช้ภาษาไทย พร้อม ๆ กับเป็นการปิดกั้นผู้ใช้ภาษาอื่นที่เขียนด้วยอักษรไทยด้วย ยิ่งเป็น output method ที่ยึดอักขรวิธีไทยอย่างแนบแน่น ก็ยิ่งปิดโอกาสการใช้ภาษาที่ไม่ใช่ภาษาไทยไปเลย เรื่องนี้ หลังจากพูดคุยกันใน วทท 3.0 ข้อสรุปจะเป็นประมาณว่า input method จะต้องแยกตามโลแคล (อิง ภาษา โดยใช้ข้อกำหนด วทท 2.0 กับภาษาไทย และผ่อนคลายกับภาษาอื่น) ส่วน output method จะต้องวาดครอบจักรวาลได้ (อิง อักษร ตามแบบยูนิโค้ด)

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

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

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

hacker emblem