My first epub: Cover is on page 2 (?)

[omk3]

You are so right, thank you!!!! I removed the comments and it is now on page one (and it is only 1kb of size)


(also any other comments on my code or structure would be much appreciated - without taking up much of your time of course)

However, the mystery is not solved yet for me, because all the comments were actually copied from Jellby's cover of "The Prince and the Pauper", and this cover was on page one all right.... I really don't understand why they would behave differently. I had kept the commented code because I thought I might need it if I wanted to edit the cover, but I can see now that it is best to keep the cover.xhtml as small as possible. But...again...why did Jellby's cover work fine and mine didn't, when it was actually only a copy of his? Oh well...

[omk3]

Okay, here is a dummy version of the book, with every small character replaced with x's (not very beautiful, but the best I could come up with to keep size and everything else as true to the original as possible). Scrambled the cover, and only included the first 4 stories.

I kept the comments on the cover page, so that you see it on page 2 or 3. If I remove the comments, it goes to page 1 as intended, as pdurrant said. But the question remains, why does this really happen?

So if you want to read a lot of x's, here it is

Comments on my code and structure are very welcome.

[EDIT] It was validated, and ADE displays it okay, put epubreader seems to have a problem with things like &xxxxx;which are remnants of apostrophes I would guess... This problem exists only for the dummy book of course, not the original one.

[Jellby]

Stupidly enough (on the part of Adobe), it seems pagination depends on the compression level of the files! I've just uncompressed your book and recreated it in two versions:

A) No compression (level 0). The cover is in pages 2-3, and the book is 56 pages long.

B) Maximum compression (level 9). The cover is in page 1, and the book is 14 pages long.

This makes the "page" numbers even more arbitrary than before

[omk3]

Unbelievable! Thank you so much Jellby! I would never have guessed.

So Adobe uses the compressed size instead of the actual size of the files to determine pages.... What can I say...

What do you use for zipping, by the way? I just used UltimateZip with no compression, so that I would have no problems with the mimetype file. It does not seem to offer many levels of compression, just "fast", "normal", etc. I tried with normal compression and got the cover on page 1, and 56 pages of book...

So to anyone else having the same problem: Either keep your cover page <=1kb or compress!

for answering what to me was a great mystery!

Was the rest of my code okay? I'd like to hear any corrections from you ePub pros!

[zelda_pinwheel]

Originally Posted by Jellby

Stupidly enough (on the part of Adobe), it seems pagination depends on the compression level of the files! I've just uncompressed your book and recreated it in two versions:

A) No compression (level 0). The cover is in pages 2-3, and the book is 56 pages long.

B) Maximum compression (level 9). The cover is in page 1, and the book is 14 pages long.

This makes the "page" numbers even more arbitrary than before

wow, that's... pretty crazy. i'm glad it's all sorted out now, and i've learned a thing or two as well in this thread. the epub kings save the day again ! nicely done, jellby and pdurrant.

[Jellby]

Originally Posted by omk3

What do you use for zipping, by the way?

I use just the standard "zip" command in Linux, which is Info-ZIP, it seems.

Was the rest of my code okay? I'd like to hear any corrections from you ePub pros!

It seems you have your first paragraph wrapped in a <div> and the rest of the chapter in another <div>:

<div class="firstp">
<p>First paragraph of the story</p>
</div>
<div class="body">
<p>Rest of the story</p>
<p>...</p>
</div>

I don't think that's really useful, you could get the same with:

<p class="firstp">First paragraph of the story</p>
<p>Rest of the story</p>
<p>...</p>

which looks cleaner to me. And then, are you sure you meant "text-indent: 10%" in the first paragraph? Books usually have no indent in the first paragraph. Anyway, you could simply write:

p
{
margin-bottom: 0;
margin-top: 0;
text-indent: 1em;
}

p.firstp
{
text-indent: 10%;
}

[omk3]

Thank you and you're right, the <div> tags were not really useful. I had doubts about them myself, but thought I might need them later in ways I could not predict. If p.anything overrules simple p, then obviously I don't need them at all. I also had some small poems in later stories, which need different handling too. I had them in <div class="poem"> tags, but I guess <p class="poem"> would suffice. What would I need a <div> tag for, then, I wonder... I'll probably find out with experience.

About the indents, I was not at all sure how to format the book, so to avoid experimenting well into next year, I just copied the formatting of the original paper book, which actually had deeper indents for the first paragraphs, along with the titles. It surprised me too, but it looked okay.

Jellby, Pdurrant and Zelda, have I told you you have been fantastic? I'm so happy to be here among you

[Jellby]

Originally Posted by omk3

If p.anything overrules simple p, then obviously I don't need them at all.

It does. More specific selectors override less specific ones, much like "div.firstp p" overrides a bare "p".

I also had some small poems in later stories, which need different handling too. I had them in <div class="poem"> tags, but I guess <p class="poem"> would suffice. What would I need a <div> tag for, then, I wonder... I'll probably find out with experience.

Poems are a nasty dusty beast

For simple poems, you don't need much, indeed. But when you start having different indents and long lines (which you'd like to wrap nicely), things start to get complicated. My personal way of dealing with poems is something like:

<div class="poetry">
<div class="stanza">
<p>How doth the little crocodile</p>
<p class="indented">Improve his shining tail,</p>
<p>And pour the waters of the Nile</p>
<p class="indented">On every golden scale!</p>
</div>

<div class="stanza">
<p>How cheerfully he seems to grin,</p>
<p class="indented">How neatly spread his claws,</p>
<p>And welcome little fishes in</p>
<p class="indented">With gently smiling jaws!</p>
</div>
</div>

