Vous consultez actuellement l'aide de la version:

Questions fréquentes (FAQ) sur la mise en page, la prise en charge des scripts, et les plages des formulaires HTML5.

 

Disposition

  1. Pourquoi les champs des codes à barres et de signature ne figurent-ils dans pas dans mon formulaire ?

    Réponse : les champs de codes à barres et de signatures ne sont pas adaptés aux cas de figures impliquant du HTML ou des périphériques mobiles. Ces champs apparaissent comme des zones non interactives. Cependant, AEM Forms Designer propose un nouveau champ de saisie tactile de signature qui peut être utilisé à la place du champ de signature. Vous pouvez également ajouter un widget personnalisé pour les codes à barres et l’intégrer.

  2. Le texte enrichi est-il pris en charge par le champ de texte XFA ?

    Réponse : le champ XFA, qui supporte le contenu enrichi dans AEM Forms Designer, n’est pas pris en charge ; il est généré sous forme de texte normal sans prise en charge du style du texte à partir de l’interface utilisateur. En outre, les champs XFA possédant la propriété comb sont affichés sous forme de champs normaux, bien qu’il existe encore des restrictions quant au nombre de caractères autorisés en fonction de la valeur des chiffres comb.

  3. Existe-t-il des restrictions concernant l’utilisation de sous-formulaires répétables ?

    Réponse : les sous-formulaires répétables avec un nombre initial de zéro ne fonctionnent pas. Une solution consiste à ajouter un script à l’événement formReady qui vérifie le nombre d’instances du sous-formulaire : si le nombre d’instances est égal à zéro, ajoutez une instance et marquez-la comme étant masquée ; sinon, ne faites rien.

  4. Existe-t-il des restrictions concernant l’utilisation de sous-formulaires masqués ?

    Réponse : un sous-formulaire masqué avec une hiérarchie complexe fractionnée sur plusieurs pages génère des problèmes de mise en page. Une façon de contourner ce problème consiste à marquer le sous-formulaire visible au début, puis de le masquer dans un script d’initialisation basé sur une logique ou des données.

  5. Pourquoi des texte sont-ils tronqués ou ne s’affichent-ils pas correctement dans HTML5 ?

    Réponse : lorsque l’espace attribué à un champ de texte constitué d’une illustration ou d’une légende est insuffisant et ne lui permet pas d’afficher le contenu, le texte apparaît tronqué dans le formulaire pour périphériques mobiles généré. Cette troncature est également visible dans la vue de conception d’AEM Form Designer. Bien que cette troncature puisse être prise en charge dans les fichiers PDF, ce n’est pas le cas dans les formulaires HTML5. Pour éviter ce problème, assurez-vous de prévoir un espace suffisant pour qu’un champ de texte constitué d’une illustration ou d’une légende puisse s’afficher sans être tronqué dans le mode de conception de AEM Forms Designer.

  6. Je constate des problèmes de mise en page liés à du contenu manquant ou à des chevauchements. Quelle en est la raison ?

    Réponse : si un élément de texte  ou un élément d’image constitué d’une illustration est chevauché par un autre élément (un rectangle par exemple), le contenu du champ de texte constitué de l’illustration n’est pas visible s’il apparaît plus loin dans le document (dans la vue hiérarchique d’AEM Forms Designer). Le format PDF prend en charge la mise en calque transparente mais ce n’est pas le cas du HTML et des navigateurs. 

  7. Pourquoi certaines polices affichées dans le formulaire HTML sont-elles différentes de celles utilisées lors de la conception du formulaire ?

    Réponse : les formulaires HTML5 n’intègrent pas de polices (contrairement aux formulaires PDF où les polices sont intégrées au formulaire). Pour la version HTML du formulaire à générer comme prévu, assurez -vous que les polices indiquées dans le XDP sont disponibles sur le serveur et sur l’ordinateur client. Si les polices requises ne sont pas disponibles sur le serveur, les polices de secours sont utilisées. De plus, si vous utilisez des polices dans le modèle de formulaire qui ne sont pas disponibles sur le périphérique client, les polices par défaut du navigateur sont utilisées pour le rendu du texte.

  8. Les attributs d’alignement vertical et horizontal sont-ils pris en charge dans les formulaires HTML ?

    Oui, ils le sont. L’attribut d’alignement vertical n’est pas pris en charge dans Internet Explorer et dans le champ multiligne. 

  9. Les formulaires HTML5 prennent-ils en charge les caractères de l’hébreu ?

    Les formulaires HTML5 prennent en charge les caractères de l’hébreu tous les navigateurs, à l’exception de Microsoft Internet Explorer.

  10. Existe-t-il des limites de caractères dans les champs numériques des formulaires HTML5 ?

    Réponse : oui, les formulaires HTML5 sont soumis à certaines limitations. Si le nombre de chiffres dépasse celui indiqué dans la clause d’image, les numéros ne sont pas traduits et s’affichent dans les paramètres régionaux anglais. 

  11. Pourquoi les formulaires HTML sont-ils plus volumineux que les formulaires PDF ?

    De nombreuses structures et objets de données intermédiaires tels que les DOM du formulaire, les DOM de données, les DOM de disposition sont requis pour rendre un XDP sur un formulaire HTML. 

    Pour les formulaires PDF, Adobe Acrobat dispose d’un moteur XTG intégré pour créer des structures de données intermédiaires, et des objets. Acrobat prend également en charge la présentation et les scripts.

    Pour les formulaires HTML5, les navigateurs n’ont pas de moteur XTG intégré pour créer les structures de données intermédiaires, et les objets à partir d’octets bruts XDP. Ainsi, pour les formulaires HTML5, les objets intermédiaires sont générés sur le serveur et envoyés au client. Côté client, les scripts basés sur JavaScript et le moteur de mise en page utilisent ces structures intermédiaires.

    La taille de la structure intermédiaire dépend de la taille du XDP original et des données fusionnées avec XDP.

  12. Existe-t-il des restrictions concernant l’utilisation des tableaux dans mon xdp ?

    Réponse : les tableaux complexes génèrent des problèmes de rendu. 

    • La section (SubformSet) à l’intérieur d’un tableau n’est pas prise en charge.
    • Les lignes d’en-tête ou de pied de page dans certains tableaux sont marquées pour la répétition. Le fractionnement de ces tableaux sur plusieurs pages peut conduire à certains problèmes.
  13. Les tableaux accessibles sont-ils soumis à des restrictions ?

    Réponse : oui, les tableaux accessibles sont soumis aux restrictions suivantes :  

    • Les tableaux imbriqués et le sous-formulaire à l’intérieur d’un tableau ne sont pas pris en charge.
    • Les en-têtes sont uniquement pris en charge pour la ligne supérieure ou les colonnes de gauche du tableau. Les en-têtes ne sont pas pris en charge pour les éléments de mi-tableau. Vous pouvez appliquer des en-têtes à plusieurs lignes et les en-têtes de colonne sont pris en charge si toutes les lignes et colonnes sont associées à la ligne la plus élevée ou la colonne la plus à gauche du tableau.
    • Rowspan et colspan ne sont pas pris en charge depuis un emplacement aléatoire du tableau.
    • Vous ne pouvez pas dynamiquement ajouter ou supprimer l’occurrence des lignes contenant des éléments possédant une valeur rowspan supérieure à 1.  

     

  14. Dans Designer, un utilisateur peut configurer les propriétés personnalisées d’aspect des boutons radio et des cases à cocher. Lors du rendu des formulaires, les formulaires HTML5 prennent-ils en compte ces propriétés personnalisées d’aspect ?

    Réponse : Les formulaires HTML5 ignorent les propriétés personnalisées d’aspect des boutons radio et des cases à cocher. Les boutons radio et les cases à cocher s’affichent selon les spécifications du navigateur sous-jacent.

  15. Lorsqu’un formulaire HTML5 est ouvert dans un navigateur pris en charge, la bordure des champs placés de manière adjacente n’est pas alignée correctement ou les sous-formulaires se chevauchent. Lorsque le même formulaire HTML5 est prévisualisé dans Forms Designer, les champs et la mise en page semblent correctement alignés et les sous-formulaires apparaissent dans la bonne position. Comment corriger le problème ?

    Lorsqu’un sous-formulaire peut enchaîner un contenu et qu’il présente un élément de bordure masqué, la bordure des champs placés de manière adjacente n’est pas alignée correctement ou les sous-formulaires se chevauchent. Pour résoudre le problème, vous pouvez supprimer ou commenter les éléments <border> masqués du fichier XDP correspondant. Par exemple, l’élément <border> suivant est marqué comme commentaire :

    <!--<border>
       <edge presence="hidden"/>
       <corner thickness="0.175mm" presence="hidden"/>
    </border> -->

