Nativer Linux-Cairo-Renderer

HPDFHeadlessCairoDevice rendert eine geladene PDF-Seite in ein RGB-PNG, mit Cairo-Image-Surfaces und FreeType, ohne Display-Server oder PDF-Reader

Liefern Sie eine serielle geliehene Ansicht aus THPDFHeadlessDocument.GetRenderAccess(PageIndex) und halten Sie das Dokument geladen und unverändert, bis das Rendering zurückkehrt

Document := THPDFHeadlessDocument.Create;
try
  Document.LoadFromFile('input.pdf');
  Options := THPDFHeadlessRenderOptions.Default;
  Info := HPDFRenderHeadlessPagePNGFile(
    Document.GetRenderAccess(0), 'page.png', Options);
finally
  Document.Free;
end;

Laufzeitabhängigkeiten

Natives Linux nutzt libcairo.so.2, libfreetype.so.6 und die Fontconfig-Abhängigkeit des Standardfont-Providers; installieren Sie passende Schriften für Helvetica-, Times- und Courier-Ersatz

HOTPDF_CAIRO_LIBRARY und HOTPDF_FREETYPE_LIBRARY können vor dem ersten Rendering explizite kompatible Bibliothekspfade wählen; erfolgreich geladene Module bleiben geladen, weil native Font-Caches Destruction-Callbacks behalten können

Der Host muss seinen HotPDF-Executable-, DLL- oder Package-Code geladen halten, solange diese nativen Caches HotPDF-Font-Destruction-Callbacks behalten können; das Entladen eines Host-Moduls unabhängig von der Cache-Lebensdauer liegt außerhalb dieses Profils

Windows nutzt kompatible libcairo-2.dll und libfreetype-6.dll über dieselbe Bridge; Runtime-Binaries und ihre Lizenzierung liefert die Anwendung

ICCBased-Farben laden zusätzlich liblcms2.so.2; JPEG nutzt libturbojpeg.so.0, und JPEG 2000 nutzt ein OpenJPEG-2.5-kompatibles libopenjp2.so.7; diese Abhängigkeiten werden nur für entsprechende Eingaben geladen

HOTPDF_LCMS_LIBRARY, HOTPDF_TURBOJPEG_LIBRARY und HOTPDF_OPENJPEG_LIBRARY überschreiben diese Pfade; Windows-Defaults sind lcms2.dll, turbojpeg.dll und openjp2.dll

Rendering-Profil

Unterstützter Inhalt umfasst Pfadaufbau und -zeichnung, Nonzero- und Even-Odd-Füllregeln, Clipping, verschachtelten Graphics State, CTM-Transforms, Linienstil, DeviceGray/RGB/CMYK-Farben, normale Alpha und wiederholte Form XObjects mit eigenen Ressourcen, Matrix und BBox

Linienbreiten dürfen null sein: PDF-Hairlines, angefordert mit 0 w oder ExtGState LW=0, verwenden einen Ein-Pixel-Strich im Gerätekoordinatenraum; negative Breiten werden abgelehnt

ExtGState D und der Content-Stream-Operator d teilen sich begrenzte Dash-Validierung: durchgezogene leere Muster, Wiederholung ungerader Länge, Einträge der Länge null, gebrochene Längen und vorzeichenbehaftete Phasen werden unterstützt

Ein Dash-Muster erlaubt höchstens 256 endliche nichtnegative Längen bis 1e9, mit mindestens einer positiven Länge, wenn nichtleer, und einer endlichen Phase mit Absolutwert höchstens 1e9; jedes Element verbraucht Operationsarbeit, und temporärer Speicher geht in die Working-Byte-Zulassung ein

Operandenarrays akzeptieren PDF-Kommentare, einschließlich numerischer Dash-Arrays und TJ-Textarrays; fehlerhafte lexikalische Werte und fehlende schließende Klammern werden vom gemeinsamen Scanner gemerkt und vom Renderer abgelehnt, statt stillschweigend zu verschwinden

Horizontaler Text nutzt den gemeinsamen Glyph-Interpreter für Textmatrizen, explizite PDF-Breiten, kanonische Helvetica/Times/Courier-Vorschübe, Zeichen- und Wortabstand, Horizontalskalierung und TJ-Korrekturen

Eingebettete unterstützte Schriftprogramme nutzen FreeType mit aufgelösten Glyph-IDs; Unicode-ToUnicode-Mappings bleiben über die Dokument-Text-API verfügbar, während Rasterformen von Standardschriften von installierten Ersatzschriften abhängen

Zusammengesetzter Text unterstützt Identity-H, Identity-V, explizite eingebettete Encoding-CMap-Streams sowie eingebaute UniJIS-, UniGB-, UniCNS- und UniKS-UCS2/UTF16-Mappings horizontal und vertikal; separat installierte CMap-Ressourcen sind nicht nötig

