Saisie de texte longue à partir de l'utilisateur et génération de PDF

Question

J'ai créé une application Web qui peut être considérée comme un formulaire de demande très compliqué. Il y a beaucoup de zones de texte avec une limite de caractères donnée. Après la soumission du formulaire, il se passe diverses choses, dont la génération PDF.

Le texte est interrogé à partir de la base de données et inséré dans le modèle PDF créé dans iReports. Cela fonctionne bien, mais la douleur majeure est le texte qui déborde.

Le nombre maximal de caractères est défini en fonction du texte "moyen". Mais parfois, les gens préfèrent écrire avec CAPS ou ajouter beaucoup de sauts de ligne pour formater leur texte. Celles-ci provoquent alors un débordement du texte de l'utilisateur par rapport à l'espace donné au format PDF. Malheureusement, le document PDF doit ressembler à un vrai formulaire, je ne peux donc pas laisser un espace illimité.

Quel type d’approche avez-vous utilisé pour y remédier?

• Nettoyer / restreindre les entrées de l'utilisateur?
• Calculez l'espace requis du texte en fonction des métriques de police?
• Fournir un aperçu du PDF? (Les utilisateurs trop mauvais ne sont pas autorisés à modifier leur saisie après la soumission ...)

Answer 1

Idéalement, calculez les besoins en fonction de statistiques. Je ne sais pas comment iReports traite le texte, mais avec iText, tout est présenté, vous ne présentez que les données sous forme de document en continu, pour que nous ne craignions pas le débordement de texte.

Toutefois, iReport peut ne pas prendre en charge cette fonctionnalité ou vous devrez peut-être adapter la présentation PDF à certaines limites. J'essayerais de nettoyer l'entrée (c'est-à-dire: si c'est tout en majuscule, minuscule / casse de phrase / casse proprement dit), effacez les espaces. Si le nettoyage de l'entrée ne peut pas être effectué de manière fiable, ou si les gens vont toujours au-delà, je le limiterai également.

En dernier recours, je présenterais le fichier PDF à autoriser par l'utilisateur. En réalité, il ne faut pas donner plus de travail aux utilisateurs, et ils ne le feront pas de toute façon.

Answer 2

Vos propres solutions suggérées à votre problème sont toutes bonnes. Probablement la question la plus importante à laquelle il faut répondre est de savoir à quoi doit ressembler votre PDF lorsque les données à afficher dans un champ ne correspondent pas. Avez-vous déjà besoin de la " réponse complète " pour autre chose? Lorsque vous connaissez la réponse à ces questions, vos options sont réduites.

Par exemple, si un champ doit être limité à 1/2 page et que les utilisateurs entrent parfois plus de 1/2 page de texte, vous pouvez soit   1) limitez les entrées de l'utilisateur - lors de la soumission, calculez la taille (en utilisant les métriques de police comme vous l'avez dit) et refusez la soumission jusqu'à ce qu'elle soit corrigée. Cela suppose que vous puissiez légitimement forcer l'utilisateur à réduire la saisie de ses données.   2) acceptez la saisie de l'utilisateur et tronquez l'affichage de ce rapport. Certains systèmes utilisent " ... " pour indiquer que les données ont été tronquées et peuvent fournir un lien hypertexte (même au sein du PDF) pour obtenir plus d'informations.

Fournir une prévisualisation fonctionnerait vraiment bien, mais uniquement si les utilisateurs sont capables de vérifier et de corriger les erreurs et si votre système peut gérer la charge supplémentaire que cela engendrera.

Answer 3

Avez-vous le contrôle de la police utilisée lors de la génération du fichier PDF? Si oui, je chercherais une police dans la famille Monospace. Cela vous donnera une longueur cohérente pour un nombre donné de caractères, sans tenir compte de la ponctuation, de la capitalisation, etc.