บทนำแบบอินเทอร์แอกทีฟสู่ประสบการณ์น่าทึ่งของการเรนเดอร์ตัวพิมพ์อาหรับและหนี้ทางเทคนิค

 (lr0.org)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ตัวพิมพ์อาหรับบนเว็บเป็น ปัญหาโครงสร้างพื้นฐานของการเรนเดอร์ ที่พัวพันทั้งการเชื่อมอักษร ข้อความสองทิศทาง การจัดการตัวเลขและเครื่องหมายวรรคตอน รวมถึงการจัดบรรทัด จึงยากจะมองเป็นแค่บั๊ก CSS ธรรมดา
  • การเรียงพิมพ์อาหรับแบบดั้งเดิมทำการจัดชิดขอบสองด้านด้วย kashida โดยยืดเส้นภายในตัวอักษร ไม่ใช่เพิ่มช่องว่างระหว่างคำ แต่ text-align: justify ในเบราว์เซอร์สมัยใหม่มักเพิ่มช่องว่างระหว่างคำเป็นหลัก
  • อักษรอาหรับหนึ่งโค้ดพอยต์ที่เก็บไว้สามารถเปลี่ยนเป็นรูปเดี่ยว รูปต้น รูปกลาง หรือรูปท้ายตามบริบท และหากไม่มีฟีเจอร์ OpenType กับ shaping engine ก็จะถูกเรนเดอร์เป็นตัวอักษรที่แยกออกจากกัน
  • Arabic Presentation Forms, ระบบตัวเลข, อัลกอริทึมสองทิศทาง UAX #9 และอักขระควบคุมที่มองไม่เห็นใน Unicode นำไปสู่ปัญหาจริงในผลิตภัณฑ์ เช่น ค้นหาไม่เจอ หมายเลขโทรศัพท์กลับด้าน หรือเคอร์เซอร์เคลื่อนที่สับสน
  • แม้จะมีฐานสำคัญอย่าง HarfBuzz, Amiri และ W3C Arabic Layout Requirements แล้ว แต่การจัดย่อหน้าอาหรับและการใช้ jstf ในเบราว์เซอร์ยังคงเป็นช่องว่างของการพัฒนา

จุดเริ่มต้น: ปัญหาการเรียงพิมพ์อาหรับที่ดูเหมือนเป็น “บั๊ก CSS”

  • ย่อหน้าอาหรับที่มีเนื้อหาแบบผสมในแดชบอร์ดสำหรับลูกค้าไม่ได้ถูกเรนเดอร์ให้ชิดขอบสองด้านเหมือนแบบดีไซน์ และขอบซ้ายก็ดูไม่เรียบ
  • เวอร์ชันที่เป็นอักษรละตินในบล็อกเดียวกันดู “โอเค” แต่ในอาหรับ บรรทัดเริ่มจากขวา จึงเกิดขอบที่ไม่เรียบบนฝั่งซ้าย
  • แม้จะใช้ text-align: justify ก็ยังไม่สามารถยืดเส้นภายในคำเพื่อเติมบรรทัดให้เหมือนรูปแบบที่ทีมดีไซน์อนุมัติได้
  • ผลิตภัณฑ์เดียวกันนี้ก็เคยมีปัญหาอาหรับซ้ำๆ มาก่อน เช่น ชื่อใน PDF ถูกแยกตัวอักษร การทำดัชนีค้นหาล้มเหลว และปัญหาโค้ดพอยต์ Unicode แบบเก่า
  • แก่นของปัญหาไม่ใช่ข้อบกพร่องในสไตล์ชีตใดสไตล์ชีตหนึ่ง แต่คือ สภาพของตัวพิมพ์อาหรับบนเว็บ

ปัญหาที่ประเพณีการคัดลอกต้นฉบับเคยแก้ไว้แล้ว

  • ประเพณีการคัดลอกอาหรับแบบดั้งเดิมจัดบรรทัดชิดสองด้านด้วยการยืดเส้นเชื่อมภายในรูปอักษร ไม่ใช่เพิ่มช่องว่างระหว่างคำ
  • วิธีนี้เรียกว่า taṭwīl หรือในศัพท์เทคนิคสมัยใหม่คือ kashida ซึ่งเป็นการยืดเส้นเชื่อมระหว่างคู่อักษรบางคู่ให้ยาวขึ้น
  • หน้าที่จัดอย่างดีของอักษร Naskh ในศตวรรษที่ 17 ทำให้ระยะขอบสองด้านตรงกัน โดยไม่ต้องเพิ่มช่องว่างระหว่างคำ และให้ผิวสัมผัสที่แน่นและสม่ำเสมอ
  • al-khaṭṭ al-mansūb ที่ Ibn Muqla วางระบบไว้ ทำให้รูปอักษรเป็นแบบแผนผ่านจุดรูปสี่เหลี่ยมข้าวหลามตัดจากปลายปากกากก ความสูงของ alif และสัดส่วนของส่วนโค้ง
  • ในประเพณีนี้ การจัดบรรทัดไม่ใช่ปัญหาการกระจายช่องว่าง แต่เป็น ปัญหาการทำ shaping ที่ต้องเลือกทั้งรูปอักษรและ glyph ทดแทน

หนึ่งตัวอักษร สี่รูปแบบ

  • อาหรับเป็นอักษรที่เชื่อมต่อกันแบบลายมือเสมอ และไม่มีการแยกแบบตัวพิมพ์บล็อกระหว่างตัวพิมพ์กับลายมือ
  • ตัวอักษรแต่ละตัวจะเปลี่ยนเป็นรูปเดี่ยว รูปต้น รูปกลาง หรือรูปท้ายตามอักษรข้างเคียง และมีอักษรหกตัวที่ไม่เชื่อมต่อไปข้างหน้า ทำให้การไหลภายในคำขาดตอน
  • Unicode เก็บอักษรเชิงนามธรรม ฟอนต์ให้ glyph ตามตำแหน่ง และ shaping engine จะใช้ฟีเจอร์ OpenType อย่าง isol, init, medi, fina, rlig, mark, mkmk
  • คำอย่าง محمد ถูกเก็บเป็นสี่โค้ดพอยต์ แต่ตอนเรนเดอร์จะผ่านการเลือก glyph หลายตัวและการค้นหา OpenType จนเห็นเป็นเส้นต่อเนื่องเดียว
  • หากไม่มี shaping engine อย่าง HarfBuzz หรือเครื่องมือสร้าง PDF ไม่ผ่านขั้นตอนนี้ โค้ดพอยต์เดียวกันก็จะถูกเรนเดอร์เป็นตัวเดี่ยวที่แยกจากกัน

ฟอสซิลของ Unicode: Arabic Presentation Forms

  • โค้ดเพจ 8 บิตในยุค DOS และ Windows แรกๆ ไม่ได้เข้ารหัสอักษรเชิงนามธรรม แต่เข้ารหัส รูปแบบของตัวอักษรเอง เช่น รูปต้นหรือรูปกลาง เป็นอักขระแยก
  • Unicode รับสิ่งนี้ไว้เพื่อความเข้ากันได้แบบไปกลับ และยังคงเก็บไว้ในบล็อก Arabic Presentation Forms ตั้งแต่ U+FB50 ถึง U+FEFF
  • เอกสารใหม่ไม่ควรมีโค้ดพอยต์เหล่านี้ แต่ตัวดึงข้อความจาก PDF ก็ยังอาจส่งออกมันได้แม้ในปัจจุบัน
  • หากชื่อเดียวกันถูกเก็บแยกกันด้วย Unicode สมัยใหม่กับ Presentation Forms แม้จะแสดงผลเหมือนกันบนหน้าจอ แต่การเทียบสตริงและการค้นหาจะถือว่าต่างกัน
  • การทำ normalization แบบ NFKC สามารถพับ Presentation Forms กลับเป็นอักษรเชิงนามธรรมเพื่อลดการค้นหาที่พลาดไปได้

