Proseguimos nuestro estudio de software de accesibilidad bajo Linux examinando una primera tanda de propuestas del proyecto Gnome: gnome-speech y LSR. Por Juan Rafael Fernández García.
Historial de versiones | ||
---|---|---|
Revisión 0.1 | 2007-07-17 | jrf |
Primera versión CC 2.0 del artículo de Linux Magazine. |
Está usted leyendo Síntesis de voz en Gnome, tercero de una serie de cuatro artículos sobre la síntesis de voz y la accesibilidad en 2007 publicado por primera vez en el número 26 de la revista Linux Magazine, de abril de 2007 (pero escrito en febrero de 2007). La versión pdf del artículo puede descargarse en el enlace http://www.linux-magazine.es/issue/26/.
La versión «canónica» del artículo, la única mantenida por el autor, se encuentra en http://people.ofset.org/jrfernandez/edu/n-c/orca_3/index.html. Está publicada por contrato con la editorial bajo licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 2.0 (-sa-by-nc 2.0).
Índice de la tercera parte
I. Gnome-speech y Gnopernicus
II. LSR, el Linux Screen Reader
III. Y en el próximo número...
Cuadro 1: Protagonistas
Imágenes
Notas
Lectores de pantalla para consola
(Primera parte de la serie)
Presente imperfecto, futuro brillante
(Segunda parte de la serie)
Llega el juez de la Orca
(Cuarta y última entrega de la serie)
¿Qué ha ocurrido en el mes transcurrido entre la terminación de la segunda parte y la redacción de esta tercera? Bastantes cosas relacionadas con nuestro tema de estudio. Por lo pronto se saben ya las versiones que irán en la Etch Estable. Orca (renombrada gnome-orca porque ya existe una aplicación que se llama orca) se queda en Experimental, en la versión 2.17.4-1[1] (la numeración tiene que ver con las versiones de Gnome). eSpeak no pasa de la 1.16 (a Experimental había llegado la 1.19, que aporta dos novedades decisivas: modos asíncronos y voces francesas)[2]: en el sentido de la accesibilidad Etch nace desfasada. No obstante es posible actualizar estos paquetes desde Experimental sin que hoy por hoy se produzca ningún problema de dependencias.
En la lista de accesibilidad de Debian está vivo desde el 14 de febrero un interesante hilo sobre la accesibilidad del instalador, que nos proporciona información sobre las dependencias de los distintos lectores de pantalla y sobre los problemas de los parches de SpeakUp para entrar en el núcleo estándar[3]. En la lista del consejo de la asociación OFSET se ha mencionado otra propuesta de síntesis para el francés en un entorno Squeak: cresta[4]; y es que a pesar de nuestro optimismo en la segunda entrega la síntesis libre de calidad en francés sigue siendo una asignatura pendiente. Han reaparecido noticias de la distribución especializada de la mano de Klaus Knopper: ADRIANE[5]. Por otra parte el repositorio subversion de orca echa humo, con actualizaciones diarias. Además, ya más en local, en la Conferencia Internacional de Software Libre 3.0 de Badajoz[6] se han anunciado unas futuras voces de calidad en castellano para festival con financiación de la Junta de Andalucía. ¡Gran noticia!
Pero debemos retomar el hilo de nuestra serie de artículos. Partíamos de un desafío: ¿es posible una síntesis plurilingüe de calidad con las herramientas actuales? En las anteriores entregas hemos examinado las propuestas que trabajan en modo consola y las que llamábamos interfaces intermedias entre las aplicaciones de usuario y los motores de síntesis; proseguimos por el estado de la síntesis de voz del proyecto KDE. ¿Qué propone Gnome?
GNOME Speech tiene su origen en las necesidades del proyecto Gnopernicus. Gnopernicus ha sido durante un tiempo la clave de bóveda del sistema de tecnologías para la accesibilidad visual de Gnome: venía a unificar la magnificación de pantalla (gnome-mag), la síntesis de voz (con el lector de pantalla srcore) y la salida braille bajo una interfaz común. Para la síntesis del habla en Gnome se desarrolló gnome-speech, que utiliza y proporciona las bibliotecas libgnomespeech.
Pero adelantemos acontecimientos: gnome-speech está aquí para quedarse, gnopernicus tiene los días contados. ¿Qué cómo lo sabemos? Porque nos lo han dicho[7] sus desarrolladores (en concreto Thomas Friehoff, miembro de la directiva de Baum Retec AG)
«Como equipo de desarrollo de Gnopernicus, durante varios años hemos trabajado en hacer el escritorio de GNOME y aplicaciones relacionadas accesibles para los ciegos y deficientes visuales (...) Nosotros también hemos seguido en la investigación de la personalización específica de aplicaciones, que se ha convertido en el lector de pantalla Orca.
Orca, con su radical aproximación diferente del código en hacer accesibles las aplicaciones, es en su forma actual más flexible que el diseño original de Gnopernicus. Esto nos ha llevado a la conclusión de que debemos unir esfuerzos con Orca. No creemos que el desarrollo de estos dos lectores/magnificadores de pantalla diferentes sea beneficioso para el escritorio de GNOME y los usuarios ciegos y deficientes visuales.
Apoyamos la proposición del equipo de Orca para que Orca sea el lector de pantalla/magnificador por defecto en el escritorio GNOME en la versión 2.16, y de que Orca sea el sucesor lógico/espiritual de Gnopernicus (...)»
Decíamos que Gnopernicus usaba gnome-speech. Como prueba valga la figura 1, donde vemos la interfaz de configuración de las voces que se iban a utilizar. ¿Hay algún modo de acceder a gnome-speech directamente, para comprobar si está correctamente instalado y configurado? Depende. Para lograrlo tenemos que salirnos de las sendas prefijadas. El problema es que en Debian Etch y también en Experimental los paquetes disponibles son los de libgnome-speech3_0.3.10-1.2; en ellos la última anotación de cambios en las fuentes es ¡del 23 de febrero de 2006! ¡hace casi un año! En cambio si acudimos a las fuentes la última modificación es del 11 de febrero de 2007 (preparando la versión 0.4.9). ¿Qué ha pasado en este año? ¿nos estamos perdiendo algo? Además de las numerosas correcciones de errores y mejoras, la aparición de GNOME_Speech_SynthDriver_Speech_Dispatcher.server, GNOME_Speech_SynthesisDriver_Loquendo.server y GNOME_Speech_SynthesisDriver_Espeak.server o, lo que es lo mismo, controles para poder utilizar, además de festival o viavoice, los motores speech-dispatcher, loquendo (no libre pero muy usado por la ONCE) y eSpeak. Y un ejecutable que misteriosamente no está presente en los paquetes Debian: test-speech.
¿Qué hacemos, esperamos? ¿O nos arriesgamos en la frontera bleeding edge de las fuentes inestables? Como este es un artículo didáctico, exploratorio y aventurero, vamos por una vez a aprender a descargar las fuentes de una aplicación y a compilarlas. Desde enero (otro cambio) las fuentes de los programas de Gnome están en unos repositorios regidos por un sistema de control de versiones que se llama subversion. Vale, creemos en nuestro ordenador un subdirectorio code/gnome (o como queramos llamarle) y ejecutemos como usuario normal esta orden
$ svn co svn://svn.gnome.org/svn/gnome-speech/trunk gnome-speech
Con ello se nos creará la carpeta gnome-speech con una copia de la última versión de las fuentes. En lo sucesivo para actualizar nuestra copia ya no tendremos que volver a hacer esto, bastará cambiar a ese directorio y hacer algo tan sencillo como actualizar
$ svn update
De acuerdo, ¿y cómo se compila? Fácil, sólo hay que tener apuntada la siguiente chuleta (producto de haber ejecutado ./configure --help y haber seleccionado las opciones que nos interesaban -- recuerde el lector que en estos artículos sólo documentamos software libre, pero que sus necesidades y elecciones pueden variar)
./autogen.sh --with-speech-dispatcher --with-espeak-dir="/usr" make
Con la orden anterior compilamos las bibliotecas y los controladores para festival, speech-dispatcher y eSpeak; pero nos falta instalarlos...
sudo make install
Y comprobar que todo funciona (en nuestras pruebas hemos tenido que hacer copia de seguridad de la versión anterior instalada y crear enlaces simbólicos desde /usr/local a los directorios correspondientes). Ver si funciona era el objeto de test-speech
01 ~$ test-speech 1: OAFIID:GNOME_Speech_SynthesisDriver_Festival:proto0.3 2: OAFIID:GNOME_Speech_SynthesisDriver_Speech_Dispatcher:proto0.3 3: OAFIID:GNOME_Speech_SynthesisDriver_Espeak:proto0.3 Select a server: 1 Attempting to activate OAFIID:GNOME_Speech_SynthesisDriver_Festival:proto0.3. Driver name: Festival GNOME Speech Driver Driver version: 0.3 Synthesizer name: Festival Speech Synthesis System Synthesizer Version: 1.4.3 Enter desired gender ('m' or 'f'): f Enter desired locale, or 'all' to display all voices: all 1. en1_mbrola (language english) 2. rab_diphone (language english) 3. kal_diphone (language english) 4. ked_diphone (language english) 5. don_diphone (language english) 6. us1_mbrola (language english) 7. us2_mbrola (language english) 8. url_cat_jdf_diphone (language cat) 9. el_diphone (language spanish) 10. pc_diphone (language italian) 11. lp_diphone (language italian) Select voice: 9
A partir del momento en que hemos elegido una voz (entre las 9 compatibles disponibles en mi ordenador) el proceso se acompaña de la síntesis interactiva de la conversación entre la máquina y el usuario. Bien, festival sigue funcionando y nos habla con la voz castellana (aunque el programa no esté localizado). ¿Funcionará Speech-dispatcher?
Select a server: 2 Attempting to activate OAFIID:GNOME_Speech_SynthesisDriver_Speech_Dispatcher:proto0.3. Driver name: Speech Dispatcher GNOME Speech Driver Driver version: 0.1 Synthesizer name: Speech Dispatcher Synthesizer Version: unknown Enter desired gender ('m' or 'f'): f Enter desired locale, or 'all' to display all voices: all 1. MALE1 (language any) 2. MALE2 (language any) 3. MALE3 (language any) 4. FEMALE1 (language any) 5. FEMALE2 (language any) 6. FEMALE3 (language any) 7. CHILD_MALE (language any) 8. CHILD_FEMALE (language any)
Ocho voces, estupendo. Se activa una voz masculina (a pesar de haber elegido género femenino) que habla un inglés comprensible. ¿Y eSpeak?
Enter desired locale, or 'all' to display all voices: all 1. en-rhotic (language en-r) 2. english (language en-uk) 3. lancashire (language en-uk-north) 4. english_rp (language en-uk-rp) 5. english_wmids (language en-uk-wmids) 6. esperanto (language eo) 7. spanish (language es) 8. finnish (language fi) 9. french-test (language fr) 10. quebec-test (language fr-ca) 11. hindi-test (language hi) 12. italian (language it) 13. dutch-test (language nl) 14. norwegian-test (language no) 15. polish_test (language pl) 16. brazil (language pt) 17. romanian (language ro) 18. russian_test (language ru) 19. swedish-test (language sv) 20. vietnam-test (language vi) 21. afrikaans (language af) 22. welsh-test (language cy) 23. german (language de) 24. greek_test (language el) Select voice: 7
Listado esperanzador, ¡24 voces, incluidas dos francesas!, pero no se oye nada. El omnipresente problema de la lucha por los dispositivos de audio que analizamos en el cuadro «El problema del sonido» de la segunda entrega.
De todas formas todavía no hemos planteado la pregunta clave: ¿qué servidor es preferible? La respuesta hoy día (la tecnología avanza a pasos en aceleración continua) dependerá de nuestras necesidades. Si el espacio es una prioridad (como en el caso de los discos vivos o el instalador) nos inclinaremos directamente por eSpeak, porque sus diccionarios y voces son los que ocupan menor espacio y es una tecnología ligera en uso de memoria. Si todas las voces que vamos a utilizar están disponibles en la versión para festival y nos vamos a limitar a trabajar en el entorno Gnome y no tenemos conflictos de uso de los dispositivos de sonido, si se cumple todo eso, entonces no hay duda tampoco. Pero en el mundo real gana puntos speech-dispatcher, porque independiza los sintetizadores de la salida de audio y permite el uso de más de un motor, los necesarios para las voces que necesitemos.
La importancia de todo esto se nos hará evidente cuando debamos configurar las interfaces gráficas existentes sobre gnome-speech: LSR y orca.
Esta sección es un paréntesis. Pero un paréntesis ineludible. Y los lectores fieles (¿existen?) sabrán ya que nuestros los artículos están montados sobre el mismo andamiaje, la ilusión de progreso, el examen de sucesivas soluciones hasta llegar a la más apropiada. Este norma sitúa aquí nuestro examen de LSR, el Linux Screen Reader[8] (lector de pantalla para Linux; podemos ver una captura de la pantalla de configuración la figura 2) desarrollado por Peter Parente y otros ¡para IBM! y con una licencia BSD desde su versión 0.3.2.
Probamos la aplicación utilizando el paquete incluido en la Edubuntu Edgy (un tanto anticuado). En primer lugar debemos familiarizarnos con la terminología utilizada: un UIE es un «Elemento de la Interfaz de Usuario». lsr -s nos da la siguiente salida:
Installed UIEs device: ['IBMSpeech', 'FestivalSpeech', 'CliqueAudio', 'Keyboard'] chooser: [] monitor: ['TaskMonitor', 'RawEventMonitor'] perk: ['MetacityPerk', 'GaimPerk', 'DeveloperPerk', 'DefaultPerk', 'AltShiftPerk', 'GTerminalPerk'] Associated UIEs profile: user device startup: ['Keyboard', 'CliqueAudio', 'IBMSpeech', 'FestivalSpeech'] chooser startup: [] monitor startup: [] perk all tiers: ['DefaultPerk', 'AltShiftPerk'] one tier: [('metacity', ['MetacityPerk']), ('gaim', ['GaimPerk']), ('gnome-terminal', ['GTerminalPerk'])] profile: developer device startup: ['Keyboard', 'CliqueAudio', 'IBMSpeech', 'FestivalSpeech'] chooser startup: [] monitor startup: ['RawEventMonitor', 'TaskMonitor'] perk all tiers: ['DefaultPerk', 'AltShiftPerk', 'DeveloperPerk'] one tier: [('metacity', ['MetacityPerk']), ('gaim', ['GaimPerk']), ('gnome-terminal', ['GTerminalPerk'])] 12 installed UIEs, 2 profiles
Parece muy complicado, intentemos descifrarlo. La salida anterior nos informa de la existencia de dos perfiles predefinidos completos, «usuario» y «desarrollador»; cada perfil agrupa varios cuadros de diálogo, dispositivos (módulos que definen cómo LSR va a comunicarse con el hardware o el software, por ejemplo el teclado o festival) y guiones (perks). Vemos que el perfil «desarrollador» activa varios módulos de monitorización además de los módulos activados por el «usuario».
La idea es que exista una aplicación núcleo y extensiones programables en la forma de cuadros de diálogo, dispositivos y guiones. Por tanto las extensiones originales para trabajar con metacity o gaim pueden completarse con extensiones creadas para propósitos distintos. Serían ejemplos, según la documentación:
Cómo se usa LSR? Se lanza eligiendo un perfil (predeterminado o uno que ha podido crearse previamente)
lsr -p user
Y se trabaja mediante combinaciones de teclas, enumeradas en la documentación. Por ejemplo Alt + May. + K hace revisar la palabra visible actual; si está habilitada la síntesis de voz, una segunda pulsación hará deletrear la palabra actual y una tercera hará deletrear fonéticamente la palabra (todo esto pensado para lenguas como el inglés, en las que la escritura y la palabra hablada pueden variar considerablemente).
Quizás el vehículo más interesante de acercarse a los objetivos para los que se ha creado LSR está en la documentación visual que han preparado sus autores. En concreto y especialmente el screencast «Linux Screen Reader... is not just a screen reader»[9] documenta tres usos principales para LSR: uno es la accesibilidad visual, tan evidente; otro es como ayuda para las personas con problemas de memoria (sea por senilidad, discapacidades, o sencillamente exceso de trabajo: figura 3); un tercer uso es como apoyo a la lectura (figura 4): no sólo el alumno o lector puede escuchar la pronunciación de la palabra que está leyendo, sino que puede ver una imagen que clarifique el término o sirva de ampliación o ilustración (las posibilidades son enormes).
Pero estamos haciendo un estudio de la síntesis de voz y vamos a acercarnos siquiera superficialmente al código en python. FestivalSpeech.py se limita poco más que a llamar a GSpeech.py, que contiene la clase abstracta que permite el uso de cualquier dispositivo de gnome-speech. Alternativamente SpeechDispatcher.py permite el uso directo de speech-dispatcher (y en consecuencia del resto de motores compatibles con él).
¿Cuál es el problema con LSR? Simplemente que ha llegado tarde, cuando Orca ha ocupado el lugar central del escenario y ha sido incorporada oficialmente al escritorio Gnome desde la versión 2.16. He sondeado la comunidad española de usuarios de aplicaciones de accesibilidad y nadie ha comunicado usar LSR. Quizás sea demasiado reciente. Quizás si Orca encuentra problemas sea bueno tener una alternativa.
Tres entregas y aún no hemos hablado de Orca, la gran promesa, la justificación de esta serie. Es el momento de presentar la gran novedad, ¿resistirá nuestro análisis? En el próximo número tendremos la respuesta.
Protagonistas |
Hay proyectos que mueren y proyectos que progresan. En el debe, el Accessibility-HowTo no se ha renovado desde el 21 de junio de 2002[10], el sitio LARS (Linux Accessibility Resource Site)[11], del que extrajimos tanta información, solicita colaboradores desde junio de 2006... tenemos que buscar los avances en otro lado. ¿Dónde? En los grupos en trabajan en las distintas aplicaciones, apoyados por empresas grandes (IBM, Sun) o modestas (Brailcom). En los proyectos de escritorio, Gnome especialmente en este campo, por el esfuerzo coordinado de tanta gente. En las distribuciones que se esfuerzan por avanzar en la accesibilidad, especialmente las versiones pioneras de Fedora de Janina Sajka y las Ubuntu (es un placer reconocer lo bien hecho). Y en las organizaciones que con su presión y su apoyo económico y político están detrás de los progresos; especialmente, y hay que hacerlo público porque creo que es poco conocido en la comunidad, en la labor de la ONCE de consultoría pero también también de trabajo a pie de código: traduciendo, aportando controladores para el hardware que utilizan sus miembros, participando en las distintas listas y en los diferentes proyectos. No hay más que seguir durante un tiempo los debates en torno a las tecnologías de accesibilidad o leer los registros de cambios de las herramientas para leer nombres españoles. Gracias a todos. Prometíamos en la primera parte de este estudio hablar de los esfuerzos por superar las limitaciones que nos encontrábamos en cuanto a voces libres de calidad. Es el momento, aunque con cierto retraso (lo prometíamos para la segunda entrega), de cumplir nuestra promesa. En numerosos grupos de investigación y en empresas se está trabajando en la creación de voces para festival. El sitio FestLang nos proporciona una lista amplia[12]; desgraciadamente el enlace para la voz en francés no ha respondido en varios días, la voz libre en alemán sigue siendo una promesa... ¿Cuál es la situación para el castellano y desde otro punto de vista las lenguas de España? El observador habrá advertido que en la lista de voces aparecía una voz en catalán. Se trata de la voz desarrollada en el Departamento de comunicaciones y teoría de la señal de la Universidad Ramón Llull, por Jordi Domínguez en 2003[13]. En el enlace de la nota se explica cómo instalarla. ¿Y para el castellano? Existen las voces del Center for Spoken Language Understanding (CSLU) de la escuela de Ciencia e Ingeniería de Oregón (OGI). Son dos voces con acento mejicano y requieren una versión de festival no disponible en Debian ni Ubuntu (ya hablamos de las versiones de festival en una nota de la primera entrega). ¿Es eso todo? No. En los ambientes interesados se venía hablando de algún proyecto de cierta universidad... Pero los más informados percibían además que algo se movía en Andalucía[14]. Es divertido reconstruir cómo se ha ido difundiendo la información. Quim Gil destapaba la liebre en su bitácora (traduzco del original inglés): «Cierta administración pública desea una nueva voz sintética para el sistema Festival. Contactad conmigo si podéis recomendar un equipo que pueda crear un voz sintética en español». Era el 29 de septiembre de 2006. Para entonces ya sabíamos de la cooperación entre la ONCE y la Junta de Andalucía por varias noticias publicadas en el sitio de Guadalinex. Al fin el 27 de noviembre de 2006 se anuncia públicamente la resolución del concurso público: «Aunque Guadalinex incluye un sintetizador de voz capaz de hablar en castellano, el tono y acento de esta voz electrónica la hacen poco idónea para un uso continuado. En especial resulta incómoda como lector de textos para discapacitados visuales. Para mejorar este sintetizador y hacerlo más natural y práctico, la Consejería de Innovación, Ciencia y Empresa promueve el desarrollo de dos nuevas voces, de hombre y mujer, que se podrán incorporar a las futuras versiones de Guadalinex. Los trabajos han sido adjudicados mediante concurso público a MP Sistemas y estarán terminados en la próxima primavera; mientras el desarrollo se podrá seguir en la forja de Guadalinex. De acuerdo con las directrices de la Junta de Andalucía, los desarrollos se publicarán con una licencia libre, permitiendo a otras iniciativas la incorporación de estas voces a sus propias distribuciones y proyectos. » ¿Cuál es el estado de estas dos voces? Lo apuntamos en la introducción de esta entrega: los desarrolladores nos han presentado sus trabajos en la Conferencia Internacional de Software Libre 3.0 de Badajoz. Lo más importante es que se comprometen a hacer un desarrollo transparente, con un repositorio público en la Forja de Guadalinex, y a que las voces estén disponibles para la comunidad el 31 de mayo de 2007. Es pronto para que tenga contenidos (se anunció el 7 de febrero) pero seguiremos con impaciencia y entusiasmo sus progresos. |
[1] http://lists.debian.org/debian-accessibility/2007/01/msg00037.html.
[2] http://lists.debian.org/debian-accessibility/2007/02/msg00006.html.
[3] http://lists.debian.org/debian-accessibility/2007/02/msg00021.html.
[4] http://www.squeaksource.com/Cresta.html.
[5] http://www.knopper.net/knoppix-adriane/index-en.html. Para los desmemoriados Knopper es el creador de las famosas knoppix, los live-CDs por antonomasia. Es importante mencionar que se usa provisionalmente una voz mbrola para el alemán pero que se planea cambiar a una voz plenamente libre.
[6] El CISL 3.0 se ha celebrado en Badajoz los días 7 al 9 de febrero de 2007. La comunicación a la que nos referimos puede descargarse en http://www.freesoftwareworldconference.com/virtual/comunicaciones/AoteroCISL2007.pdf.
[7] Leído en la traducción que se ha publicado en http://www.tiflolinux.org/?q=node/34.
[8] http://live.gnome.org/LSR. En el mismo sitio puede consultarse la documentación. Existen paquetes de la versión 0.4.0 (anunciada el 2 de febrero) para Ubuntu Edgy en http://archive.ubuntu.com/ubuntu/pool/universe/l/lsr/. También están disponibles los paquetes que prepara Janina Sajka en http://SpeakupModified.Org/current/i386/os/Fedora/RPMS/.
[9] http://www.gnome.org/~parente/lsr/screencast/lsr-gsummit06.html. Por cierto, no creo que sea inconveniente comunicar que la animación puede descargarse directamente con la orden wget http://www.gnome.org/~parente/lsr/screencast/lsr-gsummit06.swf.
[10] http://tldp.org/HOWTO/Accessibility-HOWTO/. Por supuesto no ha habido novedades en la versión española http://es.tldp.org/htmls/comos.html.
[11] http://larswiki.atrc.utoronto.ca/wiki.
[12] http://festlang.berlios.de/docu/doku.php?id=languages.
[13] http://www.salle.url.edu/Eng/elsDCTS/tsenyal/english/recerca/areaparla/tsenyal_software.html.
[14] La bitácora de Quim Gil: http://desdeamericaconamor.org/blog/node/301. Colaboración Junta de Andalucía y ONCE: http://www.guadalinex.org/modules/news/article.php?storyid=121, http://www.andaluciajunta.es/aj-not-.html?idNot=70680&idCanal=214445, http://www.guadalinex.org/modules/news/article.php?storyid=136. Anuncio de la resolución para crear las voces sintéticas: http://www.guadalinex.org/modules/news/article.php?storyid=174. Repositorio del proyecto: http://forja.guadalinex.org/repositorio/projects/hispavoces/.