Qu'est-ce que l'empreinte des polices ? Cohérence du texte

BotBrowser peut aligner le comportement des polices sur un profil choisi et comparer les résultats de texte entre hôtes, mais il ne garantit pas l'anonymat ni l'acceptation par un site. Considérez donc les polices comme une limite mesurable de confidentialité et de compatibilité, pas comme une preuve d'identité. Les media queries CSS offrent un signal d'affichage associé ; consultez comment elles exposent la configuration.

TL;DR

La disponibilité, le repli et les métriques des polices peuvent révéler des traits de plateforme. Gardez le profil choisi comme référence, testez des pages multilingues représentatives entre hôtes et considérez les changements visibles comme des signaux de compatibilité, pas comme une preuve d’identité.

Contents

• Ce que mesure l'empreinte des polices
• Pourquoi la cohérence compte plus qu'une valeur isolée
• Garder un texte cohérent d'un hôte à l'autre
• Constituer un jeu de textes représentatif
• Valider entre hôtes et approuver les résultats
• Ce que BotBrowser couvre pour les polices et ce qu'il ne couvre pas
• Conclusion

Ce que mesure l'empreinte des polices

Notez fontFamilyRequested, fallbackFace, measureTextWidth, lineBreakCount et rasterizerClass pour relier l'observation au texte rendu.

L'empreinte des polices s'appuie sur la disponibilité des polices, le comportement de repli et les métriques de texte pour savoir comment un navigateur affiche le texte. Un site web n'a pas besoin d'une autorisation particulière pour observer si le texte est mis en page comme sous Windows, macOS, Linux ou sur un appareil mobile. Il lit un comportement de rendu ordinaire et peut le combiner avec les signaux de canvas, de WebGL, de langue et d'écran.

• La disponibilité des polices révèle des traits généraux du système d'exploitation et des paquets de langues.
• Le comportement de repli montre quelle police le navigateur choisit lorsque la famille ou le glyphe demandé manque.
• Les métriques de texte montrent comment le navigateur mesure la largeur des glyphes, la hauteur de ligne et la mise en page.
• Le texte dans un canvas peut refléter le même comportement de polices à travers les pixels produits.

Une page peut observer les polices de trois façons ordinaires. Elle peut demander du texte dans une famille nommée et voir si cette famille ou une police de substitution a été utilisée. Elle peut s'appuyer sur les règles de repli de CSS Fonts Level 4, qui décrivent comment un navigateur parcourt une liste de font-family et choisit une autre police pour les caractères que le premier choix ne sait pas dessiner. Enfin, elle peut appeler des méthodes de mesure comme measureText, qui renvoie les largeurs et les boîtes englobantes d'une chaîne. La même chaîne se mesure différemment lorsqu'une autre police est sélectionnée.

Pour que cela compte, la page n'a pas besoin d'une liste directe des polices installées. Les largeurs de boîtes, les sauts de ligne et les hauteurs de défilement découlent des polices utilisées, de sorte que la mise en page seule porte déjà des informations sur la plateforme. Le texte dans un canvas ajoute une seconde vue du même comportement, car les pixels issus d'un appel de dessin de texte dépendent de la police choisie et du rastériseur.

Les polices interagissent aussi avec la langue et la région. Lorsqu'une page déclare une langue, ou que le navigateur annonce des langues préférées, l'ordre de repli pour des écritures comme le chinois, le japonais et le coréen suit ces indications. Un profil qui annonce une langue tout en dessinant le texte avec les choix de polices d'une autre crée une incohérence qu'un observateur attentif peut remarquer sans lire un seul nom de police. Traitez l'inventaire de polices et les réglages de langue d'un profil comme une seule décision, et non comme deux.

Pourquoi la cohérence compte plus qu'une valeur isolée

Comparez profileTarget, hostClass et fontMode ensemble; conservez browserVersion avec le relevé des métriques de texte.

Pour les équipes de confidentialité, le risque est rarement une valeur isolée. Le risque, c'est l'incohérence. Un profil de navigateur peut se présenter comme un poste Windows alors que la machine hôte expose un comportement de texte propre à Linux. Une identité mobile peut porter des traits de polices de bureau. Un profil peut rester stable dans un environnement et dériver dans un autre.

Trois accords comptent :

• Identité de plateforme : les profils ciblant Windows, macOS, Linux et mobile ne doivent pas exposer de traits de polices propres à l'hôte.
• Continuité de session : le même profil doit produire un comportement de texte stable d'un lancement et d'une machine à l'autre.
• Cohérence entre signaux : le comportement des polices doit s'accorder avec la marque de navigateur, la classe d'appareil, la langue et le modèle de rendu du profil.

