Known bugs in ADE

[SBT]

Originally Posted by Doitsu

AFAIK, most new ADE4 features only work with ePub3 files. I.e., you'll have to code your ePub file as an ePub3 file to take advantage of the new ADE4 features.

I've created a simple test file with Sigil 0.8.4, converted it with the optional Sigil ePub3 plugin and both nowrap and the solid border top styles seem to work with ADE4.

Thanks for testing, Doitsu. Still, the odd thing is that this is an EPUB2 document which works in ADE2, but not in ADE4. The text inside the "nowrap" environment is a sequence of <span>-tags, but it does not include any explicit whitespace.

[JSWolf]

Originally Posted by SBT

Thanks for testing, Doitsu. Still, the odd thing is that this is an EPUB2 document which works in ADE2, but not in ADE4. The text inside the "nowrap" environment is a sequence of <span>-tags, but it does not include any explicit whitespace.

Check if what you are doing is valid in ePub 3 or if it's changed. That could be why it doesn't work as expected with ADE 4.

[dgatwood]

Originally Posted by SBT

Thanks for testing, Doitsu. Still, the odd thing is that this is an EPUB2 document which works in ADE2, but not in ADE4. The text inside the "nowrap" environment is a sequence of <span>-tags, but it does not include any explicit whitespace.

Breaking at spaceless tag boundaries is a known ADE bug, IIRC. You might try adding  (a zero-width nonbreaking space) between the span tags and see if that helps.

[MacEachaidh]

I'm using ADE 2.0, and encountering the issue of an uncoded page break if the html file in an epub exceeds 200K (or thereabouts -- I'm not sure of the exact length that triggers it).

Other than reformatting the file and breaking it anyway (which I don't really want to do if I can avoid it), is there any kind of fix for this? Has it been addressed in more recent versions of ADE?

[DaleDe]

Originally Posted by MacEachaidh

I'm using ADE 2.0, and encountering the issue of an uncoded page break if the html file in an epub exceeds 200K (or thereabouts -- I'm not sure of the exact length that triggers it).

Other than reformatting the file and breaking it anyway (which I don't really want to do if I can avoid it), is there any kind of fix for this? Has it been addressed in more recent versions of ADE?

ADE has always done this. There is no way to prevent this that I know of. It is designed to avoid loading excessively long files.

Dale

[MacEachaidh]

Thanks Dale.

Yes, I thought it was a fairly long-standing, ermm, behaviour -- I just rarely encounter it, because I always give chapters their own file.

It's just that the book I'm formatting is divided into four major sections, with no subdivisions (chapters or the like) within each section. I could force a break in the coding, but there's no logical place to do it, so the end result would be no different from what ADE is already doing. (Well, a slight difference: I could choose where it breaks that way, but the disruption to the formatting would be essentially the same.)

I understand the need to contain file sizes within an epub, but is 200K really that much of a worry?

[JSWolf]

Originally Posted by MacEachaidh

Thanks Dale.

Yes, I thought it was a fairly long-standing, ermm, behaviour -- I just rarely encounter it, because I always give chapters their own file.

It's just that the book I'm formatting is divided into four major sections, with no subdivisions (chapters or the like) within each section. I could force a break in the coding, but there's no logical place to do it, so the end result would be no different from what ADE is already doing. (Well, a slight difference: I could choose where it breaks that way, but the disruption to the formatting would be essentially the same.)

I understand the need to contain file sizes within an epub, but is 200K really that much of a worry?

It is something you do need to deal with if you plan on publishing this and it's not just something for yourself. Older devices that use an older version of RMDSK do need to have the sections divided and if you don't, they won't be able to read your book.

[DaleDe]

Originally Posted by MacEachaidh

Thanks Dale.

Yes, I thought it was a fairly long-standing, ermm, behaviour -- I just rarely encounter it, because I always give chapters their own file.

It's just that the book I'm formatting is divided into four major sections, with no subdivisions (chapters or the like) within each section. I could force a break in the coding, but there's no logical place to do it, so the end result would be no different from what ADE is already doing. (Well, a slight difference: I could choose where it breaks that way, but the disruption to the formatting would be essentially the same.)

I understand the need to contain file sizes within an epub, but is 200K really that much of a worry?

It is actually about 260K I think. Anyway, Calibre splits it for you as well. It is better for you to control the split I think. It is really bad when it comes within a paragraph. Some devices have very limited memory.

Dale

[Jellby]

Originally Posted by DaleDe

It is actually about 260K I think. Anyway, Calibre splits it for you as well. It is better for you to control the split I think.

On the other hand, if you don't split it and the device does it on its own, it will work fine automatically when the book is opened in a device that doesn't need the split. But books with artificially split chapters will remain split forever, even in devices with several GB or RAM...

[MacEachaidh]

Originally Posted by DaleDe

It is actually about 260K I think.

These files aren't that high. Two of them, 142K and 171K in the expanded ePub, have no issues. The two that do split are 203K and 208K. (I've confirmed there's nothing in the code to make them split, which is why I'm assuming it's the size.)

Anyway, Calibre splits it for you as well.

Nahh, Calibre's not for me, but thanks.

Originally Posted by Jellby

On the other hand, if you don't split it and the device does it on its own, it will work fine automatically when the book is opened in a device that doesn't need the split. But books with artificially split chapters will remain split forever, even in devices with several GB or RAM...

That was my thinking. In this case, the file's just for me, so in a sense it doesn't really matter. But I think it's important to understand these things, rather than just assume.

Speaking of assuming: Am I right in thinking this is a product of the way the F/W caches documents from an ePub? (Is that what it does?) I know my Aura HD has 4GB of storage, but does it actually have its own kind of RAM, or does it use virtual memory? and some kind of paging?

[davidfor]

Originally Posted by MacEachaidh

Speaking of assuming: Am I right in thinking this is a product of the way the F/W caches documents from an ePub? (Is that what it does?) I know my Aura HD has 4GB of storage, but does it actually have its own kind of RAM, or does it use virtual memory? and some kind of paging?

From memory, the Aura HD has 512KB of RAM. I have no idea how it loads the books. But, for epubs it is relying on the RMSDK to do a lot of the work.

The kepub reader is completely different and doesn't have this type of limit. Or at least not one I've hit when experimenting. If you load the book as a kepub you won't need to split it. But, you will need to add the spans kepubs need.

[MacEachaidh]

I have no knowledge of the workings of kepubs whatsoever. Where does one find this information?

[Toxaris]

Originally Posted by MacEachaidh

I have no knowledge of the workings of kepubs whatsoever. Where does one find this information?

Look here: https://wiki.mobileread.com/wiki/Kepub.

It is an Kobo format.

[davidfor]

Originally Posted by MacEachaidh

I have no knowledge of the workings of kepubs whatsoever. Where does one find this information?

The little official documentation is https://github.com/kobolabs/epub-spec. But, for most purposes, it is just an epub. The reader application on the Kobo ereaders is different. It uses ACCESS rather than the Adobe RMSDK as the renderer. There are a few extra's that Kobo has coded in the reader. An example is that footnote are displayed as a popup. There is a link to the location. Another is some nice in-book stats.

The only real issue with kepubs is that they use a different reading position method. The kepub conversion wraps each sentence in a span with an id. This id is used for the location for the current position and bookmarks. There are calibre plugins to convert to kepub either in the library or when sending to the device.

You can test any epub as an kepub simply by copying it to the device with the extension ".kepub.epub". This triggers treating it as a kepub. Everything except the reading position will work. It will remember the chapter, but not where in the chapter.

[PeterT]

I can see the only possible issue is how each engine handles invalid markup; for instance tags not properly closed.