Release Speed reader

[Granitehead]

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

Possibly, would need to be tried, but I'm not sure about it. When one looks at the center of the place words appear and then looks in between of words I don't think that would be good. On the other hand, I think maybe with practice often used word combinations would be recognized as one word and that would be faster.
I'm also not sure what I would think about it after reading for an hour or something, whether that would be relaxing, whether it would be more tiring, whether I could enjoy a good book that way.

I would most certainly need controls to change speed, to stop, and to seek backwards (to seek backwards I would need to see the text in a more classical way).

It probably should pause a little longer after commas and colons, longer after sentence ends, longer after newlines combined with sentence ends, longer after paragraphs, longer after chapters. The pause after commas could be a split second extra, the one after chapters between 1s and 5s and the rest in between.

 

[dimag0g]

_wb_

I believe that the second option you proposed is better. It's important to refer to a particular letter, and I would keep the option to refer to positions between letters with fraction values (like 3.5 for the space between letters 3 and 4). Askarus is right, spritz always selects one exact letter as ORP, but I don't know if this is just rounding to the nearest, or there is a reason for this. I suggest we keep our approach flexible for now.

T4b,

I will definitely increase pauses when punctuation is encountered, just be patient. It might get a little trickier with chapters and paragraphs, because different tools (pdftotext, html2text, etc) have different formatting approaches, but everything is possible since those tools are open-source.

Could you tell me more about that navigation controls? I imagine it's easy to make buttons to go 10 words forward/back, to previous/next paragraph and previous/next chapter. Do you want to also have a regular window with scrollbar to show all the text, where you could find the right spot and click on a word to start speedreading from?

 

[ekianjo]

Could you tell me more about that navigation controls? I imagine it's easy to make buttons to go 10 words forward/back, to previous/next paragraph and previous/next chapter. Do you want to also have a regular window with scrollbar to show all the text, where you could find the right spot and click on a word to start speedreading from?

Previous/next sentences would be best rather than 10 words forward/back.  

 

[Askarus]

I'd like an overview.

So that the text can also be displayed in normal Paper style and then you can chose the word you want to start reading.

 

[ekianjo]

I'd like an overview.

So that the text can also be displayed in normal Paper style and then you can chose the word you want to start reading.

not practical, then you'd have to code a whole regular e-reader just for that "overview mode"

 

[_wb_]

I'd like an overview.

So that the text can also be displayed in normal Paper style and then you can chose the word you want to start reading.

not practical, then you'd have to code a whole regular e-reader just for that "overview mode"

True, it would be a lot of work. But I agree with Askarus that it would be very nice to have some kind of overview mode, especially for navigation.

 

[ekianjo]

True, it would be a lot of work. But I agree with Askarus that it would be very nice to have some kind of overview mode, especially for navigation.

Haha, one idea: you could build something like PIV thumbnail view where you "unzoom" from a single word view to a larger view where you see the other words/paragraph flowing around

Note: More realistically though, as long as you have the chapter name, and your latest position bookmarked, why would you need a "larger view" ? It defeats the purpose of the single word view, and you shouldn't really need it you memorize the book in the same way no matter how you read. 

 

[mcobit]

Or just display some lines of text at the bottom that scrolls down and the single words above that. If you didn't get a word you can hit a button and look down to read the sentence traditionally. Then start the fast reading again.

 

[Granitehead]

Could you tell me more about that navigation controls? I imagine it's easy to make buttons to go 10 words forward/back, to previous/next paragraph and previous/next chapter. Do you want to also have a regular window with scrollbar to show all the text, where you could find the right spot and click on a word to start speedreading from?

As said, make it sentences, not x words. Colons and semicolons could also be points to stop at.
But, yes, I would like a more or less regular display too, for searching something you just read and being able to look at a sentence for a moment if you want to think about it.

I would just feed the text to LaTeX and display the result (don't know how fast that is, but for only a few sentences I think it should be fast enough to do on the fly and LaTeX is just beautiful. You could also use it to render the individual words).

Maybe 5 lines (of, ideally, average book length, I've forgotten the exact number, but there is a length which is considered to be ideal for books. Probably that should be default value, but it should also be configurable for when you want a larger font size or have a small screen), filled with as many full sentences as possible before and including the one you were at.

The rest of the screen filled with as many of the following sentences as there is room for, as long as that's less than or equal to 5 lines. Once it's more than 5 lines, it should also include more of the previous sentences to make it more or less symmetric.

Highlight the position the reader was at before switching modes (if you use LaTeX that's just a question of inserting some tag around the current word in the text you feed to LaTeX. Don't know it's name right now).

I think by using LaTeX that should be possible without /too/ much work (but some fiddling around with LaTeX sources if you don't use to write LaTeX). Just hope it's fast enough as that isn't its purpose.

If you use LaTeX but aren't used to it feel free to ask me to supply you with source code for anything you need type set (and then rendered). I'm no pro either, but having used it a few times I'm starting to know where to look stuff up and how to do some easy stuff.

(a while ago I've written a script which turns LaTeX sources directly into .png files... being a script it would probably be too slow to use as a renderer for a program, but you could do something similar: https://gist.github.com/TT44bb/4518131)

 

[_wb_]

As much as I like LaTeX, I think it's a bit overkill here. It would make the PND huge if we have to include a copy of LaTeX. Also, I think it makes sense to use the same font for the word rendering as for the sentence rendering. If it's just for rendering a few lines of text, SDL_ttf (which is what I plan to use for the word rendering) should be good enough -- we don't need real typesetting with variable spacing between letters and words to fill the pages of a book with justified alignment and all that.

 

[Granitehead]

If you want me (and possibly other book lovers) to use it, then yes you do need kerning and so on even for a few lines of text and especially for the primary mode of display, i.e. the single words. Yes, consistent font is necessary.

I'm aware of the size of LaTeX, that's certainly not very nice if that needs to be included, but it would be worth it to me. To be honest I didn't specifically think of the Pandora but of what I would like for a reader app which if I got this correctly is supposed to become multi platform, isn't it?

 

[_wb_]

Well SDL_ttf does correct kerning, that is not the problem. It only renders single lines of texts though, not paragraphs or pages.

 

[Granitehead]

Well SDL_ttf does correct kerning, that is not the problem. It only renders single lines of texts though, not paragraphs or pages.

Then I will need to see it and judge for myself.
If LaTeX was available though I think it was probably the easiest and best solution especially when also considering to display some paragraphs of standard text.

 

[_wb_]

Well SDL_ttf does correct kerning, that is not the problem. It only renders single lines of texts though, not paragraphs or pages.

Then I will need to see it and judge for myself.

If LaTeX was available though I think it was probably the easiest and best solution especially when also considering to display some paragraphs of standard text.

I agree that LaTeX is the best for rendering books.


However, I think for the purposes of this application, it's better to forget about physical pages of a book. The relevant entities are words, sentences, paragraphs, chapters. Not pages consisting of lines of text. I think we should invent a new kind of visualization for "overview mode", maybe something like showing the current position in the current sentence by fitting the entire sentence on one line (or maybe two), showing previous and next sentences above and below that, in a smaller and smaller font as you go further away.


Also, if the source material is already formatted (e.g. a PDF), maybe overview mode should just show the PDF. Of course we need a mechanism to map back text positions to (page,x,y) coordinates in the PDF file.


Anyway, let's first get the core "speed reading" mode working well.


@dimag0g : Could you make a version of your ORP engine that outputs the words in a format that is easy to use for the renderer? e.g. printf("%f,%i,%s\n", offset, delay, word); would be good.

 

[Reyhn]

That's a nice project and interesting technology.

What do you think of a modular approach, having two processes : one fetching the input text and one doing the front-end rendering. This way one could write its own front-end using the rendering tech and providing the functionnalities he wants etc.

 

[_wb_]

That's a nice project and interesting technology.

What do you think of a modular approach, having two processes : one fetching the input text and one doing the front-end rendering. This way one could write its own front-end using the rendering tech and providing the functionnalities he wants etc.

That is what we have in mind. I'm making a rendering program in SDL, dimag0g is making something that computes the word splitting, ORP offsets and timing. So basically you should be able to do something like "cat textfile | engine | renderer".

 

[mcobit]

You could even make a client server model this way with the renderer connecting to the enigne on a server that sends the data over the network


With a solid backend different renderers could be used to integrate into different frameworks like php gtk qt sdl etc.

 

[Askarus]

Note: More realistically though, as long as you have the chapter name, and your latest position bookmarked, why would you need a "larger view" ? It defeats the purpose of the single word view, and you shouldn't really need it you memorize the book in the same way no matter how you read.

Why?

If for example one reads education books (school, university, learning just for fun) then it might be good to be able to switch to common book mode and read slowly the paragraph (again) which contains important stuff.

 

[_wb_]

@dimag0g : Could you make a version of your ORP engine that outputs the words in a format that is easy to use for the renderer? e.g. printf("%f,%i,%s\n", offset, delay, word); would be good.

Also, I'm assuming that the text is in UTF8 format.

 

[ekianjo]

by the way if you plan to support japanese you cannot do it word by word based on the text file since there are no spaces in japanese. a special function to cut the strings would be needed.