Standard-XFDF-Stamp-Appearance-Transport

Stamp-Annotationen können ihre echten PDF-Appearance-Streams und Ressourcen-Dictionaries über das Adobe-XFDF-appearance-Element exportieren und importieren

Das stamp-typed-xml-v1-Profil nutzt base64-kodierten UTF-8-typisierten XML, wie in der Adobe-XFDF-3-Spezifikation beschrieben; die dekodierte Payload repräsentiert PDF-Objekte statt einer vollständigen PDF- oder FDF-Datei

Gemappte Ressourcen

Das Top-Level-DICT KEY="AP" enthält einen erforderlichen normalen N-Form-Stream sowie optionale R- (Rollover) und D- (Down) Streams

Forms behalten ihre endliche vierstellige BBox, ihre optionale sechsstellige Matrix und den unterstützten Ressourcen-Graphen, einschließlich Fonts und ihrer eingebetteten Programme, Bilder und Soft Masks, Farbräume, Patterns, Shadings, Funktionen und Graphics States

Typisierte Werte umfassen DICT, STREAM, ARRAY, INT, FIXED, NAME, BOOL und NULL; Dictionary-Keys und Name-Werte bewahren ihre semantischen PDF-Namen, und gültige Quell-Nummer-Tokens bewahren Dezimalpräzision

Stream-DATA unterstützt MODE="RAW" oder MODE="FILTERED" mit ENCODING="HEX" oder 7-Bit-ENCODING="ASCII"; RAW behält die kodierten Bytes samt Filter/DecodeParms, während FILTERED dekodierte Bytes ohne veraltete Filtering-Metadaten installiert

Export nutzt RAW-Hexadezimaldaten und regeneriert die Stream-Length aus echten Bytes; authentifizierte verschlüsselte Streams werden vor dem Austausch dekodiert beziehungsweise entschlüsselt und in der gespeicherten Revision korrekt verschlüsselt

Geteilte azyklische Ressourcen werden als äquivalente Werte expandiert und mit unabhängigen Objektreferenzen importiert; dieses Profil bewahrt keine Referenz-Identität

Eingebettete Fontprogramm-Bytes und ihre Embedding-Flags bleiben erhalten, ohne License-Bits zu ändern oder ein anderes Fontprogramm zu substituieren

APIs und Callbacks

HPDFExportHeadlessAnnotationsXFDF und SaveAnnotationsXFDFToFile für native Transaktionen oder die begrenzten Overloads von HPDFXFDFExportAnnotations und HPDFXFDFImportAnnotations für Graph-Adapter im Besitz des Aufrufers verwenden

Die bestehenden Windows-Dateijobs und V1-Callbacks und Linux-V1-Callbacks nutzen ihre bestehenden Annotation-Operationen und Record-Layouts

Capabilities behalten appearanceImport=false für allgemeine Annotation-Appearances und ergänzen stampAppearanceImport=true, appearanceProfile="stamp-typed-xml-v1", appearanceTypes=["stamp"], appearanceDataModes=["RAW","FILTERED"], appearanceEncodings=["ASCII","HEX"] und appearanceResources="acyclic-expanded-graph"

Transaktionen und Limits

Input-XML, Base64, Namen, Stream-Encoding, Ressourcentypen, semantische Dictionary-Keys und Form-Geometrie werden vor der Veröffentlichung validiert; fehlerhafte Daten, Zyklen, erschöpfte kumulative Limits oder Abbruch lassen die vollständige Transaktion fehlschlagen

XFDF-Limits decken Input/Output gesamt, XML- und Graph-Nodes, Tiefe, Stream-Speicherung und Working-Reservationen über die Annotation-Operation ab

Import behält den aktuellen ungespeicherten Graph-State, die AES-R5/R6-Sicherheit und authentifizierte Zertifizierungs-Restriktionen; P1/P2 verweigern Annotation-Änderungen, und P3 bewahrt den originalen signierten Präfix und die echte Signatur-Integrität

Ein autorisierter leerer Import liefert null und bewahrt exakte aktuelle PDF-Bytes, wenn keine ungespeicherten Änderungen vorliegen; Dirty-Graph-Änderungen werden gespeichert statt verworfen

Windows- und Linux-Callback-Kontexte übernehmen ein vorbereitetes PDF erst, nachdem PDF-Output, JSON-Ergebnis-Output und die finale Abbruchprüfung erfolgreich sind; fehlgeschlagene oder partielle Callbacks behalten den vorherigen Kontext, und der erste fehlgeschlagene Writer bleibt sticky

Nur-Annotation-Import akzeptiert leere fields-Container und wertlose field-Deklarationen als No-op-Metadaten; echte Form-Werte und Rich-Feld-Updates erfordern die separate authentifizierte Form-Data-Operation

Verbleibende Arbeiten

Allgemeiner Annotation-AP-Transport, Appearance-State-Dictionaries, String-Ressourcenwerte, nichtleere DEFINE/REF-Referenzen, zyklische Graphen, Redact-Overlay-Appearance, Annotation-Ersetzung/-Entfernung und FDF-Annotation-Austausch bleiben separate Arbeiten

Geometrische und Text-Annotationen ohne transportierte Stamp-Appearance behalten ihr bestehendes Verhalten; diese Operation synthetisiert keine beliebigen Annotation-Appearances und führt keine Actions aus

Der gemeinsame begrenzte Adapter reserviert rohe Annotation-Keys und expandierte AP-Graphen vor der Payload-Konvertierung und reserviert Base64-Whitespace sowie dekodierte DATA, bevor diese Repräsentationen alloziert werden; die PDF-Namen-Konvertierung nutzt lineare Durchläufe mit Abbruch-Checkpoints