Eink friendly feature requests

[gerroon]

Hello

The recent wallabag app is great and it is so much better than the previous version.

I am using it on my android eink device. It is all good however these areas might help even further

• page down/up button support (implementation: an option to scroll by pressing on screen sides)
• on screen font sizing option (they are undert a menu atm)
• bold font support
• better and sharper font display for eink devices (maybe render them as black as possible?)
• detect more e-ink-based devices
• allow to disable animations (opening hamburger menu, etc.)
• disable smooth scrolling by default for e-ink readers?
• enable tap-to-scroll by default for e-ink readers?

thanks

[di72nn]

Hello,
Thank you for the suggestions.

page down/up button support

Can you give some examples of the apps that support physical buttons (preferably open source apps)?

better and sharper font display

Did you try "Light (high contrast)" theme? It uses black color for fonts.

[Continuation of #60].

[gerroon]

@di72nn

Hi

The page up/down buttons can be on screen or can utllize the volume buttons etc for paging. You can check Document Viewer for Android.

I am already using the contrast theme. It improves the look but I find it to be still a bit faint as far as the font rendering goes.

thanks

[grote]

Hi, I also have an Android based E-Book Reader where I can install wallabag on. It would be awesome to be able to read stuff from wallabag on an E-Ink Screen.

Basically, the problem with E-Ink is that it does not do scrolling well. Refreshing the screen takes much more time than on other displays. That is why @gerroon asked for paging with buttons.

[silberzwiebel]

I also have an android based e-reader (inkbook prime) and would like to read my wallabag articles with it.
The inkbook prime has four physical buttons (two on each side) that turn the page up or down. Using these buttons scrolls e.g. the app list in f-droid. I presume they send a code similar PageUp/Down on a PC keyboard? However, they do not work in the wallabag app. I could configure to scroll with the volume up/down buttons but this conflicts with other apps.
So, could you add support for this type of buttons, also? That would be great!

[di72nn]

@silberzwiebel F-Droid app doesn't seem to use anything specific to handle keys (at least the new versions with fancy UI). Do your buttons do anything in wallabag at all? Can you use something like KeyEvent Display to gather some info? (Use proprietary apps at your own risk).

[silberzwiebel]

Do your buttons do anything in wallabag at all?

The first button press in the article mode "selects" the software button on the top left with the arrow that points to the left. If I touch this software button via the touchscreen, I get back to the article list. Pressing the hardware buttons, however, does only once "select" the software button (it is "highlighted", hard to say on a e-ink display), but no action is happening. Subsequent button presses do nothing, no visual feedback either.

Can you use something like KeyEvent Display to gather some info?

Please find some output here. Happy to provide more information.

[di72nn]

Thanks for the info. Your next/prev buttons generate KEYCODE_PAGE_DOWN and KEYCODE_PAGE_UP KeyEvents. The third button generates KEYCODE_CAMERA keyevent.

#620 implements scrolling with PAGE_UP/PAGE_DOWN.

You can create a separate issue regarding the extra hotkeys to disable touch screen.

[anarcat]

i've opened #862 regarding the flickering i see in e-ink readers, since that wasn't listed here, but it's obviously related. :)

thanks for the "page" scroll feature, it's real nice!

[di72nn]

I'm thinking maybe we should add a dialog at first start (if it was detected that the device is an e-reader) going something like this: "It seems you have an e-reader. Would you like to enable e-reader friendly features? Yes/No". Maybe even show a list of features with checkboxes.

The features being:

• e-ink theme,
• tap-to-scroll,
• disable smooth scrolling.

Better ideas?

I mean, the app is primarily oriented towards reading so I guess e-readers should get more attention.

[anarcat]

another feature i would like to see, is "last page should be a real page". it's kind of hard to explain, but when you flip pages, in a book, the last page often has a blank space at the bottom. but when you flip pages, in the wallabag app, the last page isn't really a page. you just "scroll up" and you need to "find" the place you were at before you flipped the page.

e-readers do not work like this, normally: they format each page individually and do the right thing at the end of a chapter or document, and scroll the top of the screen to the "end" of the previous page. wallabag doesn't do that correctly right now and it's quite confusing. :)

[silberzwiebel]

Yes, @anarcat, I'm missing this feature since yearsm too -- but I'm to lazy to implement it. Would love to see it implemented! I think it should be fixed in this function by somehow adding enough whitespace at the end of an article:

android-app/app/src/main/java/fr/gaulupeau/apps/Poche/ui/ReadArticleActivity.java

Line 1100 in 4db7805

