¿Qué es la huella de fuentes? Coherencia de texto entre plataformas

BotBrowser puede mantener el comportamiento de las fuentes alineado con un perfil seleccionado y permite comparar resultados de texto entre hosts. No puede garantizar anonimato ni aceptación por un sitio; por eso este artículo trata las fuentes como un límite medible de privacidad y compatibilidad, no como una conclusión sobre identidad. Las media queries CSS ofrecen una señal de pantalla relacionada; consulta cómo exponen la configuración.

TL;DR

La disponibilidad, el respaldo y las métricas de las fuentes pueden revelar rasgos de la plataforma. Mantén el perfil seleccionado como autoridad, prueba páginas multilingües representativas entre hosts y trata los cambios visibles como señales de compatibilidad, no como una prueba de identidad.

Contents

• Qué mide la huella de fuentes
• Por qué importa la coherencia más que cualquier valor aislado
• Mantener el texto coherente entre hosts
• Crea un conjunto de texto representativo
• Valida entre hosts y aprueba los resultados
• Qué cubre BotBrowser en fuentes y qué no
• Conclusión

Qué mide la huella de fuentes

La huella de fuentes usa la disponibilidad de fuentes, el comportamiento de respaldo y las métricas de texto para saber cómo renderiza un navegador el texto. Un sitio web no necesita un permiso especial para observar si el texto se maqueta como en Windows, macOS, Linux o un dispositivo móvil. Lee comportamiento de renderizado corriente y puede combinarlo con señales de canvas, WebGL, idioma y pantalla.

• La disponibilidad de fuentes revela rasgos generales del sistema operativo y de los paquetes de idioma.
• El comportamiento de respaldo muestra qué tipografía elige el navegador cuando falta la familia o el glifo solicitado.
• Las métricas de texto muestran cómo mide el navegador el ancho de los glifos, la altura de línea y la maquetación.
• El texto en canvas puede reflejar el mismo comportamiento de fuentes a través de los píxeles renderizados.

Una página puede observar las fuentes de tres maneras corrientes. Puede pedir texto en una familia con nombre y ver si se usó esa familia o una sustituta. Puede apoyarse en las reglas de respaldo de CSS Fonts Level 4, que describen cómo un navegador recorre una lista de font-family y elige otra tipografía para los caracteres que la primera opción no puede dibujar. Y puede llamar a métodos de medición como measureText, que informa de anchos y cuadros delimitadores de una cadena. La misma cadena se mide de forma distinta cuando se selecciona otra tipografía.

Para que esto importe, la página no necesita una lista directa de las fuentes instaladas. Los anchos de las cajas, los saltos de línea y las alturas de desplazamiento se derivan de las tipografías usadas, así que la maquetación por sí sola lleva información de plataforma. El texto en canvas añade una segunda vista del mismo comportamiento, porque los píxeles que salen de una llamada de dibujo de texto dependen de la tipografía elegida y del rasterizador.

Las fuentes también interactúan con el idioma y la región. Cuando una página declara un idioma, o el navegador informa de idiomas preferidos, el orden de respaldo para escrituras como el chino, el japonés y el coreano sigue esas indicaciones. Un perfil que informa de un idioma mientras dibuja el texto con las tipografías de otro produce una incoherencia que un observador atento puede notar sin leer un solo nombre de fuente. Trata el inventario de fuentes y los ajustes de idioma de un perfil como una sola decisión, no como dos.

Por qué importa la coherencia más que cualquier valor aislado

Compara profileTarget, hostClass y fontMode juntos; conserva browserVersion con el registro de métricas de texto.

Para los equipos de privacidad, el riesgo rara vez es un valor aislado. El riesgo es la incoherencia. Un perfil de navegador puede declararse un escritorio Windows mientras el equipo anfitrión muestra un comportamiento de texto propio de Linux. Una identidad móvil puede llevar rasgos de fuentes de escritorio. Un perfil puede mantenerse estable en un entorno y desviarse en otro.

Importan tres tipos de acuerdo:

• Identidad de plataforma: los perfiles con destino Windows, macOS, Linux y móvil no deben exponer rasgos de fuentes propios del host.
• Continuidad de sesión: el mismo perfil debe producir un comportamiento de texto estable entre lanzamientos y máquinas.
• Coherencia entre señales: el comportamiento de las fuentes debe coincidir con la marca de navegador, la clase de dispositivo, el idioma y el modelo de renderizado del perfil.

