Koreader running on Kobos (all of them, hopefully!)

[Alan_S]

Yes, magnetic cover could be culprit here, or at least one of the culprits.

But, I also noticed that using magnetic cover doesn't always lead to higher battery drain. And, also, if device exits suspend, it doesn't do it in regular way as light stays off. In normal exit light should be on after waking device.

Magnetic senzor should be always on, even in suspend, but maybe code that monitors it, or the way koreader communicates with it is culprit?

Just guessing...

EDIT: And I asked about having option to use or not magnetic cover in github: https://github.com/koreader/koreader/issues/1733

EDIT2:

I'm looking at this code for operating magnetic cover:

if keycode == "Power_SleepCover" then
if ev.value == EVENT_VALUE_KEY_PRESS then
return "Suspend"
else
return "Resume"
end
end

Does this can mean that if device is suspended with power button (so, it is already in suspend) and after that comes signal from magnetic cover, device can think that it was resumed? In a way, code could be interpreted this way.

[NiLuJe]

@Alan_S:

If the sensor hasn't changed behavior since whomever wrote that piece of code tested it, the intended behavior is:

Sleep Cover is closed -> PRESS event -> SUSPEND
Sleep Cover is opened -> RELEASE event -> RESUME

The general power handling code has guards against double-suspend/double-wakeup attempts, so closing the cover after flicking the power button shouldn't have any impact.

Opening the cover should, however, wake the device up, no matter how it was put to sleep.


TL;DR: Unless you see spurious RELEASE events coming from the sensor, the device shouldn't wake-up from the sleep cover.


EDIT: On the other hand, doing it the other way around, i.e., closing the sleep cover and *THEN* flicking the power switch, that *WILL* cancel the suspend, if you do that in the ~10s window before the device is actually put to sleep.

EDIT²: With debug logging enabled, any of these events will be logged ("Suspending..." or "Resuming...").

[Alan_S]

It's a good news that reader differentiate between closing and opening magnetic cover. Probably by changing strength of magnetic field.

[Alan_S]

Originally Posted by Alan_S

Now I'm testing suspending with CoolReader suspend script and see what happens.

I know this isn't "final verdict" on CoolReader's suspend script, but from time of writing this post (5.12 till today) battery stays at 100%. Reading habit is as described (about one to two hours of reading in one block, other time reader is suspended till next day).

It certainly looks like CR's suspend script really suspends reader and that there's no battery leak at all.

I'll continue testing it and report.

[Khiron]

hi, how i can change font?

[Ken Maltby]

Originally Posted by Khiron

hi, how i can change font?

1. Poke the top of the screen.

2. Poke the second tab/icon.

3. Poke "Change font.

Luck;
Ken

[anton79ru]

Okay, I think I have read through the related posts here but it really lead me nowhere. I installed Koreader on two devices recently:
- Glo HD;
- Aura H2O.

The two-finger swipe gesture works on the Glo HD, but not on the Aura H2O. When I try it on the Aura H2O, all it does is select text and/or turn the page, just as if the multitouch were not supported in the first place. I'm not aware of the hardware differences or the stock software functioning of the two devices but since I decided to stick with the H2O, is there any way I can circumvent or simulate multitouch? Otherwise I have to go to menu and input a number value for brightness, which feels pretty much like stone age.

[Ken Maltby]

Actually, I am surprised to hear that multitouch might be working on your Glo HD.

I though that only the 6" Aura, with its capacitance touchscreen, had it working.

Luck;
Ken

[anton79ru]

Originally Posted by Ken Maltby

I am surprised to hear that multitouch might be working on your Glo HD.

I forgot it hadn't worked on my Aura HD, that's why I wasn't surprised. But now what you're saying makes me think the Glo HD might well be the first device on which they implemented IR multitouch.

[anton79ru]

One more please, if you don't mind me drinking from the pool of your wisdom again. Why might Koreader suddenly ignore a CSS rule for one paragraph of a Calibre-edited epub, but not others? Like, there's a bunch of paragraphs of the same class, and there's that "text-align: justify;" rule for that style, but in one of the paragraph the text is left-aligned and in the next one it's good again although they're labeled with identical styles.

[Ken Maltby]

While you can tell KOReader to ignore embedded CSS and can even remove the embedded styles' I don't see how it could be selective about it. To be that selective it would have to be defined at the paragraph itself. One other consideration would be if there were any tags to make a formatting statement !important or default, and give it overriding capability, over the normal CSS statements.

Luck;
Ken

[anton79ru]

Originally Posted by Ken Maltby

I don't see how it could be selective about it.

Thanks for trying to help, Ken, I don't get it either. It's two similar paragraphs, one after another, both refer to the same style, which contains a rule for the text to be justified. In one of the paragraph, this rule is ignored, and the text is left-aligned. What's interesting, another rule of the same style that says "text-indent: 1em;" is respected in both paragraphs. I changed the alignment rule to "text-align=justify !important;" but nothing happened.

[anton79ru]

I think I located that one. Compared to good paragraphs, problematic paragraphs contain more than a class/style indication. They go like:

<p class="txt"><dfn class="calibre3"><a id="pg_55"></a>La première fois que je suis entré au dépôt remonte à deux ans.

or

<h1 id="calibre_toc_2" class="calibre10"><a id="TOC_idp29967616"></a><a id="TOC_idp29967760"></a>RACHEL

Once I removed the <a> tag in the first case and moved RACHEL before the <a> tag in the second case, the text alignment rule was respected. The <a> tag before the text breaks some style rules for some reason.

[Ken Maltby]

The <a> Something ...</a> is supposed to be for links. Scroll down to the Bookmark section.

In your first example a link to page 55. In the second a TOC link of some kind.

Luck,
Ken

[anton79ru]

Originally Posted by Ken Maltby

The <a> Something ...</a> is supposed to be for links

In my examples, those were not links, but anchored locations where links brought you. Destinations. But that doesn't matter much.

Here's what happens: if in a paragraph of a *.epub file, there is an <a>nchor after the indication of style and class, but before the main text starts, Koreader screws up text alignment in that paragraph. A centered, justified or right-aligned paragraph becomes left-aligned.

I reproduced that by opening a book that had no problem of that kind and I inserted an empty anchor <a></a> right in front of the main text, after the paragraph indicator — and text alignment crashed.