private void scroll(boolean up, float percent, boolean smooth, boolean keyUsed) {

[di72nn]

I think it would take "real" pagination (i.e. split content into pages and show the pages separately) to implement it properly. I also think this would require better content awareness, which doesn't seem to be implemented anytime soon.

As a simplest workaround, some kind of spacer can be added at the end of the article (about the height of the screen), so the article is scrollable past its end. That's a really dumb solution, but IMO it beats waiting for a perfect solution that may never come.

Edit:
Forgot to say what I actually wanted to say:
I'm not sure if adding extra space in scroll(...) is a good idea (it may be though), because it would dynamically change article length and maybe affect something else. Also determining the height of spacer to add may be tricky. I would start with an option (buried in misc) to add a spacer of a fixed height to all articles.

[Strubbl]

Maybe we can use CSS to force a page break, this needs to be tested.

CSS:

    .pagebreak {
        clear: both;
        page-break-after: always;
    }

Append some HTML to the end of the article:
<div class="pagebreak"> </div>

[The-Compiler]

@Strubbl I tested that, but I don't see any difference. Here's what I did:

diff --git app/src/main/assets/main.css app/src/main/assets/main.css
index 7d9a0b8..7f93292 100755
--- app/src/main/assets/main.css
+++ app/src/main/assets/main.css
@@ -246,6 +251,11 @@ header.mbm {
   content: none;
 }
 
+.pagebreak {
+    clear: both;
+    page-break-after: always;
+}
+
 /* ==========================================================================
    6 = Media Queries
    ========================================================================== */
diff --git app/src/main/res/raw/webview_htmlbase.html app/src/main/res/raw/webview_htmlbase.html
index f1f11c6..d705fa5 100644
--- app/src/main/res/raw/webview_htmlbase.html
+++ app/src/main/res/raw/webview_htmlbase.html
@@ -18,6 +18,7 @@
                                        <article>
                                                %7$s
                                        </article>
+                                       <div class="pagebreak"> </div>
                                </div>
                        </div>
                </body>

Also my main issue with using Wallabag on an e-ink device is that I can't tell apart links from other text as both are rendered as black. I fixed this like this:

diff --git app/src/main/assets/main.css app/src/main/assets/main.css
index 7d9a0b8..7f93292 100755
--- app/src/main/assets/main.css
+++ app/src/main/assets/main.css
@@ -74,6 +74,11 @@ a {
   text-decoration: none;
 }
 
+.high-contrast a {
+  color: #000;
+  text-decoration: underline;
+}
+
 a:hover, a:focus {
   text-decoration: none;
 }

however, that underlines links (and displays them black) with the "light (high contrast)" theme as well - but maybe that's a good thing?

[di72nn]

I tried adding <div style="height: 100vh;"></div>, but 100vh didn't work. Hardcoded px values do work. I don't know HTML/CSS well enough to suggest a proper solution.

Also my main issue with using Wallabag on an e-ink device is that I can't tell apart links from other text as both are rendered as black

This should definitely be corrected.

// dev note: we probably need a separate CSS file for the "e-ink" theme. How do you achieve code-reuse in CSS?

[The-Compiler]

// dev note: we probably need a separate CSS file for the "e-ink" theme. How do you achieve code-reuse in CSS?

Using something like a .e-ink or .monochrome CSS class instead of .weighted-font would be enough IMHO - there's just a handful of properties you'd need to override from the default theme.

[The-Compiler]

Anyone else having problems telling apart links and text on their devices? At least for my Onyx Boox Nova Pro, it looks like the device injects a { color: #000000 !important } style (and also * { font-weight:900 !important } which is quite infuriating...). Because the Wallabag stylesheet adds text-decoration: none, there's no way to tell apart links and "normal" text. Thus, I re-added the underline (and made the text black) for the "high contrast" theme in #885. I also made sure the e-Ink theme is used automatically for Onyx devices in #886.

[anarcat]

Anyone else having problems telling apart links and text on their devices?

Yes, i see the same thing. In fact, the links display correctly at first then "flash" away when something loads, presumably some CSS file... Quite infuriating. :)

Then again it's kind of neat that we're not distracted by links while reading!

[The-Compiler]

So I found a way to undo Onyx' stupid styling:

document.addEventListener("DOMContentLoaded", function(event) {
	const observer = new MutationObserver(function(mutations) {
		const node = mutations[0].addedNodes[0];
		if (node && node.nodeName === "STYLE") {
			node.remove();
			observer.disconnect();
		}
	});
	observer.observe(document.head, {childList: true});
});

I feel dirty after writing this, but I guess their insane style-tag is still worse than my workaround:

before:

after:

Is this something that'd be accepted (if I add a proper setting, turned off by default)? It's a hack, but hey, it works!

[di72nn]

Fine with me.