Fallback de polices riches à familles fournies sous Windows
Les file jobs Windows et hpdf_document_execute_json_v1 prennent en charge un fallback opt-in entre les familles de polices fournies par l'appelant pour les imports FDF/XFDF riches et les runs riches typés d'origine ; le fallback sélectionne une famille qui couvre le graphème entier, y compris les parties traversant les frontières de styles riches
La valeur par défaut reste stricte : fallbackFontFamilies est false et un glyphe requis manquant échoue normalement ; fournir une liste ne sélectionne pas silencieusement des polices système installées
Requête typée
{
"schemaVersion": 1,
"type": "forms.fill",
"fontFamilies": ["Primary", "Sans", "Serif"],
"fallbackFontFamilies": true,
"fields": [{"name": "Input", "richTextRuns": [
{"text": "A\u03a9a\u0301", "fontStyle": "regular",
"fontFamilyCandidates": ["Unavailable", "Primary", "Serif", "Sans"]}
]}]
}
fontFamilies contient de une à seize étiquettes configurées distinctes ; les lettres ASCII se comparent sans casse et les autres points de code Unicode se comparent exactement ; les fontFamilies et fallbackFontFamilies au niveau du champ priment sur leurs valeurs par défaut d'opération pour forms.fill
Un run typé peut spécifier de un à seize fontFamilyCandidates ordonnés quand le fallback à familles configurées est activé ; les noms inconnus restent dans les métadonnées rédigées et sont sautés pendant la résolution des programmes fournis ; si fontFamily est absent, le premier candidat déclaré configuré devient la famille du run
Une liste de candidats déclarée contrôle la préférence avant l'ordre des familles configurées ; dans cet exemple, une police Primary sans Omega sélectionne Serif avant Sans quand les deux alternatives fournies couvrent le graphème entier
Import XML riche
Pour forms.import, utilisez les propriétés fontFamilies et fallbackFontFamilies au niveau de l'opération ; le décodeur XHTML borné préserve chaque liste CSS font-family inline et le véritable compositeur d'apparences applique cet ordre aux programmes de polices fournis
<span style="font-family:Primary,Serif,Sans;font-weight:bold">AΩá</span>
Les chaînes RV FDF et le value-richtext XFDF utilisent tous deux ce chemin ; le profil inline-xhtml-font-families-v1 existant reste inchangé, tandis que le comportement réel du fallback est rapporté séparément
Vrais octets de polices
Le callback de police THPDFCABIFormDataOperationV1 existant reçoit chaque étiquette canonique de famille configurée et l'identifiant de style regular, bold, italic ou boldItalic ; il retourne la table read-IO bornée d'origine et ses octets sont copiés dans un stockage possédé
Les file jobs lisent les mêmes programmes famille/style depuis leur objet fonts existant ; pour chaque style riche utilisé, le binding charge les programmes candidats configurés avant de préparer la transaction ; les assets correspondants sont partagés entre les champs typés
Les layouts IO et opération V1 et les symboles exportés existants restent inchangés ; les budgets globaux d'assets, d'octets de polices, de mémoire, de champs, d'objets, de résultats et de sortie restent appliqués ; les échecs de callbacks restent sticky et les checkpoints d'annulation couvrent parsing, chargement, préparation et publication
Transactions et limites
L'authentification AES, la préservation des révisions signées, DocMDP, les verrous de champs et les vérifications read-only utilisent la transaction authentifiée existante ; des valeurs riches, styles, polices et sémantiques d'apparences à entrée identique peuvent produire un no-op identique octet par octet, y compris pour les champs read-only
Les callbacks PDF et JSON doivent tous deux réussir avant que le contexte courant ne change ; jetez les octets candidats émis après tout statut non nul ; les file jobs préparent le candidat complet avant de remplacer la cible
formDataExchange.suppliedFamilyFallback rapporte default=false, richOnly=true, wholeGrapheme=true, fontFamilyCandidates=true, maxCandidates=16 et candidateOrder=declared-before-configured
Cette fonctionnalité s'applique au contenu riche ; le fallback scalaire ordinaire, de labels de choix et de captions de boutons reste une capacité séparée ; par exemple, une première police de subset sans le glyphe de caption de checkbox a toujours besoin d'une police scalaire appropriée ou d'une future prise en charge du fallback scalaire
Le remplissage riche direct de jobs chargés, l'extension plus ancienne de callback de handle/font de job, la mise en page CSS arbitraire, les feuilles de style externes et les échanges FDF/XFDF supplémentaires d'annotations, de fichiers, d'actions ou incrémentaux restent un travail séparé
Sujets associés
Remplissage riche typé d'origine, Échange de form-data Windows, Transport de polices versionné, Familles fournies natives