Lorsqu'un formulaire PDF est rempli, les valeurs saisies se fondent dans la mise en page visuelle pour former un artefact scellé. Migrer ces saisies vers un autre modèle implique de ressaisir chaque champ à la main. La solution consiste à traiter les données de formulaire comme un actif portable : extraire les valeurs des champs dans un fichier de données autonome, puis les réinjecter dans une copie vierge du formulaire afin de reproduire toutes les saisies en une seule passe automatique. Ce cycle export puis import est ce que [Spire.PDF for JavaScript](/Introduce/pdf-for-javascript.html) offre via `PdfFormWidget.ExportData` et `PdfFormWidget.ImportData`.
Les PDF contiennent souvent plus d'espaces blancs que nécessaire — des documents numérisés avec d'épaisses bordures, des dessins techniques avec des marges généreuses, ou des factures où seul le tableau central compte. Le recadrage de la page est la solution naturelle, mais le faire dans un flux de travail basé sur le navigateur n'est pas simple. Les outils de bureau nuisent à l'expérience web, et l'envoi du fichier à un serveur backend soulève des préoccupations de confidentialité et de conformité.
Un simple entier — le nombre total de pages d'un PDF — se cache derrière un nombre surprenant de décisions concrètes : limites de téléversement, estimation du papier pour l'impression, opérations de fractionnement, barres de progression. La plupart des bibliothèques de rendu PDF se contentent de dessiner les pages et n'exposent pas de comptage simple, et envoyer le fichier à un backend juste pour lire un nombre de pages ajoute de la latence et soulève des problèmes de confidentialité.
Lorsqu'une personne remplit un formulaire PDF et l'enregistre, les valeurs saisies résident dans les structures de champs du document — pas sous forme de texte brut que vous pouvez rechercher ou copier en masse. Pour un formulaire avec trente ou quarante champs, la transcription manuelle devient un goulot d'étranglement. Le problème plus profond est que chaque type de champ stocke sa valeur différemment : une zone de texte expose une chaîne, une case à cocher renvoie un booléen, une liste déroulante sépare les options de la sélection, et un bouton radio stocke l'élément choisi. Un appel unique et uniforme « donnez-moi la valeur » n'existe pas.
Un graphique à colonnes avec des régions et des mois sur le même axe présente deux problèmes, et ce ne sont pas les mêmes problèmes. Le premier est que les étiquettes de catégorie s'effondrent en une seule ligne — « Nord », « Janv », « Nord », « Fév » — et le lecteur doit regrouper mentalement quel mois appartient à quelle région. Le deuxième est que lorsqu'une série de taux de croissance est ajoutée à côté d'une série de ventes qui se chiffre en millions, le taux de croissance devient une ligne plate collée à la ligne de base, car un seul axe de valeurs ne peut pas servir deux ordres de grandeur à la fois.
Un tableau de ventes à vingt colonnes de chiffres est exact et illisible. L'œil ne peut pas comparer 43 210 à 38 900 sur une ligne assez vite pour repérer le trimestre faible, et la personne qui lit le rapport le sait — c'est pourquoi elle demande un graphique. Mais un graphique par colonne, cela fait vingt graphiques, et la feuille de calcul devient une galerie au lieu d'un tableau.
Une feuille de calcul n'est pas toujours une simple grille de chiffres. Parfois, c'est un canevas — un diagramme de flux esquissé entre des blocs de données, un diagramme de relations reliant des équipes à des projets, une annotation pointant d'une note vers la cellule qu'elle annote. Dans chacun de ces cas, l'élément manquant est une ligne : un trait droit entre deux cases, un arc courbe autour d'une région, un connecteur coudé qui plie une fois puis continue.
Une ligne entre deux boîtes dans un organigramme dit « ces deux éléments sont liés ». Une flèche de l'un à l'autre dit « celui-ci vient en premier ». Cette distinction — la direction — est ce qui sépare un connecteur d'une décoration, et c'est la seule chose que l'API de base `Lines.AddLine()` ne peut pas faire aux deux extrémités. Un flux de processus a besoin d'une flèche sortant de chaque étape ; un diagramme de cause à effet a besoin de flèches pointant vers l'intérieur ; une comparaison a parfois besoin de flèches à double sens pour montrer un lien bidirectionnel. Aucun de ces cas n'est possible avec un seul `EndArrowHeadStyle`.
Page 3 of 54
Maison page 3