Creating multiple ebook formats from same source files!

[tompe]

Originally Posted by Jellby

Good! I tried using <mbpagebreak crossable="no">, as suggested in the documentation, with html2mobi, but it didn't work in the Cybook or in the desktop reader. Do you think this is due to a missing feature in html2mobi?

The code is not removed so it is in the packed data (I just checked). Does it work with mobigen?

[llasram]

Originally Posted by tompe

The code is not removed so it is in the packed data (I just checked). Does it work with mobigen?

It does work with mobigen. The issue that the Mobipocket renderers (well, Mobipocket Reader Desktop 6.2 anyway) don't actually use the markup to find uncrossable boundaries. Instead, they use a "trailing data item" appended to the end of each text-content record. The details are:

1. The MOBI header version field(s) must be >= 6.
2. The MOBI header extra data flags field must have 0x4 set.
3. Each text record has a trailing data item in the standard form (<data><size>, where <size> is a Mobipocket variable-length encoded integer and includes the size of <size>).
4. The data consists of a running index of the offsets of uncrossable boundaries, represented by a series of variable-length encoded integers.
5. The value of each integer is the offset from the position specified by the previous entry (or the beginning of the record for the first) to the last byte of the boundary tag (the '>' character) and right-shifted 3 bits. The "previous offset" for each entry is not the exact previous offset, but the actually-encoded offset & ~0x7.

I'm actually not 100% sure about the "last byte of the boundary tag" business, but that's how it seems to work. I'm planning to add this plus a few other things I've figured out to the MOBI page on the wiki at some point.

-Marshall

[llasram]

Originally Posted by kovidgoyal

An alternative is to render complex markup as images (see for example the --render-tables-as-images option in html2lrf)

Ooh, nice. That does sound like a good idea for tables, although is probably overkill for lists .

[llasram]

Originally Posted by Jellby

The biggest problem with mobipocket, format-wise, is that (as far as I know) it only allows to set vertical spacing above elements, so if you want to have some space below a chapter heading, or a piece of poetry, or an indented block... you have to set the space (with "height") in the element below that (a paragraph, a div, or whatever).

Yah, but that's pretty easy to handle at the conversion layer. My "MobiMLizing" code applies an approximation of the CSS margin and padding rules to block level element and drops any accumulated vertical space into the "height" attributes of <p> and <div> tags as appropriate to produce something like the CSS specifies.

[llasram]

Originally Posted by Jellby

Something a bit unrelated, is there a way (in CSS) to set the punctuation after the labels in a list, i.e., having "1:" or "1.-" instead of "1."?

It's possible with CSS3 generated content support, but not with CSS 2/2.1. It looks like Firefox supports it, and I know Prince does, but I'm not sure about other browsers and AdobeDE -- the OEB/EPUB specs only require CSS 2.

[nrapallo]

Originally Posted by llasram

I'm working on an "oeb2mobi" for Calibre which will allow the generation of Mobipocket books from OEB XHTML+CSS content.

Where do you envision the input oeb files will come from?

