Rich-Text-Namespace-Ressourcen

Der begrenzte XHTML-Decoder speichert jede Namespace-Deklaration auf ihrem deklarierenden Element und löst geerbte Bindings über Parent-Scopes auf, sodass nicht für jedes Kind wiederholt Kopien geerbter Namespace-Arrays anfallen

Default-Namespace-Vererbung, leere Default-Undeclaration, Präfix-Shadowing, Sibling-Isolation, Expanded-Attribut-Eindeutigkeit und das implizite xml-Binding behalten ihr bestehendes Verhalten

Das unterstützte XHTML-Profil validiert weiterhin den aufgelösten Element-Namespace, sodass ein fremder Namespace oder ein undeklariertes Präfix die Elementvalidierung nicht umgehen kann

THPDFHeadlessRichTextDecodeOptions.MaxNodes zählt geparste Objekte weiterhin nach den etablierten Regeln, während MaxCodeUnits, MaxTotalCodeUnits, MaxDepth und MaxRuns ihre Bedeutungen behalten

Die Ressourcenänderung unterstützt bestehende legale XML-Eingaben, ohne ein kleineres Eingabeprofil einzuführen oder geerbte Namespace-Bindings als neu geparste Nodes zu zählen

Standard-FDF-Rich-Werte, die über die Forms-API importiert werden, nutzen denselben Decoder und die konfigurierten Working-Limits des Aufrufers, einschließlich forms.memoryBytes

Ein erfolgreicher Import speichert den Feldwert, das kanonische Rich-XML und die echte Appearance über die bestehende Transaktion; Abbruch, Output-Callback-Fehler und Budget-Ablehnung behalten den committed Dokumentzustand

Kanonisches Rich-XML bewahrt den dekodierten Rich-Wert und die Styles statt der originalen lexikalischen Namespace-Deklarationen oder leeren span-Markups

Siehe Rich-Text-Run-Spacing für authored Run-Semantik und Windows-Form-Data-Austausch für Transaktionsverhalten

Die normalen Tests/Linux/RichTextNamespaces-Consumer decken Namespace-Auflösung, originale Node- und Tiefengrenzen, gestrichelten Abbruch und Retry, Heap-Wachstum und echten Callback-Import-Rollback ab