rfc: speakup's character and punctuation processing

[Bruce Noblick]

Hello all,

Please pardon me while I think out loud and hopefully come up with something 
coherent though I make no promises of that.

I can see advantages to keeping as much control of exception dictionaries 
within speakup.  If the synth is shared among other applications, speakup 
could be easily configured so that it would not be affected by other 
program's settings and speech produced by other programs would not be 
affected by its settings.

Synths will certainly come along with a long list of features that are 
useful for direct programming but unless the definitions can't be fairly 
standard, their usefulness can be limited.  In my opinion, a program like 
speakup works best if it can use a short list of common features especially 
where use of those features might affect other application's use of the 
device or interface.

I also vote for keeping the distributed content of this exception dictionary 
as small as possible, perhaps even having it empty and just providing a 
simple mechanism for placing items in it.  This would eliminate the need to 
maintain different exception dictionaries for a long list of hardware and 
software synths.  The only case I can make for distributing content is if 
there is a glaring flaw in a particular synth's text to speech algorithm.

In general, I don't like similar code being implemented in more than one 
place but in this case and if it is done correctly, it may allow the choice 
to be deferred to the user at run time which is a luxury I do like.

Thanks for allowing me to think out loud.  Now I will go back to what I do 
best: talking to myself, grin.

Enjoy!
Bruce




--------------------------------------------------
From: "Kirk Reiser" <kirk at braille.uwo.ca>
Sent: Monday, April 26, 2010 8:22 AM
To: "Speakup is a screen review system for Linux." <speakup at braille.uwo.ca>
Subject: Re: rfc: speakup's character and punctuation processing

> Hey folks: I of course have an oppinion on all of this but am more
> interested in bringing a few issues up.  It is true that a lot of
> hardware synths provide exception handling rules for pronunciation but
> manipulating those rules is often not trivial.  The DoubleTalk family
> is an example.  You can have exceptions but you need to compile those
> exceptions extermally and then download them to the synth at start up.
> As far as I know there is no compiler available for the DoubleTalk
> family in gnu/linux.  Also, downloading firmware or exceptions adds
> another level of complication to synth initialization which can be
> frustrating as many DECTalk PC users can declare.  So, you will need
> to either make exception handling software available for all the
> hardware/software synths or leave folks basically in the same
> situation they are currently.  Even developing exception dictionaries
> for the various soft synths is not a trivial matter as anyone that has
> tried to make exceptions for espeak/espeakup will tell you.
> Fortunately, Jonathan has been very good at updating pronunciations
> when it's brought to his attention but what about the other soft
> synths like festival?  So although it may be theoretically more
> desirable to hand-off processing to the individual synths the
> implementation is a whole lot more involved than central processing
> one time at the speakup level for all synths even if each synth might
> need to be slightly different.
>
> As for levels of punctuation for console output versus reading mode it
> isn't really that confusing once you understand it and it was a
> feature request which was written because of users desires.  The code
> is already there so I don't quite understand the desire to remove the
> feature.  If there is confusion I believe it is a documentation lack
> and not a difficulty with the implementation.  I do aggree however
> that a direct synth mode should be available and I thought we had all
> decided that already.  If it hasn't exactly been implemented so far
> then it is more a problem of developers not following through than
> nondetermination to have the feature.  A toggle to turn processing on
> or off depending on users wish is a good idea but is not quite as easy
> to implement as one might think and that's why I suspect we're having
> this discussion.
>
> So those are my thoughts currently.
>   Kirk
>
> --
> Kirk Reiser The Computer Braille Facility
> e-mail: kirk at braille.uwo.ca University of Western Ontario
> phone: (519) 661-3061
> _______________________________________________
> Speakup mailing list
> Speakup at braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup