koreader
Can't "columnise" a PDF
- KOReader version: v2024.11-262-g135453776_2025-03-15
- Device: PocketBook Era P700
Issue
I cannot choose a number of columns when reading this PDF
Steps to reproduce
Open the PDF, open the bottom menu -> cog wheel, and see the bottom line (choosing columns) greyed out.
I have semi-automatic cropping on, to get rid of the top and bottom lines that cross the column-separating whitespace, so there is a clear "canal" of white separating the two columns.
The Document Columns selector is a hint for the reflow engine to properly process the columns. (Long press on Document Column to read the help text.)
Funnily, its current value - and also the default value! - is 2. But the document shows as pages, not columns.
Switching "Reflow" on did the trick. Which confuses me, as I had understood "reflow" to be about extracting the text and rendering it, not about zooming in to, in this case, single columns. I probably misunderstand what reflow is.
Anyway, thanks! This helps my old eyes a lot!
One small issue - it seemed for a moment that the "grey out the segment of the page already read" feature got a bit confused now. Al least, whole pages (i.e. columns) now show greyed out. But it isn't that, as setting contrast to 6 solves it - and in other documents lets the greying-out feature intact. So I am not sure what is going on, but with more contrast than before all is well.
its current value - and also the default value! - is 2.
It stands for the max columns that the reflow engine will try to detect in the document. So one or two. Set it to 1 if reflow incorrectly detects 2 columns (has never happened to me). Set it to 3 if the original document has 3 columns.
Which confuses me, as I had understood "reflow" to be about extracting the text and rendering it, not about zooming in to, in this case, single columns.
It uses this tool which also exists as a stand-alone program (with even more available options):
https://www.willus.com/k2pdfopt/
So I am not sure what is going on
There are some known bugs involving reflow and page overlap, so it is possible you encountered one of those.
All right. I believe some more help information would not be a bad idea.
We have gestures now - what if gesturing up from any bottom menu item, or down from any top menu item, brought up a help text? (Maybe up would work, but not for the very top icons - a bit like the problem of gesturing à on the keyboard.)
Now sometimes long pressing does, or a separate menu item does - but long pressing is also used for setting defaults, and maybe other uses. Having an equivalent of F1 would be helpful, I think.
Instead of popping up a window it might also open the manual at the relevant page. Currently the "manual" is merely a minimal introduction, but with some crowd work I guess it could be populated quite quickly - wiki-like.
Personally I would not like swiping to bring up any kind of help text, anywhere. It would be too easy to trigger on accident. And you really only need to see it once and then don't want to be bothered by it again. The long-press approach makes sense to me, because you have to do it with purpose. I agree with you though that it would be helpful to add some kind of little marker (e.g., a little 🛈) to indicate the availability of a help text. Different symbols could be used to indicate make default or additional options.
Btw, there is a full-fledged user guide available here: https://koreader.rocks/user_guide
All right - what about a less accident-prone gesture? Say, Left-Right or Right-Left? (Both, so it can be used on all corner items too.) And yes, it could just (offer to) call up the relevant page from the existing user guide.
I don't really see any kind of gesture be a viable approach here. Long-press (or F1) or nothing ;).
You mean a technical limitation? If it is that, then all options for having more than two actions per menu item (other than by some kind of submenu) are off, and we must make do with what we have. Pity, though, as there are at least three recurring possible actions:
- choose;
- set default;
- get help.
And unfortunately none of my e-readers has an F1-button.. (Though a short press on the On-button of my PocketBook, which currently opens the main menu, could bear redefinition.) But more generally: how would the system know about which item help was requested?
No, I meant that from a UX perspective ;).
There isn't really an expectation for any kind of gesture to do that sort of stuff anywhere, while, on the other hand, we have many expectations for gestures to do anything but that ;).
(As for your last question, on non-touch devices, FocusManager tracks, well, focus, so an F1 can easily be contextualized to the current focus (NOTE: I have no idea if we actually bind F1 anywhere, it's just what the key is usually used for in common UX concepts, IIRC).
Well, I could easily learn a long press to mean "Function key", with a following swipe to be the number (on a virtual phone keypad, so NW=1; N=2; .. SE=9). If we then take F5 (the long press with no swipe) to mean "set as default", I think we'd get something that, once quickly explained, would feel quite natural.
And isn't KOReader all about that? The menu structure definitely does not have the structure a novice would expect, but it has its own logic (up to a point), which, once understood, makes sense.
And yes, on non-touch a button could work well.
There isn't really an expectation for any kind of gesture to do that sort of stuff anywhere, while, on the other hand, we have many expectations for gestures to do anything but that ;).
To allow for this kind of stuff on any device is a big reason I created multiswipes. :-)
However, I'm not convinced by the suggestion to split up the moderate amount of help text and set as default. That sounds like a lot of work for no benefit.
If you expect to see help text somewhere please just ask to add help text there. There should be no need for anything else.
Often when long-press is used to set-as-default, we added some explanation & help text in the text in the ConfirmBox to confirm set-as-default. In the bottom menu, long-press on the widget on the right sets as default - but long-press on the title on the left shows the help-text and the current & default values.
There are a very limited set of cases where I remember we couldn't hijack long-press to show some help_text, and so we sacrified that help_text - but I'm sure you haven't found them :) Most often, there is just no help_text because the feature was obvious - or we forgot to add it.
No real need for anything more twisted. As the chronicler of the poet rewrote it better: "In KOReader, everything is long press-able, unless it isn't".
If you expect to see help text somewhere please just ask to add help text there. There should be no need for anything else.
All right: see here (and the preceding messages).