¿Cómo funciona realmente el renderizado de fuentes?

Me doy cuenta de que esencialmente no sé nada sobre la forma en que las fuentes se representan en mi computadora.

Por lo que puedo observar, el renderizado de fuentes generalmente se realiza de manera consistente en todo el sistema. Por ejemplo, la configuración de sugerencia de fuente de subpíxeles que configuro en mi panel de control DE tiene influencia en el texto que aparece en los bordes de las ventanas, en mi navegador, en mi editor de texto, etc. (Debo observar que algunas aplicaciones Java muestran una diferencia notable, por lo que supongo que están utilizando un mecanismo de representación de fuente diferente).

Lo que obtengo de lo anterior es que probablemente todas las aplicaciones que necesitan representación de fuentes utilizan alguna biblioteca de todo el sistema operativo (o DE).

Por otro lado, los navegadores generalmente administran su propio renderizado a través de un motor de renderizado, que se encarga de colocar varios elementos, incluido el texto, de acuerdo con reglas de flujo específicas.

No estoy seguro de cómo estos dos hechos son compatibles. Supongo que el navegador tendría que pedirle al sistema operativo que dibuje un glifo en una posición determinada, pero ¿cómo puede administrar el flujo de texto sin saber de antemano cuánto espacio ocupará el glifo? ¿Hay llamadas separadas para determinar los tamaños de glifos, de modo que el navegador pueda administrar el flujo como si los caracteres fueran pequeños cuadros que luego el SO rellena? (Aunque esto no se ocupa del kerning). ¿O es el sistema operativo responsable de dibujar un área de texto completo, incluido el flujo de texto? ¿El sistema operativo devuelve el glifo representado como un mapa de bits y lo deja en la aplicación para dibujarlo en la pantalla?

Tiene razón en que, en general, las aplicaciones usan bibliotecas proporcionadas por el sistema operativo o un kit de herramientas GUI para hacer la representación de fuentes.

Los motores de fuente típicos permiten varios modos de operación. Para el caso simple, una aplicación puede pedir que se dibuje una cadena de texto en una posición determinada, y el motor se encarga de todo (medición, posicionamiento, dibujo de píxeles en la pantalla, etc.).

Para las aplicaciones que requieren un mayor grado de control, como navegadores o procesadores de texto, por ejemplo, el motor expondrá las interfaces donde la aplicación puede solicitar que se mida un fragmento de texto por adelantado. La aplicación puede usar este conocimiento para calcular cuánto texto puede caber en una línea, dónde deberían estar los saltos de línea, cuánto espacio ocupará un párrafo, etc. La aplicación aún puede pedirle al motor que haga el renderizado real de los píxeles

(Puede haber un escenario intermedio en el que el motor puede tomar un parámetro de ancho máximo, y posiblemente algunos parámetros de interletraje / relleno, y generar automáticamente la mayor cantidad de texto posible).

Finalmente, el motor de fuentes podría permitir que la aplicación se haga cargo de la representación final del texto, devolviendo mapas de bits de glifos pre-renderizados en un cierto tamaño, permitiendo que la aplicación lo posicione y componga en la pantalla final. O el motor podría incluso ofrecer devolver los datos de esquema de glifo sin procesar para renderizar con algún conjunto de herramientas vectoriales.