Vertikales Glyphenzeichnen beachtet Default- und explizite DW2/W2-Positionierungsvektoren, Textanhebung, Horizontalskalierung, Text- und Grafikmatrizen sowie TJ-Versatz; UTF-16-Mappings akzeptieren ergänzende Zeichencodes

Alle acht Text-Rendering-Modi werden unterstützt, einschließlich vertikaler Fill/Stroke/unsichtbarer Konturen, die bei ET in den Clip akkumuliert werden; eingebettete Encoding-CMap-Streams behalten ihr WMode und ihre nicht-identischen CID-Mappings

Transparente kombinierte Fill-und-Stroke-Operationen nutzen Object-Knockout-Compositing, damit sich überlappende Füllung nicht durch den Strich hindurchleakt; Type3-Glyphenprozeduren führen ihre eigenen begrenzten Ressourcen und Fontmatrizen aus

Bilder akzeptieren 1/2/4/8/16-Bit-Samples und Decode-Arrays, Stencil-, explizite, Color-Key- und Soft-Masks, unterschiedlich große Masks und Matte-Wiederherstellung; fehlendes Interpolate nutzt Nearest-Neighbor-Abtastung, true wählt bilineare Abtastung

JPX-Codestreams akzeptieren vorzeichenbehaftete oder vorzeichenlose Quellkomponenten bis 26 Bits, einschließlich gemischter Präzision, Subsampling und expliziter Opazität, und normalisieren in begrenzte 8- oder 16-Bit-Samples; BitsPerComponent im Bild-Dictionary und nicht-Stencil-Decode-Einträge werden bei JPX-Bildern ignoriert, wie es das PDF-Bildprofil verlangt

Indizierte Paletten und validierte ICCBased-Profil-zu-sRGB-Transforms werden für Bilder und Pfadfarben unterstützt; DeviceCMYK ohne Profil behält die einfache Gerätekonvertierung

ICCBased-Transforms akzeptieren Gray-, RGB-, CMYK-, Lab- und XYZ-Profilsignaturen und validieren streng die deklarierte Komponentenzahl und die Komponentenbereiche

Lab-Profiloperanden nutzen physische L a b-Koordinaten mit Defaultbereichen [0 100 -128 127 -128 127]; XYZ-Operanden nutzen physische X Y Z-Koordinaten mit einem Defaultbereich [0 65535/32768] pro Komponente, vorzeichenlos gemäß 1.15

XYZ-Profileingaben sind eine native Kompatibilitätserweiterung und implizieren keine Archivierungs-PDF-Konformität; Lab- und XYZ-Quellprofile wählen keinen unterstützten Transparenz-Blending-Space

Der Range eines ICC-Streams verlangt zwei endliche geordnete Werte pro Komponente und begrenzt Farboperanden; rohe Bild-Decode-Defaults und Indexed-Lookup-Werte nutzen diese Komponentenbereiche

CalGray, CalRGB und Lab unterstützen Pfade, Text, Bilder und Indexed-Palettenbasen; Parameter werden streng validiert, CalRGB-Matrixeinträge folgen der PDF-Spaltenreihenfolge, und Lab-Komponenten sowie Bild-Decode-Defaults nutzen die deklarierten Bereiche

CIE-Farben nutzen Bradford-Chromatic-Adaptation und relative sRGB-Ausgabe; BlackPoint-Metadaten werden validiert, während zusätzliche Black-Point-Kompensation und Rendering-Intent-State-Policies separate Erweiterungen bleiben

Separation- und DeviceN-Verbundfarben behalten ein bis zweiunddreißig Tint-Komponenten für Pfade, Text, Indexed-Basen und gepackte Bilder; Geräte- oder CIE-Alternativfarben nutzen begrenzte Sampled-, Exponential-, Stitching- oder Calculator-Tint-Funktionen

ICCBased-Lab/XYZ- und CalGray/CalRGB/Lab-Alternativfarbquellen behalten ihre physischen Koordinaten durch die Tint-Transformation hindurch, bevor sie in eine unterstützte Transparenzgruppe konvertiert werden

Mehrdimensionale Sampled-Tint-Funktionen unterstützen lineare und kubische Interpolation, Domain, Encode, Decode, Output-Range und gepackte Sampletiefen bis 32 Bits; die kubische Auswertung erweitert die vorhandene skalare Vier-Knoten-Konvention um Tensorprodukte, mit linearem Fallback für kurze Dimensionen sowie begrenzter Arbeit und Abbruch

Siehe Native Sampled-Farbfunktionen für Interpolationskonventionen sowie getrennte Formel- und Reader-Nachweise

Separation None und DeviceN-Spaces, die nur None-Farbstoffe enthalten, tragen weder Farbe noch Knockout-Form bei; gemischte None-Komponenten erreichen weiterhin die Alternativ-Tint-Transformation

Separation All wendet ihren Tint auf jeden verfügbaren Ausgabefarbstoff an, nutzt neutrale RGB-Seitenausgabe und bewahrt jede Prozesskomponente innerhalb von CMYK-Gruppen

