Très bonne question ! Comme chacun a pu en faire l'expérience, InDesign n'affiche pas tous les chiffres saisis par l'utilisateur dans la palette Transformation. Par exemple, si vous fixez la largeur d'un bloc à 0,859375 pouces, l'interface indiquera 0.8594 pouce. À ma connaissance, la précision d'affichage d'InDesign est seuillée à un dix millième (4 chiffres après la virgule), et ce seuil n'est pas modifiable par l'utilisateur.

Si l'on se plonge dans des strates plus techniques, on s'aperçoit que toutes les valeurs métriques manipulées par l'application sont aplaties en points PostScript avec une précision qui ne peut excéder 7 chiffres après la virgule, du fait que l'implémentation — cf. SDK d'InDesign — repose sur un epsilon machine égal à 1e-8. Ceci est attesté par le fichier d'en-tête PMReal.h. Ainsi que le précisent les développeurs d'Adobe, l'emploi d'une classe dédiée (PMReal) plutôt que le type double natif « permet essentiellement d'encapsuler l'incertitude epsilon dans les opérateurs de comparaison ». Cela induit également des « conversions implicites au sein de la classe PMReal ».

Pour en revenir aux unités de mesure d'InDesign — du moins, telles qu'on les appréhende depuis le module de scripting —, de nombreuses expériences ont démontré qu'elles requièrent à leur tour l'introduction d'un epsilon machine, notamment pour comparer valablement les positions ou les dimensions des objets. Deux difficultés majeures se manifestent à ce stade : d'une part, on ne sait pas dire précisément comment les valeurs exposées en JavaScript interagissent avec l'infrastructure réelle d'InDesign ; d'autre part, on ignore à quel moment précis se produisent les conversions numériques d'une unité vers une autre. Or, on sait que dans tous les cas, l'arithmétique à virgule flottante basée sur la spécification IEEE754 (en 32 ou 64 bits, selon le système d'exploitation) introduit par nature des erreurs d'approximation.

Toutes ces raisons me font supposer — au moins à titre empirique — qu'InDesign ne peut pas gérer une précision plus poussée que 0,001 pt (soit 0,0003528 mm, soit 0,3528 µm.) Sachant qu'un pouce vaut 72 points (PostScript), une précision de 0,0001 pouce équivaudrait à 0,0072 pt, soit 2,54016 µm. Remarquez en passant que le diamètre moyen d'un globule rouge est de l'ordre de 7 µm. Donc, pour l'exemple proposé ("0,859375 pouce"), les deux derniers chiffres significatifs se situent dans un ordre de grandeur voisin de l'épaisseur de la membrane cellulaire !

Gestion des décimales dans HurryCover

Quoi qu'il en soit, HurryCover s'efforce de traiter le plus exactement possible les informations métriques. En fait, toutes les valeurs sont stockées en interne sous forme de nombres entiers, par le truchement d'une unité spéciale que j'appelle le micropoint. 1 micropoint représente le millionième d'un point PostScript. La plus grande valeur autorisée dans HurryCover (hauteur maximale d'une couverture) est de 3 685 000 000 micropoints (environ 1,3 m). Dans la mesure où ExtendScript adresse sans erreur tous les entiers signés compris entre -2^53 et +2^53, HurryCover contourne par cet expédient de nombreuses difficultés liées à l'arithmétique à virgule flottante.

Toutefois, ce que l'utilisateur observe dans la boîte de dialogue est une expression arrondie des valeurs effectivement mémorisées. Lorsque l'unité [PT] est active, les mesures sont arrondies à deux décimales, alors que quatre décimales sont affichées pour l'unité [IN] (pouces). Mais la valeur saisie est de toute façon convertie et mémorisée en micropoints. Par exemple, si vous entrez manuellement la valeur "0,859375 in" pour le dos de couverture, le paramètre réellement stocké est 61 875 000 (micropoints). Il est facile de vérifier que ce nombre reflète fidèlement la saisie initiale : 61,875 / 72 = 0,859375.

HurryCover utilise en interne le micropoint, une unité de mesure qui préserve la meilleure précision possible.

Du coup, même si HurryCover affiche "0,8594 in" dans la zone dialoguée, c'est bien la valeur de 61,875 points qu'il envoie à InDesign dans ce cas précis. Ensuite, reste à savoir quel circuit d'approximations l'application lui fera emprunter… (Comme dit plus haut, je ne m'attends pas à une précision supérieure à 0,001 pt en fin de course.)

Note. — Incidemment, j'en profite pour souligner que la précision atteinte par HurryCover supportera difficilement les procédures de conversions multiples initiées par l'utilisateur. En effet, lorsque ce dernier bascule d'une unité à l'autre, modifie certaines cotes, puis rebascule vers l'unité initiale, le script doit décider si les valeurs mémorisées jusqu'alors doivent s'actualiser en conséquence. Gardez cela à l'esprit lorsque vous changez vos unités de travail.