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`.
Quelqu'un a construit ce classeur il y a des années. Il se recalcule lorsque les données changent, les totaux évoluent d'une manière que plus personne ne prévoit, et il n'y a aucune documentation — parce que les formules sont la documentation. Lire les nombres ne vous dira pas comment ils ont été produits. Lire les règles le fera.
Un tableur généré rempli de nombres pré-calculés n'est qu'un instantané. Il semble correct au moment où il est produit et commence immédiatement à vieillir : les données qui le sous-tendent évoluent, les nombres qu'il contient non, et une fois que le fichier a quitté votre application, personne ne peut dire quelles cellules peuvent être modifiées. Un classeur qui contient ses formules reste au contraire un document vivant — modifiez une entrée, et les totaux suivent.
Page 2 of 3
Maison Spire.Office page 2