Traducción al español por Isaac Uribe
el día 30 de Junio 2003, para La Gaceta de Linux

EL CONTROLADOR DE LA CONSOLA

Hasta el momento, con Linux 2.4.x, el kernel incluye un controlador de consola subdivido en un controlador de teclado y otro de pantalla. El controlador de consola est� siendo completamente reescrito para Linux 2.6.0 pero en este instante, b�sicamente, el controlador del teclado env�a caracteres a una aplicaci�n, la aplicaci�n hace su trabajo y solicita del controlador de pantalla alguna salida a la misma. El controlador de consola se complementa con el paquete kbd, que normalmente se encuentra en '/usr/share/kbd/' o en '/usr/lib/kbd/'.

Durante el camino entre el controlador de teclado a la aplicaci�n y hacia el controlador de pantalla, los caracteres no son m�s que c�digos (n�meros hexadecimales). Y ya que al final queremos ver sus peque�as im�genes (glyphs) en la pantalla, debe haber alguna de asociar los glyphs con estos c�digos.

�ste art�culo se enfocar� s�lamente en el controlador de pantalla, dando por sentado que algo ocurre entre el teclado y la aplicaci�n. Necesitaremos conocer algunas cosas b�sicas sobre las fuentes. Tambi�n ten a mano la p�gina del manual (man) de la utiler�a 'setfont'. Este art�culo est� basado en material de:

ftp://win.tue.nl/pub/linux-local/utils/kbd/
ftp://ftp.debian.org/debian/pool/main/c/console-tools/
http://qrczak.home.ml.org/programy/linux/fonty/

UNICODE

Tradicionalmente, las codificaciones de caracteres utilizan 8 bits, por lo que est�n limitados a 2^8=256 caracteres, lo cual es insuficiente. Por supuesto, hubo una vez hace mucho tiempo cuando las impresoras y monitores no se ten�an que preocupar por s�mbolos diacr�ticos (acentos, di�resis, etc.), solo manejaban may�sculas y en ocasiones min�sculas. Esos tiempos pertenecen a la historia, y ahora con la internacionalizaci�n (i18n), 256 caracteres no son m�s que un "aperitivo".

El "Conjunto Universal de Caracteres" (UCS - Universal Character Set), tambi�n conocido como Unicode, fu� creado para manejar y mezclar todos los lenguajes del mundo, incluyendo aquellos ideogr�ficos de China, Korea, Jap�n. Tiene m�s de 65000 caracteres para empezar, pero puede alcanzar hasta 2^31, intenta imaginarlo...

UCS es una codificaci�n de 32-bit/4-byte. Est� normalizado por ISO como el st�ndard 10646-1. Los caracteres m�s com�nmente utilizados de UCS est�n contenidos en el subrango UCS-2 16-bit. Este es el subrango utlizado ahora por la consola Linux. El conjunto de caracteres que utiliza Linux por defecto para N y S America, W Europa y Africa se conoce como latin1 o ISO 8859-1.

Por comodidad, una codificaci�n llamada UTF-8 fu� dise�ada para tener compatibilidad hacia atr�s con ASCII. Todos los caracteres que tienen una codificaci�n UCS pueden ser expresados como una secuencia UTF-8, y viceversa. No obstante, UTF-8 y Unicode son distintas codificaciones.

En modo UTF-8, el controlador de la consola trata al rango ASCII exactamente como antes, de manera que visores de texto antiguos pueden continuar desplegando ASCII. Los caracteres fuera del rango ASCII son convertidos a una secuencia de bytes de longitud variable (hasta 6 bytes por caracter), UTF significa en realidad Unicode Transformation Format (Formato de Transformaci�n Unicode), y UTF-8 cubre la conversi�n de caracteres de 8-bit - que era el rango utilizado por los conjuntos de caracteres tradicionales.

Unicode es complejo. S�lo ten presente que nos permite asignar un c�digo a cualquier caracter. �ste c�digo tiene 4 bytes en su forma completa, y 2 bytes en el subconjunto UCS-2, y aqu� el c�digo unicode se v�, por ejemplo 0x2502 tambi�n se puede escribir como U+2502. Si conoces este c�digo, puedes seleccionar el glyph (im�gen) para ese caracter de alguna fuente adecuada. En realidad, a�n los nombres de los glyphs est�n estandarizados y todos est�n en may�sculas, por ejemplo:

FEMININE ORDINAL INDICATOR (INDICADOR ORDINAL FEMENINO)

�Todo claro hasta ahora?

Problema 1: Encontrar el nombre oficial para un unicode dado.