Una buena gestión de fuentes no consiste en bloquear la maquetación. Las páginas siguen necesitando que el texto se muestre bien, y las personas siguen necesitando controles legibles. El objetivo es que el comportamiento del texto venga del perfil seleccionado y no de lo que el host tenga instalado, manteniendo la compatibilidad web habitual. El texto en canvas es el vecino más cercano de este tema, y la coherencia de canvas explica cómo se aplica el mismo principio a los píxeles dibujados.

Esto importa sobre todo en despliegues de servidor. Muchas flotas de producción funcionan sobre Linux porque es eficiente y fácil de escalar, mientras que la identidad de navegador que necesita un equipo puede representar un entorno de escritorio o móvil. Las fuentes son uno de los lugares más fáciles por los que la infraestructura anfitriona se hace visible, así que merecen una comprobación explícita.

La misma comparación se aplica a las ejecuciones headless y headful, pero el renderizado idéntico no está garantizado entre hosts, servicios de pantalla, backends gráficos o pilas de fuentes. Usa el mismo perfil y los mismos flags como entradas controladas, registra el host y la política de pantalla, y compara las métricas obtenidas en vez de asumir que las capturas headless coincidirán con una sesión headful. Si difieren, revisa el modo de fuentes y el entorno de renderizado antes de tratarlo como una regresión del producto.

Mantener el texto coherente entre hosts

Modo de perfil y paquetes de fuentes integrados

Con un perfil, host, autorización y modo de fuentes compatibles, las fuentes del perfil pueden alinear la disponibilidad y las métricas de texto con la plataforma de destino. Valida el perfil, host, autorización y modo de fuentes exactos; no se garantiza la paridad en todas las superficies de renderizado. La portabilidad en Linux/Ubuntu requiere ENT Tier1; el soporte de fuentes en Android es PRO.

El respaldo aún puede cambiar los resultados renderizados. En algunas plataformas, los caracteres CJK poco frecuentes pueden recurrir a fuentes del sistema, y la cobertura no es idéntica en todos los hosts o superficies de texto.

Cuándo expand o real es intencional

El comportamiento de las fuentes se controla con la opción --bot-fonts, que tiene tres modos:

• profile es el predeterminado y usa las fuentes incluidas en el perfil.
• expand usa las fuentes del perfil y añade respaldo con las fuentes del host.
• real usa las fuentes reales del sistema y no ofrece protección de fuentes.

Mantén --bot-fonts=profile cuando importe la coherencia entre hosts, porque así el inventario del perfil y su política de respaldo siguen siendo la referencia. Usa expand o real solo cuando el flujo de trabajo admita a propósito la variación del host y esa variación forme parte del plan de pruebas. Si una lista de fuentes en una prueba muestra fuentes del host, revisa el modo antes de buscar en cualquier otro sitio.

Páginas CJK y con varias escrituras

El texto CJK depende mucho de los paquetes de idioma, del orden de respaldo y del comportamiento de renderizado, así que es la forma más rápida de notar una fuga del host. Los glifos ausentes suelen indicar que el inventario disponible no tiene una tipografía adecuada, y la documentación de BotBrowser señala que los perfiles de Windows y macOS incluyen compatibilidad CJK de forma predeterminada. Para los detalles del texto chino, japonés y coreano, lee renderizado de fuentes CJK. Para la cuestión más amplia de mantener un perfil estable entre sistemas operativos, consulta la documentación de perfiles.

Crea un conjunto de texto representativo

Da a cada punto de control pageId, viewport, zoomPercent, profilePackage y applicationRevision antes de compararlo.

Un conjunto de texto útil sale del producto que se prueba. Empieza por las páginas que los clientes usan cada día: inicio de sesión, ajustes de cuenta, resultados de búsqueda, tablas, editores, pago, documentos imprimibles y contenido de soporte. Incluye los estados que cambian la maquetación, como mensajes de validación, controles desactivados, menús desplegados y resultados vacíos. Un único párrafo de muestra no puede representar la tipografía de una aplicación.

Mantén el conjunto lo bastante pequeño como para ejecutarlo en cada versión. Diez páginas bien elegidas suelen ser más útiles que cientos de capturas que nadie revisa. Cada página debe tener un responsable, un motivo de inclusión y un punto de control estable. El punto de control puede ser una captura, una exportación de documento o un resultado funcional registrado, como una etiqueta de botón que sigue visible.

La cobertura de idiomas debe seguir a los usuarios reales. Un producto que admite inglés, español, francés, ruso y chino necesita texto representativo en cada idioma admitido. Añade japonés, coreano, árabe, hebreo u otras escrituras cuando formen parte del producto. Incluye registros con varios idiomas, donde nombres, direcciones o entradas de catálogo suelen usar más de una escritura.