with:

div.poetry {
  margin: 1em 0 1em 2em;
  font-style: italic;
}
div.stanza {
  margin: 0.5em 0;
  page-break-inside: avoid;
}
div.poetry p {
  margin: 0;
  text-align: left;
  padding-left: 5em; 
  text-indent: -5em;
}
div.poetry p.indented {
  margin-left: 1.5em;
}

The combination of margins, paddings, and text-indent allows me to indent the whole poetry block, have additional indent for the "indented" class (I have also "indented2", "indented3", etc. if needed), and let the wrapped portions of a line (if it gets wrapped) be further indented (ideally they would be right-aligned, with a "[" before them, but that's simply not possible with CSS). Sometimes I think I should use <div> instead of <p> in poetry, but <p> is shorter

[Peter Sorotokin]

Originally Posted by omk3

So Adobe uses the compressed size instead of the actual size of the files to determine pages.... What can I say...

This is all documented in EPUB Best Practices Guide (http://www.adobe.com/devnet/digitalpublishing/):

When page map is not available in the document, Adobe Digital Editions will synthesize a page-map based on the document content. The approach used is the following:
1. Determine a compressed byte length of each resource which is referenced in the spine, subtracting any known encryption overhead (IV size)
2. Assume that there is a page for each 1024 bytes in each resource, rounding up to the nearest whole number of pages for each resource
3. To map page breaks into a resource, use the number of pages for the resource as determined in step 2, count the number of Unicode characters in the resource; distribute synthetic page breaks in the resource evenly between the characters by dividing the number of characters by the number of pages; if the number of characters don’t divide evenly among the pages, round the number of characters per page up and let the last “page” contain less characters than the rest.

It may be "obvious" to you that uncompressed size should be used, but it would not work reliably. Compressed size is better because it is the only reliable number about the resource without expensive decompression and sometimes decryption (and decryption may not even be possible in some cases).

[DaleDe]

There is a discrepancy between step 2 and 3. In 2 you say bytes and in 3 you say unicode characters. I believe 3 is right but they are not always the same number. I think ADE looks at the coding to figure out what to do and probably uses a formula for UTF-8.

[Jellby]

Originally Posted by Peter Sorotokin

This is all documented in EPUB Best Practices Guide (http://www.adobe.com/devnet/digitalpublishing/):

Of course, I had read it some time ago, but it didn't register in my head

It may be "obvious" to you that uncompressed size should be used, but it would not work reliably.

What is obvious to me is that page numbers are not reliable anyway Just like for paper books, page numbers are only useful if you refer to a specific particular edition of a book, or if you keep them for your own private use, like estimating how long it will take you to read a book or finish a chapter.

But... doesn't the zip file store (or isn't it "easy" to get) the uncompressed size of the files? I think I usually see the uncompressed size in GUI zip apps, and it doesn't seem like they really uncompress the files. Or maybe is it because I strip all permissions and such when zipping?

Originally Posted by DaleDe

There is a discrepancy between step 2 and 3. In 2 you say bytes and in 3 you say unicode characters.

But step 2 refers to the compressed size, and there are no characters there, only bytes. With the compressed size you calculate the number of pages. Then, after you uncompress the resource (file), you can place the pagebreaks by distributing the characters.

[DaleDe]

Originally Posted by Jellby

Of course, I had read it some time ago, but it didn't register in my head

But step 2 refers to the compressed size, and there are no characters there, only bytes. With the compressed size you calculate the number of pages. Then, after you uncompress the resource (file), you can place the pagebreaks by distributing the characters.

How can that work? It you already used step two to figure the total then how can you use the uncompressed to get to the same number. The zipped file includes all of the images as well which are not counted in the page sizes. This needs fixing I think.

Dale

[Peter Sorotokin]

Originally Posted by DaleDe

There is a discrepancy between step 2 and 3. In 2 you say bytes and in 3 you say unicode characters. I believe 3 is right but they are not always the same number. I think ADE looks at the coding to figure out what to do and probably uses a formula for UTF-8.

There is no discrepancy. To determine number of pages allocated to a resource, its compressed size in bytes is used. To place page boundaries inside the resource Unicode characters are used.

[Peter Sorotokin]

Originally Posted by Jellby

What is obvious to me is that page numbers are not reliable anyway Just like for paper books, page numbers are only useful if you refer to a specific particular edition of a book, or if you keep them for your own private use, like estimating how long it will take you to read a book or finish a chapter.

That's true, of course. And in addition to compression ratio there are many other variables, for instance UTF-8 vs UTF-16 encoding, entity references, DOS/UNIX linebreaking, whitespace.

But... doesn't the zip file store (or isn't it "easy" to get) the uncompressed size of the files?

It does, except when it does not. Sometimes there is just zero there. And if a resource is encrypted, it is not stored anywhere.

I think I usually see the uncompressed size in GUI zip apps, and it doesn't seem like they really uncompress the files. Or maybe is it because I strip all permissions and such when zipping?

It is there most of the times. But some common toools don't put it there (e.g. I think Java Zip implementation sometimes omits it, but I may be mistaken).

[Jellby]

Originally Posted by DaleDe

How can that work? It you already used step two to figure the total then how can you use the uncompressed to get to the same number.

Simple: by forcing it

First, with the compressed size, you calculate the number of pages. Now the number of pages is fixed, and you place the pagebreaks in the uncompressed file so that you get the fixed number. There's no specification on the page length here, they'll be as long as needed to get the number of pages you calculated before.