Problema 2: Obtener el glyph para el unicode dado.

http://partners.adobe.com/asn/developer/typeforum/unicodegn.html

GLYPHS

A pesar de que ya hemos estado hablando de glyphs, y creo que por intuici�n nos queda claro que es lo que son, aqu� tenemos algunos comentarios adicionales.

Ejecuta tu editor de texto winword o su equivalente y escribe la letra 'a' varias veces, cambiando el tipo de fuente y el tama�o en cada una de ellas. Todas esas 'a'es se ven parecidas, aunque difieren en forma y tama�o. Lo que tienen en com�n es que todas ellas representas el mismo glyph, el caracter 'a'.

La referencia a un glyph es s�lo una abstracci�n de la fuente particular que necesariamente estar�s utilizando para poder ver algo.

Una fuente a es una colecci�n de glyphs de una forma particular. Mientras que en modo gr�fico se enfatiza la forma de la fuente (typeface), en modo consola nos debemos ocupar acerca de qu� glyphs est�n incluidas o no - y quiz�s acerca del tama�o de los mismos. Una fuente por software para la consola viene en un archivo binario con series de bits para cada glyph. Y hay una fuente por hardware en la ROM del adaptador VGA. �sta es la fuente que ver�s, si no hay fuentes por software cargadas al momento de arrancar.

UNIMAP

El mapa de fuentes de la pantalla nos da, para cada posici�n de la fuente de la consola, la lista de caracteres que va a desplegar. En Linux 2.4.x, el controlador de pantalla est� basado en la codificaci�n UCS-2.

El mapa de fuentes de la pantalla es conocido tambi�n como "Mapa Unicode" (Unicode Map) o "Unimap" o "Mapa de Consola" (Console Map) o "Mapa de Pantalla" (Screen Map) o "Tabla psf" (psf table), como sea. La terminolog�a var�a mucho y no contribuye para una f�cil comprensi�n. Sobre todo porque todos estos t�rminos ten�an diferentes significados antes de que llegara Unicode. Y especialmente ya que archivos que sirven para el mismo prop�sito y tienen el mismo formato est�n nombrados con diferentes extensiones. Al parecer esto se est� esparciendo, y como suena bastante diferente, vamos a ce�irnos al t�rmino "unimap" y a sus archivos '*.uni'. Si te encuentras revisando/utilizando diversas utiler�as de consola, diferentes del paquete kbd, ten en cuenta este "enredo" de terminolog�as.

Siempre hay un unimap. Se incluye con la fuente o se carga de un archivo diferente, o como �ltimo recurso tenemos el mapeo "derecho-a-la-fuente" (straight-to-font), "directo-a-la-fuente" (direct-to-font), "trivial", "directo", "nulo", "idem" o "de identidad". Otra vez terminolog�a que no est� estandarizada y que entorpece el fortalecimiento del usuario. Mapeo "idem" significa que la petici�n de un caracter por ejemplo 0xB3 es recibida y el glyph en la posici�n 0xB3 en la fuente es seleccionado directamente. Para enrededar m�s esto, el mapeo "derecho-a-la-fuente" (straight-to-font) no se considera de alguna manera un unimap. Preferimos decir que siempre hay un unimap, a�n que setfont del paquete kbd diga lo contrario. Ellos utilizan la opci�n

setfont -u none

Un glyph nos puede servir para diferentes unicodes. �C�mo es esto? Bueno, en ocaciones glyphs id�nticos tienen diferentes nombre, por ejemplo, la letra may�scula 'A' est� disponible en Ruso y en Espa�ol con diferentes nombre. Pero una fuente que cubra ambos idiomas no necesita este glyph dos veces. As� que dos unicodes nos dan en este caso el mismo resultado visual.

Tambi�n puede ocurrir que dos glyphs son diferentes pero muy parecidos visualmente, as� que s�lo se incluye uno en la fuente para ahorrar espacio, y funciona como sustituto del otro. Esto es an�logo a los viejos h�bitos de la era de la mecanograf�a. Por ejemplo, las comillas para citar textualmente, se abr�an y cerraban con el mismo glyph, aunque tipogr�ficamente fueran distintos.

Estas alternativas est�n formalizadas mediante las entradas de reserva (fallback). Una entrada de reserva es una serie de dos o m�s c�digos UCS-2, separados por un espacio en blanco. El primero es el unicode para el que queremos el glyph. Los siguientes son aquellos de los que usaremos sus respectivos glyphs en caso de que no tengamos disponible uno dise�ado para el primero. El orden de c�digos define el orden de prioridad (glyph propio disponible, si no el segundo, si no el tercero, etc).

