We do not believe that all texts are of the same type. Often information about the general contents of file will aid synthesis greatly. For example in Latex files we do not want to here "left brace, backslash e m" before each emphasized word, nor do we want to necessarily hear formating commands. Festival offers a basic method for specifying customization rules depending on the mode of the text. By type we are following the notion of modes in Emacs and eventually will allow customization at a similar level.
Modes are specified as the third argument to the function tts
.
When using the Emacs interface to Festival the buffer mode is
automatically passed as the text mode. If the mode is not supported a
warning message is printed and the raw text mode is used.
Our initial text mode implementation allows configuration both in C++ and in Scheme. Obviously in C++ almost anything can be done but it is not as easy to reconfigure without recompilation. Here we will discuss those modes which can be fully configured at run time.
A text mode may contain the following
xml
the file is read through the built in XML
parser rxp
. Alternatively if analysis mode is xxml
the
filter should an SGML normalising parser and the output is processed in
a way suitable for it. Any other value is ignored.
tts_text_modes
.
When using Festival in Emacs the emacs buffer mode is passed to Festival as the text mode.
Note that above mechanism is not really designed to be re-entrant, this should be addressed in later versions.
Following the use of auto-selection of mode in Emacs, Festival can
auto-select the text mode based on the filename given when no explicit
mode is given. The Lisp variable auto-text-mode-alist
is a list
of dotted pairs of regular expression and mode name. For example
to specify that the email
mode is to be used for files ending
in .email we would add to the current auto-text-mode-alist
as follows
(set! auto-text-mode-alist (cons (cons "\\.email$" 'email) auto-text-mode-alist))
If the function tts
is called with a mode other than nil
that mode overrides any specified by the auto-text-mode-alist
.
The mode fundamental
is the explicit "null" mode, it is used
when no mode is specified in the function tts
, and match
is found in auto-text-mode-alist
or the specified mode
is not found.
By convention if a requested text model is not found in
tts_text_modes
the file MODENAME-mode will be
required
. Therefore if you have the file
MODENAME-mode.scm in your library then it will be automatically
loaded on reference. Modes may be quite large and it is not necessary
have Festival load them all at start up time.
Because of the auto-text-mode-alist
and the auto loading
of currently undefined text modes you can use Festival like
festival --tts example.email
Festival with automatically synthesize example.email in text
mode email
.
If you add your own personal text modes you should do the following.
Suppose you've written an HTML mode. You have named it
html-mode.scm and put it in /home/awb/lib/festival/. In
your .festivalrc first identify you're personal Festival library
directory by adding it to lib-path
.
(set! lib-path (cons "/home/awb/lib/festival/" lib-path))
Then add the definition to the auto-text-mode-alist
that file names ending .html or .htm should
be read in HTML mode.
(set! auto-text-mode-alist (cons (cons "\\.html?$" 'html) auto-text-mode-alist))
Then you may synthesize an HTML file either from Scheme
(tts "example.html" nil)
Or from the shell command line
festival --tts example.html
Anyone familiar with modes in Emacs should recognise that the process of adding a new text mode to Festival is very similar to adding a new buffer mode to Emacs.