Advanced ebook formatting tips

[GeoffC]

Originally Posted by Jellby

Which, besides, is not true. Paragraphs can be indented after an illustration, a centered block, a piece of poetry, etc. (wich are usually not <p>'s, but <div>'s or whatever).

I note, by accident this morning, there is an xml tag of <poem></poem>; has anyone had any success with this and its associated tags <verse><stanza> etc ..... I've found a few examples but none of them 'work' in my browser, nor can I find a definitive reference to their use ....

[Jellby]

Originally Posted by GeoffC

I note, by accident this morning, there is an xml tag of <poem></poem>; has anyone had any success with this and its associated tags <verse><stanza> etc ..... I've found a few examples but none of them 'work' in my browser, nor can I find a definitive reference to their use ....

XML can be almost anything, the question is, is it XHTML? I don't think so.

[GeoffC]

Originally Posted by Jellby

XML can be almost anything, the question is, is it XHTML? I don't think so.

my thoughts too .... shame (!)

[bobcdy]

Trying to learn a bit about css styles, and had a question. Will Adobe DE and by extension BeBook epubs work with CSS3 pseudo-classes such as first-letter? I find it works fine with mozilla and sigil, but doesn;t seem to work with Adobe DE; perhaps there is some way to force it to work?
Bob

[KNotTed]

Originally Posted by GeoffC

I note, by accident this morning, there is an xml tag of <poem></poem>; has anyone had any success with this and its associated tags <verse><stanza> etc ..... I've found a few examples but none of them 'work' in my browser, nor can I find a definitive reference to their use ....

This interested me so I decided to check it out. CSS2 + XHTML is fairly flexible. Obviously, you can define styles for tags like p, i, em, etc. However, with this flexibility, you can also define new tags, e.g. a poem tag. I created the following style.css file:

poem {
  text-align: center; 
  font-style: italic;
  margin-top: 2.0ex;
  margin-bottom: 2.0ex;
  display: block;
}
p {
  text-indent: 1.1em; 
  margin: 0;
}

I created a test HTML file using this stylesheet, converted it to EPUB with Calibre, and tested it in Calibre's viewer, ADE, and on my Sony Reader. All three displayed the text in the poem tag centered and italics, with the proper top and bottom margins.

[lindsayw]

The "name" attribute of the <a> tag is definitely deprecated, you should use the "id" attribute instead.
I have converted 9 of my own novels into html and worked my way through making a css stylesheet that suits my particular book presentation tastes in strict xhtml, then made ePub and MOBI files of them successfully... very happy with the overall presentation.
BUT: On some books the end of the last chapter needs some sort of <END HERE> tag, so the Reader knows to look no further.
Anyone know how to do this? Like, is there a convention that inserting a tag like <a id="end" /> will be recognized by most common ebook compilers?

[JSWolf]

How about putting THE END at the end?

[lindsayw]

The <a> tag is still valid, but the "name" element has been deprecated, so you should use <a id="xxxx"> instead. Also note that, under strict xhtml, you can't use self-closing ( .../> ) on the <a> tag, you have to explicitly close it with a </a> tag. If you use the self-closing method, xhtml still regards the <a> as "open", so any subsequent layout tends to be screwed up. Been there, done that...

[lindsayw]

Here's an extract from my stylesheet file:
div.book {
margin-top:0.1em;
margin-bottom:0.4em;
font-family: serif;
}
...this expresses "white space" in ems, so it doesn't matter how large or small a font the user selects, the white space between paragraphs remains fairly proportional. I don't like paragraph indents ( perhaps because I'm Australian, we like things kept simple? ) but this could easily be added. The overall white space between paragraphs is 50% of a normal line of type, not 100% as would happen using standard html <p> tags.

And here's another one:
span.cap {
font-size:1.5em;
font-weight:bold;
line-height:90%;
}
Drop-caps for starts of break-points don't work very well with re-flowable text, but a larger-size cap works well, 150% bigger than whatever size the user has selected for body text. The 90% line-height is to reduce the gap reserved for "descenders" and avoid gaps between lines #1 and #2.

[Jellby]

Originally Posted by lindsayw

Also note that, under strict xhtml, you can't use self-closing ( .../> ) on the <a> tag, you have to explicitly close it with a </a> tag.

Can you give a reference for that? I have only found that it's not possible in HTML (but it is in XHTML, see here), or that some browser has problems with that.

[lindsayw]

I will try to dig up a reference from among the myriad sites I have visited but, from memory, the xhtml rule is simple: any "empty" tag (that doesn't ever have content) may be self-closed. Any tag that MIGHT have content must be explicitly closed. The <a> tag might have content and, in fact, normally has an href="xxxx" element, so it needs a separate closing tag to delineate the operating element (the link). Tags such as <br> or <hr> never have content so they should be: <br /> or <hr />. <p> ALWAYS has content, so needs a </p> to delineate the scope of the paragraph.

[Jellby]

I've found this:

Given an empty instance of an element whose content model is not EMPTY (for example, an empty title or paragraph) do not use the minimized form (e.g. use <p> </p> and not <p />)

But it is in the "HTML Compatibility Guidelines" appendix, i.e., it is not a prohibition in the specification, but a recommendation in order to have XHTML documents render in HTML-only browsers. I don't think it applies to ebook readers and ebook formats.

[lindsayw]

OK, that's probably right, but I use a 3-stage method of "building" e-books. First, using Anthemion eCub to assemble all the files in an ePub, then Sigil to modify the structure (and run their Validity Check) to remove the auto-generated TOC and hack the content.opf file, then finally Calibre to "explode" the ePub and make final adjustments before converting to MOBI for Kindle use. I know that files that fail HTML-5 validation also fail Sigil's validation and, when I view it on the Kindle there are subtle layout errors that I believe are created by "open" tags. When I make sure that all <a> tags are explicitly closed I don't get those errors.

[JSWolf]

I think some of the Kindle layout errors are due to bugs in the Kindle parser. Do your ePub look OK before you convert to mobi? Do your Mobi look OK in Mobipocket Reader?

[lindsayw]

My ePub files all look fine on PC-based Readers and, of course, I can't check them on the Kindle. As soon as I get this phase of my project ( converting all my stuff from p-books ) out of the way, I will definitely be buying a different brand of actual Reader so that I can concentrate on ePub, which seems a much more versatile format. My work is technically done, and I'm qute happy with the appearance on the Kindle, but I'm still finding tiny errors from proof-reading... mostly arising from the manual method I used to copy from Word and paste as a plain-text block into an html editor... won't make that mistake again.