Elige contenido que ejercite la tipografía normal sin volverse artificial. Los nombres largos de clientes, las columnas estrechas de tablas, las etiquetas de varias líneas, las fechas, las divisas y las vistas previas de documentos son buenos candidatos porque exponen regresiones prácticas de maquetación. Las páginas creadas solo para enumerar detalles del entorno no muestran si el producto sigue siendo utilizable, así que déjalas fuera.

Registra el viewport y el nivel de zoom esperados en cada punto de control visual, porque un salto de línea causado por otro viewport no es una regresión de fuentes. El registro de la versión también debe identificar la familia de perfiles, la versión de BotBrowser, la imagen base y la revisión de la aplicación. Esos datos permiten que otra persona reproduzca la misma revisión orientada al usuario sin recopilar datos innecesarios de la máquina.

Las páginas que cargan sus propias fuentes web necesitan una regla más: captura un punto de control solo después de que las fuentes hayan terminado de cargarse. Un cambio de una tipografía temporal a la final modifica los anchos y los saltos de línea, y una captura tomada a mitad de ese cambio parece una regresión cuando solo es una diferencia de tiempo. Espera a que el texto se asiente antes de comparar resultados.

La revisión del texto debe incluir los estados que aparecen después de que alguien actúa. Los menús abiertos, los mensajes de validación, los resultados de autocompletado, los diálogos modales y los estados de carga suelen tener límites de maquetación más estrictos que la página inicial. Recorre los mismos estados con el teclado, porque los indicadores de foco, los textos de ayuda y los resúmenes de error pueden usar una tipografía distinta de la del contenido normal.

Incluye páginas imprimibles, documentos exportados y vistas de accesibilidad cuando el producto dependa de ellos. Comprueba que los saltos de página, los encabezados, las etiquetas de formulario y el orden de lectura siguen siendo utilizables. Registra el resultado de la aplicación junto con el resultado visual para que quien revise distinga un cambio de aspecto inofensivo de una pérdida de información.

Valida entre hosts y aprueba los resultados

Comparación entre hosts

Para cada par, registra baselineId, candidateHost, renderingBackend y una visualDecision vinculada a la página revisada.

La revisión entre hosts responde a una pregunta sencilla: ¿conserva el mismo perfil aprobado la misma experiencia de texto utilizable en cada clase de worker admitida? Ejecuta el conjunto representativo en los hosts que se usan en producción y compara los resultados con la base aprobada.

• Ejecuta el mismo perfil en dos sistemas operativos anfitriones distintos.
• Compara una página representativa que incluya texto normal, texto CJK si corresponde y texto en canvas si forma parte del flujo de trabajo.
• Confirma que el comportamiento observado sigue alineado con el destino del perfil y no con la máquina anfitriona.
• Conserva el resultado como parte del paquete de validación de la versión o del perfil.

Las diferencias pequeñas de píxeles no significan automáticamente que una versión no sea adecuada. La regla de aceptación debe venir del producto. Un servicio de capturas puede exigir una base visual más estricta que un flujo que solo lee y envía formularios. Define las tolerancias antes de la revisión para que las decisiones de versión sean coherentes y no dependan de quién inspecciona el resultado.

Trata los caracteres ausentes, los controles ilegibles, las sustituciones inesperadas de símbolos y el texto que se superpone con el contenido cercano como problemas bloqueantes. Un salto de línea distinto puede ser aceptable cuando no se pierde información y la página sigue estable. Documenta la decisión con el responsable de la página para que el mismo cambio no se discuta de nuevo en la siguiente versión.

Las capturas son una buena evidencia, pero no la única. La selección de texto, la entrada en formularios, copiar y pegar, la salida a PDF y las etiquetas de accesibilidad pueden revelar problemas visibles para el cliente que una imagen estática no muestra. Nombra un responsable para cada página representativa y familia de perfiles. Esa persona decide si una diferencia visible es esperada, actualiza la base cuando cambia la tipografía del producto y registra la decisión de versión.

Registros de versión y actualizaciones

La fila de despliegue debe distinguir browserVersion, profilePackage, baseImageRevision, languagePackSet y approvalState.

La versión del navegador, el paquete de perfil y la imagen del servidor forman una unidad desplegable. Guarda sus versiones juntas en el registro de despliegue. Un perfil aprobado con una versión no debe reutilizarse en silencio tras un cambio importante de navegador o de imagen. Vuelve a ejecutar el conjunto de texto representativo y registra la nueva base.