• User created? Those that prepare ebooks from HTML could create/modify their .html as well as create the accompanying .opf file and "pass" it to oeb2mobi; or
  
  
• Program created? Mobipocket Creator saves a .opf file that could be used as input for "oeb2mobi" (I know what's the point). Moreover, I can modify a Mobipocket .opf for it to load into the .imp creation software eBook Publisher and use that to create .imp ebook. There is python code in PDFRead's output.py which shows how to use/call the eBook Publisher's OLE/COM .dll (windows only). I've also got Perl scripts doing the same thing, which is easy enough to create a windows executable from (again windows only).

After that, I want to try to shore up differences among the outputs of Calibre's various target format conversions. The goal would be to allow book creators to use one standards-compliant HTML source and produce books which look "the same as possible" in all the various output formats. No IMP support yet, but perhaps one day...

I think Ashish Kulkarni (original author of PDFRead) has already done some work with Kovid in getting the .imp format better supported by Calibre. So I will let them tackle this first and wait on the sidelines until I can be of assistance.

[llasram]

Originally Posted by nrapallo

Where do you envision the input oeb files will come from?

Well, you know, anywhere . Hand-created versus tool-created doesn't really matter as long as they're standards-compliant enough to parse correctly. That said, whatever tool produced the OPF you attached required some new non-compliance-correction cases in my code . But hopefully the tools will improve with time.

[nrapallo]

Originally Posted by pdurrant

On a stylistic note, I prefer to specify no space between paragraphs (by setting margin-top and margin-bottom to 0em), but to have a text indent on the first line of each paragraph, except the first paragraph of each chapter. But that it a personal preference.

I appreciate that there will be a lot of personal preferences when creating ebooks, so I don't really want to concentrate on what does work, but would rather focus on what doesn't work when we each make .prc/.mobi, .lrf/.epub or .imp ebooks. Your preferences "work" when I create a .imp from your Mobipocket-specific .htm, except:

• My reader cannot adjust L/R margins so I usually have to give it a fixed (small) margin of 2% (but 2px works as well) so I needed to leave (re-introduce) the body {CSS rule} in the <style> section.
• My reader does not display a cover image unless it is embedded at the beginning of the ebook. I needed to reinsert the code for that first illustration. On second thoughts, I could add another file to the .opf <spine>, namely cover.html (to display the cover image like I do in Mobi2IMP) which would then be separate from the main .html. What do you think?
• I put back the "Contents" after the title page and made it centered now by changing the class used in the <div> to 'center'. It now works better. The location of the TOC is not the issue here, I just wanted to show you that it could be "fixed" and then appear like my original .imp/.lrf ebooks.
• Something weird is happening in the .imp ebook when the <h2 id=> tag is combined with the CSS rule for "page-break-before". The TOC entries bring me to the page BEFORE the Chapter title in the .imp version. Strange behaviour!
• I decided to see if I could emulate the <pre> tag by changing it to <p><small><small> and then for each line within the <pre></pre> pairs, add a <BR> to each line easily with a Text Editor. It somewhat worked!

I do like the idea of coming up with a 'generic' HTML format that works with the software to create multiple formats. I've avoided creating LRF or other files, because I can't test how they'll look.

For Mobipocket, you need an extra item in the opf file in the metadata part of the manifest:

<x-metadata><EmbeddedCover>images\illus-0001-1.jpg</EmbeddedCover></x-metadata>

and also a guide item to the table of contents is a good idea, just before the end of the package

<guide><reference type="toc" title="Table of Contents" href="Little%20Stories%20for%20Little%20Children.h tm%23contents"></reference></guide>

For .imp creation, I too need extra metadata in the <x-metadata> block for the Mobipocket .opf to load into my .imp eBook Publisher software. I've now added it, but my program ignores your cover image unfortunately. My program "chokes" on the 'url spaceless encoding' and I had to restore the original .htm filename (with spaces) for it to work. Also, your pictures in the images directory you posted along with your .prc ebook were washed and were a blueish/gray tint/hue. They did not appear the same as the original PG source images. Also, they were in a jpeg (jfif) encoding that my program did not recognize, so I just reverted back to the PG images again.

Anyway, I attach a zip of my html,opf & images (for which I corrected the white point), along with my prc.

Paul

OK, I herein attach two .zip files for you (and all) to see what "compromises" can be reached in order to be able to use the same .html source files to again make different format ebooks, in this case .imp and .prc.

This is tricky, so please follow:

Little Stories for Little Children-use prc to imp.zip is a file that used your Mobipocket-specific .html/.opf and I changed to create a valid .imp with the above changes implemented. I also produced a new .prc from that revised/changed .htm for you to see if it looks acceptable (format-wise, not necessarily personal preference-wise. )

Little Stories for Little Children-use imp to prc.zip is a file that used my IMP-specific .html/.opf and I changed to create a valid .prc and closer to what you want. I also produced a new .imp from that revised/changed .htm for you to see how that now looks to me.

I hope we are converging...

[Nate the great]

Interesting thread.

I only got interested in this a couple months back. I agree that working out a set of html that works for most formats is a good thing.

I'd already switched to compliant tags for my ebooks, but now that I know page-break-after doesn't work for imp I'll change that, too.

[nrapallo]

Ok, here's what I've learnt works better for .html that will be converted to multiple ebook formats (while writing GuteBook.pl):

• change any <pre> to <pre><small><tt> and </pre> to </tt></small></pre>. The <small> helps with the display on small screen ebook readers and the <tt> is recognised in Mobipocket as a monospaced font!!!
• use a body CSS style declaration, placed in the <style> section, like:
  body { margin-left: 2%; margin-right: 2%; text-align: justify; text-indent: 2em;}
  or just include this directly in the HTML <body> tag like:
  <body style="margin-left: 2px; margin-right: 2px; text-align: left; text-indent: 0em; font-size: +1">
  Of course, when the ebook hardware reader can control things like text-justification, font-size, etc. it may be better to omit those instead.
• <p> paragraph spacing can be controlled with a CSS style declaration, placed in the <style> section, like:
  p {text-indent: 2em; margin-top: 0em; margin-bottom: 0em; padding-top: 0em; padding-bottom: 0em}
• same thing with <br> that cause too big of a break, i.e., placed in the <style> section:
  br {margin-top: 0em; margin-bottom: 0em; padding-top: 0em; padding-bottom: 0em}
• <h1> .. <h6> may not center properly if there are left/right margins set in the <body> tag, so for them it is best to use the CSS style, placed in the <style> section:
  h1, h2, h3, h4, h5, h6 { margin-left: 0; margin-right: 0; text-align: center; }
• Mobipocket: for anchor links to Chapter headings to start on a new page with pagebreak HTML <h1>...<h6> tags, use:
  <a style="page-break-before: always;" name="CHAPTER_I" id="CHAPTER_I"></a>
  <h2>CHAPTER I</h2>
  but not:
  <h2 style="page-break-before: always;"><a name="CHAPTER_I" id="CHAPTER_I"></a>CHAPTER I</h2>
• split combined <a id/name and href> tags into <a name> and <a href> like:
  <a id="linkback" name="linkback" href="#linkto">...</a> into
  <a id="linkback" name="linkback"><a href"#linkto">...</a>
• strip (depreciated) width, border, height from within <img> to avoid squished pictures or even disappearing ones for .imp and also remove any width elements within the <div class=figcenter> which breaks for .epub, leaving only:
  <img src="filename.jpg" /> and <div class="figcenter">
  (p.s. this changes the preferred coding of Project Gutenberg .html ebooks with illustrations.)

Try adopting some of these "rules" for your next mulitple ebook creations and see if they help!

[Nate the great]

Originally Posted by nrapallo

Ok, here's what I've learnt works better for .html that will be converted to multiple ebook formats (while writing GuteBook.pl):

• change any <pre> to <pre><small><tt> and </pre> to </tt></small></pre>. The <small> helps with the display on small screen ebook readers and the <tt> is recognised in Mobipocket as a monospaced font!!!
  ...
  
• same thing with <br> that cause too big of a break, i.e., placed in the <style> section:
  br {margin-top: 0em; margin-bottom: 0em; padding-top: 0em; padding-bottom: 0em}
• ...<a style="page-break-before: always;" name="CHAPTER_I" id="CHAPTER_I"></a>
  <h2>CHAPTER I</h2>
  

Try adopting some of these "rules" for your next mulitple ebook creations and see if they help!

I've never had trouble with the pre tag, but I've always thought it should be avoided as much as possible.

I've also never seen the br tag do anything other than be a line break. Someone must have done something funky to get a space after that line.

I think it's too much effort to combine the anchor tag with the page break. I place a separate page break immediately before the anchor, but I look at it as placing it at the end of the previous chapter/section/article.

Other than that, I'm doing most of the rest already (I need to follow though on the p tag).

[AlexBell]

Originally Posted by pdurrant

For identifying links in the document, Mobipocket prefers the use of is rather than name.
Paul

Sorry to side track the thread, but do you mean 'Mobipocket prefers the use of ids rather than name'?

If so, it puzzles me a bit because as far as I know the use of id rather than name is specific to XHTML 1.1, which in fact does not permit name. Again, so far as I know, the Mobipocket format was defined long before XHTML 1.1 was a twinkle in anybody's eye.

What bothers me even more is that I have not caught up with XHTML 1.1 since none of the books I have mention it, nor how to make internal links without name. Can you point me to a book or source please where I can learn?

Regards, Alex

[HarryT]

Originally Posted by nrapallo

use a body CSS style declaration, placed in the <style> section, like:
body { margin-left: 2%; margin-right: 2%; text-align: justify; text-indent: 2em;}

Please don't include "hard-wired" justification in Mobi books, except in cases where it's absolutely vital (eg you probably don't want poetry to be fully justified). Hard-wiring justification in Mobi prevents the user from being able to select left or full justification, which most implementations of the Mobi Reader permit.

[AlexBell]

Originally Posted by Jellby

The biggest problem with mobipocket, format-wise, is that (as far as I know) it only allows to set vertical spacing above elements, so if you want to have some space below a chapter heading, or a piece of poetry, or an indented block... you have to set the space (with "height") in the element below that (a paragraph, a div, or whatever).

No, I don't think that's true - or at least
.spaceabove { margin-top: 1.0em; }
.spacebelow { margin-bottom: 1.0em; }
both work well in a test HTML/CSS file converted to Mobipocket by Calibre. It's true that it margin-bottom is not recognised by Mobipocket Creator, and I have found other differences in tests of the same HTML/CSS rendered by Calibre or Mobipocket Creator - almost all in favour of Calibre.

For what it is worth I whole heartedly support the idea of working towards getting standard HTML/CSS which will work in all formats, and hope that we can agree on and share a standard template.

Regards, Alex

[Nate the great]

Originally Posted by AlexBell

No, I don't think that's true - or at least
.spaceabove { margin-top: 1.0em; }
.spacebelow { margin-bottom: 1.0em; }
both work well in a test HTML/CSS file converted to Mobipocket by Calibre. It's true that it margin-bottom is not recognised by Mobipocket Creator, and I have found other differences in tests of the same HTML/CSS rendered by Calibre or Mobipocket Creator - almost all in favour of Calibre.

For what it is worth I whole heartedly support the idea of working towards getting standard HTML/CSS which will work in all formats, and hope that we can agree on and share a standard template.

Regards, Alex

I use margin-bottom all the time. In fact, just last night I checked to make sure it worked. It did.