epr crashes on pinch-zoom in Termux on Android environment

[jarun]

I get the following error when I pinch-zoom in the Termux environment on Android:

Please take a look.

[wustho]

Ah forgot to fix it in epr. So, I forked epr: http://github.com/wustho/epy which is basically epr with reading progress percentage. And I already fixed this issue there: https://github.com/wustho/epy/commit/b635668356848fe59fd4ac8ab6a899c0fda648aa , just simple try:except: block, but forgot to implement it on epr. I'll get to it soon...

[jarun]

Thank you!

[jarun]

Are you planning to merge progress percentage to epr later or these 2 are different projects?

Why not add a program option to epr for the progress percentage? That way users can use the mode of their choice without having to deal with 2 projects. I can see why progress percentage is useful.

[wustho]

Just fixed this issue (https://github.com/wustho/epr/commit/b0b898d38f817832d5b63d9a3b8e79031634e82c). Tho not actually fixing it, just catching its error, I still don't know what exactly causes this problem...

And about epy's progress percentage being merged to epr, I'm still searching for best scheme to calculate reading percentage, what I currently use is pretty ridiculous (by counting total letters read divided by total letters in all chapters) so I'm still waiting for issues to raise with this scheme. epy being in different repo instead of different branch is because it's easier for me to manage...

[jarun]

I'm still searching for best scheme to calculate reading percentage

Do you get the number of pages easily? I know from epr that you can store the current page number and remember it across sessions. So maybe just (current page number / total pages) * 100 gives a simple and fast solution to your problem?

[wustho]

The problem with page based percentage is that total page of a chapter will be different with different column width, and the only way to count each chapters pages is by passing it to text formatter inside HTML parser class, which is the most time consuming object in this script. Not to mention the necessary step to recount total pages every time we adjust column width...

[jarun]

Not to mention the necessary step to recount total pages every time we adjust column width...

Do the calculation vary a lot with different column widths? I think you can still use an approximation - have a static table with the average number of words per page based on column width. That's how people count the number of words in a limited-word essays in exams (count number of words in 3 lines, divide by 3 and use it as the average. Then count total lines and multiply). That's a good approximation.

Also, do epubs support metadata? If yes, you can probably add an entry for the number of words/pages/lines you count first time.

[wustho]

Do the calculation vary a lot with different column widths?

Well I actually haven't consider this, but I found counting letters being more exact than approximate.

Also, do epubs support metadata? If yes, you can probably add an entry for the number of words/pages/lines you count first time.

I tried saving number of letters as state the first time epub is read, it actually improve startup time by whole lot differences, but it costs so much memory when there're thick books in my reading history, so I figure a little startup time is cheaper than little more memory usage.

Besides, what motivates me making this script is its low memory usage because it processes epub by one chapter at a time instead of processing all chapter together like many GUI reader...

[jarun]

but I found counting letters being more exact than approximate

Sure, if it doesn't lag significantly, accuracy is always the best thing to have.

so I figure a little startup time is cheaper than little more memory usage

If the performance is reasonable on Termux then you don't really need to bother about it.

[wustho]

Indeed, thanks for the feedbacks... Hoping to get more input from everyone...

[jarun]

Marking the defect as fixed. Works fine now!