Soporte de modelado árabe / persa / urdu

Canalización de modelado del lado productor (v2.85.0 - v2.119.68)

HotPDF ejecuta una canalización de modelado del lado productor que convierte secuencias árabes, persas y urdu de entrada Unicode en sus Arabic Presentation Forms durante la emisión de texto PDF, de modo que los lectores reciben glifos posicionales y de ligadura listos para renderizar sin necesitar un modelador propio de clase Harfbuzz

Qué hace la canalización

Modelado posicional (v2.85.0): cada letra base árabe tiene hasta cuatro formas posicionales - aislada (isol), inicial (init), medial (medi), final (fina). HotPDF inspecciona la clase de unión de cada carácter árabe y las clases de unión de sus vecinos inmediatos, y luego asigna el código de punto de entrada al glifo adecuado de Arabic Presentation Forms-B (U+FE70 - U+FEFC) antes de la emisión. Las letras que no se unen, los unidores, los caracteres transparentes (marcas combinantes) y la kashida Tatweel se manejan conforme al algoritmo Unicode Arabic Shaping

Ligadura obligatoria LAM-ALEF (v2.119.32): la especificación Arabic Unicode Shaping exige que cualquier LAM (U+0644) seguida inmediatamente por un ALEF (U+0627 normal, U+0622 con madda arriba, U+0623 con hamza arriba, U+0625 con hamza abajo) se pliegue en un solo glifo de ligadura (U+FEFB - U+FEFC formas aislada / final con variantes apropiadas de hamza / madda). Esta es una de las muy pocas ligaduras no opcionales en la tipografía árabe y es necesaria para la corrección; renderizarlas como glifos separados produce texto que los lectores nativos reconocen de inmediato como mal formado. HotPDF realiza el pliegue durante la emisión para que los llamadores no necesiten un modelador de clase Harfbuzz en su propia ruta de código

Nueve letras núcleo de persa / urdu (v2.119.35): el persa y el urdu amplían el árabe con letras que no están en el bloque Arabic Presentation Forms-B (U+FE70 - U+FEFC). Las 9 letras más usadas de ese grupo - entre ellas 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) y HEH GOAL (U+06C1) - tienen formas de presentación en Arabic Presentation Forms-A (U+FB50 - U+FDFF). HotPDF ahora asigna estas letras al glifo Forms-A adecuado durante el modelado posicional, de modo que el texto persa y urdu se renderiza con las formas init / medi / fina / isol correctas en cualquier lector consumidor

Arabic Extended-A + Supplement (v2.119.52, v2.119.56): la tabla de clases de unión ahora cubre los caracteres restantes de Arabic Extended-A (ALEF WASLA / NOON GHUNNA / variantes HEH), Arabic Supplement U+0750-U+077F y el rango superior Arabic Extended-A U+08A0-U+08FF. Los caracteres con una codificación estática de Presentation Forms-A se asignan mediante el modelador de 4 posiciones existente; los que no la tienen (la mayoría de Extended-A) solo reciben clasificación por clase de unión para que los vecinos se modelen correctamente incluso cuando el propio carácter se pasa sin cambios. v2.119.56 corrigió dos asignaciones Forms-A erróneas introducidas por v2.119.52 (U+06C2 / U+06C3)

Cobertura completa de Persian / Urdu Form-B (v2.119.57): la tabla de clases de unión se amplió para abarcar todo el rango U+0672-U+06D5 (unas 80 caracteres que cubren variantes de REH / DAL / SEEN / SAD / TAH / AIN / FEH / QAF / KAF / GAF / LAM / NOON / HEH / WAW / YEH), y se agregaron 26 nuevos mapeos de Presentation Forms-A (15 formas de 4 formularios de clase D + 11 formas de 2 formularios de clase R). En particular, el HEH DOACHASHMEE estándar 'h' del urdu (U+06BE → FBAA-FBAD) y el yeh final de palabra YEH BARREE del urdu (U+06D2 → FBAE-FBAF) ahora se asignan correctamente a las posiciones Forms-A que el arreglo temporal de ALEF WASLA / NOON GHUNNA de v2.119.52 había usado mal. La cobertura estática de Forms-A ahora abarca más de 40 caracteres de origen