Script

  1. Existe-t-il des restrictions de mise en œuvre JavaScript pour les formulaires HTML ?

    Réponse :

    • La prise en charge du script xfa.connectionSet est limitée. Pour connectionSet, seul l’appel côté serveur du service Web est pris en charge. Pour plus d’informations, voir Prise en charge des scripts.
    • Il n’existe aucune prise en charge de $record et $data dans les scripts côté client. Cependant, si les scripts sont constitués de blocs formReady ou layoutReady, ils fonctionnent toujours car ces événements s’exécutent côté serveur.
    • Les scripts spécifiques des éléments XFA constitués d’illustrations (ou les éléments de texte constitués de légendes quand il s’agit de champs) ne sont pas pris en charge.
  2. Existe-t-il des restrictions concernant l’utilisation de formCalc ?

    Réponse : seul un sous-ensemble de scripts formCalc est actuellement implémenté. Pour plus d’informations, voir Prise en charge des scripts.

  3. Existe-t-il une convention de dénomination recommandée et des mots-clés réservés à éviter ?

    • Dans AEM Forms Designer, il est recommandé de ne pas faire commencer le nom d’un objet (tel qu’un sous-formulaire ou un champ de texte) par un tiret bas (_). Pour utiliser le tiret bas (_) au début du nom, ajoutez un préfixe à sa suite,  _<prefix><objectname>.
    • Toutes les API des formulaires HTML5 API sont des mots-clés réservés. Pour les API/fonctions personnalisées, utilisez un nom différent de celui des API de formulaires HTML5
  4. Les formulaires HTML5 prennent-ils en charge les champs flottants ?

    Oui, les formulaires HTML5 prennent en charge les champs flottants. Pour permettre l’utilisation de champs flottants, ajoutez la propriété suivante au profil de rendu :

    Remarque :

    Le flottement des champs n’est pas activé par défaut. Vous pouvez utiliser Forms Designer pour définir la propriété de flottement des champs.

    1. Ouvrez CRXde lite et accédez au nœud /content/xfaforms/profiles/default.

    2. Ajoutez une propriété mfDataDependentFloatingFieldDans et définissez la valeur de la propriété sur true.

    3. Cliquez sur Enregistrer tout. Désormais, les champs flottants sont activés pour les formulaires HTML à l’aide du profil de rendu mis à jour. 

      Remarque :

      Pour activer les champs flottants pour un formulaire spécifique sans mettre à jour le profil de rendu, transmettez la propriété mfDataDependentFloatingField=true en tant que paramètre d’URL.

Conception XDP

  1. Existe -t-il des mots-clés réservés dans les formulaires HTML5 ?

    Réponse : toutes les API des formulaires HTML5 sont des mots-clés réservés. Pour les API/fonctions personnalisées, utilisez un nom différent de celui des API de formulaires HTML5. Outre les mots-clés réservés, si vous utilisez des noms d’objet qui commencent par un tiret bas (_), il est recommandé d’ajouter un préfixe unique à sa suite. L’ajout d’un préfixe permet d’éviter tout conflit possible avec les API internes des formulaires HTML5. Par exemple, _fpField1

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne