Release Speed reader


dimag0g

Very Active Member
Joined
Jan 12, 2011
Messages
608
Location
Strasbourg, France
Last week I discovered Spritz, innovative software which enables fast text reading on small screens. So I pulled together a PND I call Speed Reader, which implements something similar on the Pandora.

Right now Speed Reader only looks like Spritz, I don't know their "patent pending" algorithm for ORP (Optimal Recognition Point) calculation, so I used some heuristics here. I have written to Spritz describing them OpenPandora and asking if it's possible to use their algorithm on non-commercial basis (probably staying closed-source). I will keep you informed.

Meanwhile, check out Speed Reader and tell me what you think.

speedread.pnd

speedread.pnd
 

Attachments

Last edited by a moderator:
I hope you'll still be able to help. If there is interest for this app, I'll have to make a proper GUI, with a pause button/key and a fast rewind button/key (going 10 words back in case you lost concentration and didn't get it). There's also navigation issues with bigger files like ebooks or documents 10+ pages long, and I have no idea on how to do that properly.
 
ok, i checked it quickly at noon here, and it works fine, but I have the following inputs:

- make it full screen or at least make the window fill the screen,so that one can concentrate on the words. 

- when resizing the windows it shows more lines, which is not practical - ideally showing a single word, even when resized, is the expected outcome. 

- yeah, as you mentioned, keys to pause / rewind / go forward / increase / decrease speed are needed. 

- I didn't check but I'd expect as well that the text would pick up where you left when you re-open the same file. 

On top of that:

- ideally you'll need to make it work to open epub files as well as pdf. (there is a library to extract text from pdf btw)

Lots of work ahead but this is exciting and a very good start.

If you could post the code on github or something like that, I'd probably contribute. 

Where I can help:

- additional features

- GUI

- testing and polish

There's also navigation issues with bigger files like ebooks or documents 10+ pages long, and I have no idea on how to do that properly.
\\

What issues exactly ? 
 
Last edited by a moderator:
Well, I can share the code (small console app printing stdin to stdout one word at a time), but it won't be of much use to you if you plan to make a proper GUI. The rest of the package is just some apps I found to convert various formats to text. (html, pdf, fb2, rtf). Those are open source already. I will try to find epub2text if you think epub is relevant (I don't have a single epub file personally).

I wonder what kind of good/bad things might come from spritz and their patents. Do you think we should collaborate, or rather make something completely independent and fight for it to be open-source?
 
This is a cool idea. Let's make a FOSS application! We just have to use our own heuristics / publicly available articles to get that ORP thing right.

If you want, I could make something in SDL to nicely render words it gets from stdin (word/offset/delay tuples).
 
I'm all for a FOSS solution as well. Something that could be used both for the Pandora and the desktop. 

_wb_ good idea to use SDL and you are probably the right person to handle that :)

One thing which is very important to get right for readability, is the kerning of fonts -> any idea if SDL supports that ? 

I will try to find epub2text if you think epub is relevant (I don't have a single epub file personally).
Yeah epub is very relevant as it's one of the standards for ebooks.  
 
wow, never heard of that before.. it's truly impressive... I can easily follow the text on spritz even at 500wpm... that seems quite good...
 
I tried the SPRITZ demo site.

Please make it possible to invert colors.

The Glowing white will hurt my eyes after some minutes.

Grays background with white letters (red in the middle) would be nice :) .
 
Ok, I will try to read a couple of articles about psychophicis of reading. I hope to come back with a function which, given any word, would reasonably guess the position (colored letter in the demo) and the relative duration of display.

We would also need a smart splitting algorithm, books and articles are full of hyperlinks these days file paths email addresses and the like, and these are often too long to be perceived as a single word. Even some longer words would benefit from splitting.

_wb_, ekianjo, if you could start developing a nice rendering app that would be great. I have little to none experience with SDL.
 
Some questions about some of the underlying assumptions:

I assume we want to use a proportional spaced font, no monospace. I'll just use the SDL_ttf rendering, I assume it creates good kerning etc.

The "optimal recognition position" (ORP), is it always exactly at one of the letters, or can it be between letters too? What Spritz is doing looks like it always centers the word around one of its letters, but maybe they just do it like that to make it easier to code.

If the ORP is not an integer letter position, then it may depend on the font.

I'll read some more on that Spritz blog now...
 
"Click above to learn how to spritz" (it doesn't work, but it amuses me on a very low level)

Now, in Chromium it works. "At that speed you could read a 1000 page novel in about 10 hours". Why doesn't that impress me? Ah, yes, I used to do that, without breaks. Now I tend to spread that over a few days, it's too expensive (can't buy a new book every day) and time consuming (I do have other hobbies too) to read them in one go.

And my average of 100 pages/hour isn't when reading especially fast, because that's too tiring and makes it harder to grasp all of the content.

I'm not sure how good this works at speeds like 1000wpm, that's ... about 16/s? Damn, why do we need such strange units like minutes.

The demo doesn't allow me to go faster.

How it splits words is annoying, I generally read words in one go, not syllable wise. It's been proven that that's the normal way to do it (assuming practised readers). If it just used a box large enough to display them at once I'm sure that would improve speed for me.

But it's an interesting idea. Not usable for todays eInk screens, though. Are transflective LCDs better?
 
_wb_,

I suppose that making one letter as ORP is just for the programming convenience. Some research papers postulate that the ORP lies between two letters, splitting the word into two parts which are recognized independently to some extent. ORP positioning error of 1 letter makes you lose 1/50 of a second in average, so it's more or less safe to round it to the nearest letter anyway and lose 0.01s per word. ORP lies between the 1/4 and 1/2 of length for most words, although familiar prefixes and suffixes may shift it (for example in "autoimmune" the ORP would be on one of the m's). And yea, there is no "true" ORP, this is a statistical concept valid for most (but not all) people.

I have the impression that monospace fonts are not that good for fast reading, but this is MHO.

T4b, do you think if it's useful to group short words together, like "in the", "look at" etc.? Would that improve your speed?
 
What will be able to be supported?

When I convert my text document into PDF will the program be able to convert it into whatever it uses?

In University we get free E-books.

I can mark and copy texts in the PDF (no scans but legal full versions).

Can this work?
 
_wb_,

I suppose that making one letter as ORP is just for the programming convenience. Some research papers postulate that the ORP lies between two letters, splitting the word into two parts which are recognized independently to some extent. ORP positioning error of 1 letter makes you lose 1/50 of a second in average, so it's more or less safe to round it to the nearest letter anyway and lose 0.01s per word. ORP lies between the 1/4 and 1/2 of length for most words, although familiar prefixes and suffixes may shift it (for example in "autoimmune" the ORP would be on one of the m's). And yea, there is no "true" ORP, this is a statistical concept valid for most (but not all) people.
How would you want to encode the ORP offset? I was initially thinking a number between, say, 0 and 1000, where 0 is left, 1000 is right, 500 is the center of the word. That is easy to work with for rendering and may be suitable if you want to do a rough approximation of the ORP by using, say, 400 for short words and 300 for long words or something like that. But it depends on the font, there is no clear relation to the letter position. So maybe it's better to use a number between 1 and n (where the word has n letters), where e.g. 3 means "centered on the third letter" and 3.5 means "centered between letters 3 and 4".
 
3.5 means "centered between letters 3 and 4
Spritz doesn't do that.

They use 3rd or 4th letter and mark it red.

The red one is always the center.

There's no "between two letters"

Maybe there is a good reason for it, maybe not?

Better check.

Maybe your suggestion is even better.
 
Back
Top