Native Annotation-Dekorationen

HPDFRenderHeadlessPagePNG erzeugt fehlende Relief-Rahmen und Line-Captions über seinen normalen begrenzten Annotation-Form-Renderer

Eine gelieferte normale Appearance hat Vorrang vor erzeugten Dekorationen

Rechteckige Relief-Rahmen

Square-, Link-, FreeText- und Stamp-Rahmen unterstützen BS-Styles B und I mit gegensätzlichen schattierten Bändern, mit umgekehrter Lichtrichtung bei Inset

Für jede Border-Farbkomponente c nutzt das helle Band 1 − (1 − c) × 0.35 und das dunkle Band c × 0.5

Die Bandbreite wird auf die Hälfte der kürzeren Rahmendimension geklemmt; Rechteck-Differenzen, Breite null, leere Farben und separate CA/ca-Opazität bleiben wirksam

Unbekannte benannte BS-Styles nutzen den soliden Standard-Default; ein falsch typisierter Style bleibt ein fehlerhafter Dictionary-Eintrag

Line-Caption-Layout

Cap aktiviert eine Caption aus Contents oder XHTML RC mit DS-Styling; CP wählt Inline- oder Top-Platzierung, und CO liefert Offsets entlang der ursprünglichen Endpunktrichtung und ihrer linken Normale

Inline-Captions lassen eine gemessene Lücke in der Linie; Top-Captions und Captions, die breiter als die Linie sind, nutzen Platzierung über der Linie

Umgekehrte Endpunkte behalten aufrechten Text, während Pfeilenden und Leader-Linien ihre unabhängige Geometrie behalten

Der Plain-Default ist ein deterministischer 12-Punkt-Helvetica-Ressourcenname mit der Annotation-Farbe, aufgelöst über die bestehenden Dokument- und Seiten-Font-Ressourcen

Unicode, Rich-Text-Styling und explizite Absatzumbrüche nutzen den bestehenden Read-only-Text-Appearance-Builder; leerer Text lässt die gewöhnliche Linie unangetastet

Clipping, Lebensdauer und Limits

Die Caption-Platzierung nutzt die gemessenen temporären Form-Dimensionen und behält ihre BBox- und Annotation-Rechteck-Clips

Der Inner-Padding-Clip des Field-Builders wird nur aus diesem erzeugten Caption-Layout entfernt; gewöhnliche PDF-W- und W*-Operatoren bleiben unverändert

Erzeugte Text-Ressourcen teilen sich unveränderliche TrueType-Programm-Bytes innerhalb einer Annotation, mit unabhängigen Stream-Positionen und Aufräumen, nachdem alle temporären Ressourcen-Views freigegeben wurden

Dekodierte Bytes, Working Memory, Tokens, Operationen, Output-Größe und Abbruch bleiben begrenzt, einschließlich langer mehrsprachiger Captions und Recovery nach fehlgeschlagenem Render

Abnahme und verbleibende Arbeiten

Die Nicht-GUI-Runner in Tests/Linux/HeadlessAnnotationDecorations.en-us.md vergleichen gewöhnliche Seiteninhalt-Geometrie-Begleiter in zwei Skalen in View- und Print-Usage und behalten separate MuPDF- und Poppler-Beobachtungen

Fixtures decken Opazität, Transparenz, optionale Sichtbarkeit, verschlüsselte Dokumente, kurzes und langes Unicode, Caption-Grenzen, Quellgraph-Bewahrung und Abbruch-Recovery ab

CFF- oder Type1-Default-Font-Shaping, zusätzliche FreeText-DA-Operatoren und das separat getrackte allgemeine Fraktional-Glyph-Clipping-Problem bleiben separate Arbeiten

Das begrenzte FreeText-DA-Profil wendet Texttransformationen und den anfänglichen Strichzustand auf generierten Text und Dekorationen an; Text-Clipping nutzt Glyphenkonturen statt der erweiterten Strichsilhouette, und die vier endlichen Zwei-Run-Tr4-bis-Tr7-Kontrollen bestanden native Vergleiche sowie unabhängige MuPDF-1.28.5- und Poppler-Reader

Die fraktionale gefüllte-Glyph-Komposition hat ihre eigenen veröffentlichten Grenzen und Allokationsregeln; endliche DA-Kontrollen begründen weder beliebige transformierte Rasterhüllen noch eine exakte mathematische Abdeckung an jedem Randpixel

Siehe Annotation-Fallback für den breiteren unterstützten Geometrie- und Format-Umfang

Siehe Native Cloudy-Annotation-Rahmen für kontinuierliche Konturkonstruktion, Unicode-Content-Bounds und die normalen Abnahme-Einstiegspunkte