Las entradas de reserva est�n habilitadas si se incluye en el unimap una l�nea como esta:

0x04a U+20AC U+004A

MODOS DE PANTALLA

Hay dos modos de pantalla, modo de byte �nico (hasta hace poco el valor por defecto m�s ampliamente utilizado) y el modo UTF-8. Cambiando la pantalla a UTF-8 y viceversa se realiza con las secuencias de escape '\e%G' y '\e%@' en el prompt. Utilizando:

unicode_start
unicode_stop

En modo UTF-8, los bytes recibidos de la aplicaci�n y los que ser�n escritos a la pantalla son interpretados como secuencias UTF-8, convertidas a unicodes y luego buscados en el unimap para determinar el glyph a utilizar.

El modo de byte �nico aplica un mapeo intermedio adicional a los bytes enviados por la aplicaci�n antes de utilizar el unimap.

�ste mapeo intermedio, se llamaba el "Mapa de Caracteres de Aplicaci�n" (Application Charset Map) o "Mapa de Aplicaci�n de Consola" (Application Console Map) - ACM or acm. Desfortun�damente, esta es la terminolog�a de las utiler�as de consola que silenciosamente a quedado en el olvido.

El paquete kbd no le d� ning�n nombre especial al mapa, se refiere a �ste como una "tabla de traducci�n" y lo coloca en archivos con extensi�n '.trans'. La p�gina del manual lo llama "Mapa de Consola Unicode" (Unicode console map) que es bastante ambiguo, ya que nos recuerda al Mapa Unicode (unimap). Llam�moslo "cmap", una abreviaci�n utilizada aqu� y all�.

Aqu� tenemos un diagrama simple de los dos modos:

    Modo byte �nico :
        aplicaci�n ->      cmap ->         unimap -> pantalla
                     (bytes)      (UCS-2)

    Modo UTF-8:
        aplicaci�n ->                      unimap -> pantalla
                     (UTF-8 / UCS-2)

Memoriza este diagrama ya que es la clave para entender esta confusi�n de t�rminos en la documentaci�n. Aseg�rate que puedes distinguir entre cmap y unimap: �Qu� es lo que hace cmap?

�QU� ES LO QUE HACE CMAP?

Hay varios formatos para cmap, y s�lo uno que nos permite entender lo que realmente hace cmap. Por ejemplo, echa un vistazo al archivo 'cp437_to_iso01.trans' en el directorio '../consoletrans' del paquete kbd. El c�digo de p�gina 437 viene de los tiempos del primer DOS y a�n es la fuente en la ROM de cualquier adaptador VGA.

El archivo tiene dos columnas de n�meros hexadecimales. La primera columna es una enumeraci�n de las entradas en la fuente, 256 como m�ximo. Solamente 256 pueden ser manejadas por cmap.

La segunda columna es la traducci�n. El archivo en cuesti�n hace posible utilizar una fuente cp437 como si fuera una fuente latin1. La traducci�n no es perfecta, pero funciona, por ejemplo:

0xA1 0xAD

Cuando utilizamos fuentes de 256 caracteres, un cmap que realmente traduce significa que da alternativas. Cuando no se necesitan alternativas, el cmap es "derecho-a-la-fuente" (straight-to-font): cada car�cter se traduce a su mismo c�digo, solamente el unimap es relevante. Este es el m�s natural y com�n caso.

Sin embargo, una fuente puede estar dise�ada para abarcar m�s de un rango de caracteres. Esto es evidente para las fuentes de 512 caracteres pero hay en realidad fuentes de 256 caracteres que pueden manejar m�s de un rango de caracteres (claro que parcialmente). Si utilizas esa clase de fuentes, el cmap te permite seleccionar uno de los rangos cubiertos. Un ejemplo (lat1-16.psfu) se discute a continuaci�n.

LEYENDAS G0/G1

Aunque solamente hay un cmap activo en un momento dado, el kernel maneja cuatro de ellos. Tres de ellos son empotrados y nunca cambian. Estos definen el c�digo de p�gina IBM 437 de las primeros versiones de DOS con caracteres de caja, el conjunto de caracteres DEC VT100 tambi�n con caracteres de caja, y el conjunto ISO latin1. El cuarto conjunto de caracteres del kernel est� definido por el usuario, por defecto el mapeo "derecho-a-la-fuente" (straight-to-font), y s�lo puede ser cambiado cargando una fuente por software.

