Windows-Formularfüllung mit original getipptem Rich Text

Windows-Dateijobs und hpdf_document_execute_json_v1 akzeptieren forms.fill-Requests, die richTextRuns neben gewöhnlichen Text-, Choice- und Button-Updates enthalten; alle Felder teilen sich ein authentifiziertes Kandidaten-PDF

Die originalen Typed Runs erreichen den nativen Appearance-Composer direkt; die AP-Generierung läuft nicht über die serialisierte RV-Farbdarstellung; einfaches V, standardkonformes Rich-RV und tatsächliches AP werden gemeinsam vorbereitet

Request

{
  "schemaVersion": 1,
  "type": "forms.fill",
  "fontFamilies": ["DejaVu Sans", "DejaVu Serif Condensed"],
  "fields": [
    {"name": "Input", "richTextRuns": [
      {"text": "Original typed precision", "fontFamily": "DejaVu Sans",
       "fontStyle": "regular", "fontSize": 12.123456,
       "color": [0.123456, 0.234567, 0.345678]},
      {"text": "Another paragraph", "fontFamily": "DejaVu Serif Condensed",
       "fontStyle": "boldItalic", "fontSize": 14.125,
       "paragraphBreakBefore": true, "alignment": "center",
       "underline": true, "strikeOut": false}
    ]},
    {"name": "Plain", "value": "Changed scalar"},
    {"name": "Choice", "values": ["B", "C"]},
    {"name": "Check", "value": "Yes"}
  ]
}

Jedes Feld liefert richTextRuns oder einen Skalarwert bzw. mehrere Werte; ein optionaler value neben richTextRuns muss exakt dem nativ abgeleiteten Klartext entsprechen, einschließlich Carriage Returns zwischen getippten Absätzen; serialisiertes richText ist keine Typed-Run-Eingabe

Jeder Run braucht text und akzeptiert fontStyle, fontSize, color, underline, strikeOut, paragraphBreakBefore und alignment; fontStyle ist regular, bold, italic oder boldItalic; alignment ist left, center oder right; RGB-Komponenten sind endliche Zahlen von null bis eins

Run-Größen müssen positiv und höchstens 4096 Punkte sein; eine fehlende Größe verwendet die fontSize des Feldes oder 12 Punkte; die native PDF-Zahlenformatierung gilt weiterhin, während standardmäßiges RV-CSS Farben auf Acht-Bit-Komponenten serialisiert

Appearance-Optionen eines Feldes umfassen fontSize, padding, characterSpacing, wordSpacing und paintWhiteBackground; echte AP-Generierung ist Pflicht, daher ist appearance=false ungültig

Echte Schriftprogramme

Ein fontFamilies-Array auf Feldebene überschreibt das Array der Operation; konfigurierte Arrays enthalten ein bis sechzehn nichtleere, gültige Familienbezeichnungen; der Vergleich ignoriert ASCII-Groß-/Kleinschreibung und vergleicht anderen Unicode exakt; eine explizite run-fontFamily muss zu einer konfigurierten Bezeichnung passen, und eine fehlende Run-Bezeichnung wählt die erste Familie

Ohne fontFamilies bleibt der ursprüngliche Single-Family-Pfad verfügbar; die Font-Callback-Bezeichnung kommt aus der fontFamily des Feldes, der Operation oder DejaVu Sans; ursprüngliche Single-Family-Runs lassen die run-fontFamily weg

Dateijobs ergänzen input, output und fonts; fonts mappt jede konfigurierte Familienbezeichnung auf Dateipfade für regular, bold, italic und boldItalic; geladen werden nur verwendete Stile und der von Skalar-Appearances benötigte Regular-Schnitt; Dateipfade dürfen nicht auf die Ausgabe zeigen

Versionierte C-ABI-Aufrufer nutzen die vorhandene hpdf_form_data_operation_v1-Erweiterung und liefern aus ihrem Font-Callback lesbare hpdf_io_v1-Tabellen zurück; Familienbezeichnungen sind UTF-8, Stilwerte sind 0 bis 3; alle echten Programme werden vor dem Zusammensetzen der Appearances in begrenzte eigene Bytes kopiert

