Arabic / Persian / Urdu Shaping Support

Producer-side shaping pipeline (v2.85.0 - v2.119.68)

HotPDF รันไพป์ไลน์การปรับรูปร่างฝั่งผู้สร้างที่รวมอินพุต Unicode ภาษาอาหรับ เปอร์เซีย และอูรดูให้เป็น Arabic Presentation Forms ของพวกเขาในระหว่างการส่งออกข้อความ PDF เพื่อให้ผู้อ่านที่เป็นผู้บริโภคได้รับกลีฟบอกตำแหน่ง/ลิเกเจอร์ที่พร้อมเรนเดอร์โดยไม่จำเป็นต้องใช้ตัวปรับรูปร่างคลาส Harfbuzz ของตัวเอง

สิ่งที่ไพป์ไลน์ทำ

การปรับรูปร่างตามตำแหน่ง (v2.85.0): ตัวอักษรพื้นฐานภาษาอาหรับทุกตัวมีรูปแบบตามตำแหน่งสูงสุดสี่รูปแบบ - เดี่ยว (isol), เริ่มต้น (init), กลาง (medi), สุดท้าย (fina) HotPDF จะตรวจสอบคลาสการเข้าร่วมของอักขระภาษาอาหรับแต่ละตัวและคลาสการเข้าร่วมของตัวข้างเคียงที่อยู่ติดกัน จากนั้นจะแมปรหัสพิกัดอินพุตไปยังกลีฟ Arabic Presentation Forms-B (U+FE70 - U+FEFC) ที่เหมาะสมก่อนการส่งออก อักขระที่ไม่เชื่อมต่อ, ตัวเชื่อม, อักขระโปร่งใส (เครื่องหมายผสม) และ Tatweel kashida ทั้งหมดจะได้รับการจัดการตามอัลกอริทึมการปรับรูปร่างภาษาอาหรับของ Unicode

ลิเกเจอร์บังคับ LAM-ALEF (v2.119.32): ข้อกำหนดการปรับรูปร่างของ Unicode ภาษาอาหรับระบุว่า LAM (U+0644) ใดๆ ที่ตามด้วย ALEF ทันที (U+0627 แบบธรรมดา, U+0622 ที่มี madda ด้านบน, U+0623 ที่มี hamza ด้านบน, U+0625 ที่มี hamza ด้านล่าง) จะต้องรวมเป็นกลีฟลิเกเจอร์เดียว (รูปแบบเดี่ยว / สุดท้าย U+FEFB - U+FEFC พร้อมตัวแปร hamza / madda ที่เหมาะสม) นี่เป็นหนึ่งในลิเกเจอร์ที่ไม่ใช่ทางเลือกไม่กี่ตัวในอักษรศิลป์ภาษาอาหรับและจำเป็นสำหรับความถูกต้อง; การเรนเดอร์แยกเป็นกลีฟเดี่ยวๆ จะสร้างข้อความที่ผู้อ่านเจ้าของภาษาจะรับรู้ได้ทันทีว่ารูปแบบผิดปกติ HotPDF จะทำการรวมนี้ในระหว่างการส่งออกข้อความเพื่อให้ผู้เรียกไม่จำเป็นต้องใช้ตัวปรับรูปร่างคลาส Harfbuzz ในพาธโค้ดของตนเอง

ตัวอักษรหลัก 9 ตัวของเปอร์เซีย / อูรดู (v2.119.35): ภาษาเปอร์เซียและภาษาอูรดูขยายภาษาอาหรับด้วยตัวอักษรที่ไม่อยู่ในบล็อก Arabic Presentation Forms-B (U+FE70 - U+FEFC) ตัวอักษรประเภทดังกล่าว 9 ตัวที่ถูกใช้งานมากที่สุด - ได้แก่ PEH (U+067E), TCHEH (U+0686), JEH (U+0698), KEH (U+06A9 / U+06AF), GAF (U+06AF), NOON GHUNNA (U+06BA), HEH DOACHASHMEE (U+06BE), YEH BARREE (U+06D2) และ HEH GOAL (U+06C1) - มีรูปแบบการนำเสนออยู่ใน Arabic Presentation Forms-A (U+FB50 - U+FDFF) ตอนนี้ HotPDF จะแมปตัวอักษรเหล่านี้ไปยังกลีฟ Forms-A ที่เหมาะสมในระหว่างการปรับรูปร่างตามตำแหน่ง เพื่อให้ข้อความภาษาเปอร์เซียและอูรดูแสดงผลด้วยรูปแบบเริ่มต้น / กลาง / สุดท้าย / เดี่ยว ที่ถูกต้องในโปรแกรมอ่านที่เป็นผู้บริโภคทั่วไป

Arabic Extended-A + Supplement (v2.119.52, v2.119.56): ตอนนี้ตารางคลาสการเชื่อมโยงครอบคลุมอักขระ Arabic Extended-A ที่เหลืออยู่ (ตัวแปร ALEF WASLA / NOON GHUNNA / HEH), Arabic Supplement U+0750-U+077F และช่วง Arabic Extended-A U+08A0-U+08FF ที่สูงกว่า อักขระที่มีการเข้ารหัส Presentation Forms-A แบบคงที่จะถูกแมปผ่านตัวปรับรูปร่าง 4 ตำแหน่งที่มีอยู่ อักขระที่ไม่มี (Extended-A ส่วนใหญ่) จะได้รับการจำแนกคลาสการเชื่อมโยงเท่านั้นเพื่อให้ตัวข้างเคียงปรับรูปร่างได้อย่างถูกต้อง แม้ว่าตัวอักขระจะถูกส่งผ่านโดยไม่มีการเปลี่ยนแปลงก็ตาม v2.119.56 ได้แก้ไขการแมป Forms-A ที่ผิดพลาดสองรายการซึ่งเกิดจาก v2.119.52 (U+06C2 / U+06C3)

Persian / Urdu Form-B ครอบคลุมทั้งหมด (v2.119.57): ตารางคลาสการเชื่อมโยงได้รับการขยายให้ครอบคลุมช่วง U+0672-U+06D5 ทั้งหมด (ประมาณ 80 อักขระที่ครอบคลุมตัวแปร REH / DAL / SEEN / SAD / TAH / AIN / FEH / QAF / KAF / GAF / LAM / NOON / HEH / WAW / YEH) และเพิ่มการแมป Presentation Forms-A ใหม่ 26 รายการ (คลาส D แบบ 4 รูปแบบ 15 ตัว + คลาส R แบบ 2 รูปแบบ 11 ตัว) โดยเฉพาะอย่างยิ่ง HEH DOACHASHMEE 'h' มาตรฐานของภาษาอูรดู (U+06BE → FBAA-FBAD) และ yeh ท้ายคำอูรดู YEH BARREE (U+06D2 → FBAE-FBAF) ได้ถูกแมปอย่างถูกต้องไปยังช่อง Forms-A ที่เคยใช้ผิดวัตถุประสงค์จากการแก้ไขชั่วคราว ALEF WASLA / NOON GHUNNA ของ v2.119.52 ตอนนี้ความครอบคลุมของ Forms-A แบบคงที่ครอบคลุมอักขระต้นทางมากกว่า 40 ตัว

ขั้นตอนตรวจสอบภายหลังของลิเกเจอร์ YEH-HAMZA + สระ (v2.119.58): ขั้นตอนการตรวจสอบภายหลังที่เพิ่มใน _ApplyArabicShaping หลังจากการปรับรูปร่างตามตำแหน่ง ครอบคลุมลิเกเจอร์ 8 คู่ในบล็อก Forms-A U+FBEA-U+FBFB - YEH-HAMZA + ALEF / AE / WAW / U / OE / YU / E / ALEF MAKSURA แต่ละคู่จะส่งออกรูปแบบเดี่ยว (FBEA / FBEC / FBEE / FBF0 / FBF2 / FBF4 / FBF6 / FBF9) บวกกับรูปแบบสุดท้ายของ base+1 ส่วนช่องรูปแบบเริ่มต้น / กลาง FBF8 / FBFB จะถูกปล่อยไว้ให้เอ็นจิ้น GSUB ผ่านการเลือกเข้าร่วม sfArabicGSUB สร้างขึ้นบนโครงสร้างเดียวกันกับ v2.119.32 LAM-ALEF

ลิเกเจอร์ Allah (v2.119.60): ลำดับอักขระสี่ตัว ALEF + LAM + LAM + HEH จะถูกรวมเป็น U+FDF2 ARABIC LIGATURE ALLAH ISOLATED FORM ถูกใช้งานเป็นขั้นตอนตรวจสอบภายหลังแบบคงที่ในระดับรหัสพิกัดหลังจากการทำ v2.119.32 LAM-ALEF และ v2.119.58 YEH-HAMZA ในเชน _ApplyArabicShaping

ลิเกเจอร์วลี Bismillah (v2.119.62): วลี Bismillah มาตรฐานจำนวน 22 รหัสพิกัด "بسم الله الرحمن الرحيم" จะถูกรวมเป็นกลีฟเดียว U+FDFD ARABIC LIGATURE BISMILLAH AR-RAHMAN AR-RAHEEM โดยจะทำงานเป็นขั้นตอนแรกสุดก่อนขั้นตอนอื่นใน _ApplyArabicShaping (ก่อน LAM-ALEF) เพื่อให้กลีฟ Bismillah ที่รวมแล้วส่งไปยังไพป์ไลน์ส่วนที่เหลือในฐานะรหัสพิกัดเดียวและไม่ถูกแก้ไขโดยการแทนที่ในขั้นตอนหลังๆ

ตัวช่วยคิวรีสาธารณะ

GetArabicJoiningClass จะส่งคืนคลาสการเชื่อมโยง Unicode ที่ใช้โดยตัวปรับรูปร่างภาษาอาหรับแบบคงที่ GetArabicPosition จะแยกแยะอักขระตัวหนึ่งในชุดข้อมูลให้อยู่ในตำแหน่งเดี่ยว เริ่มต้น กลาง หรือสุดท้าย เพื่อให้ผู้เรียกสามารถตรวจสอบหรือสะท้อนการตัดสินใจการปรับรูปร่างเดียวกันก่อนที่จะส่งออกข้อความ

วิธีที่ผู้เรียกใช้เรียกใช้งาน

ไพป์ไลน์การปรับรูปร่างจะทำงานโดยอัตโนมัติภายในเมธอดการส่งออกข้อความ Unicode - ไม่จำเป็นต้องเรียกใช้ "ปรับรูปร่างสิ่งนี้" อย่างชัดแจ้ง ส่งผ่านสตริงภาษาอาหรับ / เปอร์เซีย / อูรดู ที่เป็นอินพุต Unicode ไปยัง THPDFPage.UnicodeTextOut หรือ THPDFPage.RtLTextOut และ HotPDF จะจับคู่รหัสพิกัดอินพุตแต่ละตัวไปยังรูปแบบการนำเสนอของอักขระก่อนที่จะเขียนโอเปอเรเตอร์แสดงข้อความ PDF ไบต์ Unicode ดั้งเดิมจะถูกจัดเก็บไว้ใน FUnicodeUsedCps ด้วยเช่นกันเพื่อสร้าง ToUnicode CMap เพื่อให้การคัดลอก / วางฝั่งผู้อ่านและโปรแกรมอ่านหน้าจอยังคงเห็นข้อมูลเพย์โหลด Unicode ดั้งเดิม

ข้อกำหนดของฟอนต์

ฟอนต์ที่ลงทะเบียนผ่าน RegisterUnicodeTTF จะต้องมีกลีฟสำหรับทั้งบล็อก Arabic Presentation Forms-B (U+FE70 - U+FEFC) และช่วง Arabic Presentation Forms-A ที่เกี่ยวข้อง (สำหรับเปอร์เซีย / อูรดู) (U+FB50 - U+FDFF) ฟอนต์แนะนำที่มาพร้อมกับชุดข้อมูลทั้งหมด:

Noto Sans Arabic (ละติน + อาหรับ; Forms-A + Forms-B + Arabic Extended-A)

Noto Naskh Arabic, Noto Naskh Arabic UI

Amiri (Naskh แบบดั้งเดิม, ครอบคลุม Forms-A + Forms-B ทั้งหมด)

Scheherazade New (SIL, ออกแบบมาสำหรับภาษาของโลกมุสลิม)

Microsoft Arabic Typesetting / Tahoma / Times New Roman (แถมมากับ Windows, ครอบคลุม Forms-B ทั้งหมด; บางตัวครอบคลุม Forms-A)

เมื่อฟอนต์ที่ลงทะเบียนไม่มีกลีฟสำหรับรูปแบบการนำเสนอที่ดึงมา HotPDF จะถอยกลับไปใช้รหัสพิกัด Unicode ดั้งเดิมและส่งออกโดยไม่มีการเปลี่ยนแปลง; จากนั้นโปรแกรมอ่านที่เป็นผู้บริโภคอาจพยายามปรับรูปร่างด้วยตนเอง (Acrobat, Foxit) หรือเรนเดอร์เป็น .notdef

เวิร์กโฟลว์ทั่วไป

PDF.RegisterUnicodeTTF('NotoArab', 'NotoSansArabic-Regular.ttf');

PDF.BeginDoc;

PDF.CurrentPage.SetFont('NotoArab', [], 14);

PDF.CurrentPage.RtLTextOut(100, 700, 0,

  UnicodeString(#$0645#$0631#$062D#$0628#$0627));  // "marhaba" (hello)

PDF.EndDoc;

การรวมไพป์ไลน์ Phase 8 แบบอัตโนมัติ (v2.119.59 - v2.119.68)

v2.119.59 ได้แนะนำคุณสมบัติแบบเลือกเข้าร่วม ShapingFeatures: THPDFShapingFeatures และการแจงนับ (enum) THPDFShapingFeature ซึ่งยกระดับไพป์ไลน์การปรับรูปร่างให้สูงกว่าการยุบตัวอักษรแบบคงที่ของขั้นตอนการตรวจสอบภายหลัง ไปสู่การแทนที่อักขระตามรูปแบบของแต่ละฟอนต์ที่ขับเคลื่อนด้วย GSUB อัตโนมัติ ตั้งค่า PDF.ShapingFeatures := [sfArabicGSUB] เพื่อใช้การค้นหาภาษาอาหรับดั้งเดิม init, medi, fina, isol, rlig, calt และ rclt ของฟอนต์ที่ลงทะเบียน และส่งออก ID กลีฟตามบริบทที่เป็นผลลัพธ์; เพิ่ม sfCursiveAttachment เพื่อใช้จุดยึดทางเข้า/ทางออกแบบเขียนหวัด (cursive) ของ GPOS กับการทำงานที่ปรับรูปร่างแล้วนั้น; เพิ่ม sfStandardLigatures สำหรับลิเกเจอร์ละตินมาตรฐาน (FB00-FB06 ff / fi / fl / ffi / ffl / ſt / st ผ่าน v2.119.65 ApplyLatinLigatureRefinement); เพิ่ม sfIndicShaping เพื่อเปิดใช้งานการจัดเรียงใหม่ก่อนตรวจสอบภายหลังของอักษรเทวนาครี (Devanagari) (v2.119.67) ค่าเริ่มต้น [] จะรักษาเอาต์พุตที่เหมือนกันทุกไบต์สำหรับผู้เรียกใช้ที่ขึ้นอยู่กับไพป์ไลน์แบบคงที่

เมื่อตั้งค่า sfArabicGSUB ตัวปรับรูปร่าง Unicode Presentation Forms แบบคงที่จะถูกบายพาสเพื่อหันไปใช้กฎ GSUB ของฟอนต์เอง HotPDF จะส่งออก ID กลีฟตามบริบทดั้งเดิมผ่านทางรหัสพิกัดเทียมเมื่อกลีฟเหล่านั้นเข้าไม่ถึงจาก font cmap, รักษาชุดย่อยที่ฝังไว้ให้ปิด และเขียนการจับคู่ย้อนกลับ ToUnicode สำหรับการคัดลอกและวาง ผู้เรียกที่ต้องการให้ตัวปรับรูปร่างแบบคงที่ทำงานต่อไปสำหรับความครอบคลุมรหัสพิกัดนอกเหนือจากที่ GSUB ของฟอนต์ประกาศไว้ควรปล่อย sfArabicGSUB ปิดไว้และพึ่งพาเชนตรวจสอบภายหลังแบบคงที่

การจับคู่ย้อนกลับลิเกเจอร์ ToUnicode CMap (v2.119.61, v2.119.62, v2.119.65)

Adobe-Identity-UCS ToUnicode CMap ที่ส่งออกโดย RegisterUnicodeTTF จะส่งมอบรายการการจับคู่ย้อนกลับแบบ bfchar สำหรับทุกรหัสพิกัดลิเกเจอร์ที่เชนตรวจสอบภายหลังสามารถสร้างได้ โดย v2.119.61 ได้เพิ่ม 27 รายการ (8 LAM-ALEF + ตระกูล YEH-HAMZA 18 ตัว + Allah 1 ตัว); v2.119.62 เพิ่ม Bismillah (U+FDFD); v2.119.65 เพิ่มรายการลิเกเจอร์ละตินมาตรฐาน 7 รายการ (FB00-FB06) การคัดลอก / วางของโปรแกรมอ่านผู้บริโภคจะแปลงกลีฟลิเกเจอร์ใดๆ กลับไปเป็นลำดับรหัสพิกัดต้นทาง เพื่อให้ PDF ที่เรนเดอร์ยังคงเป็นมิตรกับผู้ใช้งานในการเข้าถึง

การส่งออกรหัสพิกัดเทียม PUA (v2.119.68)

AssignSyntheticCodepointForGID(GID; out CP): Boolean + GetSyntheticCodepointForGID(GID): Word ช่วยให้โค้ดฝั่งผู้สร้างส่งออก GID ตัวแทน GSUB ที่ไม่มีรหัสพิกัด Unicode ปกติที่สามารถเข้าถึงได้ผ่าน cmap ของฟอนต์ ตัวจัดสรรจะแจกรหัสพิกัดในพื้นที่ใช้งานส่วนตัว (Private Use Area - U+E000 ถึง U+F8FF, 6400 สล็อต) และทำการคัดลอกการจัดสรรไปยัง FUnicodeCpToGid (เพื่อให้ /CIDToGIDMap แปลงค่ารหัสพิกัดเทียมกลับไปเป็น GID เป้าหมายในฝั่งผู้อ่านที่เป็นผู้บริโภค), FAcroFormUnicodeAdvances (เพื่อให้การตัดคำของ v2.65 ค้นหา em-fraction ที่ถูกต้อง) และตารางการค้นหาย้อนกลับตาม GID (เพื่อให้คำขอจัดสรรซ้ำได้ผลลัพธ์เหมือนเดิม) ใช้ตัวนี้สำหรับรูปทรงคลัสเตอร์ Devanagari, ตัวเลือกสไตล์ที่ต่างกัน และลำดับการแปรผันของสัญลักษณ์ CJK ที่ GSUB แนะนำแต่ cmap เข้าไม่ถึง

ความสัมพันธ์กับเอ็นจิ้น OpenType GSUB

ตัวปรับรูปร่างขั้นตอนตรวจสอบภายหลังแบบคงที่ที่อธิบายไว้ข้างต้น (v2.85.0 + v2.119.32 / 58 / 60 / 62) จะเป็นอิสระจากเอ็นจิ้น OpenType GSUB เป็นค่าเริ่มต้น เมื่อ sfArabicGSUB ถูกเปิดใช้งานผ่าน ShapingFeatures เอ็นจิ้น GSUB จะกลายเป็นส่วนหนึ่งของพาธการส่งออกฝั่งผู้สร้าง: HotPDF จะอ้างอิง cmap เพื่อสร้างอาร์เรย์ GID พื้นฐาน ใช้การค้นหา GSUB ตามตำแหน่งและตามบริบทภาษาอาหรับดั้งเดิมกับชุดกลีฟนั้น กำหนดรหัสพิกัดเทียมสำหรับ ID กลีฟทดแทนที่ไม่มีรูปแบบการนำเสนอ Unicode และเรียกใช้ MarkUnicodeGlyphUsed เพื่อรักษาตัวกลีฟทดแทนไว้ในชุดย่อยฟอนต์ที่ฝังไว้

สำหรับกลีฟทดแทนที่ไม่มีรหัสพิกัด Unicode ผู้เรียกจะรวม ShapingFeatures เข้ากับตัวจัดสรรรหัสพิกัดเทียม PUA ของ v2.119.68 เพื่อให้ GID ทดแทนยังคงสามารถเข้าถึงได้ผ่านไพป์ไลน์ฐานสิบหกมาตรฐาน เชนการตรวจสอบภายหลังแบบคงที่จะยังคงเป็นทางเลือกเริ่มต้นสำหรับรหัสพิกัดที่การประกาศ GSUB ของฟอนต์ไม่ครอบคลุม

ขอบเขตและข้อจำกัด

อัลกอริทึม BiDi ยังคงอยู่นอกหน้านี้: ผู้เรียกยังคงต้องจัดลำดับการทำงาน LTR และ RTL แบบผสมด้วยตนเอง หรือใช้ไลบรารี BiDi แยกต่างหาก การสนับสนุน GPOS, Indic/Tibetan/Mongolian, Hebrew, N'Ko, Adlam, Thai/Lao และ Javanese ขณะนี้อยู่ในหน้าแฟล็กการปรับรูปร่างและหน้า API แบบเลือกเข้าร่วมที่แยกต่างหาก ดังนั้นหน้านี้จึงมุ่งเน้นเฉพาะการปรับรูปร่างภาษาอาหรับแบบคงที่และแบบใช้ GSUB เท่านั้น

ดูเพิ่มเติม: OpenType GSUB Substitution Engine, Automatic Shaping Pipeline (Phase 8), Syriac / Mongolian / Devanagari Shaping, THotPDF.AssignSyntheticCodepointForGID, THPDFPage.RtLTextOut, THPDFPage.UnicodeTextOut, CFF / OpenType Font Subsetting