El controlador de consola tiene dos entradas etiquetadas G0 y G1, cada una referenciando a alguno de los conjuntos de caracteres del kernel. G0 y G1 pueden variar de consola a consola mientras que apunten a cp437, vt100, latin1. Si pones un cmap diferente de estos tres en cualquier entrada G0 o G1 en cualquier consola, todas las dem�s consolas cambiar�n al mismo conjunto de caracteres definido por el usuario. Por defecto, G0 apunta a latin1 y G1 apunta a vt100. G0 y G1 pueden ser manipulados con secuencias de escape en la consola. Y a pesar de que son mencionados frecuentemente, mejor los dejas tal cual. �Por qu�?

Si cargas una fuente por software y env�as secuencias de escape para cambiar de conjuntos de caracteres del kernel, podr�as estar aplicando a tu fuente por software una traducci�n que produce bastante basura. El cmap que selecciones debe ser adecuado para tu fuente y ser un "jugador del equipo" con el unimap actual. La �nica garant�a que tienes al respecto es confiar en 'setfont' y controlar cmap y unimap. Si comienzas a mezclar comandos 'setfont' con secuencias de escape a la consola, los cuales se basan parcialmente en los valores por defecto, podr�as (�seguramente!) terminar perdiendo el rumbo. Para mantener cmap y unimap bajo control, utiliza fuentes que tengan un unimap incluido y utiliza

setfont -m none mi_nueva_y_hermosa_fuente.psfu

�Y qu� acerca de los conjuntos definidos por el usuario? Si le has echado un vistazo a una fuente por software (y siempre que ejecutas 'setfont' cargas una fuente por software, a excepci�n de cuando est�s guardando la fuente actual a disco), la secuencia de escape para seleccionar el conjunto de caracteres definido por el usuario del kernel activa �sa fuente por software con el conjunto de caracteres impl�cito a su cmap y no tienes manera de revertirlo a la fuente de la ROM. Si revisas el c�digo fuente de 'setfont', te dar�s cuenta que est�n activando la fuente por software de todos modos. Olv�date del conjunto definido por el usuario, no es de tu incumbencia, deja esto a 'setfont'.

Por otro lado, si ejecutas la fuente de la ROM y no has cargado una fuente por software, solicitar el conjunto definido por el usuario solamente har� que cambies a cp437, la raz�n por la que el conjunto definido por el usuario tiene "derecho-a-la-fuente" (straight-to-font) como valor por defecto. Por ejemplo, as�mamos que escogiste vt100 que no tiene letras min�sculas e inmediatamente nos desplegar� basura, env�a la secuencia de escape para el conjunto definido por el usuario (que no ha sido definido a�n, por lo que contiene el valor por defecto): la basura desaparece y tenemos las min�sculas de nuevo.

Hay, sin embargo, una fuente por software que ha sido expl�citamente hecha para lidiar con los conjuntos del kernel. Esta fuente se llama

lat1-16.psfu

Advertencia: Si est�s en una regi�n donde latin1 no es adecuado, mantente con la fuente proveida por tu distribuci�n (y seguramente desp�dete de los elementos de dibujo caja). Si latin1 funciona, utiliza lat1-16.psfu. Esto te dar� los caracteres latin1 adem�s de las lineas-caja de tu administrador de archivos.

DOCUMENTACI�N O LA FALTA DE ELLA

