Escalas fraccionarias, fuentes y hinting

Artículo original ↗ Discusión en Hacker News ↗

Reacción general a los cambios de renderizado de fuentes en GTK

  • Muchos usuarios veteranos de GTK están satisfechos; las capturas muestran una gran mejora en nitidez frente al GTK4 anterior.
  • Algunos quieren comparaciones con pilas anteriores (p. ej., GTK 3 con Pango anterior a la 1.44), que recuerdan como más nítidas.
  • Unos pocos sostienen que GTK 3 sigue viéndose mejor que GTK 4, incluso después del nuevo trabajo.

Hinting, AA subpíxel y filosofías de renderizado

  • La discusión contrapone:
    • Renderizado que preserva la forma pero es ligeramente borroso (a menudo asociado con Apple).
    • Renderizado alineado con la cuadrícula de píxeles, más nítido pero que distorsiona la forma (a menudo asociado con Windows antiguo/ClearType).
  • Varios señalan que muchos toolkits están abandonando el AA subpíxel (GTK, Apple moderno, algunas pilas de MS) a favor del AA en escala de grises más HiDPI.
  • Hay desacuerdos:
    • Algunos consideran que el AA en escala de grises es “lo bastante bueno”, incluso a ~100–110 DPI.
    • Otros insisten en que el AA subpíxel sigue siendo notablemente más nítido en pantallas comunes 1080p/1440p/4K@150%.
  • Se debate si el AA subpíxel merece sus inconvenientes (franjas de color, geometría dependiente del dispositivo, capturas de pantalla malas) en paneles modernos.

HiDPI, escalado fraccionario y configuraciones multi-monitor

  • GTK antes usaba renderizado a 2x más reducción; ahora hace escalado fraccionario por widget, lo que se ve como más eficiente pero más difícil de hacer bien.
  • El nuevo comportamiento de gtk-hint-font-metrics es bien recibido; ahora se aplica automáticamente según el DPI de la pantalla, mejorando las configuraciones con DPI mixto.
  • Comparaciones:
    • macOS: renderiza a una resolución virtual más alta y se apoya en HiDPI; puede verse torpe en pantallas externas no HiDPI, especialmente desde la eliminación del AA subpíxel.
    • Windows: algunos elogian el escalado de DPI por monitor; otros informan de una UI borrosa, muchas configuraciones confusas y compatibilidad frágil entre aplicaciones.
    • Haiku y las API antiguas de Windows usan unidades de diseño basadas en el tamaño de fuente; algunos lo ven elegante, otros dicen que carga a los desarrolladores.

Corrección gamma, ajuste de FreeType y configuraciones

  • Varios sostienen que el renderizado de fuentes en Linux suele ser incorrecto por falta de corrección gamma o por una corrección gamma errónea, especialmente para texto claro sobre fondo oscuro.
  • Se mencionan soluciones alternativas:
    • Las propiedades de FreeType (p. ej., el oscurecimiento de trazos y la versión del intérprete) pueden cambiar de forma significativa el peso y la nitidez percibidos.
    • Variables de entorno y banderas para que las aplicaciones Electron/Chromium usen Wayland y mejores rutas de fuentes.
  • Hay desacuerdo sobre si los cambios en FreeType “rompieron” el ajuste a la cuadrícula o simplemente se desplazaron para coincidir con distintas épocas tipográficas.

Preocupaciones residuales

  • Algunos siguen viendo borrosidad en capturas de GTK y cuestionan la ausencia de AA subpíxel y de un hinting completo en horizontal y vertical.
  • Se reconoce ampliamente que hacer el renderizado de texto “perfectamente” en todos los dispositivos y DPI es muy complejo y polémico.