Estoy tratando de comprender la historia completa detrás de cómo llega el texto a las pantallas. Para simplificar las cosas, me quedo con codificaciones de un solo byte (sin Unicode).
En mi disco hay una secuencia de bytes, cada uno con un valor entre 0 y 255. Luego puedo decirle a mis programas de computadora qué codificación de caracteres deben usar para mostrar estos bytes. Podría usar ISO-8859-1 donde, por ejemplo, el byte con valor 0xA4 es un círculo con puntos (¤). O podría cambiar a ISO-8859-15, entonces mi byte con valor 0xA4 se define como el símbolo del euro (€).
Todo esto sigue siendo sencillo de entender. Pero además de cambiar la codificación de caracteres, también puedo cambiar la fuente para definir la forma exacta de un símbolo. Ahora bien, una fuente está destinada a funcionar contodocodificaciones de caracteres. Entonces, una fuente debe tener ambos símbolos: ¤ y €.
Entonces, los pasos para recibir un mensaje de texto en mi pantalla son obviamente:
- Leer secuencia de bytes en serie
- Utilice el valor numérico del byte actual para buscar en la tabla de codificación de caracteres
- Utilice [algo] para buscar en el archivo de fuente la forma exacta del símbolo que se encuentra en el paso 2
- Dibujar símbolo como se define en el archivo de fuente
En el paso 3, ¿qué es ese "algo" que se utiliza para asignar la codificación de caracteres a la fuente? ¿Los archivos de fuentes dependen de la codificación de caracteres? Entonces, ¿una fuente tiene algún mecanismo incorporado de "doble interruptor" que funciona como (pseudocódigo)?
get_symbol(code, encoding) {
switch code{
case 0xA4: switch(encoding) {
case 'ISO-8859-1' : return '¤';
case 'ISO-8859-15': return '€';
}
}
}
?
¿Cuáles son los detalles sobre cómo pasar de una secuencia de bytes determinada y una codificación de caracteres determinada al símbolo real de la fuente? ¿Cómo se asigna esto para dar siempre el símbolo correcto?
Respuesta1
Los archivos de fuentes están diseñados para mostrar una codificación particular. El programa que utiliza una fuente determinada debe asumir que un valor nen una codificación determinada se muestra representando el número de glifo correspondiente n.
Los archivos de fuentes no necesitan tener glifos para todos los valores posibles de una codificación de caracteres determinada (para Unicode es raro que una fuente cubra todo el rango), ni necesitan comenzar con el primer valor de la codificación (normalmente se omiten los caracteres de control). . Existen diferentes esquemas de formato de archivo para especificar el punto inicial, el punto final y los glifos omitidos que se utilizan para mantener manejables los tamaños de archivos de fuentes.
Según el ejemplo dado, es probable que el OP esté utilizando el sistema X Window. Se utiliza más de un formato de archivo, con las correspondientes diferentes formas de acceder a ellos. Los principales sonXLFD(mayor) yconfiguración de fuente(más nuevo). Con otros sistemas (Microsoft Windows), se utilizan otras API (lasLOGFONTestructura es un buen punto de partida). OSX es otro ejemplo, con su propia API (Texto central).
Por supuesto, son para interfaces gráficas. Las fuentes son más aplicables que eso. Por ejemplo, Linux y BSD permiten especificar diferentes fuentes de consola, que además de la codificación, tienen limitaciones en la cantidad de glifos que se pueden utilizar. Aquí hay algunos enlaces útiles para aquellos:
Respuesta2
La aplicación que dibuja el texto especifica una fuente en las API de dibujo de texto que está usando o, si no la especifica, se usa una fuente predeterminada del sistema.
Los sistemas de dibujo de texto basados en Unicode a menudo tienen un algoritmo de sustitución de fuentes para encontrar una fuente que contenga un determinado glifo si la fuente especificada no tiene el glifo solicitado. Pero los sistemas anteriores a Unicode generalmente simplemente no logran dibujar un glifo o dibujar un glifo de "glifo faltante". Incluso los sistemas basados en Unicode a veces dibujan un símbolo de "glifo faltante".