Verlustfreie leere Choice-Werte in XFDF
Ein Choice-Feld kann keine ausgewählten Optionen haben oder eine Option auswählen, deren Export-Wert der leere String ist; diese Zustände erzeugen unterschiedliche PDF-Feldwerte und müssen während eines Export/Import-Round-Trips unterschiedlich bleiben
Leere Auswahl und leerer Export-Wert
HotPDF exportiert ein leeres Wert-Array mit einem expliziten Extension-Attribut im Namespace https://www.loslab.com/hotpdf/xfdf/
<xfdf xmlns="http://ns.adobe.com/xfdf/" xmlns:hpdf="https://www.loslab.com/hotpdf/xfdf/">
<fields>
<field name="Choice" hpdf:empty-values="true"><value/></field>
</fields>
</xfdf>Das Attribut repräsentiert ein leeres Array, sodass der Import dieses Felds seine ausgewählten Optionen leert
Ein unmarkiertes leeres value behält seine gewöhnliche Bedeutung: Es repräsentiert den leeren String und wählt die passende leere Export-Option, wenn diese Option existiert
<field name="Choice"><value/></field>Ein Feld, das nur seinen Namen enthält, behält das bestehende Name-only-Verhalten und wird keine explizite Löschung
Namespace- und Eingabevalidierung
Der Importeur identifiziert die Extension über ihren expandierten Namespace-Namen, sodass das Präfix von hpdf abweichen kann; ein unqualifiziertes Attribut oder ein Attribut in einem anderen Namespace fordert keine Löschung an
Der Extension-Wert muss exakt true sein, mit entweder keinem value-Element oder einem leeren value-Element; kollidierende nichtleere Werte, wiederholte Werte und Rich-Text-Werte werden abgelehnt
Die Namespace-Deklaration und das Extension-Attribut zählen gegen die bestehenden Objekt- und Byte-Budgets; Abbruch- und Transaktionsprüfungen bleiben wirksam
Interoperabilität
Dieses Attribut ist eine HotPDF-Erweiterung und keine Adobe-XFDF- oder ISO-Extension-Deklaration; andere Consumer dürfen es ignorieren und den leeren Wert nach ihrem eigenen Verhalten interpretieren
Einen HotPDF-bewussten Consumer verwenden, wenn der Unterschied zwischen keiner Auswahl und einer Leerstring-Auswahl einen Round Trip überleben soll
Native, Job- und Callback-APIs
Dieselbe Repräsentation gilt für den nativen Form-Data-Austausch und die bestehenden Windows- und Linux-JSON-/Callback-Einstiegspunkte; sie fügt den versionierten V1-Callback-Records keine Felder hinzu
Windows-Form-Data-JSON-Limits nutzen formData, während Linux-Form-Data-JSON-Limits formDataLimits nutzen; den dokumentierten Key für die Ziel-API verwenden
Ein unveränderter Import bewahrt die Original-Datei-Bytes, wenn keine ausstehenden Dokument-Editierungen vorliegen; bestehende ausstehende Editierungen bleiben Teil des vorbereiteten Dokuments, und die Veröffentlichung behält die bestehenden atomaren Output- und authentifizierten Rechteprüfungen