Open bertfrees opened 8 months ago
- A dedicated option to specify lexicons (in addition to the possibility to attach lexicons to the input)
- A dedicated option to specify CSS style sheets (in addition to the possibility to attach style sheets to the input)
In addition, there could also be a global setting for the default lexicons, so that the user doesn't need to specify it for every job. The need for a default style sheet is less obvious, but might also exist. Note that there would have to be separate settings for HTML and DTBook.
- Dedicated options for certain TTS properties
org.daisy.pipeline.tts.mp3.bitrate
Here also, it would make sense to keep the global setting for the default bit rate, as a producer will usually have a standard for MP3 quality and wouldn't want to set it on a per job basis.
A generic solution for this kind of global defaults is a templating feature. However such a feature is probably still further away, and might not be implemented on the level of the engine, but only in the GUI.
Note that we should probably not completely eliminate the options yet in release 1.14.17 because the UI currently still relies on these options and there might not be enough time to update it.
I want to eliminate the "Text-to-speech configuration file" options, and replace it with the following:
org.daisy.pipeline.tts.log
: already a dedicated optionorg.daisy.pipeline.tts.mp3.bitrate
: makes most sense as global setting; per-job settings could be achieved with a templates featureorg.daisy.pipeline.tts.lame.cli.options
: has already been deprecatedorg.daisy.pipeline.tts.host.protection
has already been deprecated, but that the deprecation warning has been disabled because the GUI needs this feature in order to avoid restarts (and because in the future we might want to be able to connect to remote engines and yet use or own TTS engine credentials). One possible solution is to continue supporting theorg.daisy.pipeline.tts.host.protection
setting, but limit it to very specific properties. Another solution is to create a settings API. The benefit of the latter is that we can get ditch the XML configuration format. The downside is that the API would require admin privileges, so it wouldn't be possible to use different credentials for different clients/jobs.org.daisy.pipeline.tts.config
setting. The same remarks as above also count for setting theorg.daisy.pipeline.tts.config
property dynamically.