CMYK-Gruppen empfangen originale Vier-Komponenten-Alternativ-Tint-Werte vor dem Blending; Spot-Separation-Platten, NChannel-Prozess-/Farbstoffauswahl und Mixing-Hint-Simulation bleiben separate Erweiterungen

Der terminale Bild-Callback bewahrt Dokumententschlüsselung und vorausgehende Stream-Filter vor der nativen JPEG-, JPEG-2000-, CCITT- oder JBIG2-Dekodierung; JBIG2 unterstützt arithmetischen und Huffman-Text, MMR und gemeinsame globale Dictionaries

JPEG 2000 unterstützt subgesampelte und vorzeichenbehaftete Komponenten, erschlossene Farb- und Sampledeklarationen, eingebettete ICC-Profile, explizite Farbraum-Overrides und separate oder assoziierte Opazität über SMaskInData; seine Komponentenwerte werden auf acht oder sechzehn Bits normalisiert, und sein Bild-Decode-Array wird ignoriert

Eingebettete oder explizite Lab/XYZ-ICC-Profile nutzen physische Komponentenbereiche; assoziierte Opazität wird aus den normalisierten gespeicherten Samples entfernt, bevor die physische Koordinatenabbildung angewandt wird, unter Bewahrung der Lab-Offset-Kanäle

Der Graphics-State-SMask unterstützt Alpha- und Luminosity-Gruppen, Backdrop-Farben, Form-Matrizen, Saved-State-Wiederherstellung sowie Sampled-, Exponential-, Stitching- und begrenzte Calculator-Transferfunktionen; die eigene Soft Mask eines Bildes überschreibt die Graphics-State-Soft Mask

Alle sechzehn standardmäßigen PDF-Blend-Modi werden unterstützt; Form- und Seitengruppen unterstützen isolierte und nicht-isolierte Komposition, Object-Knockout sowie DeviceGray, DeviceRGB, DeviceCMYK, CalGray, CalRGB oder ein-, drei- und vierkomponentige ICCBased-Blending-Spaces

Kalibrierte Gruppen behalten native Komponentenwerte bis zu einer Gruppengrenze und akzeptieren Geräte- oder Lab-Quellfarben über inverse kalibrierte Transforms; Lab selbst ist kein gültiger Blending-Space

Kalibrierte Luminosity-Masks behalten ihre Gruppenkoordinaten und werten CIE XYZ-Y aus, einschließlich Gruppenopazität und Backdrop-Farben, bevor die Transferfunktion angewandt wird

Knockout-Compositing hält die geometrische Form eines Objekts getrennt von der Soft-Mask-Opazität; Stencil-Löcher bewahren vorherige Objekte, während ein gemaskter Pfad sie in seiner gesamten gezeichneten Geometrie ersetzt

Verschachtelte Knockout-Gruppen behalten die Vereinigung der geometrischen Formen ihrer Kinder, einschließlich Objekte mit Opazität null; nicht-isolierte Kindergruppen nutzen den anfänglichen Backdrop der umschließenden Knockout-Gruppe

CMYK-Gruppen bewahren komplementäre CMY- und Schwarzkomponenten in separaten begrenzten Bildebenen und konvertieren das kombinierte Ergebnis an Gruppengrenzen; nicht separierbare Blend-Modi behalten oder ersetzen Schwarz gemäß dem gewählten Modus

Nicht-isolierte Gruppen rendern einen zusätzlichen begrenzten Opazitätsdurchlauf, entfernen den anfänglichen Backdrop-Anteil und wenden ankommende Gruppen-Alpha und Blend-Modus einmal an; Seitentransparenzgruppen nutzen eine isolierte Surface, bevor sie auf den Seitenhintergrund komponiert werden

Eine nicht-isolierte Form erbt ihren umschließenden Blending-Space; ein expliziter Gruppen-CS-Eintrag schaltet den anfänglichen Backdrop nicht auf einen anderen Space um

Vorhandene normale Anmerkungs-Appearances werden von ihrer transformierten BBox auf das Rect eingepasst; RenderAnnotations=false lässt Appearances in beiden Verwendungen weg

Usage hat den Default hruView, der Hidden- und NoView-Annotationen sowie unbekannte Annotationstypen mit gesetztem Invisible überspringt; ISO-32000-Standardannotationstypen, einschließlich PDF-2.0-RichMedia und Projection, mit unterstützten normalen Appearances bleiben sichtbar, wenn nur Invisible gesetzt ist

Die RichMedia- und Projection-Abnahme deckt vorhandene statische normale Appearances mit gültigen Medien-Assets oder einer assoziierten Default-3D-Ansicht ab; Medienwiedergabe und interaktive 3D-Aktivierung liegen außerhalb dieses Rasterpfads

hruPrint zeichnet nur Annotationen mit gesetztem Print und klarem Hidden; Invisible unterdrückt unbekannte Annotationstypen in beiden Verwendungen, NoView unterdrückt kein Drucken, und NoZoom ändert die gedruckte Appearance-Größe nicht

Sichtbare Annotationen brauchen einen vorhandenen, unterstützten normalen Appearance-Stream; der Renderer synthetisiert keine Appearances aus Annotationsmetadaten oder Feldwerten

Für View-Ausgabe entfernt Annotations-NoZoom den Render-Scale aus der Appearance-Größe, unter Bewahrung von UserUnit; NoRotate hält die eingepasste Appearance in beiden Verwendungen über Seitenrotation hinweg aufrecht, und beide bewahren den transformierten Anker oben links im Rect und den Seitenclip

Textannotationen mit vorhandenen normalen Appearances verhalten sich in der View-Ausgabe wie NoZoom und NoRotate, unabhängig von ihren expliziten Flags; die Print-Ausgabe behält ihr NoRotate-Verhalten bei und ignoriert NoZoom

Die Verwendung steuert statische Rastersichtbarkeit und Annotationsgeometrie; nur auf Interaktion wirkende Flags erzeugen kein Hover- oder Editing-Verhalten, und der vorhandene Extraktionsberechtigungs-Callback bleibt erforderlich, ohne Druckberechtigung zu gewähren

Optional Content in statischer Ausgabe

Das Rendering nutzt die Default-OCProperties/D-Konfiguration des Katalogs, initialisiert Gruppenzustände aus BaseState, wendet ON- und OFF-Overrides an und verwendet passende Intent-Werte bei der Sichtbarkeitsbestimmung

Membership-Dictionaries unterstützen AnyOn, AllOn, AnyOff und AllOff; rekursive VE-Ausdrücke unterstützen And, Or und einoperandiges Not, wobei VE Vorrang vor der einfacheren Policy hat

Null-, nicht verfügbare und veraltete Gruppenreferenzen haben keinen Membership-Effekt; Gruppen außerhalb der Intents der Konfiguration steuern keine Sichtbarkeit, und eine Membership oder ein Ausdruck ohne anwendbare Gruppen lässt Inhalt sichtbar

Verschachtelter /OC-Marked Content, Bild- und Form-XObjects sowie Annotationen respektieren den entstehenden Zustand; verborgene markierte Abschnitte aktualisieren weiterhin Farben, Matrizen, Clipping und Textposition, während verborgene ganze XObjects und Annotationen übersprungen werden dürfen

Gewöhnliche Marked-Content-Property-Dictionaries bleiben nutzbar, einschließlich verschachtelter Inline-Werte; Content-Arrays bewahren den Marked-Content-Zustand über ihre Komponentenstreams hinweg, und Kindstreams behalten ihre eigene Marked-Content-Verschachtelung

Eigenständige Final-Form-Rasterung nutzt in beiden Modi, View und Print, die Defaultkonfiguration, ohne interaktive AS-Usage-Empfehlungen automatisch anzuwenden, wie in ISO 32000-1:2008 Abschnitt 8.11.4.5 festgelegt; ein expliziter ViewerState aktiviert View-, Print-, Export-, Zoom-, Language- und User-Empfehlungen mit persistenten manuellen Auswahlen und temporärem Event-Zustand

Fehlende Optional-Content-Eigenschaften oder ein nil geliehener Katalog lassen Optional-Content-Strukturen ohne Sichtbarkeitseffekt; fehlerhafte aktive Memberships, Ausdruckszyklen und konfigurierte Arbeits-, Speicher- oder Rekursionslimits scheitern vor der PNG-Veröffentlichung

Affine Appearance-Matrizen und BBox-Ursprünge ungleich null behalten ihre normale Anpassung unter diesen Flags; ein extrem kleiner Render-Scale kann Cairos anfängliche Seitenmatrix weiterhin numerisch nichtinvertierbar machen

Die gerenderte Seite nutzt die MediaBox/CropBox-Schnittmenge, geerbte Seitenboxen und Vierteldrehungs-Rotate sowie die UserUnit der Seite; Scale 1 erzeugt ein Pixel pro effektivem Seitenpunkt, mit nach oben gerundeten Surface-Abmessungen

Der sh-Operator zeichnet funktionsbasierte, axiale und radiale Shadings (ShadingTypes 1–3), mit Zwei-Eingaben-Domains, Shading-Matrizen, Radialkreis-Auswahl, Extend-Endpunkten, BBox und vorhandenen Pfadclips

Unterstützte Farb- und Skalarfunktionsarrays konvertieren über Geräte-, kalibrierte, ICC-Lab/XYZ- und Separation/DeviceN-Quellfarben; aktuelle Füllopazität, Blend-Modi, Graphics-State-Soft-Masks und Transparenzgruppen-Knockout gelten für das entstehende Shading

Der aktuelle Pfad und die Farbe bleiben erhalten; das Shading-Background wird von sh ignoriert, und AntiAlias ist ein Gerätehinweis mit Farbabtastung an Pixelzentren

