Informaticosas

Algo de agua ha pasado bajo el puente desde que publiqué el alfabeto monotrazo que utilizaba en los crucigramas. Ahora, por medio de esta nota encontré una manera muy sencilla de hacer una nueva versión.

El sitio FontCapture facilita la creación de un tipo de letra personalizado de una manera sencilla. Se descarga una plantilla (PDF), se escribe cada letra en la casilla que corresponda, se carga en el propio sitio y al momento se dispone de un archivo de tipografía (TTF) listo para descargar.

La manera elegante de hacerlo es imprimir la plantilla, escribir, digitalizar y cargar; pero como hace años que no imprimo (ni tengo impresora) pues lo hice algo diferente. Convertí el PDF a un formato de imagen (PNG, creo) y sobre la misma plantilla escribí con una tableta digitalizadora, y cargué la imagen con las letras; de este modo evité dos pasos: imprimir y digitalizar. El problema es que la letra no queda tan bien trazada como con un lápiz, pero, es lo que hay. Una muestra de texto en un procesador de ídem (Kword):

Se puede hacer mejor, en cualquier caso, este primer intento se puede descargar directamente.

Nada más fácil: se crea una cuenta en Flickr o Twitpic y enviando un mensaje de correo con foto anexa, se publica directamente en estos y quién sabe cuántos más servicios.

Pero, ¿qué pasa si quieres tener todas tus fotos en tu propio servidor y para ello utilizas la versión 1 de Gallery y sigues apegado a ese programa? Ahí la cosa se complica porque no hay -todavía- ninguna manera de publicar una foto mediante un mensaje de correo. Lo que sí hay es un script de Perl llamado galleryadd.pl que permite publicar una foto desde el disco local de la máquina a tu galería fotográfica.

Después de mucha vuelta, llegas a la conclusión de que lo que necesitas es un script que al recibir el mensaje con la foto, la guarde en el disco y le diga a galleryadd.pl que la coloque en su album.