Pospaso de ligadura YEH-HAMZA + vocal (v2.119.58): un pospaso agregado a _ApplyArabicShaping después del modelado posicional cubre los 8 pares de ligadura del bloque Forms-A U+FBEA-U+FBFB - YEH-HAMZA + ALEF / AE / WAW / U / OE / YU / E / ALEF MAKSURA. Cada par emite la forma aislada (FBEA / FBEC / FBEE / FBF0 / FBF2 / FBF4 / FBF6 / FBF9) más la forma final base+1. Las posiciones de forma inicial / medial FBF8 / FBFB se dejan al motor GSUB mediante la opción sfArabicGSUB. Construido sobre la misma estructura que LAM-ALEF v2.119.32

Ligadura Allah (v2.119.60): la secuencia de cuatro caracteres ALEF + LAM + LAM + HEH se pliega en U+FDF2 ARABIC LIGATURE ALLAH ISOLATED FORM. Implementado como un pospaso estático a nivel de código de punto después de LAM-ALEF v2.119.32 y YEH-HAMZA v2.119.58 en la cadena _ApplyArabicShaping

Ligadura de la frase Bismillah (v2.119.62): la frase Bismillah estándar de 22 códigos de punto "بسم الله الرحمن الرحيم" se pliega en un solo glifo U+FDFD ARABIC LIGATURE BISMILLAH AR-RAHMAN AR-RAHEEM. Se ejecuta como la primera prepasada en _ApplyArabicShaping (antes de LAM-ALEF), por lo que el glifo Bismillah plegado llega al resto de la canalización como un solo código de punto y no es retocado por sustituciones posteriores

Ayudantes públicos de consulta

GetArabicJoiningClass devuelve la clase de unión Unicode usada por el modelador árabe estático. GetArabicPosition resuelve un carácter de una secuencia a posición aislada, inicial, medial o final para que los llamadores puedan inspeccionar o reproducir las mismas decisiones de modelado antes de emitir texto

Cómo lo invocan los llamadores

La canalización de modelado se ejecuta automáticamente dentro de los métodos de emisión de texto Unicode - no hace falta una llamada explícita de "dar forma a esto". Pase cadenas árabe / persa / urdu de entrada Unicode a THPDFPage.UnicodeTextOut o THPDFPage.RtLTextOut y HotPDF asigna cada código de punto de entrada a su forma de presentación antes de escribir el operador PDF de presentación de texto. Los bytes Unicode originales también se capturan en FUnicodeUsedCps para generar la CMap ToUnicode, de modo que el copiar / pegar del lector y los lectores de pantalla sigan viendo la carga Unicode original

Requisitos de fuente

La fuente registrada mediante RegisterUnicodeTTF debe contener glifos tanto para el bloque Arabic Presentation Forms-B (U+FE70 - U+FEFC) como, para persa / urdu, para el rango pertinente de Arabic Presentation Forms-A (U+FB50 - U+FDFF). Fuentes recomendadas que incluyen el conjunto completo:

Noto Sans Arabic (latín + árabe; Forms-A + Forms-B + Arabic Extended-A)

Noto Naskh Arabic, Noto Naskh Arabic UI

Amiri (traditional Naskh, full Forms-A + Forms-B coverage)

Scheherazade New (SIL, designed for languages of the Muslim world)

Microsoft Arabic Typesetting / Tahoma / Times New Roman (Windows-bundled, full Forms-B; some have Forms-A coverage)

Cuando la fuente registrada no tiene un glifo para una forma de presentación derivada, HotPDF retrocede al código de punto Unicode base y lo emite sin cambios; los lectores consumidores pueden entonces intentar su propio modelado (Acrobat, Foxit) o renderizar .notdef

Flujo de trabajo típico

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;

Integrazione automatica della pipeline fase 8 (v2.119.59 - v2.119.68)

v2.119.59 introdujo la propiedad optativa ShapingFeatures: THPDFShapingFeatures y el enum THPDFShapingFeature, que eleva la canalización de modelado más allá del plegado estático de pospaso hacia una sustitución automática específica de la fuente impulsada por GSUB. Establezca PDF.ShapingFeatures := [sfArabicGSUB] para aplicar automáticamente las sustituciones rlig definidas por la fuente a medida que se emite el texto (v2.119.63 - ApplyArabicGSUBRefinement); agregue sfStandardLigatures para ligaduras estándar latinas (FB00-FB06 ff / fi / fl / ffi / ffl / ſt / st mediante v2.119.65 ApplyLatinLigatureRefinement); agregue sfContextualAlternates para alternancias contextuales rclt (v2.119.66 ApplyArabicGSUBContextualRefinement); agregue sfIndicShaping para habilitar el reordenamiento prepaso de Devanagari (v2.119.67). El valor predeterminado [] conserva una salida idéntica a nivel de bytes para los llamadores que dependen de la canalización estática v2.119.32-58

Cuando sfArabicGSUB está activado, el modelador estático v2.85.0 se omite en favor de las reglas GSUB propias de la fuente; los llamadores que quieran que el modelador estático siga funcionando para cobertura de codepoints fuera de lo que declare el GSUB de la fuente deben dejar sfArabicGSUB desactivado y apoyarse en la cadena de pospaso estática

Mappatura inversa delle legature nella CMap ToUnicode (v2.119.61, v2.119.62, v2.119.65)

La CMap ToUnicode Adobe-Identity-UCS emitida por RegisterUnicodeTTF incluye entradas bfchar de mapeo inverso para cada código de punto de ligadura que la cadena de pospaso puede producir. v2.119.61 agregó 27 entradas (8 LAM-ALEF + 18 de la familia YEH-HAMZA + 1 Allah); v2.119.62 agregó Bismillah (U+FDFD); v2.119.65 agregó 7 entradas de ligadura estándar latina (FB00-FB06). El copiar / pegar del lector consumidor resuelve cualquier glifo de ligadura de vuelta a la secuencia de código de punto de origen, de modo que el PDF renderizado sigue siendo accesible

Emisión de codepoints sintéticos PUA (v2.119.68)

AssignSyntheticCodepointForGID(GID; out CP): Boolean + GetSyntheticCodepointForGID(GID): Word permiten que el código productor emita GIDs sustitutos de GSUB que no tienen un codepoint Unicode natural alcanzable mediante el cmap de la fuente. El asignador entrega codepoints en el Private Use Area (U+E000 - U+F8FF, 6400 espacios) y replica la asignación en FUnicodeCpToGid (de modo que /CIDToGIDMap resuelva el CP sintético de vuelta al GID objetivo en el lector consumidor), FAcroFormUnicodeAdvances (para que el ajuste de línea v2.65 encuentre la fracción de em correcta) y una tabla de búsqueda inversa por GID (para que las solicitudes repetidas de asignación sean idempotentes) Úselo para formas de clúster devanagari, alternas estilísticas y secuencias de variación ideográfica CJK que GSUB introduce pero el cmap no alcanza

Relación con el motor OpenType GSUB

El modelador estático de pospaso descrito arriba (v2.85.0 + v2.119.32 / 58 / 60 / 62) es independiente del motor OpenType GSUB de forma predeterminada. Cuando la canalización automática de la Fase 8 se habilita mediante ShapingFeatures, el motor GSUB pasa a formar parte de la ruta de emisión del lado productor: cada ayudante BuildUnicode*FieldContent consulta la cmap para construir un arreglo GID, ejecuta la consulta de función GSUB apropiada (rlig / liga / clig / rclt), vuelve a mapear el GID sustituto a través de la cmap inversa hasta un código de punto Presentation Form y llama a MarkUnicodeGlyphUsed para mantener el glifo sustituto dentro del subconjunto de fuente incrustado

Para glifos sustitutos sin código de punto Unicode, los llamadores combinan ShapingFeatures con el asignador de códigos de punto sintéticos PUA de v2.119.68 para que el GID sustituto siga siendo alcanzable a través de la canalización hexadecimal estándar. La cadena de pospaso estática sigue siendo el respaldo predeterminado para los códigos de punto que las declaraciones GSUB de la fuente no cubren

Alcance y limitaciones

El algoritmo BiDi queda fuera de esta página: quien llama a la API debe ordenar las secuencias LTR y RTL mezcladas o usar una biblioteca BiDi separada. GPOS, Indic/Tibetan/Mongolian, Hebrew, N'Ko, Adlam, Thai/Lao y Javanese ahora viven en páginas propias de banderas y API de modelado opcionales, por lo que esta página se centra solo en el modelado Arabic estático y basado en GSUB

Ver también: Motor de sustitución OpenType GSUB, Canalización automática de modelado (fase 8), Modelado siríaco / mongol / devanagari, THotPDF.AssignSyntheticCodepointForGID, THPDFPage.RtLTextOut, THPDFPage.UnicodeTextOut, Subconjunto de fuentes CFF / OpenType