Die ursprünglichen V1-Symbole, Basisstrukturgrößen und optionalen Erweiterungs-Offsets bleiben unverändert; Familien-/Stil-Assets werden innerhalb eines Requests gecacht und feldübergreifend geteilt, ohne dieselbe eigene Allokation mehrfach zu belasten

Opt-in fallbackFontFamilies=true wendet Whole-Grapheme-Fallback zwischen den tatsächlich gelieferten Familien an; Typed Runs können ein geordnetes fontFamilyCandidates-Array mitführen, wobei deklarierte Kandidaten vor der konfigurierten Reihenfolge geprüft werden; siehe Windows-Fallback auf mitgelieferte Rich-Font-Familien für Request-Vererbung und Callback-Laden mit vier Stilen

Aktueller Graph und Veröffentlichung

Ohne InputIO verwendet die C ABI ihre eigene geladene Revision und den tatsächlichen Pending-Graphen; ein optionales InputIO liefert ein Ersatz-PDF, das vor jedem Font-Callback privat kopiert und authentifiziert wird; weder eine Mutation der geliehenen Eingabe noch eine fehlgeschlagene Ersetzung darf den committeten Kontext verändern

OutputIO und ResultIO sind Pflicht; das tatsächliche Kandidaten-PDF und das Ergebnis-JSON müssen beide erfolgreich abschließen, gefolgt vom letzten Abbruch-Checkpoint, bevor die C ABI Dokument und Quelle austauscht

Ein fehlgeschlagener Callback kann bereits Kandidaten-Bytes erhalten haben; Aufrufer müssen diese Bytes verwerfen, wenn der zurückgegebene Status ungleich null ist; der zuvor committete Bibliothekskontext bleibt unverändert

Dateijobs stufen den vollständigen Kandidaten und die begrenzte Antwort ein, bevor die angeforderte Ausgabe atomar ersetzt wird; eine fehlende Schrift, ein Policy-Fehler, Abbruch oder Kapazitätsfehler bewahrt das vorhandene Ziel

Policies und Ergebnis

Vorhandene Signaturintegrität, DocMDP P1/P2/P3, FieldMDP-Sperren, Read-only-Flags und AES-Formularfüllberechtigungen werden über die native authentifizierte Engine durchgesetzt; signaturePolicy akzeptiert dieselben expliziten Trust-, Timestamp- und Widerrufseinstellungen wie Windows-Formularimporte

Ein Read-only-Update mit gleicher Eingabe gelingt nur, wenn tatsächliche AP-Operatoren, Schriften, Ressourcen und Feldwerte äquivalent sind; komprimierte AP-Streams und nichtkanonisches äquivalentes RV werden unterstützt; eine echte Stiländerung bleibt eine Änderung, selbst wenn ihre RV-Farbe auf denselben CSS-Wert quantisiert

Ein wirklich unveränderter Request veröffentlicht exakte Bytes der vorbereiteten aktuellen Revision nach der Policy-Authentifizierung; Pending-Graph-Änderungen werden vor dem Vergleich in dieser aktuellen Revision materialisiert

Erfolgreiche Antworten enthalten typedRichText=true, typedRichProfile=original-typed-runs-v1, updated, fieldCount, fontBytes und fields aus dem tatsächlichen vorbereiteten Kandidaten; formDataExchange.typedRichFill beschreibt diese implementierten Einstiegspunkte

Jedes fields-Element behält den gewöhnlichen Namen, den Skalarwert und die fieldType-Zusammenfassung; eine durch ein Array gestützte Choice hat in dieser Zusammenfassung einen leeren Skalarwert, während ihre volle Auswahl in der gespeicherten PDF und im nachfolgenden FDF/XFDF-Export bleibt

Die direkte ExecuteLoadedOperation-Job-Fassade und die Legacy-HPDFDocRunJob-Handle/Font-Callback-Erweiterung bleiben separates Vorhaben; diese Bindung ergänzt keinen Annotation-, Embedded-File-, Action- oder Incremental-FDF-Austausch

Verwandte Themen

FillTypedData, Windows-Transaktion, Native gemischte Typed Updates, Windows FDF/XFDF-Austausch