Signos de rich text a través de estilos
El rich text tipado conserva el V lógico original y el RV canónico mientras posiciona un signo combinante inicial contra el glifo renderizado precedente real en la misma línea física
La base y el signo pueden usar programas de fuente suministrados distintos, regular, bold, italic o bold-italic, tamaños de punto distintos y colores distintos
El posicionamiento lee attachments GPOS reales mark-to-base, mark-to-ligature y mark-to-mark, incluidos los lookups de posicionamiento de extensión; el anchor de la base usa su propia fuente y escala, y el anchor del signo usa su propia fuente y escala
El joining contextual árabe sigue activo a través de los límites de estilo, y un signo adjunto usa el glifo base unido resultante en lugar de un glifo nominal aislado
Los signos iniciales reciben transforms hijos independientes, de modo que adjuntar un signo no mueve el texto ordinario siguiente ni cambia el avance lógico de character-spacing
Los formularios hijos rich conservan los overhangs de glifos, incluidos los signos combinantes de origen negativo y los contornos italic; la apariencia propietaria aporta el clip del widget, la rotación y la alineación de párrafo
La tinta adjunta contribuye al ajuste de las extensiones de línea para que los signos apilados puedan seguir visibles en la parte superior de un campo; un cluster indivisible más alto que el widget conserva su comportamiento existente de clipping acotado
Cuando falta la cobertura de attachment coincidente, los bounds reales del glyph-header TrueType seleccionado aportan un fallback de colocación con escalas independientes por tamaño de punto y la combining class nativa de Unicode
La colocación de fallback distingue signos above, below, attached, left/right y dobles; los signos del mismo lado se apilan mientras los del lado opuesto vuelven al contorno de la base, y los anchors GPOS coincidentes siempre tienen prioridad
Los signos combinantes dobles siguen siendo candidatos a attachment incluso cuando su clase de line-break Unicode es nonbreaking; el texto lógico, los estilos originales y el avance de character-spacing siguiente permanecen intactos
El borde de fallback de un signo doble sigue el nivel bidi real resuelto de su elemento de texto, incluido un elemento de dirección opuesta embebido dentro del párrafo
Los bounds de fallback describen el outline header declarado de la fuente real; la reconstrucción automática de familias de fuentes arbitrarias queda fuera de este contrato de fuentes suministradas
Las lecturas de tablas de fuente quedan acotadas a su tabla GPOS real, observan la cancelación y comparten un presupuesto de recorrido entre todas las fuentes de estilo suministradas; los offsets de tabla inválidos fallan antes de mutar el campo del documento
Los contornos PDF unhinted usan anchors en coordenadas de diseño, sin ajustes de píxel específicos del dispositivo
Aceptación
HotPDFHeadlessRichMarkTests.pas guarda y recarga apariencias reales de signos latinos, árabes y hebreos, signos apilados, una ligadura árabe genuina, tamaños y colores mezclados, wrapping, spacing, alineación y rotación
Verify-HeadlessRichMarks.py lee los programas de fuente embebidos genuinos mediante fontTools, calcula de forma independiente los anchors GPOS, verifica los valores y estilos de origen y confirma que cada signo aporta píxeles MuPDF visibles renderizando la misma apariencia real con ese signo omitido
HotPDFHeadlessRichMarkFallbackTests.pas y Verify-HeadlessRichMarkFallback.py comprueban fuentes sin GPOS reales, apariencias guardadas visibles, combining classes crudas, bounds de glifos seleccionados y cancelación; también se verifica que los anchors coincidentes conservan prioridad sobre la colocación de fallback
Bounds de glifos TrueType seleccionados · Combining classes canónicas crudas
Builder de apariencias · Campos rich-text nativos · Ajuste de grafos a través de estilos