En primer lugar parece lógico configurar galleryadd.pl para que publique en un album predeterminado con un usuario predeterminado y hacer un script de una línea (llamémoslo fotoAGaleria que simplifica el envío de las opciones, la contraseña es fija y el album es fijo. El pie de foto será el 'asunto' del mensaje de correo ("$2", muy importantes las comillas).

#!/bin/sh
/ruta/al/script/galleryadd.pl -p XXX -a NOMBREDEALBUM  -C "$2" $1

A continuación lo más sencillo resulta ser utilizar los filtros de kmail de la forma siguiente. Entre las opciones de filtrado está la de 'ejecutar orden'; con esa opción el primer adjunto (la imagen) se guarda en el disco así: cat %1 > fototemporal.jpg

Inmediatamente después (otra opción 'ejecutar orden' del filtrado) se ordena la publicación invocando el script realizado anteriormente:
/ruta/al/script/fotoAGaleria /ruta/a/fototemporal.jpg %{Subject} ; allí se puede ver que el primer argumento es el archivo con la foto y el segundo, el asunto (subject) que servirá como pie de foto.

En mi caso creé una cuenta de correo sólo para esto y cada vez que reciba una foto será publicada automáticamente. KMail revisará periódicamente la cuenta y borrará el mensaje después de publicar la fotografía... nada más fácil.

Actualización: Con adición del módulo Mailhandler a Drupal, y un poquito de configuración, el envío se puede hacer a los dos lugares; a las galerías gráficas y como post de Drupal...

Joey Hess cuenta del nuevo sitio Adiós Microsoft, que de una manera más que elegante permite instalar debian desde un navegador y corriendo en "Windows".

Para lograr la libertad (al menos esta del software) sólo hay que hacer clic en donde dice "here". El navegador descarga el programa instalador que se autoejecuta y una vez instalado pide reiniciar la máquina. Al elegir la opción de instalar debian, se procede normalmente, con la elección del idioma, etc. Todo lo que hace falta es una conexión de red y seguir los pasos (que incluyen un -último- formateo del disco); todos los programas se descargan de la red.

Adrian White (Analytic Social Psychologist, University of Leicester), en lugar de decir que acaba de publicar una representación gráfica por país que integra diversos indicadores de nivel de vida, titula: "El mapamundi de la felicidad"; con lo que obtiene publicidad abundante y gratuita para su trabajo.

Puede verse en este fragmento del mapa que el país "más feliz" de Suramérica es el que nos cobija, y esto no debe contradecir ninguna percepción porque es bien sabido que en Venezuela no estamos, somos felices. Según White no son los países más ricos los que puntean la lista de felicidad y de hecho plantea que los gobiernos deberían preocuparse más por la felicidad que por la riqueza. Parece que los países punteros (con Dinamarca a la cabeza) tienen estupendos valores en salud, ingreso y -en tercer lugar- educación. Esto sí que contradice la percepción de cualquiera...

Ahora que he hecho el proceso completo al menos una vez, creo estar en condiciones de echar el cuento de cómo producir un audiolibro en GNU/Debian(testing)/Linux. Se supone que disponemos de un libro -o cualquier otro texto- en formato PDF, al final se obtiene un cierto número de archivos mp3 u ogg que pueden escucharse en la computadora o en un tocador portátil de esos formatos.

Los programas requeridos -aparte de las herramientas normales del terminal- son: festival (incluye text2wave y voz en español), pdftotext o ps2text, y lame para producir MP3.

Primero, hay que convertir el archivo PDF a texto y el problema puede estar en la codificación del texto. En esta máquina la codificación predeterminada es iso-8859-1 o Latin1. También puede pasar que la conversión no se pueda realizar porque el conversor no "conoce" la codificación. En ese caso, hay que agregar la línea textEncoding Latin1 en el archivo de configuración de xpdf, en debian está en: /etc/xpdf/xpdfrc. Así que hay dos opciones:

• pdftotext -enc Latin1 archivo.PDF
• pstotext -output archivo.txt archivo.pdf

Después de probar ambas, me quedo con la última. ps2text hace un mejor trabajo de conversión del texto a Latin1 (de hecho es lo que hace de forma predeterminada), elimina caracteres ocultos y deja el texto más limpio (por ejemplo, convierte los guiones largos en ---). Este proceso tarda unos pocos segundos.

Pero el conversor de texto a voz comete actualmente algunos errores intolerables, como no entender los signos ¿ (pronuncia "equis" y deletrea la palabra que sigue). Así que hay que pulir el texto, esto es, corregir la ortografía (los acentos y demás detalles son importantes para la pronuciación correcta) y eliminar los caracteres no pronunciables o que causan esos errores en el robot-lector, en el caso que nos ocupa ¿ ¡ - y similares. Para ello se puede hacer un pequeño libreto (script) con sed, como líneas como esta: sed -i -e 's/¿/ /g' archivo.txt. Una vez pulido el texto, ya se puede enviar al lector, pero el resultado sería un solo archivo excesivamente largo si se trata de un libro (unas 300 páginas pueden llevar a 200 megabytes de archivo de sonido y eso en un formato comprimido). Así que es preferible 'picar' o dividir el texto original en trozos para que sea más sencillo detener al lector y llegar a un punto dado.

Para dividir el archivo ya corregido en pedazos de (por ejemplo) 300 líneas: split -l 300 -d archivo.txt prefijo. El 'prefijo' es el nombre que tendrán los archivos divididos seguidos de un número secuencial, por lo tanto esa orden crea una serie de archivos con nombre prefijo01, prefijo02, etc. Si text2wave se confunde con los nombres de los archivos, se les puede agregar la extensión .txt de forma automática así: rename 's/$/\.txt/' prefijo*

Hasta aquí, no se ha producido ningún sonido, aparte del típico repiqueteo del teclado. Ahora hay que ordenarle a text2wave que vaya leyendo cada uno de los archivos text2wave prefijo04.txt -o archivodesonido04.wav. Pero, puede pasar -así fue en este caso- que el lector predeterminado no sea el que queremos. Para hacer que la voz elegida por text2wave para leer sea la que realmente se desea hay que modificar -o crear, si no existe- un archivo llamado .festivalrc y colocar esta línea: (set! voice_default 'voice_el_diphone): la voz "el_diphone" que corresponde a un lector español será la que haga el trabajo; de otro modo muy bien puede suceder que el lector sea un gringo y la lectura será consecuentemente errada.

Además, es preferible hacer de una vez la conversión a un formato portátil, sea MP3 u Ogg, de una de estas formas:

• text2wave prefijo01.txt | lame - prefijo01.mp3
• text2wave prefijo01.txt | oggenc - -o prefijo01.ogg

Ya que pueden resultar muchos archivos (entre 10 y 100, dependiendo de la longitud que hayamos decidido poner como norma) es mejor hacer un libreto o script, algo como:


cuenta=1
for i in `ls prefijo*`
do
text2wave $i | lame - prefijo${cuenta}.mp3
cuenta=`expr $cuenta + 1`
done


Lo que queda es esperar un rato; según mi cuenta, aproximadamente una décima parte del tiempo de lectura real. Es decir, si la lectura del libro completo dura unas 30 horas, el proceso de conversión de texto a voz tardará unas tres; de hecho algo menos, dependerá de la velocidad de la máquina y demás detalles.

De las cosas menos aprovechadas en el ámbito de las tecnologías actuales (no "nuevas") la que más resalta es la del sonido. La situación se puede comparar con la radio: muchas emisoras, cero producción. Tantas y tantas horas de emisión radial y prácticamente ningún aprendizaje útil. 50 % musiquita, 50 % o más de propaganda (y no hay que olvidar que el porcentaje de musiquita también es propaganda). Alguna noticia. Más nada. Por otro lado, es casi increíble la facilidad que tiene un oyente para atender a lo que escucha y a otra cosa que puede estar haciendo simultáneamente. De allí lo de la gran oportunidad desaprovechada.

Quienes padecemos sin remedio la "autopista" regional del centro nos vemos obligados a soportar cualquier cantidad de musiquita y propagandas; la única excepción consiste en una emisora 'vial informativa' que da información sobre lo que es evidente: hay cola aquí, habrá allá, los peajes están congestionados, no hay vías alternas, etcétera. Sin embargo, hay ocasiones en que un dato de esta emisora permite evitar algo de la inevitable cola que más tarde o más lejos encontrarás.

Es en ese contexto que los tocadores de formatos comprimidos de audio (típicamente MP3) vienen a cumplir una función que podríamos llamar educativa. Es algo que también se puede hacer con lectores de CD, pero es más práctico con estos "bichitos".

He escuchado algunas conferencias e incluso algún libro grabado por lectores humanos, y por supuesto es mucho más grato que escuchar propagandas estridentes. Pero con ocasión de la búsqueda de algún libro para entretener esas horas perdidas me encontré con algo que no por conocido deja de sorprender. Conseguí un libro completo leído mediante una voz autómata que me ha impresionado por su claridad. El libro es 'La revelación de los templarios' y no merece mayor atención; sin embargo, la lectura de esta robot, porque es una voz femenina, impacta porque lee mejor que mucha gente que uno conoce. Los errores que comete se deben a algún acento mal colocado o a la presencia en el texto de nombres extranjeros (como los autores del libro) que pronuncia tal como se leen en la grafía española. El único otro inconveniente es la velocidad, que aunque correcta para la lectura, se hace pesada al rato debido a la constancia implacable de la lectora.

Viendo la cantidad de libros en formato electrónico que tengo en cola para leer 'algún dia' es evidente que si logro convertirlos en audio digital los podré escuchar con más probabilidad que leerlos en la pantalla del computador. Recordé que dispongo de un programa lector de este tipo denominado festival. Tras una pequeña búsqueda veo que el escritorio que utilizo (KDE) tiene una interfaz gráfica que facilita su uso. Lo que faltaría es recoger el sonido de la lectura en un archivo, cosa que hace con facilidad Audacity, tras lo cual se puede comprimir el resultado en formato MP3 o Vorbis. Lo demás sería automatizar el proceso para convertir todos esos libros en audio. Entre otras ventajas está la de no requerir personal, comprometido por horas para leer con tono uniforme textos que posiblemente no le interesan.

La versión de 'festival' de que dispongo tiene una sola voz en español, masculina y castiza. Se equivoca bastante con los guiones y otros signos atravesados en el texto, pero en general es entendible y esos detalles se pueden corregir si uno es el que está produciendo el material. Supongo que para convencer a los más escépticos debo aportar una prueba, y aquí está (4,5 minutos, mp3, 777 KB).

Estuve retrasando un buen tiempo el asunto de crear los respaldos de toda la información (bases de datos, documentos y por supuesto ¡el blog!) porque requería hacer un estudio en profundidad de cómo conectarme a otra máquina sin que solicitase contraseña, para poder programar un respaldo madrugador y sin intervención humana. Eso iba a ser aproximadamente nunca, si no fuese porque conseguí un sitio donde explican brevemente cómo hacerlo.

Con fines "filantrópicos" (más bien mnemotécnicos), relataré aún más brevemente el asunto y en cristiano, por si puede servirle a alguien.

Lo primero es que en ambas máquinas, la que origina la conexión (digamos UNO) y la que la recibe (digamos DOS) deben disponer de una instalación funcional de SSH (Secure SHell, en debian se trata de OpenSSH). El usuario que origina la conexión debe tener un directorio .ssh, al igual que el usuario de destino. A continuación, los tres pasos para que se dé la conexión sin explicitar contraseña:

1. En la máquina UNO, se genera un par de claves, en el directorio .ssh con esta orden: ssh-keygen -t dsa -f id_dsa -P ''; esto genera dos archivos id_dsa y id_dsa.pub que corresponden a cada clave.
2. Se copia la clave pública en la máquina DOS, en el directorio .ssh del usuario destino: scp id_dsa.pub usuariodestino@maquinaDOS:.ssh/
3. En la máquina DOS se agrega la clave pública recién copiada a la lista de claves autorizadas: cat id_dsa.pub >> authorized_keys2

El paso siguiente es probar que funciona. Para realizar un respaldo automático se debe tener en primer lugar un libreto (script) con la o las órdenes correspondientes, incluyendo los nombres de la máquina y el usuario de destino. Algo como esto: rsync -avzt /home/usuario1 usuario2@maquinaDOS:/respaldos/. Una vez guardado y hecho ejecutable, es sólo cuestión de añadir una línea en el archivo de p.e. /etc/cron.d/tareasdiarias, que debe lucir algo así: 10 4 * * * usuario1 /usr/local/bin/respaldoEnMaquinaDOS para que ejecute el libreto todos los días a las cuatro y 10 a.m.

Un uso interesante de los resultados de búsquedas internéticas se presenta en este mapa de Outer Court en el que cada país (aunque no todos) tiene asignadas unas etiquetas construidas a partir de los primeros resultados que se obtienen en ese buscador al colocar una frase como "los venezolanos son famosos por"... (no hay etiqueta para Venezuela).

Lo mejor de todo es el título asignado al mapa, porque es evidente que esos resultados reflejan mejor que nada y antes que todo eso: prejuicios.

Marco Fioretti cuenta que dió una conferencia en la 'Escuela de Estudios Avanzados Sant'Anna' en Pisa y parece que la torre inclinada no se ha caído, o al menos no menciona el hecho. Lo que hizo allí fue una presentación sobre el formato OpenDocument, recientemente aprobado por Oasis y popularizado por la adopción compulsiva que ha decretado el estado norteamericano de Massachusetts a partir del primer día de 2007.

Cualquiera que haya utilizado computadoras por más de un año seguramente ha padecido lo que es tener información en un formato tal que no puede ser recuperada, simplemente por un cambio de tecnología o -mucho peor- por capricho de un realizador de software. Fioretti comenta algunos casos que ilustran perfectamente el asunto. En primer lugar -y ya que estaba en el lugar de los acontecimientos- expone que el trabajo de Galileo aún puede ser leído después de casi cuatrocientos años debido a que está escrito en un formato totalmente abierto, el alfabeto. Cuenta también de las cintas grabadas durante la misión Viking en 1976, que debido a su formato cerrado -desconocido a todos los efectos- no hubo manera de recuperar y digitalizar sino mediante transcripción mecánica y eso gracias a que existían versiones en papel.

Fioretti habla de tres cosas necesarias para acceder a cualquier información y que deberían permanecer tan separadas como fuese posible.

Soporte físico: papel, discos, etc.
Formato: las reglas con las cuales se registra la información en el soporte
Interfase de usuario: las herramientas utilizadas para leer y escribir de acuerdo con el formato.

Muchas compañías se han beneficiado al mantener la información -que es ajena, del usuario, por otra parte- en un formato que sólo puede leerse con las herramientas que fabrica.

Pero a pesar de todas las razones ¿por qué será tan difícil hacer comprender a los neófitos que cuando utilizan (inconscientemente) formatos cerrados están haciendo daño y al mismo tiempo perdiendo libertad?