iLiad continuous mode and column view in ipdf

[alanine]

I propose a new way to implement column view. Here it goes...

Continuous mode is flawed

In its current implementation, it moves the view port (the screen) downwards (or upwards if prevpage) by one screen height, and often creates a view of 2 pages next to each other vertically, and hence the illusion of "continuous". But this is useless because

1. The top/bottom page margin takes up a big chunk of the screen;
2. Putting 2 pages vertically makes little sense.

So a modified continuous mode is to always stay within a single page until it reaches the border. In other words, it's like fitting multiple screens onto a page when page height is greater than screen height, where muliple screens may overlap.

Column view is a natural extension

So continuous mode is about fitting screens vertically on a page, and column view is about fitting screens first vertically and then horizontally. So a user can easily do column views by first zooming into one part of the column and then switching to continuous mode.

I believe this could be the simplest modification to implement column view with no extra button or icon added. My earlier 2-column patch only works with 2 columns, and WPD's column patch only works with text PDFs but not image PDFs, and poppler has to be patched too.

Download

I'm attaching the modified ipdf binary (to install, just copy it to override the system /usr/bin/ipdf binary, back up first if you are worried), as well as the patch.

Continuous mode now works differently:

1. it will skip if the next or previous screen to the edge of the page is less than 1/3 screen. (This is mostly to skip margin, but since it can't tell whether it's really margin or text, so you may need to adjust the position by panning. It rarely happens though)
2. if you start from a page top position, it'll always start from the same position when it comes to the next or previous page;
3. to do column view, switch to continuous mode, zoom to the top left column, and now flip the bar to follow columns. Sometimes you'll also need to pan to adjust position to suit your need.

[wpd]

Originally Posted by alanine

I propose a new way to implement column view. Here it goes...

So continuous mode is about fitting screens vertically on a page, and column view is about fitting screens first vertically and then horizontally.

This sounds very much like my first column mode version that moved screens Y first and bumped a screen X when no more Y was possible; you might want to give that a go if you do not have this up and running already yourself. I did add a mode and a button, but it is very elegant indeed to go "column" when in continuous mode + zoom.

See http://forum.irexnet.com/viewtopic.php?t=1707 for more info + the link to my patch.

When time permits I would like to extend my current column patch in the following way:

• Allow for three algorithms for switching columns:
  • Poppler precedence mode
  • YX mode
  • XY mode
• Allow for usage when no text has been detected by poppler in YX and YX mode
• Switch from one advance mode to another by using gestures (ie. making a horizontal line => move to XY mode, vertical => YX, diagonal => poppler precendence)

I could setup a git repository with the work I've done so far - rudimentary gestures and xy yx modes - and we could cooperate, if you like

(posted publicly to hopefully draw more ppl in to either code or comment)

[alanine]

Originally Posted by wpd

This sounds very much like my first column mode version that moved screens Y first and bumped a screen X when no more Y was possible; you might want to give that a go if you do not have this up and running already yourself. I did add a mode and a button, but it is very elegant indeed to go "column" when in continuous mode + zoom.

Thanks a lot for the feedback. Combining the continous mode and column view is my goal here. I've made the binary and patch available, you may test it out.

I honestly believe your column auto-detection patch is a better approach technically, but I'm worried that from a practical point of view, simpler operations brings better user experience. Gesture is good stuff, but I'm not a big fan of gestures without visual cue.

[mac]

Maybe will be useful to read comics if first horizontally and then vertically(XY mode?). I don't know if that is posible.

[Dr. Faustus]

[QUOTE=alanine;143475]Download

I'm attaching the modified ipdf binary (to install, just copy it to override the system /usr/bin/ipdf binary, back up first if you are worried), as well as the patch.

[QUOTE]

How do i install this binary? When connecting the iliad to my computer i do not see the directory /usr/bin/ipdf binary

[daudi]

See if this helps. Note that you need to have shell access.

[lowie]

Hi Alanine,

I'm very happy with your effort to introduce column view in the iLiad. I used daudi's bundle to install your ipdf-version, and played around with it for a while, but I experienced some glitches:

- After selecting continuous mode, and zooming in on the left column, the flip bar takes me suddenly from page 1 to page 3.
- Sometimes a part of the page is skipped. When going back and forth the reader "picks" up the correct sequence.
- Sometimes the flip bar doesn't react. (Or am I impatient?)

I don't know what the cause is. Are there perhaps any restrictions on the way to zoom in?

Apart from this, I find you solution very elegant. It is intuitive, and should work with pdf, and images as well. Great work!

Regards,
Lodewijk

[lowie]

An update to my previous post:

In normal full page mode (non-continuous) I also sometimes experience problems with this version of ipdf. When flipping the page, the reader moves 5 pages ahead, as if a long click has been given. It does not seem to occur on the same page (number) each time. Is this a known problem?

[alanine]

Iowie, thanks for the feedback and I'm glad you find it useful! Indeed I've noticed the short flip mistakenly treated as long flip problem too, but not very often so I thought maybe it was a mistake of my hand. But since you are reporting this problem too, I'll try to see if it's really a bug.

As for the skipping over problem, I intend the algorithm to skip margins only. For example when you are already reading a page portion just above the bottom margin and hit the flipbar, it should go to the next page (or column) instead of showing the margin. But there is no way to know the width or height of the margin for a PDF file, so I arbitarily set a rule it will skip if the next or previous screen to the edge of the page is less than 1/3 screen. You may need to re-adjust when you find it skipped real text that shouldn't be skipped.

[lowie]

Alanine:

Indeed I've noticed the short flip mistakenly treated as long flip problem too, but not very often so I thought maybe it was a mistake of my hand. But since you are reporting this problem too, I'll try to see if it's really a bug.

This might help you pin point the problem:
- I've noticed the described behaviour with the normal page mode as well. Have you changed any code that is used in this normal mode?
- In the normal page node, I've noticed that flipping forward from say page n, it brings me to n+5. Going back and trying again (with a short flip), the same happens. I have also waited for a while, but again it goes to n+5. If I exit the document, go back to page n, flip the page, it goes to n+1! Very strange.
- It seems that this behaviour occurs more frequently if I flip pages fast. If I wait a while on each page it seems to occur less frequent. Also very weird. Makes me think I should go to bed more early!

Anyway, I want to complement you again, because reading scientific articles was almost impossible.

As for the skipping over problem, I intend the algorithm to skip margins only.

OK, this sounds reasonable, and indeed seems to work most of the time. I had one other idea which helps reading papers where there are different even and odd page margins (see attachment for an example). The following alogrithm could help: when finishing one column, go to the next by panning the width of the column iff there is enough space on the page. If not, then the right hand margin of the column is placed against the right hand margin of the page. This condition is only met if the zoom factor is more than 50%. So normally, you wouldn't notice it.

[alanine]

lowie:

Since the patch didn't change anything other than in the continuous viewing mode, I believe the problem is very likely not related to this patch. Maybe I'll try to use the original ipdf binary to see if the problem exists there.

As for the margin problem, actually if there is not enough space, it's probably a margin and should be skipped. Current threshold is 1/3 of the screen to detect this. If its not skipped, the display is not aligned to the edge of the page, but instead it follows previous display area.

Indeed my first solution was to align to the edge, but then I often found myself losing track of the text I was reading because the new content doesn't start from screen top. Ideally one should clip out old content (or gray them) and center new content that is displayed. But I didn't see a quick way to do the clipping. (maybe I'll figure it out if trying harder :-)

[lowie]

Alanine:

Since the patch didn't change anything other than in the continuous viewing mode, I believe the problem is very likely not related to this patch. Maybe I'll try to use the original ipdf binary to see if the problem exists there.

That was my idea as well. I haven't tried the stock ipdf binary, but the problem only seems to occur if you flip pages with short intervals.

As for the margin problem, actually if there is not enough space, it's probably a margin and should be skipped. Current threshold is 1/3 of the screen to detect this. If its not skipped, the display is not aligned to the edge of the page, but instead it follows previous display area.

I experience 1/3 of a screen is a bit much. Mostly I zoom to 40% of an A4-page, then 1/3 of a screen is approx. 4 cm of the bottom of the page. Many papers have a margin of 2 cm, so perhaps 1/5 of the screen would be better? I wouldn't mind flipping a screen extra, but it is a little annoying to have to go back and move the screen down.

Indeed my first solution was to align to the edge, but then I often found myself losing track of the text I was reading because the new content doesn't start from screen top. Ideally one should clip out old content (or gray them) and center new content that is displayed. But I didn't see a quick way to do the clipping. (maybe I'll figure it out if trying harder :-)

I agree that that would be confusing, and graying out part of the screen seems a little complicated. Anyway, I noticed that the problem I described is also solved if zooming not too much.

By the way, how could I create and compile my own patch? How do you do that? Is there a way to test a patch before installing the new binary on the iLiad? Thanks in advance!

[alanine]

lowie:

I can confirm that the flipping problem is a hardware issue, as using the original ipdf binary from iRex still exhibit this problem. My flipbar actually got worse, now it won't even respond to forward flips sometimes!

So I've updated my patch to help people who have similar problems with their flipbars:

1. both long and short flips only flip a single page now;
2. up and down arrows are now mapped to long flips.

Further more, I've also updated the continuous mode to display and center only new contents from the same page. It's only for vertical viewing, and the margin problem is also adjusted. Hopefully it'll work better now. You can give it a try.

I'm only attaching the new binary here as I've mistakenly overwritten the source code by an old copy and consequently lost the new modifications

PS: To compile from source on your own linux PC you need to setup the toolchain for cross-compilation. I won't go into the details as there are already documentations that can be found on iRex site as well as this forum.

[lowie]

Hi Alanine,

Sorry for the very late reply... Thanks for the ipdf update. I've tested it, and it works like a charm! Sometimes I have to shift the page a little, but that is very intuitive. It is a bummer that the flipping problem appears to be hardware related. Has this been reported back to Irex?

Regards,
Lodewijk

[lowie]

Hi Alanine,

I managed to compile ipdf myself and made an adjustment for educational purposes. I have implemented a feature that is (already) available when viewing html files: the page offset. It shows you how far you are on the current page in the pdf file. I find it useful when using your column mode: now it is easy to see where on the page you are. The offset is a percentage: the ratio of the viewed page area and the total page area.

I have included two patch files: one from the stock ipdf and one from your ipdf version. It only works in continuous mode by the way. I also include the binary.

Your other changes are not included, as I do not have a patch for your later adjustments. Do you perhaps remember what you have adjusted?

Regards,
Lodewijk

PS: I only implemented this for Portrait view mode, if it works (and it is useful) it is trivial to implement it for Landscape view as well.