Los problemas sobre las fuentes para la consola Linux est�n pobremente documentados. Las p�ginas del manual (man) son muy densas, la terminolog�a es ambigua, y los COMOs (HOWTO's) que vienen con el paquete kbd son un desastre, me pregunto si la gente que los recomienda alguna vez a intentado leerlos.

Todo lo presentado en este art�culo es elemental y a�n as� tom� su esfuerzo para hilarlo. Vamos a resumirlo desde un punto de vista diferente, no nos afectar� en lo m�s m�nimo.

• Las siguientes distinciones deben mantenerse presentes:

(i) La fuente de la ROM (Siempre 256 caracteres) (ii) Fuentes de consola por software
(a) 256 caracteres como m�ximo (b) 257-512 caracteres

• La fuente de la ROM es la antigua DOS cp437. Despu�s de cambiar de la fuente de la ROM a una por software, no hay forma de revertir el proceso, salvo reiniciando.
• El cmap y unimap deben ser adecuados para la fuente u obtendremos basura. Cuando el mapeo es el adecuado, una fuente puede ser utilizada con diferentes "personalidades" y cubrir m�ltiples conjuntos de caracteres. Esto se hace evidente al utilizar fuentes de 512 caracteres.
• Si crees que una fuente de 512 caracteres ser�a la opci�n m�s obvia, pi�nsalo de nuevo - ya que una fuente de 512 caracteres deshabilitar�a los colores - negritas. Red Hat 8.0 utiliza una de estas fuentes como defecto, y los usuarios de Red Hat no est�n muy a gusto. Revisa, sin embargo, lo dicho acerca de Mandrake.
• Solamente puedes desplegar caracteres que est�n en la fuente de consola actual. Es decir, no puedes cambiar de la fuente X a la fuente Y al vuelo, desplegar los caracteres que est�n en Y pero no en X, y regresar a X. Porque cuando est�s de regreso en X, los caracteres escritos con Y ser�an sobreescritos al refrescar la pantalla. Esta es la raz�n por la que tu administrador de archivos, digamos Midnight Commander, no desplegar� elementos-caja si est�s utilizando una fuente latin1 pura (que no tiene elementos-caja).

PREGUNTAS Y RESPUESTAS

�C�mo forzo la fuente de la ROM en la consola?

Debe haber alguna utiler�a en alg�n lugar, pero no est� en el paquete kbd. Sin una utiler�a como esa, la �nica manera de forzar la fuente de la ROM es arrancar con la fuente de la ROM. Revisa tus scripts init y aseg�rate de que no se carguen fuentes por software. Si no lo encuentras, renombra el directorio donde se encuentra la fuente por software, de manera que no se pueda encontrar/cargar al momento de arrancar.

Mientras est�s utilizando la fuente de la ROM, intenta:

echo -ne '\e(U'
setfont -o cp437-16.psf

en el prompt. El archivo cp437-16.psf contiene la fuente de la ROM. Esta fuente tiene una altura de 16 pixeles.

Si te refieres a qu� nombre tiene la fuente, revisa los scripts de arranque y/o el log del shell para saber que fuente por software fu� cargada la �ltima ocasi�n (quiz�s ninguna, lo que significa que la fuente de la ROM est� activa). Si quieres ver los caracteres de la fuente de acuerdo con su arreglo actual, ejecuta:

echo -ne '\e(K'
setfont -om fuente_actual.trans

y revisa el archivo 'fuente_actual.trans' con alg�n editor. Esto no funciona al 100% ya que ciertos rangos de caracteres (0-31 y 128-159) no son desplegados de manera correcta aunque probablemente est�n almacenando glyphs. Si la fuente tiene un unimap, este enlistar� todos los caracteres con sus nombres oficiales. Lo cual seguramente nos dar� una idea del glyph.

Los caracteres son de 8 pixeles de ancho, pero el hardware VGA a�ade una novena columna en blanco para desplegarlos a una peque�a distancia unos de otros. Eso es bastante apropiado para la mayor�a de los caracteres, pero no para los segmentos de linea horizontales que deber�an aparecer completamente pegados. Por esta raz�n el hardware VGA hace una excepci�n para los elementos-caja: en lugar de insertar espacios vac�os repite la octava columna de pixeles. Hasta ah� vamos bien, pero �De qu� manera el hardware VGA distingue d�nde pusimos nuestros elementos-caja? No hay forma, as� que o pones estos elementos en el mismo rango donde se encontraban en cp437 o vas a tener esos espacios.

Necesitas arrancar con el framebuffer, para detalles revisa el Framebuffer-HOWTO.html. Las opiniones acerca del framebuffer est�n divididas, Mandrake arranca en �l por defecto, SuSE advierte sobre esto. Desconozco la posici�n oficial de Red Hat's pero ellos no lo utilizan a pesar de que utilizan una fuente con un conjunto de 512 caracteres, lo cual deshabilita los colores.

S�lo es posible debido a que cubre solamente en parte cada conjunto o a que cubre conjuntos menores de 256 caracteres. cp437 est� hasta el tope, tiene exactamente 256 caracteres, de manera que lat1-16.psfu lo cubre parcialmente. Por otro lado, latin1 mantiene el rango de caracteres de control (0-31 y 128-159) vac�o, de manera que s�lo contiene 192 caracteres. vt100 es manejada como un conjunto de 128 caracteres pero complementada con latin1 en el rango 160-255. De manera que en esencia lo que hace lat1-16.psfu es mantener los elementos caja-bloque en donde se encontraban usualmente en cp437 y mover los caracteres latin1 a alg�n otro lugar. De esta manera todo cabe dentro del conjunto de 256 caracteres. Bien hecho.

La fuente de la consola es la misma para todas las consolas, lo que puede variar es el conjunto de caracteres (cmaps) utilizado en cada una de ellas.