Une bonne gestion des polices ne consiste pas à bloquer la mise en page. Les pages ont toujours besoin d'un texte correctement affiché, et les personnes ont toujours besoin de commandes lisibles. L'objectif est que le comportement du texte vienne du profil sélectionné plutôt que de ce que l'hôte a installé, tout en conservant la compatibilité web habituelle. Le texte dans un canvas est le voisin le plus proche de ce sujet, et la cohérence du canvas explique comment le même principe s'applique aux pixels dessinés.

Cela compte surtout pour les déploiements sur serveur. Beaucoup de flottes de production tournent sous Linux parce que c'est efficace et facile à faire évoluer, alors que l'identité de navigateur dont une équipe a besoin peut représenter un environnement de bureau ou mobile. Les polices sont l'un des endroits où l'infrastructure hôte devient le plus facilement visible, elles méritent donc un contrôle explicite.

La même comparaison vaut pour les exécutions headless et headful, mais un rendu identique n'est pas garanti entre les hôtes, les services d'affichage, les moteurs graphiques ou les piles de polices. Utilisez le même profil et les mêmes options comme entrées contrôlées, notez l'hôte et la politique d'affichage, puis comparez les métriques obtenues au lieu de supposer que les captures headless correspondront au mode headful. En cas d'écart, vérifiez le mode de polices et l'environnement de rendu avant de le traiter comme une régression produit.

Garder un texte cohérent d'un hôte à l'autre

Mode profil et lots de polices intégrés

Avec un profil, un hôte, une autorisation et un mode de polices compatibles, les polices du profil peuvent aligner la disponibilité des polices et les métriques du texte sur la plateforme cible. Validez le profil, l'hôte, l'autorisation et le mode de polices exacts ; la parité n'est pas garantie pour toutes les surfaces de rendu. La portabilité Linux/Ubuntu requiert ENT Tier1 ; la prise en charge des polices Android est PRO.

Le repli peut encore modifier le résultat du rendu. Sur certaines plateformes, des caractères CJK rares peuvent utiliser des polices système, et la couverture n'est pas identique sur tous les hôtes ou toutes les surfaces de texte.

Quand expand ou real est voulu

Le comportement des polices se contrôle avec l'option --bot-fonts, qui propose trois modes :

• profile est le mode par défaut et utilise les polices intégrées au profil.
• expand utilise les polices du profil et ajoute un repli vers les polices de l'hôte.
• real utilise les vraies polices du système et n'offre aucune protection des polices.

Gardez --bot-fonts=profile lorsque la cohérence entre hôtes compte, car l'inventaire du profil et sa politique de repli restent alors la référence. N'utilisez expand ou real que lorsque le flux de travail admet volontairement une variation de l'hôte et que cette variation fait partie du plan de test. Si une liste de polices dans un test montre des polices de l'hôte, vérifiez le mode avant de chercher ailleurs.

Pages CJK et à écritures multiples

Le texte CJK dépend fortement des paquets de langues, de l'ordre de repli et du comportement de rendu, ce qui en fait le moyen le plus rapide de repérer une fuite de l'hôte. Des glyphes manquants signalent généralement que l'inventaire disponible n'a pas de police adaptée, et la documentation de BotBrowser précise que les profils Windows et macOS incluent par défaut la prise en charge du CJK. Pour le détail du texte chinois, japonais et coréen, lisez le rendu des polices CJK. Pour la question plus large de la stabilité d'un même profil d'un système d'exploitation à l'autre, consultez la documentation des profils.

Constituer un jeu de textes représentatif

Attribuez à chaque contrôle pageId, viewport, zoomPercent, profilePackage et applicationRevision avant la comparaison.

Un jeu de textes utile provient du produit testé. Commencez par les pages que les clients utilisent chaque jour : connexion, paramètres du compte, résultats de recherche, tableaux, éditeurs, paiement, documents imprimables et contenus d'assistance. Incluez les états qui modifient la mise en page, comme les messages de validation, les commandes désactivées, les menus ouverts et les résultats vides. Un seul paragraphe d'exemple ne peut pas représenter la typographie d'une application.

Gardez le jeu assez petit pour l'exécuter à chaque version. Dix pages bien choisies sont généralement plus utiles que des centaines de captures que personne ne relit. Chaque page doit avoir un responsable, une raison d'être incluse et un point de contrôle stable. Ce point de contrôle peut être une capture, un export de document ou un résultat fonctionnel consigné, comme une étiquette de bouton qui reste visible.

La couverture linguistique doit suivre les personnes réellement concernées. Un produit qui prend en charge l'anglais, l'espagnol, le français, le russe et le chinois a besoin de textes représentatifs dans chaque langue prise en charge. Ajoutez le japonais, le coréen, l'arabe, l'hébreu ou d'autres écritures lorsqu'elles font partie du produit. Incluez des fiches multilingues, où les noms, les adresses ou les entrées de catalogue utilisent couramment plus d'une écriture.