Nicht unterstützte ExtGState-Einträge und nicht unterstützte Content-Operatoren bleiben außerhalb dieses Profils

Dreiecksnetz-Shadings

ShadingTypes 4 und 5 zeichnen freie und Gitter-Gouraud-Dreiecksnetze mit Kantenwiederverwendung, beliebiger Gittergeometrie, bytealignierten Vertex-Records, Koordinatenpräzision bis 32 Bits und Komponentenpräzision bis 16 Bits

Vertexkomponenten werden an Gerätepixelzentren interpoliert, bevor Farben konvertiert werden; eine optionale Ein-Eingabe-Funktion oder ein Komponentenfunktionsarray wertet den interpolierten Parameter aus, einschließlich kalibrierter, ICC- und spezieller Farbräume

Indexed-Quellen runden interpolierte Indizes auf den nächsten Paletteneintrag; hexadezimale Lookup-Strings dekodieren einmalig, mit Leerraum, Ziffern in gemischter Schreibweise und ungeradem abschließendem Nibble-Padding, während literale Lookup-Strings ihre dekodierten Bytes behalten

Aktuelle Transforms, Clipping, BBox, Füllopazität, Blend-Modus, Soft-Masks, nicht zeichnende Farbstoffe und Gruppenknockout gelten für das fertige Netz; behaltene Stream-Bytes, die temporäre Seiten-Surface und zwei Gitterzeilen gehen in die Working-Memory-Zulassung ein

Vertex-Parsen, Dreiecksrasterung und Funktionen teilen sich aggregierte Operationen und Abbruchabfragen; fehlerhafte oder abgeschnittene Records und unvollständige Gitterzeilen scheitern vor der Ausgabeveröffentlichung

Gezielte Abnahme prüft geschlossene baryzentrische Gleichungen und getrennte MuPDF- und Poppler-Ausgaben; Nachweis-Records halten Source-Reader-Fehler für Vertex-Padding, ungenutzte Flag-Bits und Netztransparenz getrennt und nutzen explizite alternative Reader-Gleichungen für nicht zeichnende Farben und normalisierte Indexed-Werte

Coons- und Tensor-Patch-Netze

ShadingTypes 6 und 7 zeichnen kubische Coons-Grenzen und Tensor-Kontrollnetze, mit Wiederverwendung der Vorderkante, bytealignierten Records, Flag-Semantik in den unteren zwei Bits und denselben Koordinaten- und Komponentenpräzisionen wie Dreiecksnetze

Eckkomponenten werden bilinear in Patchparametern interpoliert, vor optionalen Funktionen und Farbkonvertierung; Coons-Grenzen werden zu einem äquivalenten bikubischen Bernstein-Netz angehoben, dessen zweite Ableitungsgrenzen Unterteilungen mit höchstens 0.125 Ausgabepixel-Geometriefehler wählt

Polynomiale Inversion verfeinert Pixelparameter; gefaltete Abdeckung wählt den größten v-Parameter und dann bei gleichem v den größten u-Parameter, während spätere Patches frühere Farben ersetzen, bevor das fertige Shading die Objekttransparenz erhält

Der gemeinsame Mesh-Compositor wendet Clipping, BBox, Shading-Patterns, nicht zeichnende Farbstoffe, Opazität, Blending, Soft-Masks und Gruppenknockout an; zwei Unterteilungszeilen sowie Pixelparameter- und Reihenfolge-Arrays gehen in die aktive Working-Byte-Zulassung ein

Kontrollpunkt-Parsen, Unterteilung, Rasterung und Farb-Funktionen teilen sich Operationslimits und Abbruch; gezielte Abnahme nutzt unabhängige Coons- und Tensor-Gleichungen und kubische Wurzeln für gefaltete Patches, wobei Source-Reader-Fehler getrennt von der gewöhnlichen RGB-Gleichungsseiten-Verifikation erfasst werden

Geerbter Textzustand

Form-, Type3- und Pattern-Kindstreams erben aus ihrem anfänglichen Graphics State das anwendbare Fontobjekt, die Schriftgröße, Zeichen- und Wortabstand, Horizontalskalierung, Durchschuss, Rendering-Modus und Anhebung; eine Kindressource mit demselben Fontnamen ersetzt keine geerbte Schrift, bis ein lokales Tf sie wählt

Gesicherter Graphics State stellt Textparameter wieder her, und TD- und Double-Quote-Operatoren behalten ihre Durchschuss- und Abstandsänderungen für nachfolgende Kindstreams; jedes Kind startet mit eigenen Textmatrizen

Unabhängige Annotations-Appearances starten aus Default-Textparametern, ohne den Endtextzustand des Seiteninhalts zu behalten

Type3-Text im Rendering-Modus 3 trägt keine sichtbare Glyphengrafik bei; der gezielte Type3-Nested-Text-Nachweis hält die Default-Parameter-Abweichung von MuPDF getrennt von den Gleichungen des geerbten Zustands, während Poppler in jenen Fixtures den geerbten Parametern folgt

Tiling- und Shading-Patterns

Pattern-Farbräume unterstützen farbige und farblose Tiling-Patterns, TilingType 1–3, Shading-Patterns, PatternMatrix, Zellen-BBox, positiven oder negativen Abstand, Pattern-Auswahl, Saved-State-Wiederherstellung sowie Fill- oder Stroke-Zeichnung

Farblose Patterns beziehen ihre Komponenten aus einem unterstützten Basisfarbraum und können Bild-Stencils zeichnen; explizite Farbwechsel, farbige Bilder und direkte Shadings innerhalb einer farblosen Definition sind ungültiger PDF-Inhalt und werden ebenso über verschachtelte Forms und Type3-Prozeduren abgelehnt

Gewählte Patterns behalten den Default-Koordinatenraum des Content-Streams, der ihre Definition aufgelöst hat; spätere cm-Operationen und ein geerbtes Pattern, das innerhalb einer Form benutzt wird, ersetzen diesen Ursprung nicht

Definitionen starten mit dem anfänglichen unterstützten Graphics State des Elternteils und Default-Transparenzparametern; Tiling-Definitionen bilden eine nicht-isolierte Nicht-Knockout-Gruppe, während Shading-Definitionen Object-Knockout nutzen

Transparente und überlappende Tiling-Zellen werden gegen den aktuellen Backdrop ausgewertet; ankommende Objekt-Alpha und Blend-Modus greifen einmal beim Zeichnen des fertigen Patterns, einschließlich verschachtelter Patterns, Text, Strichen und Bildmasken

Das ExtGState des Shading-Patterns ergänzt unterstützte Shading-Parameter, einschließlich Opazität und Soft-Masks; Background wird vor dem Shading gezeichnet, die BBox clippt beide Beiträge, und nicht zeichnende None-Farben tragen weder Farbe noch Form bei

Die Pattern-Auswertung erlaubt zwei Seiten-Surfaces und dekodierten Zelleninhalt, begrenzt die Aufzählung sichtbarer Zellen auf den aktuellen Clip und fragt Abbruch beim Zeichnen von Zellen und beim Entfernen des Backdrop-Anteils ab

Gezielte Fixtures vergleichen geschlossene Koordinaten-, Farb- und Compositing-Gleichungen mit nativen Pixeln und unabhängiger Reader-Ausgabe; Nachweisdateien behalten Reader-Unterschiede für geerbte Form-Pattern-Ursprünge, Shading-Pattern-ExtGState-Opazität und nicht zeichnende None-Farben, mit separaten gewöhnlichen Vektor-Gleichungsseiten für diese Fälle

CID-schlüsselige CFF-Schriften

Eingebettete CIDFontType0-Schriften lösen echte CFF-CIDs in eigenständigen und OpenType-Containern auf, einschließlich nicht-identischer Mappings, CID 65535, eingebetteter Encoding-CMaps, vertikaler W2-Ursprünge, transformierter Konturen und Textclipping

Eigenständige CFF-Faces laden per CID, SFNT-umhüllte Faces laden per kompaktem Glyph-Index; die Bridge nutzt das korrekte FreeType-Face-Layout für Linux LP64 und Windows LLP64

Ein nicht gemappter Zeichencode oder eine fehlende angeforderte CID fragt notdefchar und notdefrange für den Originalcode ab und nutzt dann die zwingende CID-0-Glyphe, wenn der Ersatz fehlt; Bereiche haben konstante CID-Ziele, Zeicheneinträge haben Vorrang, und vorhandene Glyphen behalten ihre angeforderte CID

Gezielte Abnahme nutzt deklarierte Polygonkonturen und Ursprungsgleichungen für 28 gültige Quellen, mit separaten MuPDF- und Poppler-Vergleichen und gewöhnlichen RGB-Gleichungsseiten

Nachweisdateien behalten Source-Reader-Unterschiede für CID-schlüsselige OpenType-Glyphenauswahl und weggelassene Notdef-Ersatzungen; die Auslassungs-Alternative wird separat gemessen und ersetzt nicht die erforderliche native Quellgleichung

Grenzen und Abbruch

Exakte eingebaute Type0-Kodierungen decken alle 200 mitgelieferten Kodierungsnamen ab: Identity-H und Identity-V, sechzehn UCS2- und UTF16-Mappings sowie 182 weitere Legacy- und Unicode-Maps mit abgeflachten vertikalen Zeichen-Overrides

Gemischte Ein- bis Vier-Byte-Operanden nutzen per-Byte-Codespace-Grenzen und Longest-Prefix-Wiederherstellung ungültiger Codes; UTF8- und UTF32-Dekodierung und Rückwärtskodierung bewahren ergänzende Skalare und signifikante führende Null-Bytes