Actualiza una capa cada vez cuando sea posible. Primero valida la nueva versión de BotBrowser con el perfil y la imagen aprobados. Después valida la actualización de perfil prevista. Por último, valida cualquier cambio de imagen base o de paquete de idioma. Este orden acota el origen de un cambio visual y facilita las decisiones de reversión. Añadir o quitar un paquete de idioma, o actualizar una biblioteca de escritorio, puede cambiar el texto normal, así que pasa una imagen nueva por las mismas comprobaciones antes de que entre en el grupo de workers.

Un registro de versión conciso puede tener una fila por página: el resultado, el resultado esperado, las versiones del navegador y del perfil, la clase de host y la decisión de quien revisa. Anota si la página pasó, si requirió una actualización de base aprobada o si necesita investigación. Enlaza la fila con la captura o la salida del documento y con el responsable de la aplicación. Evita guardar datos de cuenta no relacionados o historiales de navegación completos, y usa cuentas de prueba dedicadas y documentos sintéticos cuando sea práctico.

Cuando una base cambia de forma intencional, conserva el resultado anterior el tiempo suficiente para explicar la transición, con un motivo breve como una actualización de tipografía del producto o de la familia de perfiles. No mezcles familias de perfiles no relacionadas en una misma base, porque los diseños de escritorio, móvil y tableta tienen expectativas distintas. La conservación debe seguir la política normal de calidad y privacidad de la organización, y los datos personales deben ocultarse antes de que una captura pase a un registro de larga duración.

Responder a cambios visibles

Abre la investigación con affectedPageId, previousBaselineId, changedComponent, rollbackDecision y ownerQueue.

Cuando el texto cambia de forma inesperada, pausa el despliegue amplio y reproduce la página afectada con el perfil, la versión del navegador, la imagen, el viewport y la revisión de la aplicación registrados. Confirma el cambio en un worker limpio antes de modificar la configuración. Así separas un problema persistente de la versión de una caché dañada o de un único host con problemas.

A continuación, compara la última combinación aprobada con la combinación candidata, cambiando un solo componente entre ejecuciones. Si la diferencia sigue a la imagen base, revisa los cambios recientes de paquetes. Si sigue al perfil, vuelve al perfil aprobado mientras el responsable revisa la actualización. Si sigue a la aplicación, envía el resultado al responsable de la página.

Si una revisión también usa los ajustes opcionales de ruido de ClientRects y de rectángulos de texto, que están desactivados de forma predeterminada, fija la semilla de ruido para la comparación. Sin una semilla fija, los valores de medición varían de una sesión a otra, y quien revisa no puede distinguir la variación prevista de un cambio real. Con una semilla fija, las sesiones repetidas dan la misma salida de medición y la comparación sigue siendo útil.

Registra el impacto en las personas usuarias y no solo la diferencia visual. Los glifos ausentes, las etiquetas recortadas, los controles inutilizables y la paginación alterada de los documentos merecen atención inmediata, mientras que una variación inofensiva de suavizado solo puede requerir una nota en la base. Tras una corrección, repite el conjunto representativo completo para la familia de perfiles afectada, porque la corrección de una página puede cambiar otro idioma o la maquetación de otro documento. Despliega por etapas, empezando por un grupo pequeño de workers, y promueve la versión solo cuando los puntos de control acordados pasen en cada clase de worker que la vaya a recibir.

Qué cubre BotBrowser en fuentes y qué no

El comportamiento de las fuentes es una señal entre varias, y un perfil solo es tan coherente como su superficie más débil. Antes de cambiar un perfil, un modo de fuentes o una imagen de host, vuelve a ejecutar el conjunto representativo y compara el resultado visible con el destino del perfil. Un cambio que parece pequeño en un idioma puede ser grande en otro, así que revisa cada idioma que admita el producto antes de aprobar la actualización. La documentación de fuentes recoge los modos y los pasos de resolución de problemas, y la documentación CJK cubre con más detalle el renderizado de chino, japonés y coreano.

Para más contexto, consulta Fingerprinting por medicion de texto: rastreo subpixel.

Conclusión

Usa --bot-fonts=profile cuando necesites un comportamiento de texto estable entre hosts. Mantén un conjunto pequeño de puntos de control multilingües, compáralo en cada clase de host compatible e investiga glifos ausentes, etiquetas recortadas o cambios de paginación antes del despliegue. La coherencia de fuentes mejora un límite de compatibilidad medible, pero no demuestra anonimato ni aceptación del sitio.

Fuentes públicas

• CSS Fonts Module Level 4
• CanvasRenderingContext2D.measureText() en MDN
• Documentación de BotBrowser sobre la huella de fuentes