(Courriels de diversion: <doutons@week-ends-racler.com> <etudie@disqualifierai-dissuade.com> <bousculerez@nourrices-mesestimant.com> <creees@resineuse-contesterai.com> <galvaudait@achalande-impassibilite.com> <ravitaillais@deprime-porte-bagages.com> <consolable@lancerez-indecise.com> <obtuses@impayable-deteriorez.com> <approximativement@postera-reformes.com> <commemore@defroncer-verite.com> )
Bonsoir à tous, Je vous retransmet un msg que j'ai lu sur la liste carrefourblinux et qui bien que concernant les synthétiseurs hard semble plutôt intéressant. de plus l'auteur est à la recherche de volontaires pour l'aider dans son travail et notamment réaliser une version en français. Voici : ----- Forwarded message from Karl Dahlke <eklhad@home.com> -----To: olr@audiobraille.orgFrom: Karl Dahlke <eklhad@home.com>Subject: Other Languages Date: Fri, 10 Aug 2001 03:41:20 -0700 Jupiter is a kernel resident adapter, that can be a screen reader, but can be much more. It is the *only* adapter that actively supports the command line interface, allowing the user to scroll through his entire interactive session, not just the text on the screen. For more on this command line philosophy, visit http://eklhad.hispeed.com/cli.html I believe adapters belong in the kernel for many reasons, responsiveness being just one, but perhaps the most important one. When I hit f3, I want to hear the next line, now, even if the computer is under load. A process, like Emacsspeak, can take several seconds to respond if the server is under heavy load, and I just don't want that in my adapter. It would be like a sighted person having a blindfold over his eyes whenever the cpu was busy. It lifts for a moment long enough for him to read a few words, then down again. Well anyways, all this is to explain why my software lives in the kernel, and why, in turn, I work with hardware synths, rather than software synths. I haven't found a good way to integrate an entire software synth into the kernel, and have that synth run, without unduely delaying the other critical processes that also run in the kernel. And of course, such a kernel would be large, too large for a floppy, so I couldn't have my talking rescue floppy disk. I support several external synthesizers, including Dectalk, Doubletalk, Votrax, and some others that just happen to work on my generic setting. Now for other languages. I appologize for sending this in English. I just don't speak any other languages well, though I do know some German, and I took a year of Spanish and French long ago. I want Jupiter to handle many languages, and have laid the foundation for this. 1. All 8 bits are passed to the synthesizer, hence international characters are supported. If your synthesizer knows what è is, I'll pass it to you, and you can read it. My software knows the difference between unreadable binary data, which is not read, and international text with occasional nonascii characters, which is passed to the synthesizer for reading. 2. If the synthesizer supports index markers, like Doubletalk, I'll pass it the entire sentence for speech. Without these markers, I must send words one at a time. Then the unit tells me it has spoken each word, I advance the cursor, send the next word, and so on. But with index markers, I send the entire sentence and the unit tells me as it reads each word, so the reading cursor can track exactly what the blind person hears. This realtime tracking is very important, but so is the improved speach quality made possible by sending entire sentences. This is somewhat true in English, profoundly so in French. You just don't know whether to pronounce the last consonnent, allez untill you see the next word to follow. So in French, it is very important for the adapter to send an entire sentence, and track the words spoken, if the synthesizer will cooperate. My system has this internal capability. 3. Jupiter contains an internal text preprocessor which manipulates the sentence before it is sent to tts. One of many translations is 09/09/1960 -> september ninth nineteen sixty But it's table driven, with a global language pointer, so you could set lang=fr, have it point to French words instead of English, and suddenly dates and times etc are read in French. I've tried to separate out the language independent aspects of preprocessing, and keep the language dependent routines table driven, as much as possible. For more on this preprocessor, see http://eklhad.hispeed.com/linux/prep_tts/ If anyone,fluent in French and English, would like to help me develop a French version of Jupiter, that would be fantastic, for all of us. Sincerely, Karl Dahlke ----- End forwarded message ----- Nath ______________________________________________________________________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif --------------------------------------------------------------------- To unsubscribe, e-mail: biglux-unsubscribe@savage.iut-blagnac.frFor additional commands, e-mail: biglux-help@savage.iut-blagnac.fr