Choisissez un contenu qui sollicite la typographie normale sans devenir artificiel. Les noms de clients longs, les colonnes de tableau étroites, les libellés sur plusieurs lignes, les dates, les devises et les aperçus de documents sont de bons candidats, car ils révèlent des régressions de mise en page concrètes. Les pages créées uniquement pour énumérer des détails d'environnement ne montrent pas si le produit reste utilisable, laissez-les donc de côté.

Consignez la fenêtre d'affichage et le niveau de zoom attendus pour chaque point de contrôle visuel, car un retour à la ligne causé par une autre fenêtre d'affichage n'est pas une régression de polices. Le dossier de version doit aussi identifier la famille de profils, la version de BotBrowser, l'image de base et la révision de l'application. Ces informations permettent à une autre personne de reproduire la même revue orientée utilisateur sans collecter de données inutiles sur la machine.

Les pages qui chargent leurs propres polices web demandent une règle de plus : ne capturez un point de contrôle qu'une fois les polices entièrement chargées. Le passage d'une police temporaire à la police finale modifie les largeurs et les sauts de ligne, et une capture prise au milieu de ce passage ressemble à une régression alors qu'il ne s'agit que d'un écart de timing. Attendez que le texte soit stabilisé avant de comparer les résultats.

La revue du texte doit inclure les états qui apparaissent après une action. Les menus ouverts, les messages de validation, les résultats de saisie semi-automatique, les boîtes de dialogue modales et les états de chargement ont souvent des limites de mise en page plus serrées que la page initiale. Parcourez les mêmes états au clavier, car les indicateurs de focus, les textes d'aide et les résumés d'erreurs peuvent utiliser une typographie différente de celle du contenu ordinaire.

Incluez les pages imprimables, les documents exportés et les vues d'accessibilité lorsque le produit en dépend. Vérifiez que les sauts de page, les titres, les libellés de formulaire et l'ordre de lecture restent utilisables. Consignez le résultat applicatif avec le résultat visuel afin que la personne qui relit distingue un changement d'apparence inoffensif d'une perte d'information.

Valider entre hôtes et approuver les résultats

Comparaison entre hôtes

Pour chaque paire, consignez baselineId, candidateHost, renderingBackend et une visualDecision liée à la page examinée.

La revue entre hôtes répond à une question simple : le même profil approuvé conserve-t-il la même expérience de texte utilisable sur chaque classe de worker prise en charge ? Exécutez le jeu représentatif sur les hôtes utilisés en production et comparez les résultats à la base approuvée.

• Exécutez le même profil sur deux systèmes d'exploitation hôtes différents.
• Comparez une page représentative qui inclut du texte normal, du texte CJK si nécessaire et du texte dans un canvas si cela fait partie du flux de travail.
• Vérifiez que le comportement observé reste aligné sur la cible du profil et non sur la machine hôte.
• Conservez le résultat dans le dossier de validation de la version ou du profil.

De petites différences de pixels ne rendent pas automatiquement une version inadaptée. La règle d'acceptation doit venir du produit. Un service de captures peut exiger une base visuelle plus stricte qu'un flux qui se contente de lire et d'envoyer des formulaires. Définissez les tolérances avant la revue afin que les décisions de version restent cohérentes et ne dépendent pas de la personne qui inspecte le résultat.

Traitez comme bloquants les caractères manquants, les commandes illisibles, les substitutions de symboles inattendues et le texte qui chevauche le contenu voisin. Un retour à la ligne modifié peut être acceptable lorsqu'aucune information n'est perdue et que la page reste stable. Documentez la décision avec le responsable de la page afin que le même changement ne soit pas rediscuté à la version suivante.

Les captures sont une preuve utile, mais pas la seule. La sélection de texte, la saisie dans les formulaires, le copier-coller, la sortie PDF et les étiquettes d'accessibilité peuvent révéler des problèmes visibles pour le client qu'une image statique ne montre pas. Désignez un responsable pour chaque page représentative et chaque famille de profils. Cette personne décide si une différence visible est attendue, met à jour la base lorsque la typographie du produit change et consigne la décision de version.

Dossiers de version et mises à jour

La ligne de déploiement doit distinguer browserVersion, profilePackage, baseImageRevision, languagePackSet et approvalState.

La version du navigateur, le paquet de profil et l'image du serveur forment une unité déployable. Conservez leurs versions ensemble dans le dossier de déploiement. Un profil approuvé avec une version ne doit pas être réutilisé silencieusement après un changement majeur de navigateur ou d'image. Relancez le jeu de textes représentatif et consignez la nouvelle base.