Encoding- und ToUnicode-Streams lösen body-usecmap- und Dictionary-UseCMap-Namen oder -Streams auf, mit Dictionary-Vorrang sowie lokalen Zeichen-, Bereichs-, Unicode-Sequenz- und Notdef-Overrides

Jede Kind-CMap behält ihren eigenen Schreibmodus, der auf horizontal fällt, wenn WMode fehlt; expliziter vertikaler Modus wählt geerbte Mappings und die vertikalen Metriken der Schrift

CMap-Vererbung nutzt thread-lokal verschachtelte Tiefengrenzen, ohne das THPDFCMapBounds-Layout zu ändern; Zyklen, fehlerhafte Eltern und überschrittene Tiefe scheitern vor der Ausgabeveröffentlichung, und finally-Blöcke stellen die Grenzen nach Abbruch oder Exceptions wieder her

Der gezielte Nachweis behält benannte UTF8- und UTF32-Quellfehler in einem unabhängigen Reader ohne jene eingebauten Tabellen, verifiziert separate eingebettete Map-Begleiter und erfasst Quelltext-Unterschiede, wenn mehrere Codes dieselbe CID wählen

Tests/Linux/Run-HeadlessLegacyCMapAcceptance.sh baut und testet auf nativem Linux exakte Kodierungsintervalle, Quell-PDFs mit gemischten Breiten, verschachteltes Rendering, Thread-Isolation und Abbruchwiederherstellung

Tests/Linux/Run-HeadlessLegacyCMapWindowsAcceptance.py führt passende native Windows-Executables aus, hält Quell-, Binär-, PNG- und Diagnose-Hashes fest und überträgt feste Aufnahmen dann auf nativen Linux-Speicher für getrennte MuPDF- und Poppler-Prüfungen

Die gepackten Maps bewahren ihre Ressourcen-Hashes und vollständigen Weitervertriebs-Hinweise; führen Sie die CMap-Datenlizenz mit Quell- und Binärdistributionen mit

Hexadezimale Escapes in PDF-Name-Werten und Content-Name-Operanden dekodieren einmalig, bevor Schriften, Farbräume, Blend-Modi und Ressourcen aufgelöst werden; ein durch Dekodierung entstandenes literales Hash bleibt Teil des semantischen Namens

Der gemeinsame Schriftdekoder wendet diese Semantik auf Font-Dictionary-Werte, benannte Kodierungen, Differences-Glyphennamen und CIDToGIDMap an, ohne geliehene Objekte zu verändern oder String-Werte zu dekodieren

Escapte Renderer-Namen nutzen lineare Dekodierung, temporäre Working-Byte-Zulassung, aggregierte Operationslimits und Abbruchabfragen; die gezielte Abnahme vergleicht äquivalente native PNG-Bytes und Text plus unabhängige MuPDF- und Poppler-Ausgaben

Shading-Rasterarbeit und Farb-Funktionen teilen sich aggregierte Operationslimits und Abbruchabfragen; die temporäre Surface und ein exakter Koordinatencache von höchstens 8192 konvertierten Farben gehen in die aktive Working-Byte-Zulassung ein

Die gezielte Shading-Abnahme nutzt geschlossene Geometrie-/Funktions-/Farbgleichungen und separate Vektor-Gleichungsseiten und behält Source-Reader-Unterschiede für BBox-Clipping, entartete Geometrie, Farbkonvertierung, spezielle Farbstoffnamen und Knockout-Tessellation

Optionen begrenzen Surface-Pixel, aktive verwaltete Puffer, kumulative dekodierte Bytes, kodierte PNG-Bytes, Token- und Operatorarbeit sowie rekursive oder Graphics-State-Tiefe

Die Schriftdekodierung nutzt konservative Zulassungszuschläge: 32 MiB vorübergehende Kapazität, das 64-Fache der dekodierten Fontstream-Größe, das 128-Fache rekursiv geprüfter Array-Slots und das Zweifache der behaltenen Decoder-Schätzung im aktiven Aggregat

CID-Tabellen erlauben 65536 behaltene Einträge; die Aufzählung begrenzt echte Charstrings, und Notdef-Arrays gehen in Decoder-Deep-Copy- und behaltene-Byte-Buchhaltung ein

CMap-Parsen und Notdef-Suche teilen sich thread-lokale verschachtelte Eintragsgrenzen und Arbeitsabfragen; Renderer-Scopes teilen sich aggregierte Token- und Operationslimits, und lange lexikalische Scans fragen höchstens alle 256 Bytes ab

Der Interpreter reserviert zudem pro Glyphe Unicode-Sequenzkapazität aus Eingabeoperanden-Bytes und dem längsten ToUnicode-Mapping, bevor Glyph-Records erzeugt werden, damit wiederholte lange Mappings die Working-Memory-Zulassung nicht umgehen können

Ein kleines Working-Memory-Budget kann eine einfache Schrift ablehnen, selbst wenn ihre eventuelle Allokation passen würde; diese Prüfungen decken verwaltete Puffer und CPU-Image-Surfaces ab, während Cairo, Fontconfig, FreeType-Caches und die gesamte Prozess-RSS außerhalb der Buchhaltung liegen

Transparenz-, Soft-Mask-, Backdrop-, Opazitäts- und Object-Knockout-Surfaces gehen in das aktive Surface-Budget ein; Transferfunktionen teilen sich das aggregierte Operationsbudget, ICC und Bildcodecs nutzen konservative Zulassung, und der native JBIG2-Decoder begrenzt Bitmap-/Kontext-Allokation kumulativ und fragt Abbruch während der Dekodierung ab

Komplementäre CMY-, Schwarz- und geometrische Formtraversierungen teilen sich die aggregierten Operations-, Dekodier- und Abbruchgrenzen; Profile, die denselben aufgelösten Stream nutzen, teilen sich einen validierten Transform und eine aktive Zulassungsreservierung, bis das Seitenrendering fertig ist

Behaltene Funktionsstreams, Funktionsauswertung und Graphics-State-Records gehen in die Working-Byte-Zulassung ein; rekursive Tint-Funktionen, mehrdimensionale Interpolation und Calculator-Instruktionen teilen sich Operations- und Abbruchlimits

Das geliehene Cancellation-Token wird während begrenzter Dekodierung, Tokenisierung, Operatoren, Glyph-Resolver-Aufrufen, Bildzeilen, Rekursion und PNG-Kodierung sowie vor der Veröffentlichung abgefragt; die Lebensdauer besitzt der Aufrufer

Der Renderer prüft die Extraktionsberechtigung über die geliehene Dokumentpolicy und behält Quellobjektwerte und Quellbytes

Ausgabebesitz

HPDFRenderHeadlessPagePNG schließt Rendering und PNG-Kodierung privat ab, bevor in einen Stream im Aufruferbesitz geschrieben wird; ein abschließender Stream-I/O-Fehler kann bereits akzeptierte Bytes behalten

HPDFRenderHeadlessPagePNGFile prüft die Quellidentität, erzeugt exklusiv eine Staging-Datei im Zielverzeichnis, flusht sie, prüft Identität und Abbruch erneut und ersetzt die Destination atomar

Die Windows-Veröffentlichung nutzt höchstens acht atomare Ersetzungsversuche und sieben Wartezeiten von 1, 2, 4, 8, 16, 16 und 16 Millisekunden und wiederholt nur Zugriffsverweigerungs-, Sharing-Verletzung- und Lock-Verletzung-Fehler; Abbruch wird vor jedem Versuch und auf beiden Seiten jeder Wartezeit geprüft

Fehlgeschlagene Windows-Veröffentlichung meldet den erfassten finalen Windows-Fehlercode über EHPDFHeadlessRenderError; Abbruch behält die Abbruchdiagnose des Renderers, und keiner der Pfade löscht die vorhandene Destination oder fällt auf nicht-atomares Kopieren zurück

Rendering-, Budget-, Abbruch- und Staging-Fehler bewahren eine vorhandene Destination und entfernen eigene unveröffentlichte Staging-Dateien; Quellpfad- und Hardlink-Aliase werden abgelehnt

Abnahme

Die Windows-Laufzeitabnahme nutzt passende native Konsolen-Executables und eine isolierte, per SHA256 gepinnte portable DLL-Import-Closure; ein separater WSL-Prozess führt unabhängige MuPDF- und Poppler-Pixel-, Gleichungs- und Geometrieprüfungen gegen die unter Windows erzeugten PNG-Dateien aus

Windows-Standardfont-Ersätze nutzen explizite Cairo-GDI-Faces für Unicode-Text und echte Konturen, einschließlich Clipping und Fill-und-Stroke-Modi; eingebettete Schriften behalten ihr FreeType-Glyphmapping

OpenJPEG-Aufrufe nutzen die Windows-stdcall-ABI und Win32-dekorierte Exporte, während Stream- und Message-Callbacks die C-Callback-Konvention behalten

Tests/Linux/Run-HeadlessCairoAcceptance.sh führt frische native ELF-Builds aus, leert DISPLAY und WAYLAND_DISPLAY, weist direkt gelinkte Desktop-Bibliotheken zurück und lässt unabhängige pypdf/MuPDF-Oracles laufen

Die Fixtures üben Standardschriften, Unicode-TrueType, Type3, alle Text-Rendering- und Blend-Modi, Alpha und Knockout, RGB-Transparenzgruppen, Sampletiefen und Decode, Bildmasken und Matte, Indexed- und ICC-Farben, terminale Codecs, AES-verschlüsselte Filterketten, Seitengeometrie, Annotations-Transforms, Budgets, Abbruch, Quellerhaltung und atomare Ausgabe aus

Siehe THPDFHeadlessRenderResult für Zähler und EHPDFHeadlessRenderError für Fehlerbehandlung