new firmware 5.19.656: eink-reader crashes?

[EastEriq]

I've updated my Touch HD to the last firmware a few days ago, and am surprised to find that various of my epubs crash the builtin reader. I cannot pinpoint the very latest firmware, but to the best of my memory, I had no earlier problem with those particular ones. And the release notes spell "Fixed: 1. Inability to open some EPUB books" - which sounds suspicious...
It may well be my device, but I note that I have still 2.5GB free on /ext1, ad that a factory reset did not help (it trashed all my neat added apps and dictionaries, though... )

Could someone test some of these epubs on their devices with older or newest FW and report?

https://www.gutenberg.org/ebooks/48913
https://www.gutenberg.org/ebooks/44549
https://www.gutenberg.org/ebooks/53768

Choose epub with images please. Try to navigate to some page in the middle of the book. To me, that simply quits the reader. Each book seems to have a point beyond which the reader gives up. Coolreader instead copes with them normally.

Those books are produced with the PG toolchain, which should be a guarantee of sanity. I actually coded them and have had fine control on the html. They are medium sized, but no way monsters. Understanding what's wrong may provide feedback to PB, or help me produce better books for PG.

Thanks, Enrico

[patrik]

Tried the first book (with images) on my Inkpad 3, 5.19.660. Just opening it and doing nothing (it calculates the pages in the background) triggers an error and the book quits.

But running epubcheck on it screams with multiple errors... so before you fix those I wouldn't blame the software.

[EastEriq]

Good catch and thanks for trying (and confirming the problem). BUT. I haven't used epubcheck so far in my workflow, and I think within reason. What I produce for PG is strictly validated XHTML, which is then compiled into epubs by PG's internal software. Now, carefully inspecting some PG epubs, I find that the "multiple epubcheck errors" boil down to a systematic addition, by PG's epubmaker/ebookmaker of an uncontemplated (according e.g. to https://www.w3schools.com/tags/tag_a.asp) "tag" attribute inside <link> and <a> html tags. Like

<a href="@public@vhost@g@gutenberg@html@files@48913@48913-h@48913-h-5.htm.html#nota_25" class="fnanchor pginternal" tag="{http://www.w3.org/1999/xhtml}a">

I doubt that this is the reason for the crash. I found several PG counterexamples with the same attribute (if it is routinely added by the production software on PG thousands of books, then it should not be a problem) which do not seem to crash on my HD. e.g.:
https://www.gutenberg.org/ebooks/44067
https://www.gutenberg.org/ebooks/45037
https://www.gutenberg.org/ebooks/49079
https://www.gutenberg.org/ebooks/44019

[patrik]

I didn't really check all errors (since there were many), but I did try "fix all errors" within the Calibre editor (which removed invalid characters, and probably more), but no change on the ereader.

You can try an epub-to-epub conversion in Calibre. It seems to fix many things.

You could also post in the epub-forum here on Mobileread. There are many very experienced people that probably can help you out.

FWIW, I don't think the software should just quit, if the epub is out of spec, give that information, and then quit.

[EastEriq]

yes but, the question here is not "who can help me fixing thousands of PG epubs", it is "is there an eink-reader bug with the latest pocketbook FW, or it is just me".

[patrik]

Well, as I seem to have the same "problem", it is probably in all current versions of the pocketbook firmware.

But, if what they changed made it more strict regards to what it tolerates for out of spec, it's not really a bug is it?

And if the epub is out of spec, is probably something the people around the epub-forum can help with, I'm guessing. Many of them have used PG as a source for epubs they edited and added to our library here.

But it may also be a bug of course, but to find out, I think we really need to know if the epub is within spec or not.

[EastEriq]

As I'm rather of the "bug in new FW" persuasion, I sent an email to the support. I'll post if I get feedback. In principle, FW releases back to 5.17.1409 are available on the support site and I could try downgrading, but I'm really not going into it. I'd be happy if someone who still has an older FW could have a look and report.

[EastEriq]

I think I'm getting where the problem is. I'd still call it a bug of the newest eink-reader, which is why I'm adding more information here. I hope that some other PB owner can test this, and that I can point the PB support to this info.
So, in my PG books I use often this construct for footnote return anchors:

<div class="footnote"><a id="Footnote_1"></a>
<p class="foot"><a href="#FNanchor_1"><span class="label">(1)</span></a>
....
</p>

and I style it with css like:

.footnote .label { padding-right: 0.5ex; min-width: 4ex; margin: auto;}

Now, ebookmaker, the software which produces epubs at PG from posted html, adds, probably in error, this tag attribute inside <a>. It appears that the combination of my css line for the label class inside a footnote container, plus the tag addition, is fatal for eink-reader.
As a proof, I attach here three small epubs produced this way. 10001 which has both the css and the anchor crashes, 10007 and 10010 which have only one of them not.

[gluejar]

Hi!

PG has asked me to look at this. The ebookmaker program has a Github repo: https://github.com/gutenbergtools/ebookmaker I have created an issue there: https://github.com/gutenbergtools/ebookmaker/issues/2

Could you please try the epub at https://github.com/GITenberg/Progett...53768/releases and tell me whether of not it has the same problem?

Thanks!

Eric

[patrik]

Same problem with that epub on my Inkpad 3, 5.19.660. Just opening it and doing nothing triggers an error and the book quits.

[Cinekk]

I can confirm this problem on my HD3 (v.5.19.673).

[EastEriq]

Originally Posted by gluejar

Could you please try the epub at https://github.com/GITenberg/Progett...53768/releases and tell me whether of not it has the same problem?

On my PB631, I cannot go past page 77/684, however the pagination is computed. Epubcheck still lists a few errors, possibly irrelevant, but looking into the code I see that the offending tag=".." has been removed; so my theory about <a tag=""><span></span></a> is probably off mark. The page beyond which I can't go falls within 53768-h-1.htm.html which is the first subfile with footnotes, though.
No reply from PB-support yet.

[gluejar]

Could it be a bug in handling the css unit "ex"?

Originally Posted by EastEriq

On my PB631, I cannot go past page 77/684, however the pagination is computed. Epubcheck still lists a few errors, possibly irrelevant, but looking into the code I see that the offending tag=".." has been removed; so my theory about <a tag=""><span></span></a> is probably off mark. The page beyond which I can't go falls within 53768-h-1.htm.html which is the first subfile with footnotes, though.
No reply from PB-support yet.

[patrik]

I tested the githup-epub and changed all ex-units to em. No difference.

[gluejar]

Originally Posted by patrik

I tested the githup-epub and changed all ex-units to em. No difference.

Thanks! I'm stumped, unless there's an issue with an italian localization in the reader. The HTML for these books is clean.