It seemed that e-reader screens would converge to 6 inches, but considerably bigger devices keep being produced too.



Amazingly, after new year I still had money left, so I bought myself an e-reader. It turns out that the screen is indeed very nice to have when you read a lot of pdfs and epubs (which I do), even though the devices tend to be short on other functionality. The screen is wonderfully convenient compared to a night lamp and a book, and better than a mobile phone's LCD screen.

Insofar as e-readers are meant to display text, there should be font settings (types and sizes) everywhere. My e-reader doesn't permit changing fonts in pdfs, not even when the text reflows. There's no changing of font types and sizes in the web browser either. There should be.

The web browser should permit saving pages as text or HTML. Web-to-PDF would be nice to have. These things are easy to do in a computer and then load onto the e-reader, but it seems like a natural function for the e-reader itself.

Text-to-speech (and saving the file, i.e. conversion of text formats to audio) should be standard in sound-capable devices. Producers of e-readers should be pioneering the speech software for other languages than English. It's an accessibility thing.

More dictionaries too, particularly from other-than-English to English. And more non-Latin scripts/fonts. Producers of e-readers should be actively developing these things.

Even though e-ink screens have only shades of grey, no colours, there should be colour settings to adjust contrast and such. At least there should be a setting to invert the text and background colours. It's again an accessibility thing. Koreader is a program that fixes this particular aspect on my device, though not globally. Settings like this make sense globally.

All quite true. I wish devices were treated more like regular computers as opposed to the locked-down experience they try to force on you.

The first step would be honest reporting about what's onboard. They often say it's "Linux" on the e-reader. It isn't. It's always a proprietary ecosystem. And sometimes they say it's "Android" but if there's no Google Play store, then that's not really Android as most people understand it, and if side-installing is locked, it should say so.

A few more details of comparison. I'm sure that Kobo's power button is not lit. It certainly isn't on Kobo Aura One. On Pocketbook, the lit power button works like activity indicator, so you can see that the device is busy and you don't anxiously press things but rather wait till it does its thing.

On Pocketbook Sense there's a little loophole for the accessory rope (or whatever you call it). I have found it immensely useful. Unfortunately it's not there on other Pocketbook devices.

The reader software on Pocketbook is quite adequate. I go to Koreader for one main reason: Night mode that inverts the colours. If Pocketbook's reader had night mode, Koreader would be unnecessary. With Kobo it's different - you need Koreader to make it a usable e-reader in the first place.

Another great function in Koreader is the fully tweakable statusbar.^[1] In Pocketbook the page count bar shows just the page count, i.e. its woefully underused, while other things you'd like to see, such as battery status and clock, are on a whole different bar. I normally have both bars hidden away in Pocketbook and when I need to see stuff, there's a single press that brings up all the buttons, menus and bars. This is convenient enough, but Koreader's statusbar is still more economical.

¹ ...which annoyingly vanishes when you press it. Can that be turned off? And can the touch regions in Koreader be tweaked to emulate Pocketbook? e.g. the center should pop up the menus and the lower corners should turn page back and the upper corners should turn page forward. I do all my annotation and bookmarking in Pocketbook, so it's not a problem to hide bookmarking away in Koreader. But my first aim would be to suppress the toggling of the statusbar.↵

A few more details of comparison. I'm sure that Kobo's power button is not lit. It certainly isn't on Kobo Aura One. On Pocketbook, the lit power button works like activity indicator, so you can see that the device is busy and you don't anxiously press things but rather wait till it does its thing.

Weird, my H2O works the way you describe, at least during startup.

...which annoyingly vanishes when you press it. Can that be turned off?

You could try this: https://github.com/koreader/koreader/issues/1350#issuecomment-65896063

Code: [Select]

DTAP_ZONE_MINIBAR = {x = 0, y = 0, w = 0, h = 0}

Weird, my H2O works the way you describe, at least during startup.

I guess I haven't looked enough H2O reviews. And of course I haven't because I aimed at bigger and newer and better. But this image of One should be telling. That blue button is the only button on the entire device.


Edit: In the image, if you look carefully, you may think you see something button-like on the front too. One of them is the ambient light detector. That's usually not a good idea. It exists on my Pocketbook Sense too, and does nothing sensical on it. There was the same thing on Xperia M5 that I had for a while, and it was just ridiculously annoying. Then again, it works well on Galaxy Note 4 and I keep it switched on there. So it's possible to make it work right, but most makers fail trying.

You could try this: https://github.com/koreader/koreader/issues/1350#issuecomment-65896063

Code: [Select]

DTAP_ZONE_MINIBAR = {x = 0, y = 0, w = 0, h = 0}

Thanks, but from the comments it looks like this switches off the Hold=Go to. I'd like to retain that, but seems impossible.

But this image of One should be telling. That blue button is the only button on the entire device.

If it's like the H2O that button has a little light underneath. I'll make a vid.

But this image of One should be telling. That blue button is the only button on the entire device.

If it's like the H2O that button has a little light underneath. I'll make a vid.

Well, thanks for telling. I didn't know. Reviewers evidently don't think it an important point, whereas for me it's been a life-saving detail to make my little Pocketbook Sense with its limited RAM usable, so I know if I have to restart it now or not yet.

Hold=Go to

...speaking of which, Koreader would be invincible (don't get me wrong, it's the best app on e-readers I know already), if Go to dialog had, in addition to the page slot, also buttons such as

- Next & Previous chapter (if any, i.e. if none detected, don't show the button)
- Next & Previous bookmark  ("-")
- Next & Previous highlight ("-")
- Next & Previous annotation ("-")

...speaking of which, I haven't noticed Koreader doing annotations/scribbles, which is a bit of a shame, but I guess it's hard to implement. And Koreader doesn't have a separate section for all bookmarks and highlights in the entire library.

Pocketbook got it almost perfect: Highlights, annotations, and bookmarking are globally available in a separate Notes app. I only wish the list of notes were a bit more informative. Right now it shows the book title or filename, if something's been done to it. I'd like to know exactly what is there (a highlight, annotation or a bookmark) and on what page.

Well, thanks for telling. I didn't know. Reviewers evidently don't think it an important point, whereas for me it's been a life-saving detail to make my little Pocketbook Sense with its limited RAM usable, so I know if I have to restart it now or not yet.

It doesn't help in that sense, but then again that sense hasn't been an issue for me. It's only when you turn it on, before it shows anything on the screen.

In Pocketbook Sense and Touch Lux 3 the power button light works like processor activity indicator. A very welcome feature on those devices. I expect the same on Pocketbook Inkpad 2.

Pocketbook Inkpad 2 is a mixed bag. I have no idea whether to be happy with or not.

The software has not been upgraded since the earlier version of Inkpad. The firmware on Inkpad 2 literally identifies itself as the same as on older Inkpad: Pocketbook 840. This can be read on the homepage, so it cannot be considered a deception, but it means that basically an old device has been repackaged a bit and sold as if a new device.

The main mode of operation and the interface are the same in Sense and Inkpad. Both devices have two arrow keys plus a power button. All keys can be somewhat configured and I have already configured them to do the same things.

The casing is new(er) on Inkpad 2, with bigger better buttons (compared both to Sense and the older Inkpad). The casing is the thing you will be paying for, because everything inside it is the same as in the first Inkpad, including the screen. Or perhaps something is missing, because at exactly the same size, the device is lighter by 50 grams compared to the older Inkpad. Still, it's a solid build, feels sturdier than Pocketbook Sense.

8" screen on Pocketbook Inkpad compared to a 6" screen on Pocketbook Sense can be considered an upgrade, but only barely. Both Inkpad and Sense qualify as relatively unresponsive with annoying delays from press on keys/touchscreen to the reaction. Annoyingly, I find myself mispressing on the touchscreen more often on Inkpad than on Sense. Then again, if the press lands rightly, Inkpad is more reliable with opening big files due to added RAM (compared to Sense) even though it's not faster.

On a 6" screen it's somewhat of a struggle to fit fixed pages (such as on PDF's) to the screen. It's hardest with PDF files that are images of books shot two opposite pages at the same time.

Dual columns and particularly two pages in the same image are more comfortably viewed on 8" screen. However, with such a great surface area on hands, one easily becomes greedy for complete pages at a single glance (fit-the-page view) and that's where 8" doesn't always cut it. For some books it does, but not nearly for every book. 10" and above would be suitable for almost every book page at a single glance.

As a display device in an instruction environment, 8" screen is too small again, unless some magnifying projector is present. And the screen should not react to touches when pointing stuff out. Inkpad is insensitive to pointer pen, so that's kind of a start.

Compared to Pocketbook Sense, Inkpad adds voice (text-to-speech; through headphones only, there's no loudspeaker), but 4 GB of internal disk space is not enough to install all the voice engines I would want. In order to install two voices that I very likely need, I had to remove two that were preinstalled. So the device is already full of it when you get it! And no, I didn't add any of my own books to the internal disk. My books are on a separate microSD.

All in all, I guess I will keep it, because it amazingly fits, cover included, into the same pocket where I have been carrying my first e-reader. If Pocketbook Sense had the same amount of RAM, I would see no reason for Inkpad. Sense can be held nicely in one hand and this is what I like more about it. Sad that the two devices don't seem to fulfil two slightly different functions. Inkpad 2 serves the exact same purpose as Sense, none other, with marginally improved comfort.

xreader (an Evince port by Linux Mint team) just added support for epub files. I tested.

- Open an epub. Yes.
- Scroll. No.
- Spacebar. No. Must press Next to get ahead from the first page and TOC.
- Main text is counted as a single page. Scrolling works fine there.
- Invert colours. Ok.
- Occasional messup and loss of text. Fixed by reloading.

How does one open multiple instances of the same file in xreader? In Evince you use hamburger > Open a copy. To put it in the words of a commenter where I found this workaround: "first they create a problem, by ignoring multiple invocations, then they give you a menu entry to work around the problem they created. Grr." (source).

A lot in GNOME seems broken by design. I'm often surprised how good many of the apps are in spite of that.

Also on that note, and this isn't so much on purpose although it is by design in the sense of how they decided to construct the program: fit to width hardly works at all unless all the pages are the same size. Is xreader working on that? It's really the flaw above all others in Evince.

How does one open multiple instances of the same file in xreader?

Ctrl+n? (If that's what you mean.)

Also on that note, and this isn't so much on purpose although it is by design in the sense of how they decided to construct the program: fit to width hardly works at all unless all the pages are the same size. Is xreader working on that? It's really the flaw above all others in Evince.

If xreader evolves away from Evince, then people would likely turn to hate it or ignore it. It's simplest and safest to copy Evince in everything and just add the menubar. (Not sure if this will remain the policy of the project.)

But yes, I dislike the ill-fitting fit-to-width too. My preferred graphical heavy-duty pdf viewer is Qpdfview.

As to e-readers, Onyxes with their Android have an important advantage - a real keyboard can be attached to them. This makes extensive note-taking much more efficient. And 1GB RAM also could make a difference. EBookdroid would probably run fairly smoothly there, if it can be installed.

Ctrl+n? (If that's what you mean.)

That's the same action as the menu entry I was talking about, yes.

It's simplest and safest to copy Evince in everything and just add the menubar.

Actually I happen to think that in Evince the way they've designed the GUI isn't bad at all, although at first glance a traditional menubar with text is often clearer than some mysterious icons. In fullscreen in particular the extra vertical space is quite nice.

My main gripe with the new GUI is that they broke standard interface conventions like Alt+F, which I would expect to open the filehamburger menu. Note that Microsoft's less usable ribbon menu took very explicit pains to preserve this rather important aspect of the interface. For example, in the attached screenshot I've pressed Alt+R (to switch to the review tab) and then it shows you what to press next. So once you know these sequences you can still go Alt+R, A to accept a change just like you always could. In GNOME, you cannot.

Microsoft: 1
GNOME: 0

Ctrl+n? (If that's what you mean.)

That's the same action as the menu entry I was talking about, yes.

It's simplest and safest to copy Evince in everything and just add the menubar.

Actually I happen to think that in Evince the way they've designed the GUI isn't bad at all, although at first glance a traditional menubar with text is often clearer than some mysterious icons. In fullscreen in particular the extra vertical space is quite nice.

Extra vertical space? Fullscreen to me means no bars whatsoever. With bars, it's merely maximised at best. I consider it false what happens by F11 in Evince.

My main gripe with the new GUI is that they broke standard interface conventions like Alt+F, which I would expect to open the filehamburger menu. Note that Microsoft's less usable ribbon menu took very explicit pains to preserve this rather important aspect of the interface.

Only if your interface is English. I wouldn't consider Alt+F a standard convention when even F11 isn't. In Libreoffice (and presumably in MS Word too), F11 does something totally useless and you have to do Ctrl+Shift+j instead. Luckily it says so in the menus.

I like the way I can navigate menus in Elinks for example. Esc to bring up the menubar and the rest can be done by arrow keys. Esc or Tab, whatever else it does in the interface, should land on menubar too and arrow keys should open and navigate the menus, as a standard convention. You would perhaps say that arrow keys take forever, but that's only until you become proficient in keyboard shortcuts. Menus are good for, among other things, as a beginner's reference guide to keybinds. Menu items without references to the corresponding keybinds are a major fail in the startup information value of a graphical app interface. Once you're pro with the keybinds for most actions you need to do, Alt+F should be unnecessary.

My habit is to study and navigate the menus only when I am not familiar with the app. When the app is likeable enough so that I open it habitually and it becomes familiar to me, I open the menus only if I forgot a keybind or I need to do something new.

Extra vertical space? Fullscreen to me means no bars whatsoever. With bars, it's merely maximised at best. I consider it false what happens by F11 in Evince.

There's something to that I suppose, although I have to say that having some controls at hand can be quite useful. Actually I would argue that in a decent window manager (i.e., pretty much anything but Windows ) the answer's obvious: what you call fake full screen is already available in Xfce under Alt+F11, whereas the F11 implemented by the app in question could go for real full screen. Or maybe real full screen should be under something like Ctrl+F11.

Only if your interface is English. I wouldn't consider Alt+F a standard convention when even F11 isn't. [...] Luckily it says so in the menus.

In Dutch I would expect it to be Alt+B, not Alt+F. The specific key is besides the point, which is that I expect those icons to respond to the same keys they always have since the 1980s if not earlier. In English, "File options" (hamburger) is Alt+F, "View options" (document with wrench) is Alt+V, and so on. In Evince you can't even press left and right to switch between the button menus! The (acceptable!) cop-out I first encountered in some Microsoft programs, but later also in Firefox, is that the actual menu is still there and it just pops out when you press the relevant keyboard binding like Alt+F, Alt+T, etc. Because frankly Alt+T, D is a lot easier to remember than Ctrl+Shift+Y.

Opera/Blink responds to Alt+F, but it feels slightly less elegant in that it only responds to that (nor does it properly underline the access keys). So you have to press Alt+F, v, d for developer tools, which may or may not be easier than Ctrl+Shift+i depending on where your hands are.

Now admittedly this isn't universal in the sense that Apple does something different, but this is universal on MS-DOS (at least in Microsoft programs), Windows, old GNOME, KDE, Xfce, etc.

Your last sentence is also of particular interest. In the menu-wielding Evince in Xubuntu, keyboard bindings are indicated in the menus. The vanilla Evince in Debian does no such thing. This explains why I didn't know about Ctrl+N earlier. It does have a little keyboard shortcut help dialog available (also in menu-Evince, either under the help menu or with Ctrl+F1) but you don't come across those organically. Incidentally, Ctrl+F1 is not mentioned in the keyboard shortcut window. This means that in vanilla Evince, this binding is a complete secret.

I like the way I can navigate menus in Elinks for example. Esc to bring up the menubar and the rest can be done by arrow keys. Esc or Tab, whatever else it does in the interface, should land on menubar too and arrow keys should open and navigate the menus, as a standard convention.

While it would be rather annoying to do something like that (because is Esc better than Alt+F or just different?), it would be a more interesting thing to try than breaking all keyboard menu accessibility in the name of touch.

Once you're pro with the keybinds for most actions you need to do, Alt+F should be unnecessary.

Except they are keybindings for all intents and purposes. Sure, the most frequently used actions tend to have slightly faster or more convenient alternatives, but for something with a lot of menu options like Word or Writer the menu is the keybinding. You don't press Alt+whatever, obstinately look at the menu, and press the next key. Arrow keys or the mouse would likely have a very similar result. No, what you do is you press the keyboard combination of Alt+s, m. Like this:

https://vimeo.com/200643905

You could create your own keybindings where the defaults are lacking. But I try to avoid going down my old Opera road.

It was bad enough that I somehow managed to break the glass of my 8" ereader. I assumed that another Pocketbook would be the quickest possible replacement, but Koreader simply doesn't install on Touch HD. This is my third ereader now and it looks like me + ereader is simply not meant to be, even though I have invested enormously trying to cultivate the relationship over a year now.

Aside from other minor bugs, there are two big flaws in Pocketbook ereaders from my perspective:

- No way to search/sort by file name
- No inverted colours (night mode)

Eink screens are very nice to look at, but overall this is, as I originally suspected, the only thing they are good for. Touching an eink screen is generally an icky and yucky experience. Ereader industry in general has learned absolutely nothing from the successes of mobile phones and tablets. Ereader devices are fragile and clunky to use. Obvious features are missing, such as search/sort by file name, power an external monitor or serve as an external screen to other devices. Or have a real OS, such as Android.

There are exceptions in every category. It's possible (sometimes) to install external reader apps that search by file name. There is one single producer who does eink monitors and one or two producers that provide ereaders with Android. The last one is something I should have gotten this time, I guess, but I know the Android there is deliberately crippled, as if Android on its own were not crippled enough.

Mobile phones and tablets have become increasingly durable and functional. Their touchscreen is responsive and intuitive (even though I like the historical first solution - touching with fingernail - better than the prevalent flatside touch). With some of them you could make a phonecall under water. They are rich with important features, such as power an external monitor, and Android ecosystem is almost limitless.

Ereaders are hopelessly behind. Why hasn't anyone thought of making normal laptops with at least a 13" eink screen? It would not even be innovative in any sense, so what's the difficulty?

It would not even be innovative in any sense, so what's the difficulty?

Not putting oversaturated monitors all over stores wouldn't be innovative either, but I guess they're just too afraid of colors not popping. Anything that takes a longer time to appreciate is a hard sell, I guess.

Now this is actually useful as a display device both for individual use and small class situation, not just as a personal reader https://youtu.be/Tu03JY7PXMo?t=525

I assume the price will be significantly more than I'm willing to spend, but hopefully it'll pave the way through richer people the way Apple paved the way for finally improving resolution again.

@Frenzie

Can you describe how you read multi-column pdfs in Koreader? From the overview mode (if that's what it's called) it's possible to go to a selected column, but how do you scroll down from it? By dragging? And when at the bottom of the page, what next?

EBookDroid implements something pretty awesome. It splits pages when it detects that the pages throughout the file consist of two blocks and arranges the result as a single long scroll. This however doesn't work when there is a page somewhere with something different, say a title at the beginning of the file or a whole-page graph or illustration in the middle.

Which is why Pocketbook's implementation is the best. In Pocketbook's reader, you can set it to zoom in to a half (called 2-column view) page or to a third (called 3-column view) of the page (would be nice to have 4 or 5 two, why not any number?). The zoom is simple mechanical regardless of the content of the page and may not properly find the column you are looking for, but then you can drag the page in whichever direction a bit to fix this. And from there, Next and Previous keys scroll down/up and when at the bottom/top of the page, they move to the logically following unread part of the page/file.

I understand that a similar function in Koreader would perhaps conflict with Scroll mode. (Scroll mode does not exist in Pocketbook.) A relevant comment is here https://github.com/koreader/koreader/issues/501#issuecomment-270099303

Sorry, that's not really a problem I've come across.

Really? You don't have

- articles in pdf format specifically layouted for print in two-column publications
- books where both face-to-face pages have been photocopied/xeroxed at the same time
- photocopies of ancient huge newspaper pages up to seven columns



Those are regular instances where I need to zoom in to a corner of the pdf image and then find a way to sensibly navigate from there. Pocketbook makes it easiest. EBookdroid on Android makes it quite tolerable. Other people mention other tools somewhat up to the task.

Edit: Isn't there something like arbitrary zoom then? Say, zoom in to the page whatever percent, perhaps best implemented the same way as Go to page dialog? Pocketbook has some sort of slider for this, but it would be better as a type-in dialog slot for any arbitrary number.

- articles in pdf format specifically laid out for print in two-column publications

There I just go up and down a little bit more than usual. KOReader also has built-in K2pdfopt for reflow. Although I'd run programs like that on my computer if at all possible because it's much faster than the slow CPU on a mobile device. However, on academic articles I tend to want to make notes and underline and whatnot and paper is really the only thing that works. PDF annotations and highlights are meh, only good for minor to possibly medium engagement. I tried Xournal for a day or two and it just felt kind of awkward. Maybe one of those Microsoft Surface things would be good, maybe paper is still the only thing. I certainly don't want to spend €800+ to find out when paper's doing a great job.

- books where both face-to-face pages have been photocopied/xeroxed at the same time

I would preprocess those with unpaper or scantailor if I wanted to read them on a smaller-screen device.

- photocopies of ancient huge newspaper pages up to seven columns

Not really. I mean, I look at newspaper archives occasionally (and it's great that it's mostly digital now) but nothing that'd make me want to load it onto my ereader. K2pdfopt should probably do the trick though.

Edit: Isn't there something like arbitrary zoom then? Say, zoom in to the page whatever percent, perhaps best implemented the same way as Go to page dialog? Pocketbook has some sort of slider for this, but it would be better as a type-in dialog slot for any arbitrary number.

Not sure, sounds like a decent enough idea. Have you tried using manual page crop for your use case?

KOReader also has built-in K2pdfopt for reflow.

Reflowing is out of the question with most technical articles (those that contain diagrams, tables, etc.). Not to mention photocopies. Oops, I just mentioned them.

However, on academic articles I tend to want to make notes and underline and whatnot and paper is really the only thing that works. PDF annotations and highlights are meh, only good for minor to possibly medium engagement. I tried Xournal for a day or two and it just felt kind of awkward.

Pocketbook's annotation tool is pretty decent, just enough for bookmarking the keywords so that it's easy to find them when you need those references later for your own work. Annotations on paper are harder for me because I'd have to retype stuff, whereas in computer it's often just link and copy-paste. For that of course I must do my best to keep stuff in sync on the e-reader and in computer.

It would be fabulous if there were a Pocketbook or Koreader app for computer such that you connect the computer app to the settings/cache on the e-reader and then all your annotations, history of files and last-opened pages are at your fingertips.

I certainly don't want to spend €800+ to find out when paper's doing a great job.

You must mean that you print a lot. Because if you had to buy all those publications on paper for annotation, you would bust €800+ in no time.

Edit: Isn't there something like arbitrary zoom then? Say, zoom in to the page whatever percent, perhaps best implemented the same way as Go to page dialog? Pocketbook has some sort of slider for this, but it would be better as a type-in dialog slot for any arbitrary number.

Not sure, sounds like a decent enough idea. Have you tried using manual page crop for your use case?

You mean: First crop one half of the page and stare at it. Then get out of it, crop manually the other half of the page and stare at it. Repeat for each page.

Yes, I've done it. I prefer the way Pocketbook works. The only serious thing missing in Pocketbook is night mode (invert colors). Scroll mode is missing too, but that's not too essential. Whereas zooming into a pdf and dragging it around is almost as smooth as EBookDroid on the phone. An important detail though: Pocketbook's zoom is limited to 300% (of the original page/text-to-screenwidth) while EBookDroid seems unlimited.

How does Kobo work in this area?

Edit: It's important to note that (arbitrary) zoom for Koreader is worth implementing only if drag-a-bit-to-any-direction is implemented at the same time. Because an arbitrary zoom that focuses to the upper left corner by default will not find the necessary column at first (why would it when it's arbitrary?!) and there's usually a need to justify it manually a bit.

On a similar note, Koreader's tap-to-a-block in Overview mode, even though it's cool and nice to have feature, is severely limited by the fact that after zooming to the block it doesn't do Next (downwards) and Previous (upwards) naturally. It would dissolve pretty much all complaints if Next and Previous worked naturally in this mode.

And actually I got a different idea now. There should be a sort of manual crop that doesn't forget the area that was cropped out. Instead, it should be something like partition: Just like in cropping, the user can draw arbitrary vertical lines over the page between the columns/blocks/elements on the page and then Koreader just reads between those lines in order. Except that it's not a single rectangle like in cropping. It's as many lines as needed to divide up the elements as many as they are on the page. -- Another edit: It could be Crop and then you can draw as many vertical lines as you want to partition the cropped area. Perhaps makes best sense this way.

Not a problem with Koreader, I guess, but with the formatting of the pdf file: The progress bar fails to display progress. Not a big problem, because the page counter still works. The pdf file in question.

The problem lies in the chapter markers. For some reason the "odalszámok" entry in the TOC (something about numbers?) includes a reference to every single page in the book, meaning every page has a TOC marker on the progress bar so that the entire thing is colored in.

Here's a quick fix, but note that you should be able to do the same thing with pdfmod in a GUI:

Code: [Select]

# dump the metadata to a file called info
pdftk ActaOrientalia_41.pdf dump_data output info
# delete lines 221 through 2359 and save the result in a file called info.tmp
sed -e '221,2359d' info > info.tmp
# create a new PDF with the updated PDF metadata from info.tmp
pdftk ActaOrientalia_41.pdf update_info info.tmp output ActaOrientalia_41_fixed_toc.pdf

It's possible that something should be fixed on KOReader's end as well to prevent this situation from occurring, but in this case that would mean displaying only the top-level TOC markers, thereby significantly reducing their utility.

After you've done that, you could also consider:

Code: [Select]

# -j0 automatically selects the number of threads
pdf2djvu -j0 ActaOrientalia_41_fixed_toc.pdf > ActaOrientalia_41_fixed_toc.djvu

It'll take a while and it could potentially introduce a certain degree quality degradation, but the result will generally handle much better for reading. [Edit: in this case the result is somewhat disappointing, at least using the default settings -- except for the fact that the resulting file is a mere 58.3 MB.)

PS Also see https://github.com/edouard-lopez/pdf2djvu-ocr which could be interesting to run some OCR to boot. Of course just running pdfsandwich and pdf2djvu manually isn't that big of a deal but the less you have to do the better.