ePubHub, an open-source eBook assembly app for Windows

[kovidgoyal]

Originally Posted by awx

OK, but they still don't imply chapter breaks.

Neither do divs. In fact nothing in HTML implies a chapter break, since chapters are not a concept the HTML spec addresses. The question you need to be asking is what approach is going to be most compatible with with widely accepted practice as well as being reasonably robust.

EDIT: in the context of ePub widely accepted practice is to put each chapter in a separate HTML file.

[awx]

Originally Posted by kovidgoyal

Neither do divs. In fact nothing in HTML implies a chapter break, since chapters are not a concept the HTML spec addresses.

Exactly, which is why the import procedure specifies these interactions. If they were defined somewhere, I wouldn't have needed to specify them.

Originally Posted by kovidgoyal

in the context of ePub widely accepted practice is to put each chapter in a separate HTML file.

I think you may have lost the jist of this discussion. ePubHub creates separate Xhtml files already.

The ePubHub import feature currently can import existing Xhtml files, which it stores in a separate "document" object which will get rendered during the ePub export function back into a separate Xhtml file. The existing ePubHub Xhtml import feature will also import several Xhtml files at once, again storing each into a separate "document" object.

In order to facilitate importing an entire book stored inside a single Xhtml file while maintaining it's structure, a specification for the use of divs to define chapters/parts/cover-pages was introduced.

By following this specification, a book stored as a single file will then be split into multiple "document" objects, which would be rendered as multiple Xhtml files in an ePub.


What DaleDe believes is that h tags can be used to define the structure of an entire book. Nothing in Html, Xhtml, ePub, Ncx, Opf, Daisy or any other standard that I have come across supports this belief. The ePub specification itself does not even use h tags for constructing the table of contents.

[kovidgoyal]

Originally Posted by awx

In order to facilitate importing an entire book stored inside a single Xhtml file while maintaining it's structure, a specification for the use of divs to define chapters/parts/cover-pages was introduced.

By following this specification, a book stored as a single file will then be split into multiple "document" objects, which would be rendered as multiple Xhtml files in an ePub.

Why define a specification at all? Make it flexible enough to handle an arbitrary structure, via XPath. See how calibre does it for example.

[awx]

Originally Posted by kovidgoyal

Why define a specification at all? Make it flexible enough to handle an arbitrary structure, via XPath. See how calibre does it for example.

Please see the original post that started this discussion. It is stated that this is a temporary stop-gap until a proper Xhtml Import dialog where this can be configured is finished.

[kovidgoyal]

Originally Posted by awx

Please see the original post that started this discussion. It is stated that this is a temporary stop-gap until a proper Xhtml Import dialog where this can be configured is finished.

Ah so your motivation for using divs is that it makes it trivial to code for, now I get it.

[awx]

Originally Posted by kovidgoyal

Ah so your motivation for using divs is that it makes it trivial to code for, now I get it.

That and it gives an unambiguous, standards-compliant means to specify an entire book in a single Xhtml file.

[kovidgoyal]

Originally Posted by awx

That and it gives an unambiguous, standards-compliant means to specify an entire book in a single Xhtml file.

So do heading tags and they are going to be much more convenient for your end users. But hey, it's your project

[awx]

Originally Posted by kovidgoyal

So do heading tags and they are going to be much more convenient for your end users. But hey, it's your project

Thanks

[DaleDe]

Originally Posted by awx

You may want to scroll up just a bit in the document you linked to and read this:
"The DIV and SPAN elements, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents."

Followed by:
"Suppose, for example, that we wanted to generate an HTML document based on a database of client information. Since HTML does not include elements that identify objects such as "client", "telephone number", "email address", etc., we use DIV and SPAN to achieve the desired structural and presentational effects."

This is definitely what I'm after.

Sure, I can read that even when the font isn't huge. I understand using DIV and SPAN elements when needed for some things that cannot be done in the normal flow of things but to require them for this purpose is over the top IMHO.

Dale

[awx]

A new version has been released. A list of errors is now shown on most objects, giving a short message about what is wrong. It is no longer permitted to export to ePub if any errors exist.

I've identified but not fixed a longstanding bug where seemingly random "NullReferenceExceptions" were being thrown during scrolling and deleting items. It has to do with the underlying Wpf sorting functionailty and how it interacts with the Navigation treeview.

[awx]

New version released.

* Small bug fixes and performance improvements.
* Work has started on ePubHub's native file format, called .ephx. It's xml inside a zip and is listed in the Formats section of the UI.
* The native Wpf error checking is now used in some places in the UI. You will see a red outline around some fields which have missing or invalid data. The metadata section currently uses this.
* Additional rendering options for the Quotation <q> tag. It is now possible to specify if the <q> tag, quotation marks or both should be rendered. You can specify the characters used for primary quotes (top level) and secondary quotes (nested), such as curly quotes, double angled brackets, Swedish-style quotes and more.

[awx]

A new version was released. A family emergency has prevented much work this week.

* New Image Page object added, for future support of comic books or any type of content where a single image is used as a page. It renders almost exactly like the existing Cover Page.
* Preliminary support for Ncx fallback chains, but not implemented in Gui yet. Initially this will be restricted to Jpg->Xhtml fallback chains. Fallbacks don't seem to be well supported on ADE/Sony Reader but perhaps if people use it the readers will support it in the future.
* New Audio object which currently renders as a link to an Mp3 file. Doesn't work in my Sony reader. Support for Ncx audio will be coming in the future.
* Open/Saving of native Ephx documents. This barely works so don't use it.
* More and improved icons.
* ClickOnce prerequisites set to .Net 4.0 Client. I had already done this but somehow the setting didn't take or was later lost.
* Improvements to Last used path/filename to better work with .Net 4.0.

[awx]

New version released.
* I believe the long-standing exception that was thrown during scrolling is now fixed.
* Sorting has been improved for all items except stylesheets.
* Bug where exporting fonts, css, audio had the wrong default file extension is fixed.
* Bug fix for exception thrown while attempting to browse unavailable network shares.
* Css import will now try to load the Fontface fonts automatically if they are in the same directory as the Css file. Still only supports Otf files.
* During Xhtml import, a <div class="scene-split" /> will be changed into a native SceneSplit object. Any contents inside the div will be removed and the normal SceneSplit rendering will take over.

[awx]

New version released with two minor features:
* GUI for documents (chapters, generic pages, etc.) has been cleaned up considerably.
* A "Show Errors" menu item added to the "Tools" menu. It simply collapses all items in the navigation pane except those with errors.

Edit: I wrote too soon about sorting improvements in the previous post. I must now revisit this again.

[awx]

New version pushed out:
* Sorting problems should now be taken care of.
* Stylesheets are now properly sorted and support drag-and-drop editing.
* ePub filename constraints modified to more closely match the standard (upper and lowercase are now allowed but filenames are not case sensitive). Epubhub still restricts you to a-z with no accented characters allowed.