alcinnz
I prefer to ensure the hypothetical machines I design are inclusive, so how'd I teach my Lua-Machine to read-aloud Lua's text output to those who can't see it?
Unfortunately this can take a lot of data, eSpeak is 9MiB of data, & 4.4MiB of code! On the otherhand I've established the underlying hardware to include all its data in its 4GiBs address-space, significant redesign that isn't otherwise needed to enlarge that memory.
So how'd we approach this?
1/3?
alcinnz
How about we provide a 3rd, smaller 1MiB cartridge slot (next to the keyboard port) which overrides the code for handling text? This wouldn't be enough memory to handle every language, but it should be enough memory to handle your language(s)!
Some of these cartridges could override `io.output` to return a File which reads aloud the text written to it. And we could add a nomally noop method which allows styling the text, which could also be useful for visual output too.
2/3!
alcinnz
In a nutshell, what would be in the screenreader-cartridge?
To start we'd need to store pronunciation rules & a dictionary of common words & symbols, which depending on the language could take up a fair bit of our MiB. Converting text to phonemes.
We may want to store a selection of voices, which'll take up to next to no memory.
We'd need audio & FX to convert the phonemes to audio, taking most of the rest of our MiB.
And we'd need code to interpret these!
2/2 Fin! Details tomorrow!
alcinnz
@wizzwizz4 Yes, I realized just as you responded!
wizzwizz4
@alcinnz 3/3 surely?
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.