Creating multiple ebook formats from same source files!

[Timoleon]

Originally Posted by 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

Charlie,

This is an excellent concept. I wonder what the status of the Book Designer code is at the moment? Is it "abandonware"? Would there be legal ramifications if someone started messing with the code? I wonder how difficult it would be to get in touch with the original authors (Russian?) and get permission from them to carry on the good name and works of Book Designer?

[crutledge]

Book Designer was developed by a Russian Group. All of the information is in the WIKI. I have tried sending email but never have received an answer. I have no idea what language or tool set was used. Getting the source code might be more trouble than its worth.

Using the pearl and/or java already available under a GNU license seems to make more sense. All HTML editors and browsers have similar sceens and tool bars.

Want to try it?
Charlie

[Timoleon]

Originally Posted by crutledge

Book Designer was developed by a Russian Group. All of the information is in the WIKI. I have tried sending email but never have received an answer. I have no idea what language or tool set was used. Getting the source code might be more trouble than its worth.

Using the pearl and/or java already available under a GNU license seems to make more sense. All HTML editors and browsers have similar sceens and tool bars.

Want to try it?
Charlie

I'd be a disaster...
But there are any number of really clever, bright, and capable folk here at MobileRead who could do a lot of good with the Book Designer code, I bet!

[carlobee]

Charlie,

you're concepts are very much useful! we appreciate your sharing of thoughts. these are important information we need to learn.

[HarryT]

Originally Posted by nrapallo

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.)

Wouldn't that insert a page-break at every paragraph? Apologies - I'm not terribly good at CSS!

[AlexBell]

Originally Posted by HarryT

Wouldn't that insert a page-break at every paragraph? Apologies - I'm not terribly good at CSS!

Yes, I think it would. What works for me is to put it in the CSS like

div.section {
margin: 1em 0 0 0;
padding: 0;
page-break-after: always;
}

Where div.section is for chapters. So at the end of the chapter there is a page break.

Regards, Alex

[HarryT]

So would you then use this by saying:

<div class="section"> ....

where you wanted a page break?

[Jellby]

Originally Posted by nrapallo

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.)

By Mobipocket Creator, maybe, but I don't think it is recognized by MobiPerl, for instance.

Originally Posted by HarryT

Wouldn't that insert a page-break at every paragraph? Apologies - I'm not terribly good at CSS!

No, only for those paragraphs you code with <p style="page-break-before:always">, the rest you can simply code them with <p>.

[HarryT]

I understand now - thank you.

[AlexBell]

Originally Posted by HarryT

So would you then use this by saying:

<div class="section"> ....

where you wanted a page break?

No, I'd use something like

<div class="section">
<a name="preface"></a> <!-- Anchors go before headings -->
<h3>Preface to this version</h3>
<p>
Major General Smedley Darlington Butler USMC was one of the most highly decorated military men from the pre-World War II era, and won two Congressional Medals of Honor. He served from 1898 to 1931 and saw action all over the world.
</p>
{Lots of text deleted}


</div> <!-- End of Preface div; page break in CSS -->

This is a small section of an ebook I uploaded in XHTML with CSS format in a post last night asking people to check out the template. You're welcome to download the zip file and look at the XHTML and CSS, and suggest any improvements or ask any questions.

Regards, Alex

PS I found three errors in the text when proof reading it on my Cybook. They have been fixed in the mobi version I'll upload later, but if you find any more errors please let me know.

[Jellby]

Originally Posted by AlexBell

No, I'd use something like

<div class="section">
<a name="preface"></a> <!-- Anchors go before headings -->
<h3>Preface to this version</h3>

[...]

This is a small section of an ebook I uploaded in XHTML with CSS format in a post last night asking people to check out the template.

Note that the "name" attribute is deprecated or forbidden in XHTML (depends on the version). Use "id" in another element for anchors, like this:

<h3 id="preface">Preface to this version</h3>

[AlexBell]

Originally Posted by Jellby

Note that the "name" attribute is deprecated or forbidden in XHTML (depends on the version). Use "id" in another element for anchors, like this:

<h3 id="preface">Preface to this version</h3>

It's acceptable in XHTML 1.0, or at least the W3C validator doesn't complain about it if one uses the XHTML 1.0. doctype. And yes, I know it's not acceptable in XHTML 1.1

I've had problems finding information about marking up with XHTML 1.1. Ronin has recommended w3schools.org; do you have any suggestions?

Regards, Alex

[AlexBell]

PS I've found that Mobipocket often does not bold or size headings correctly when the anchor is after the hn tag, hence the comment. Is this problem overcome with XHTML 1.1?

Regards, Alex

[HarryT]

Originally Posted by AlexBell

PS I've found that Mobipocket often does not bold or size headings correctly when the anchor is after the hn tag, hence the comment. Is this problem overcome with XHTML 1.1?

Regards, Alex

You mean when you jump to that point in the text?

That's because when you jump to a location in the document in Mobi, it starts parsing the HTML from that precise point, so if you're "inside" a bold, header, or any other tag, it doesn't know. It's up to the document creator to ensure that all anchor tags are placed outside such formatting tags.

[Jellby]

Originally Posted by AlexBell

It's acceptable in XHTML 1.0, or at least the W3C validator doesn't complain about it if one uses the XHTML 1.0. doctype. And yes, I know it's not acceptable in XHTML 1.1

I've had problems finding information about marking up with XHTML 1.1. Ronin has recommended w3schools.org; do you have any suggestions?

Not really, I found it the hard way (the ePUB validator said that "name" was forbidden). The changes from XHTML 1.0 strict can be found here:

http://www.w3.org/TR/xhtml11/changes.html