Natives Glyph-Clipping
HPDFRenderHeadlessPagePNG rasterisiert gefüllte Glyph-Coverage, bevor der aktive PDF-Clip angewendet wird
Eine separate Alpha-Surface erfasst den bestehenden Clip innerhalb ganzzahliger Device-Space-Glyph-Bounds und multipliziert diese Coverage mit der Glyph-Maske, bevor die originale Quelle und der Blend-Operator angewendet werden
Das vermeidet verlorene Glyph-Zeilen an fraktionalen Clip-Grenzen und behält gleichzeitig W/W*, Even-Odd-Löcher, gekrümmte Pfade, transformierten Text, Alpha, Soft Masks und gemusterte Farben
Das Zeichnen behält den PDF-Pfad und den Graphics State des Aufrufers, einschließlich verschachteltem Text- und Form-Rendering-State
Ressourcen-Bilanzierung
Beide Alpha-Buffer und das Glyph-Raster gehen vor der Allokation ins Working-Memory-Budget, und das rohe Glyph-Raster geht ins Pixel-Budget, selbst wenn nur ein kleiner Teil auf der Seite sichtbar ist
Die rohe Glyph-Pixelanzahl wird sicher als Int64 multipliziert und exakt mit dem konfigurierten Pixel-Limit verglichen, bevor eine Alpha-Surface alloziert wird
Die Byte-Schätzung prüft die verbleibende Int64-Kapazität, bevor die rohe Glyph-Pixelanzahl multipliziert wird, auch wenn Aufrufer die konfigurierbaren Pixel- und Memory-Limits anheben
Abbruch wird um Coverage-Erzeugung und finale Komposition herum abgefragt, und Fehler lassen das Ziel unverändert, bis erfolgreiches Rendering abgeschlossen ist
Präzision und Verifikation
Rechteckige Clips werden gegen exakte unabhängige Pixel-Flächen mit maximaler Kanaldifferenz zwei geprüft
Polygon- und Kurvetests vergleichen die Glyph-Komposition mit einem separaten Solid-Fill-Clip-Begleiter mit demselben Limit
Die zugrunde liegende Cairo-Clip-Rasterisierung kann von der exakten Polygonfläche abweichen, einschließlich des behaltenen Dreiecksfalls mit maximaler Differenz sechs bei vier Pixeln auf Skala zwei
Separate MuPDF- und Poppler-Bilder halten ihre eigene Font- und Clip-Rasterisierung fest, statt die native Formel zu definieren