Re: Speech failure in Baratinoo engine after CHAR symbol expansion

[Colomban Wendling]

Hello,

Le 19/07/2024 à 01:12, Samuel Thibault a écrit :
> Hello,
>
> Colomban Wendling, le jeu. 18 juil. 2024 18:32:15 +0200, a ecrit:
> > Should the server wrap the TEXT message with SSML as other messages are?
> > Or should the module be forgiving and not reject input that don't have a
> > root tag (or no tag at all)?
>
> The current state is that speech-dispatcher happens to always add a root
> tag in insert_index_marks. So modules probably already assume there is
> always one. So probably better make the server always add one.

OK so I dived a bit in this, and this patch works:

> --- a/src/server/symbols.c
> +++ b/src/server/symbols.c
> @@ -1428,6 +1428,11 @@ void insert_symbols(TSpeechDMessage *msg
>                /* if we provide a character description file, don't let the 
> module spell it */
>                if (msg->settings.type == SPD_MSGTYPE_CHAR)
>                        if (g_utf8_strlen(processed, -1) > 1)
> +                      {
>                                msg->settings.type = SPD_MSGTYPE_TEXT;
> +                              /* make sure the data is not deemed SSML at this 
> point, so
> +                               * insert_index_marks() will process it properly 
> */
> +                              msg->settings.ssml_mode = SPD_DATA_TEXT;
> +                      }
>        }
>  }

because insert_index_marks() is called after.

HOWEVER, it's probably not the right fix.

We've actually got a bigger problem: there is actually no issue if the 
client isn't in SSML mode, so for instance `spd-say -c y` will translate 
appropriately to SSML data for module_speak().

The issue is that if the client is in SSML mode (hint: Orca is), a CHAR 
call will have the issue -- and there is only hacks the client can do. 
The issue is that e.g. CHAR does *not* accept SSML data: both libspeechd 
python-speechd either assume or ensure the value is a single character. 
The client application could issue a `SET self SSML_MODE off` before the 
CHAR call, and restore if afterward, but that sounds a lot like a sad 
workaround.

So... what about internally resetting the message's ssml_mode flag when 
the command is CHAR (and probably KEY as well?), so it's simply ignored 
for this command that doesn't support it, and avoids creating issues 
like the one I'm facing?
Another solution would be to patch clients (libraries) to temporarily 
disable SSML mode if active.

What do you think?

Regards,
Colomban