- From: <bugzilla@jessica.w3.org>
- Date: Mon, 11 Oct 2010 02:42:51 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10941 --- Comment #12 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2010-10-11 02:42:50 UTC --- (In reply to comment #11) > One more thing that I just realised: sometimes it is very obvious that a > description cue will not fit into a given time frame - in particular if there > isn't actually any time available to put it in and it is basically associated > with a time point rather than a segment. > > In this case, it would be possible to record into the WebSRT file the requested > pause duration for the screenreader for the cue and have the player pause for > that duration as it reaches the cue. This solution is based on heuristics as to > how long an average screenreader will take to finish reading a cue and can turn > out rather inaccurate, but it allows solving the situation without having to > wait for an event from the screenreader to stop / continue playback. > > Actually, this is the way in which I will be implementing this functionality in > a JavaScript demo for now, which of course means introducing a non-standard > marker into WebSRT. Gah, damned custom extensions... :-( This raises an interesting option: we could add a parameter to the pauseonexit event that tells it to pause for how long. Then, such a parameter might actually make sense to include in WebSRT. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Monday, 11 October 2010 02:42:52 UTC