หนึ่งในปัญหาคลาสสิกของนักพัฒนาที่สร้างไฟล์เอกสาร .docx ผ่านโปรแกรมมิ่งไลบรารี (เช่น Open XML SDK, python-docx หรือ Apache POI) คือ เมื่อสั่งใช้สไตล์ตารางสำเร็จรูปผ่านแท็ก เช่น <w:tblStyle w:val="GridTable2-Accent1"/> ผลลัพธ์กลับแสดงผลได้สวยงามเฉพาะบน Microsoft Word เท่านั้น แต่เมื่อนำไฟล์เดียวกันไปเปิดบน Google Docs, LibreOffice Writer หรือ WPS Office หน้าตา สีสัน และเส้นกรอบกลับเพี้ยนไปคนละทิศทาง
เบื้องหลังปรากฏการณ์นี้ไม่ได้เกิดจากบั๊กของโค้ด แต่เกิดจากความคลุมเครือในข้อกำหนดมาตรฐานสากล และความแตกต่างของ Rendering Engine ในโปรแกรมแต่ละค่าย
ช่องว่างของมาตรฐาน ECMA-376 (OpenXML)
มาตรฐานเอกสาร ECMA-376 กำหนดสเปกของแท็ก <w:tblStyle> ไว้เพียงว่า “เป็นแอตทริบิวต์สำหรับอ้างอิงรหัสสไตล์ตาราง (Style ID)” แต่ ไม่ได้กำหนดมาตรฐานบังคับ (Strict Specification) ว่าสไตล์ชื่อ GridTable2-Accent1 จะต้องใช้ความหนาของเส้นกี่พอยต์ หรือต้องคำนวณสูตรผสมสี Tint/Shade อย่างไร
ทำให้รายละเอียดความสวยงามทั้งหมดกลายเป็นเรื่องของ Vendor Implementation (การตัดสินใจของผู้พัฒนาซอฟต์แวร์แต่ละราย) โดยสมบูรณ์
พฤติกรรมของแต่ละโปรแกรมเมื่อเจอ Style ID เดียวกัน
| โปรแกรม (Application) | ระดับการรองรับ Style ID ของ Word | พฤติกรรมการเรนเดอร์ (Rendering Behavior) |
|---|---|---|
| Microsoft Word (Desktop / Online) | สมบูรณ์ 100% (Native) | อ่าน Style ID ไปดึงเทมเพลตภายใน แล้วคำนวณสีร่วมกับ Document Theme อย่างสมบูรณ์แบบ |
| WPS Office | สูงมาก (~90–95%) | มีตารางแมปปิ้งเลียนแบบ Word แต่สูตรปัดเศษทศนิยมของ Tint/Shade ต่างกันเล็กน้อย ทำให้สีแถวสลับ (Banded Rows) อาจเข้มหรือสว่างต่างจาก Word |
| LibreOffice Writer | ปานกลาง (Fallback & Remap) | รู้จักเฉพาะ Core ID (เช่น TableGrid) แต่สไตล์กลุ่ม Accent จะถูกแปลง (Remap) เข้ากับสไตล์ตารางของ LibreOffice เอง ทำให้สีและกรอบเพี้ยนไปจากเดิม |
| Google Docs | ต่ำมาก (Ignored) | ไม่มีระบบ Themed Table Style ID ในตัว เมื่อเปิดไฟล์จะข้ามค่า Style ID และเรนเดอร์ตารางกลับมาเป็นตารางกริดเปล่าสีดำธรรมดา |
| Apple Pages | จำกัด (Import Conversion) | แปลงไฟล์ตอนนำเข้า (Import) โดยจะพยายามคำนวณสี ณ ขณะนั้นให้ออกมาเป็น Direct Style แต่เส้นตารางและระยะ Padding มักคลาดเคลื่อน |
เจาะลึกความแตกต่างในรายละเอียดเชิงเทคนิค
สไตล์พื้นฐาน: “ID เหมือนกัน แต่สเปกเริ่มต้นต่างกัน”
สำหรับรหัสสไตล์มาตรฐานอย่าง TableGrid หรือ TableNormal ที่ทุกโปรแกรมต่างรู้จัก แม้จะเปิดได้โดยไม่เออร์เรอร์ แต่หน้าตาก็ไม่เหมือนกัน 100%
- ระยะขอบเซลล์ (Cell Padding / Margin)
ระยะห่างเริ่มต้นระหว่างข้อความกับเส้นขอบใน Word คือ ซ้าย/ขวา 0.15 ซม. แต่ใน LibreOffice หรือ Pages อาจมีค่าเริ่มต้นที่กว้างกว่า ส่งผลให้ข้อความยาวๆ มีจุดตัดบรรทัด (Line Break) ไม่ตรงกัน - ความหนาและสีเส้น (Border Rendering)
บางโปรแกรมเรนเดอร์เส้นขอบด้วยขนาด 0.5 pt ในขณะที่บางโปรแกรมเรนเดอร์เป็น 0.75 pt หรือใช้สีดำทึบ#000000แทนที่จะเป็นเทาเข้มตาม Theme ปัจจุบัน
ตารางกลุ่มสีสัน: “ปัญหาขาดแคลน Color Palette Engine”
สไตล์ตารางแบบมีสี เช่น GridTable1Light-Accent1 ต้องพึ่งพาการทำงาน 2 ชั้น
- การค้นหาโครงสร้างเทมเพลตตาราง
- การดึงตัวแปรสีจาก Theme Palette (เช่น
accent1) มาผสมค่าความสว่าง (Tint / Shade)
โปรแกรมบนเว็บอย่าง Google Docs ไม่ได้ออกแบบมาให้อ่านระบบ Theme Color แบบไดนามิกของ OpenXML ตั้งแต่ต้น เมื่อระบบหาเอนจินคำนวณไม่พบ กลไกป้องกันความผิดพลาด (Fallback Mechanism) จึงเลือกที่จะเพิกเฉยต่อคำสั่งสไตล์ทั้งหมด เพื่อป้องกันไม่ให้เอกสารเปิดไม่ขึ้น
แนวทางแก้ไขสำหรับนักพัฒนา (Best Practices)
หากระบบของคุณจำเป็นต้องสร้างไฟล์เอกสารที่นำไปเปิดบนหลากหลายโปรแกรม โดยต้องการให้ความสวยงามคงเดิม 100% มีแนวทางแก้ปัญหาดังนี้
- กรณีใช้งานเฉพาะในองค์กรที่ใช้ Microsoft Word
สามารถใช้TableStyleผ่าน Built-in Style ID ต่อไปได้ เพราะช่วยให้ขนาดไฟล์เล็ก โค้ดสะอาด และผู้ใช้สามารถเปลี่ยน Theme สีทั้งเอกสารได้ง่าย - กรณีเอกสารต้องเปิดบน Google Docs, LibreOffice หรือแปลงเป็น PDF
ให้หลีกเลี่ยงการพึ่งพา Built-in Style ID เพียงอย่างเดียว และเปลี่ยนมาใช้ Direct Formatting (การฝังสีและเส้นลงระดับเซลล์) เช่น ระบุสีพื้นหลังด้วย<w:shd w:fill="0F6CBD"/>และกำหนดเส้นขอบผ่าน<w:tcBorders>ลงไปในทุกเซลล์โดยตรง แม้จะทำให้ไฟล์มีขนาดใหญ่ขึ้นเล็กน้อย แต่รับประกันว่าหน้าตาของตารางจะเหมือนกันในทุกแพลตฟอร์มอย่างแน่นอน