Feature: More accurate time per word

[Shyiy]

I might be mistaken, but I think that it would be better if the time that each word is displayed (scaled by the wpm setting) could take more values and be more carefully selected, instead of only having the simple separation between a short/long word.

I would propose two improvements:

1. Easier. Make the time that a word is displayed proportional to the amount of characters in it, something like: A ms + B ms * length.
2. Harder. I'm not sure but I feel like when I'm reading I need more time to understand a word that is not in the language of the rest of the text, or is a name of a place/person: something which cannot be found in the "main dictionary" of the current text. It would be nice if we could detect the language of the text and assign more time to the words which are not found in the relative dictionary/list of words file.

[skeletonsaurus]

https://github.com/pasky/speedread handles pauses differently, and I think it seems less halting. Perhaps some of their timing elements could be implemented?

[Shyiy]

Yes, in their code they use the following function to decide the time per word depending on the word length:

sub word_time {
    my ($word) = @_;

    my $time = $wordtime;
    if ($word =~ /\.\W*$/) {
        $time = $fstoptime;
    } elsif ($word =~ /[;,]\W*$/) {
        $time = $commatime;
    } elsif ($word =~ / /) {
        $time = $multitime;
    }
    $time += sqrt(length($word)) * $lentime;
    $time *= 60 / $wpm;

    # Give user some time to focus on the first word, even with high wpm.
    $time = $firsttime if ($wordcounter == 0 and $time < $firsttime);

    return $time;
}

Could be useful to have something similar

[skeletonsaurus]

In general, I think the amount of time that a word "hovers" or "hangs", relative to the average word display time, should be minimized. To increment based on word size is a good solution, and I do like that https://github.com/pasky/speedread uses

$time += sqrt(length($word)) * $lentime;

However, there should probably be an upper limit to the number of characters displayed on screen, at a given time. Spritzinc breaks up words longer than 13 characters. And this is a good solution. They justify it, thusly:

On handling long words:
(from http://www.spritzinc.com/faq/)
"We handle these words just like your eyes do when they encounter them. Most people’s focal distance (the amount of horizontal distance on a page that people can see when reading) is right around 13 characters using standard font sizes. When your eye recognizes a word longer than that, it naturally jumps to the right of those first 13 characters while processing the first part of the word as it jumps. In reality, a long word requires your eye to break it into multiple pieces and that is how your brain stores it. We analyze each word and break them up based on this standard and show you long words in multiple pieces, just like your brain is expecting them. It works really, really well."

[skeletonsaurus]

https://github.com/richardtagger/spritz-js flows pretty smoothly, with the exception of the pauses on periods. Spritzinc seems to provide a moment of whitespace immediately following a period, and I think the effect is very good.

[kukulski]

I'd assumed that a constant cadence was important and that the WPM number should be carved in stone (plus or minus hyphenation + an extra beat for sentence breaks.)

I'd considered reducing articles and trivial suffixes to a half-beat in my system, but wonder if breaking the steady cadence would make things weird.