Creating multiple ebook formats from same source files!

[AlexBell]

Originally Posted by Nate the great

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

With Mobipocket Creator? If so, back to the drawing board, and apologies.

Regards, Alex

[pepak]

Originally Posted by HarryT

in reality it's probably impractical to have completely "generic" HTML for multiple book formats.

That's pretty much my complaint against EPUB.

Final device-specific "tweaks" immediately before building the book will always be necessary to deal with the quirks of particular devices.

That's one of the reasons why I made my HTML2LRF preprocessor - it lets me keep one HTML file and convert it to just about any target format, with any last-minute tweaks I desire...

[nrapallo]

Originally Posted by HarryT

I completely understand that, Nick. I guess what I'm saying is that, desirable though it would be, in reality it's probably impractical to have completely "generic" HTML for multiple book formats. Final device-specific "tweaks" immediately before building the book will always be necessary to deal with the quirks of particular devices. I regard those basically as a part of the build process for a device.

You know, Harry, it just feels wrong NOT being able to use one (the same) source .html, but you are right that, given today's fragmented/disperse marketplace, each device's quirks will make it near impossible to achieve this goal.

So along your lines above in bold, I'm starting to think that the only solution to using one .html to make many different ebook formats may lie in perfecting the .mobi file creation and then feed that to calibre and/or Mobi2IMP. Using the SAME .html causes a lot of logistic problems with different preferences among the various ebook formats. Compromise is nice, but it should be only tolerated when it achieves a better all-around ebook!

However, it may be best to first develop a test suite of .html files (a standard per se) that we could ALL try to convert to the various ebook formats so as to yield similar looking results. Then we truly will be able to confirm if using one .html file for many ebook formats has a future...

I have an old testbed of sort that allovertheglobe prepared years ago. It tried to match features in HTML 3.2 to my device's strengths and weaknesses. While using it "as is" may be less than advisible, given our migration to HTML 4.0 and XHTML 1.1, it may be worth a shot to use it as a starting framework.

I now see a lot of separate threads in this area converging i.e. (and I paraphrase ) tricks&tips for .epub, ebook formats/layout, CSS anyone?, etc...
Perhaps, now is the time to compile a working defacto standard .html and put it through its paces...
toward a common (.html) best practices when creating ebooks...
then when can get creative/artistic once we have a good foundation.

Any thoughts, given that you wrote THE standard here for ebook creation?

[HarryT]

You flatter me, Nick. I know enough HTML to get by in what I need for my "day job" and to write reasonable-looking books, but there are people here who know far more than myself (you included) who would be far, far, better able to put together a "standard".

[nrapallo]

Originally Posted by HarryT

You flatter me, Nick. I know enough HTML to get by in what I need for my "day job" and to write reasonable-looking books, but there are people here who know far more than myself (you included) who would be far, far, better able to put together a "standard".

My situation is similar, with respect to HTML, as I am self taught for it's use within ebooks. I don't use it at all in a professional enviroment.

However, I don't create the underlying .html I choose to use as a starting point (PG does or WinHTTrack scoops it from websites), and then only "tweak" it to get the job done! (and re-tweak, and re-fix... )

But I will give this a go...

[ilovejedd]

Question. I'm not very familiar with device quirks since I haven't tried converting for various ebook readers, but would an external stylesheet not be possible? The formatting for divs could each be assigned a class. Then, just have a separate stylesheet for each format which takes into account the quirks of the device.

The html file would only include <link href="style.css" rel="stylesheet" type="text/css" />. Assuming you have a stylesheet for each device (e.g. prs505.css, prs505-justified.css, left-toc.css, center-toc.css, mobi.css, etc), you only need to copy/rename the device-specific CSS to "style.css" before you convert.

[kovidgoyal]

One file -> multi devices is certainly possible, I do it all the time. You just have to be prepared to accept some degradataion in quality. The simpler the features in the source html, the less degradation in the final book.

If you want advanced typographical features, then you have no alternative but to build each book separately since the implementation of these features is often orthogonal in different formats.

[nrapallo]

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)

Well, I thought it was time for another concrete example of what GuteBook can do with PG EText-No. 22896 used in post #1 above.

Using GuteBook, all these ebooks attached were made within two minutes with no manual intervention (using calibre v0.5.14):

Command Line
============

"E:\ebooks\GuteBook\bin\gutebook" 22896 --epub --lrf --mobi --lit --srcepub --1200 --1150 --1100 --keephtm 
--keepzip --pb "h2 h3" --embedded "Fontin" --striphr --pbfirsth1 --cover --centerh --imgsrc --calibreold

GuteBook (version 0.6) Copyright (C) 2009 Nick Rapallo (nrapallo)
Getting "http://www.gutenberg.org/files/22896/22896-h.zip" HTML file
from Project Gutenberg Website...
Fetching 485.0KB...
Extracting files...

Book Title : Little Stories for Little Children
Author     : Anonymous
Released   : October 5, 2007 [EBook #22896]
Language   : English

Cleaning "22896" HTML...
Wrote cleaned HTML "E:\ebooks\GuteBook\22896\22896-h\22896-h.htm"

Comparing the different versions, we are close, but not there yet...

Anything grossly wrong therein?

[HarryT]

Hi Nick,

The Mobi version is a little odd. It looks as though everywhere that a word could be hyphenated, a hyphen has actually been inserted:

John-ny Wil-son and Ned Brown were play-ing at ball one day, and the ball hit John on the hand: he was ve-ry an-gry, and ran af-ter Ned and beat him ve-ry hard. Just then, a man came by and gave John a box on the ear which made him let go of Ned, and he be-gan to cry. Then the man said, “You beat that lit-tle boy and for-get how you hurt him, but you do not like it your-self."

It also has a blank lines between the paragraphs, which I don't personally like.

[tompe]

Originally Posted by kovidgoyal

If you want advanced typographical features, then you have no alternative but to build each book separately since the implementation of these features is often orthogonal in different formats.

Or you can du a semantical markup of this feature and do a best effort conversion. Or you can include format specific markup in your file tagged then as format specific markup (as you do in SGML).

Every solution which include some manual work for the actual conversion is a broken solution. If manual work is required you will not fix the spelling of one word and generate a new version for example.

[HarryT]

Originally Posted by tompe

Or you can du a semantical markup of this feature and do a best effort conversion. Or you can include format specific markup in your file tagged then as format specific markup (as you do in SGML).

I believe that HTML parsers are required to ignore any tags that the don't understand, aren't they? If that is the case then adding, let's say, the Mobi-specific <mbp:pagebreak> "hard page break" tag should be safe for any non-Mobi device which understands HTML - it should simply ignore it.

Any flaws in this?

[crutledge]

I have a proposal or wish to solve a lot of the problems discussed here. A new ebook browser/editor. A mockup of this tool is attached.

It would have the following attributes and capabilities:
1. Would look much like or identical to Book Designer.
2. Would have the full capablities of Book Designer.
3. Would have a full windows tool icon set for justification, fonts, color, bold, etc.
4. Would have split screen capabilities showing text in one screen and html in the other. These screens would be synced so as one is changed the change is immediately shown in the other. For example, if a paragraph is highlighted in the text the html would also highlight. If highlighted and changed from paragraph to title the html would immediately reflect the change and vice versa. The cursors in each window would follow. The text screen is a full browser whuch displays the html loaded.
5. Would have a pop-up window showing all html tags and elements. These are in addition to the capabilities fo the Book Corrector. These tags and elements when double clicked will insert at the cursor or before and after highlighted text.(ala EditPadPro) The user can select any html tag or element and would be responsible for proper selection except for those like Book Corrector.
6. Would only accept text and/or html files. There would be no dependency on external software, e.g. Windows Word. All these tools will export html.
7 Would have no native book generator. All book generators will be insertable by the developer and/or the user. A well defined interface for calling the generator, e.g. a command line call to Calibre or Nick's imp generators, and would be published. The external generator would be responsible for generating a proper opf file.
8. Would have an External Tools icon with the built-in capabilites to add and select charm (.chm) files with help and definitions for a proper html for various book formats.
9. Would save only html.

This list could go on. But it would divorce the browser/editor from book generation. The saving grace is that the identical tool is already available for building WEB pages but are limited the WEB pages and of little use for ebooks. However, some of these are in the public domain with source code available (both java and python) and a GNU license. 60 to 90 percent of the code is already available. The parsers and editors are already written. This could be a fine project for someone and would be a great service to the mobile read and ebook community at large.

I don't know why the BD crew quit. They were on the threshold of something truly great.

Charlie

[nrapallo]

Originally Posted by HarryT

Hi Nick,

The Mobi version is a little odd. It looks as though everywhere that a word could be hyphenated, a hyphen has actually been inserted:

Sorry, that hyphenation is in the original PG conversion of the printed book. It is for little children... When I posted my original conversion of this ebook, I did removed the hyphens but it was not easy. Using a RegEx to fix it would catch even the HTML tags/CSS, so I had to do it manually, paragraph by paragraph. I didn't do that with the GuteBook automatic conversion, though!

It also has a blank lines between the paragraphs, which I don't personally like.

With GuteBook, there are options to satisfy most common preferences, case in point, these attached ebooks all now have no full justification, left/right 1% margins (about 1em), text indenting of 1em along with no blank line separation between paragraphs. See the attached image for the options selected to get these to appear in this PG conversion.

[nrapallo]

Originally Posted by tompe

Or you can du a semantical markup of this feature and do a best effort conversion. Or you can include format specific markup in your file tagged then as format specific markup (as you do in SGML).

Every solution which include some manual work for the actual conversion is a broken solution. If manual work is required you will not fix the spelling of one word and generate a new version for example.

I like that idea. Embed in the meta data of the html, the instructions/options for the converting program(s)...

EDIT: Ok, pepak, already implemented this idea for this HTML2LRF "Preprocessor"...

[nrapallo]

Originally Posted by HarryT

I believe that HTML parsers are required to ignore any tags that the don't understand, aren't they? If that is the case then adding, let's say, the Mobi-specific <mbpagebreak> "hard page break" tag should be safe for any non-Mobi device which understands HTML - it should simply ignore it.

Any flaws in this?

But isn't <p style="page-break-before:always"> recognized by Mobipocket Creator as well as the Mobi-specific <mbp: pagebreak>. Why use the Mobi-specific one? (Sorry, I know this was an example, but I don't want others to get the wrong idea.)