Mettez à jour une couche à la fois lorsque c'est possible. Validez d'abord la nouvelle version de BotBrowser avec le profil et l'image déjà approuvés. Validez ensuite la mise à jour de profil prévue. Validez enfin tout changement d'image de base ou de paquet de langue. Cet ordre circonscrit l'origine d'un changement visuel et simplifie les décisions de retour arrière. Ajouter ou retirer un paquet de langue, ou mettre à jour une bibliothèque de bureau, peut modifier le texte ordinaire : faites donc passer une nouvelle image par les mêmes contrôles avant son entrée dans le groupe de workers.

Un dossier de version concis peut contenir une ligne par page : le résultat, le résultat attendu, les versions du navigateur et du profil, la classe d'hôte et la décision de la personne qui relit. Indiquez si la page a réussi, a exigé une mise à jour de base approuvée ou demande une enquête. Reliez la ligne à la capture ou à la sortie du document, ainsi qu'au responsable de l'application. Évitez de stocker des données de compte sans rapport ou des historiques de navigation complets, et utilisez des comptes de test dédiés et des documents synthétiques lorsque c'est possible.

Lorsqu'une base change volontairement, conservez le résultat précédent assez longtemps pour expliquer la transition, avec un motif court comme une mise à jour de la typographie du produit ou de la famille de profils. Ne mélangez pas des familles de profils sans rapport dans une même base, car les mises en page de bureau, de mobile et de tablette n'ont pas les mêmes attentes. La conservation doit suivre la politique habituelle de qualité et de confidentialité de l'organisation, et les données personnelles doivent être masquées avant qu'une capture n'entre dans un dossier durable.

Réagir à une dérive visible

Ouvrez l'analyse avec affectedPageId, previousBaselineId, changedComponent, rollbackDecision et ownerQueue.

Lorsque le texte change de façon inattendue, suspendez le déploiement large et reproduisez la page concernée avec le profil, la version du navigateur, l'image, la fenêtre d'affichage et la révision de l'application consignés. Confirmez le changement sur un worker propre avant de modifier la configuration. Cela distingue un problème de version persistant d'un cache endommagé ou d'un seul hôte défaillant.

Comparez ensuite la dernière combinaison approuvée avec la combinaison candidate, en ne changeant qu'un composant entre deux exécutions. Si l'écart suit l'image de base, examinez les changements récents de paquets. S'il suit le profil, revenez au profil approuvé pendant que le responsable examine la mise à jour. S'il suit l'application, transmettez le résultat au responsable de la page.

Si une revue utilise aussi les réglages facultatifs de bruit pour les ClientRects et les rectangles de texte, désactivés par défaut, fixez la graine de bruit pour la comparaison. Sans graine fixe, les valeurs de mesure varient d'une session à l'autre, et la personne qui relit ne peut pas distinguer une variation voulue d'un vrai changement. Avec une graine fixe, des sessions répétées donnent la même sortie de mesure et la comparaison reste exploitable.

Consignez l'impact sur les personnes plutôt que la seule différence visuelle. Les glyphes manquants, les libellés tronqués, les commandes inutilisables et la pagination modifiée des documents demandent une attention immédiate, tandis qu'une variation inoffensive de lissage peut se contenter d'une note dans la base. Après une correction, relancez le jeu représentatif complet pour la famille de profils concernée, car la correction d'une page peut changer une autre langue ou la mise en page d'un autre document. Déployez par étapes, en commençant par un petit groupe de workers, et ne promouvez la version qu'une fois les points de contrôle convenus validés sur chaque classe de worker qui la recevra.

Ce que BotBrowser couvre pour les polices et ce qu'il ne couvre pas

Le comportement des polices est un signal parmi d'autres, et un profil n'est cohérent que dans la mesure de sa surface la plus faible. Avant de changer un profil, un mode de polices ou une image d'hôte, relancez le jeu représentatif et comparez le résultat visible avec la cible du profil. Un changement qui paraît faible dans une langue peut être important dans une autre : examinez donc chaque langue prise en charge par le produit avant d'approuver la mise à jour. La documentation sur les polices liste les modes et les étapes de dépannage, et la documentation CJK détaille le rendu du chinois, du japonais et du coréen.

Pour approfondir, consultez Fingerprinting par mesure de texte : suivi sous-pixel.

Conclusion

Utilisez --bot-fonts=profile lorsque vous avez besoin d’un comportement de texte stable entre les hôtes. Gardez un petit ensemble de points de contrôle multilingues, comparez-le sur chaque classe d’hôte prise en charge et examinez les glyphes manquants, les libellés tronqués ou les changements de pagination avant le déploiement. La cohérence des polices améliore une limite de compatibilité mesurable, mais ne prouve ni l’anonymat ni l’acceptation par le site.

Sources publiques

• CSS Fonts Module Level 4
• CanvasRenderingContext2D.measureText() sur MDN
• Documentation BotBrowser sur l'empreinte des polices