ซอฟต์แวร์ที่ข้าม shaping และการประมวลผลสองทิศทาง

  • ซอฟต์แวร์ที่ข้าม shaping engine และอัลกอริทึมสองทิศทางจะวาดตัวอักษรทีละตัวในรูปเดี่ยวและจัดบรรทัดจากซ้ายไปขวา
  • ผลลัพธ์ลักษณะนี้เป็นสิ่งที่ผู้อ่านอาหรับพบเจอจริงบนป้ายร้าน บัตรขึ้นเครื่อง ลายน้ำ และข้อความอาหรับในหนังเก่าๆ
  • Photoshop รุ่นเก่า, matplotlib ที่ตั้งค่าเริ่มต้น, ตัวสร้าง PDF หลายตัวบน npm และเครื่องพิมพ์ใบเสร็จ ล้วนสร้างปัญหาแบบนี้ได้
  • วิธีอ้อมยอดนิยมใน Python อย่าง arabic_reshaper และ python-bidi จะใช้บล็อก Presentation Forms เพื่อฝังรูปที่ถูก shape ล่วงหน้าไว้ในสตริง
  • วิธีอ้อมนี้คือการย้ายงานที่ควรเป็นหน้าที่ของ renderer มาใส่ในสตริงก่อนเวลา และสะท้อนข้อบกพร่องของ text stack โดยตรง

ปัญหาตัวเลขสามแบบและเครื่องหมายวรรคตอน

  • ตัวเลข 0–9 ที่โลกเรียกว่า “Arabic numerals” ไม่ใช่รูปตัวเลขที่ผู้อ่านอาหรับส่วนใหญ่ใช้ในชีวิตประจำวัน
  • อียิปต์ ซูดาน เลแวนต์ อิรัก และภูมิภาคอ่าว ใช้ ARABIC-INDIC DIGITS ٠١٢٣٤٥٦٧٨٩ ของ Unicode
  • ภูมิภาคมักห์เร็บใช้ glyph ของเลขละติน ส่วนอิหร่าน อัฟกานิสถาน และปากีสถาน ใช้ EXTENDED ARABIC-INDIC DIGITS ۰۱۲۳۴۵۶۷۸۹
  • ใน UAX #9 ตัวเลขไม่ถูกมองเป็นอักขระชนิด strong แต่เป็น weak character และจะถูกจัดประเภทใหม่เป็นเลขยุโรปหรือเลขอาหรับตามทิศทางของอักขระ strong ก่อนหน้า
  • หมายเลขโทรศัพท์อย่าง 010-1234-5678 หลังคำอาหรับอาจกลับลำดับบนหน้าจอเป็น 5678-1234-010 เพราะเครื่องหมายขีดถูกมองเป็นอักขระกลาง
  • วิธีแก้ที่แพลตฟอร์มให้มาคือการครอบหมายเลขด้วย ‎ หรือ <bdi> เพื่อแยกทิศทางของมันออกมา
  • ตัวคั่นทศนิยมและหลักพันในโลกอาหรับคือ U+066B ٫ และ U+066C ٬ โดย ASCII . และ , ดูคล้ายกันมาก แต่มีโค้ดพอยต์และคุณสมบัติด้านสองทิศทางต่างกัน

การอ้อมและการลดทอนจากงานพิมพ์สู่เว็บ

  • Kitāb Ṣalāt al-Sawāʿī ที่พิมพ์ใน Fano ปี 1514 เป็นหนังสืออาหรับตัวเรียงเคลื่อนย้ายได้เล่มแรก และแสดงให้เห็นปัญหาการแยกการเชื่อมอักษรกับตำแหน่งจุดที่ผิดพลาด
  • Qurʾān ของ Paganini ที่ Venice ปี 1537 ล้มเหลวในเชิงพาณิชย์เพราะซ้อนทั้งข้อผิดพลาดด้านการเรียงพิมพ์และความผิดในเนื้อหา โดยสำเนาหนึ่งถูกค้นพบในหอสมุดอารามแห่งหนึ่งใน Venice เมื่อปี 1987
  • เรื่องเล่าว่า Ottoman ห้ามการพิมพ์นั้นมีปัญหาตรงที่ไม่มีต้นฉบับพระราชกฤษฎีกาของ Bayezid II และ Selim I เหลืออยู่ และต้องอาศัยบันทึกของนักเดินทางยุโรป
  • Bulaq Press ใน Cairo ก่อตั้งโดย Muhammad Ali ในปี 1820 และยกระดับคุณภาพตัวพิมพ์โลหะอาหรับด้วยชิ้นส่วนตัวพิมพ์หลายร้อยชิ้นและความอดทนอย่างมาก
  • Cairo Qurʾān ปี 1924 ผลิตด้วยตัวพิมพ์โลหะที่ Amiria Press และมีส่วนช่วยทำให้ข้อความและมาตรฐานตัวพิมพ์ในศตวรรษที่ 20 เป็นแบบแผนมากขึ้น
  • ช่วงปลายทศวรรษ 1950 Kamel Mrowa และ Linotype สร้าง Simplified Arabic เพื่อให้พอดีกับเครื่องเรียงพิมพ์นิตยสาร 90 ช่อง โดยรวมรูปต้นเข้ากับรูปกลาง รูปท้ายเข้ากับรูปเดี่ยว และลดจำนวน ligature
  • Simplified Arabic ทำให้การผลิตหนังสือพิมพ์มีต้นทุนต่ำและเร็วขึ้น และครองห้องข่าวภาษาอาหรับภายในเวลาเพียงหนึ่งชั่วอายุคน

kashida ที่เว็บยังวาดไม่ได้

  • ร่างแรกของ CSS Text Module Level 3 เคยมีค่า text-justify เป็น kashida และ Internet Explorer 5.5 ก็เคยทำมันได้ตั้งแต่ปี 2000
  • IE 5.5 ยังมีพร็อพเพอร์ตี text-kashida-space แต่เมื่อเบราว์เซอร์อื่นไม่ทำตาม ค่านี้จึงหลุดออกจากสเปก
  • text-align: justify ใน Chrome, Firefox และ Safari ปัจจุบันทำงานกับอาหรับโดยเพิ่มช่องว่างระหว่างคำ
  • issue เรื่องการจัดย่อหน้าอาหรับใน CSS Working Group เปิดค้างอย่างน้อยตั้งแต่ปี 2015 และงาน W3C Arabic Layout Requirements ก็เริ่มในปีเดียวกัน
  • การจัดบรรทัดด้วย kashida ต้องให้ shaping และ layout ต่อรองกันซ้ำในระดับบรรทัด เพราะ glyph ที่ยืดแล้วทำให้ความกว้างเปลี่ยน และความกว้างที่เปลี่ยนก็ไปเปลี่ยนการตัดบรรทัดกับระยะที่ต้องยืดอีกที
  • OpenType มีตาราง jstf มาตั้งแต่ยุค 1990 เพื่อให้ฟอนต์บอกลำดับความสำคัญสำหรับการจัดย่อหน้าได้ แต่ shaping engine แทบไม่อ่าน และผู้สร้างฟอนต์ก็แทบไม่ใส่มา
  • Microsoft Word และ InDesign Middle East Edition มีการจัดย่อหน้าด้วย kashida แต่ชุด renderer ของเบราว์เซอร์ที่ผู้คนใช้อ่านมากที่สุดยังยืดตัวอักษรแบบนี้ไม่ได้

แฮ็ก Tatweel และปัญหา ligature กับสระกำกับ

  • วิธีอ้อมที่พบได้บ่อยบนเว็บคือแทรกอักขระ U+0640 TATWEEL ลงในข้อความเอง เพื่อให้ดูเหมือนเส้นที่ถูกยืด
  • Tatweel เปลี่ยนเนื้อหาจริงของข้อความ จึงทำให้เกิดปัญหากับการค้นหา การคัดลอกวาง โปรแกรมอ่านหน้าจอ และการ reflow ของคอลัมน์
  • เส้นที่ Tatweel วาดไม่ใช่ kashida ที่วางตามกฎของฟอนต์และตัวอักษร แต่เป็นขีดแบบเครื่องพิมพ์ดีดที่ผู้เขียนเดาเอาเอง
  • ligature ใน OpenType แบ่งเป็น rlig, liga, dlig และหาก ligature บังคับอย่าง lām-alif พังลง มันไม่ได้แค่ดูไม่สวย แต่ถือว่าผิด
  • หากใส่ U+200C ZERO WIDTH NON-JOINER ระหว่างตัวอักษร แม้อักษรที่เก็บไว้จะยังเหมือนเดิม แต่การเรนเดอร์จะถูกบังคับให้แต่ละตัวเป็นรูปเดี่ยว
  • Safari ไม่สนใจ "rlig" 0, "liga" 0 ดังนั้นเดโมปิด ligature บังคับจึงไม่ส่งผล
  • Amiri เป็นฟอนต์ Naskh ที่ Khaled Hosny ปล่อยภายใต้ SIL Open Font License ในปี 2011 และหลังการเขียนใหม่เป็นเวอร์ชัน 1.0 ในปี 2022 ก็รองรับ kashida แบบเส้นโค้งและการซ้อนสระกำกับที่ละเอียดขึ้น
  • คอมโพเนนต์การ์ดที่ใช้ line-height: 1 ร่วมกับ overflow: hidden อาจตัดสระกำกับด้านบนของข้อความอาหรับที่ใส่เครื่องหมายสระครบถ้วน

อัลกอริทึมสองทิศทางและเคอร์เซอร์ที่โกหก

  • หมายเลขเวอร์ชัน identifier ภาษาอังกฤษ URL และคำภาษาฝรั่งเศสภายในย่อหน้าอาหรับ จะเรียกใช้งาน UAX #9 หรือ Unicode Bidirectional Algorithm
  • อักษรอาหรับเป็นอักขระ strong แบบขวาไปซ้าย อักษรละตินเป็นอักขระ strong แบบซ้ายไปขวา ตัวเลขเป็นอักขระ weak ที่ตามบริบท และช่องว่างกับเครื่องหมายวรรคตอนเป็นอักขระกลาง
  • อัลกอริทึมจะกำหนด direction class ให้แต่ละอักขระ ตีความอักขระ weak และ neutral เป็นขั้นๆ จากนั้นกำหนด embedding level และกลับลำดับ run ที่อยู่ในระดับเดียวกัน
  • เพราะลำดับที่เห็นบนจอกับลำดับเชิงตรรกะในหน่วยความจำต่างกัน การเลื่อนเคอร์เซอร์ การคลิกเมาส์ และการเลือกข้อความ จึงต้องแปลระหว่างสองลำดับนี้ตลอดเวลา
  • ที่ขอบเขตของ run จะมีตำแหน่งเคอร์เซอร์ที่ถูกต้องได้สองแบบ คือ logical position และ visual position และ Chrome, Firefox, Qt, Outlook อาจจัดการสิ่งนี้ต่างกัน
  • การเขียนข้อความผสมอาหรับ-อังกฤษยังคงเป็นประสบการณ์ที่มีต้นทุนด้านการรับรู้สูงโดยปริยายใน editor, email client และแอปแชตหลักๆ แม้จะถึงปี 2026 แล้วก็ตาม
  • ช่วงอย่าง الصفحات 10-20 อาจดูเหมือน “20 ถึง 10” เพราะกฎ W2 และการจัดการขีดแบบ neutral และแก้ได้ด้วยการใส่ U+200E LEFT-TO-RIGHT MARK ไว้ข้างหน้า

ฐานที่ใช้งานได้และช่องว่างที่ยังเหลือ

  • Khaled Hosny สร้าง Amiri เขียนเครื่องมือบรรทัดคำสั่ง HarfBuzz hb-shape และยังเป็นผู้ดูแลร่วมของ HarfBuzz
  • Behdad Esfahbod เขียนหลายส่วนของ HarfBuzz ก่อน Hosny และมีส่วนต่อ shaping engine ที่ทำให้เบราว์เซอร์ปัจจุบันวาดอักษรอาหรับได้ถูกต้อง
  • Brill ว่าจ้าง John Hudson ให้ออกแบบฟอนต์ Brill เพื่อรวมอักษรถอดเสียงทั้งหมดที่ต้องใช้ในแค็ตตาล็อก Semitics และเผยแพร่ฟรีสำหรับการใช้งานไม่เชิงพาณิชย์ในปี 2011
  • Sakhr AX-170 เป็นคอมพิวเตอร์ MSX จากซาอุดี-คูเวตราวปี 1984 ที่แสดงผลอาหรับจาก ROM และรองรับ identifier ใน Arabic BASIC ที่เขียนจากขวาไปซ้าย
  • HarfBuzz, Amiri, Scheherazade, การรองรับ Presentation Forms ใน GNU Unifont, Noto Arabic และเอกสาร W3C Arabic Layout ล้วนพึ่งพาความพยายามของคนไม่กี่คน องค์กรไม่กี่แห่ง และอาสาสมัครจำนวนมาก
  • ผู้ผลิตเบราว์เซอร์รับ HarfBuzz มาใช้หลังมันถูกทำเสร็จแบบโอเพนซอร์สและฟรี แต่แทบไม่ได้มีส่วนกับ layout loop ที่จะทำให้รูปแบบการจัดบรรทัดแบบประเพณีคัดลอกต้นฉบับเกิดขึ้นบนหน้าจอ
  • ช่องว่างที่ยังเหลือคืออัลกอริทึมที่เข้าใจกันดีแล้วซึ่งต้องมีการลงมือทำใน layout engine บางตัว และขอบซ้ายที่ไม่เรียบในแดชบอร์ดลูกค้าก็คือรูปธรรมที่ผู้ใช้มองเห็นได้ของการขาดการลงทุนนี้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Lobste.rs

  • เป็นบทความที่ยอดเยี่ยมมาก
    และฉันชอบที่ตัวอักษร ﷽ นี้เป็น โค้ดพอยต์เดียว จริง ๆ ลองคัดลอกดูก็น่าทึ่งดี
    ว่ากันว่ามันมีความหมายว่า “ด้วยพระนามของอัลลอฮ์ ผู้ทรงกรุณาปรานี ผู้ทรงเมตตาเสมอ”

    • สำหรับ ﷽ ประโยคนี้ในบทความมีความเป็นกวีมาก
      “อนุสาวรีย์จากยุคที่ไม่มีใครไว้ใจเรนเดอริงเอนจิน จนต้องฝังการเรนเดอร์ไว้ในเอนโค้ดดิง ราวกับแมลงวันที่กำลังสวดถูกเก็บรักษาไว้ชั่วนิรันดร์ในอำพัน”
    • อักขระ Unicode ตัวนั้นก็เคยถูกพูดถึงที่นี่ด้วย: https://lobste.rs/s/7s4sjp
      ฉันสนุกกับการไล่อ่านบรรณานุกรมจากลิงก์ Wikipedia ที่อ้างถึงตรงนี้: https://lobste.rs/c/dq2ucz
      สรุปก็คือ อักขระนี้ได้เข้าไปอยู่ใน Unicode เพราะมันมีอยู่ใน code page ของปากีสถาน และที่มันอยู่ในนั้นก็เพราะมีข้อกำหนดทางกฎหมายว่าต้องใส่วลีดังกล่าวในเอกสารทางกฎหมาย ภาษา Urdu เป็นภาษาในตระกูลอินโด-ยูโรเปียน ดังนั้นด้วยเทคโนโลยีในยุคนั้น การสลับไปใช้ code page ภาษาอาหรับเหมือน “เรียกออกไปข้างนอก” เพื่อพิมพ์ Basmallah คงทำได้ยาก
      น่าเสียดายที่ไม่ใช่ทุกคอมเมนต์จะแสดงให้เห็นข้อดีของชุมชนนั้น

  • เมตา: นี่เป็นอีกตัวอย่างชั้นเยี่ยมว่าบทความแบบนี้ควรมี แท็ก typography

    • ไม่เข้าใจว่าทำไมต้องมี ดูเหมือนหัวข้อนี้จะค่อนข้างได้รับความนิยม มีความต้องการแรงขนาดนั้นเลยหรือที่จะซ่อนคอนเทนต์ประเภทนี้?
      บน lobste.rs แท็กมีไว้ใช้สำหรับ การกรอง เป็นหลัก

  • คุณสมบัติ text-justify ของ IE นี่เอง สมัยนั้นมีของน่าสนใจเยอะมาก ยังมี text-justify: newspaper ด้วย หลายสิบปีต่อมาบางคนอธิบายว่ามันเป็น Knuth-Plass หรืออะไรทำนองนั้น แต่ฉันไม่เชื่อว่าเป็นแบบนั้นจริง
    https://mediumwell.com/wp-content/uploads/… แสดงให้เห็นว่าพฤติกรรมที่ในเวลานั้นอ้างว่าเป็น text-justify: newspaper ไปสอดคล้องกับ text-justify: inter-character ในสเปกปัจจุบันอย่างไร
    IE มีฟีเจอร์เจ๋ง ๆ มากมายตั้งแต่ค่อนข้างเนิ่น ๆ จริง ๆ และเบราว์เซอร์อื่น ๆ ก็ปล่อยฟีเจอร์แบบนั้นไว้ในตะกร้า “ยากเกินไป” สุดท้ายบางอย่างก็ไม่เคยกลับมาเลย หรือไม่ก็กลับมาอีกทีหลังผ่านไป 15 ปีหรือ 30 ปี Firefox ได้ text-justify: inter-character ในปี 2017, Chromium เพิ่ง implement ส่วนนั้นเมื่อไม่กี่เดือนก่อน, ส่วน Safari ยังไม่มีจนถึงตอนนี้

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

  • มีบางอย่างในบทความที่ทำให้ ตัวจับสัญญาณ LLM ของฉันดังขึ้น ซึ่งน่าเสียดาย เพราะมันมีความลึกและพูดถึงส่วนที่เอกสารในสแตกเทคโนโลยีปัจจุบันยังไม่ค่อยครอบคลุม
    ตัวอย่างของช่วงที่อ่านแล้วให้ความรู้สึกแบบ LLM คือส่วนนี้ และทั้งบทความก็มีโทนแบบนั้นอยู่เรื่อย ๆ:
    “เหตุผลที่ไม่มีเบราว์เซอร์ใดรองรับสิ่งนี้เป็นเหตุผลเชิงโครงสร้าง และในฐานะอุปสรรค โครงสร้างนั้นก็ค่อนข้างงดงาม การจัดย่อหน้าแบบ Latin ปฏิบัติต่อข้อความที่ผ่านการ shaping แล้วว่าเป็นของตายตัว วัดคำ เทพื้นที่ที่เหลือลงในช่องไฟ แล้วก็จบ shaping กับ layout อยู่กันคนละกล่อง และทุก text stack ที่ใช้งานอยู่ก็ถูกออกแบบบนฐานของการแยกส่วนนี้ Kashida justification เปิดกล่องนั้นออก”
    อยากถาม @lr0 ว่าเนื้อหาหลักของบทความนี้ถูกสร้าง ปรับแต่ง หรือแปลด้วย LLM หรือไม่ ถ้าใช่ อาจจะดีกว่าถ้าปรับระดับการควบคุมที่ LLM มีต่อผลลัพธ์สุดท้าย บล็อกโพสต์ก่อน ๆ อย่างเช่น https://lr0.org/blog/p/gpt/ และ https://lr0.org/blog/p/linux_new_users/ ให้ความรู้สึกเป็นมนุษย์มากกว่ามาก