Constructive Criticism Needed

[aapezzuto]

I have managed to get a small team (3 of us) together to work on making a good GUI driven e-book formatting program. Before going any further, let me outline what this is, and is not.

e-Bibliophile is designed to be a program that will allow you to convert and mark up a document, creating a project file, that can have styles applied to it, and be output into many different formats. We are not targeting ALL books, we are targeting MOST books. There are several things that have been purposefully left out to keep the contextual markup and the styling separate. It should be a good tool for people who want to properly format a book, with loving care, and distribute it to the most formats, with the least amount of "fiddling."

It is not and end all, only tool anyone will ever need for all digital publishing. It is not a replacement for adobe acrobat for print perfect, every pixel right where you want it design. It is not the right platform for writing your next math text book. And sadly, when something breaks, we will not have the same 15-30 min response time you have come to expect from Calibre and kovidgoyal.

It will be open source, so that may help out on some of the shortfalls, but there are certain things that are crippled by choice, and would be hard to circumvent.

We are in early stages of this project. We have a first draft of the human editable markup, and have some proof of concept code to keep our different views synchronized. What we need from you, the well versed e-book formatting community, is feedback on the current version of the markup. It can be found here. Google code provides commenting on each page of the documentation, so please utilize that for anything specific to part of the markup. I am especialy interested in feedback about the complex lists and the drama elements.

This markup syntax will be used as the "quick and dirty" alternative to a GUI driven markup. Pains have been taken to make it as similar to existing XML/HTML type markups, while improving readability. This syntax as well as the object model that it represents will be exposed for 3rd party plugins, to allow for further automation of editing.

As soon as we have a revised version of the markup, we will begin coding the GUI and markup interactions, as well as start on the first draft of the css interface that will be used.

Thank you in advance, for your help!

[tompe]

Concerning lists what I miss with lists generally are:

• Being able to specify of there is a new paragraph directly after a list or not.
• Having more than one paragraph in a list entry.

[aapezzuto]

Originally Posted by tompe

Concerning lists what I miss with lists generally are:

• Being able to specify of there is a new paragraph directly after a list or not.
• Having more than one paragraph in a list entry.

Reading the section on blocks, we have your first issue solved, paragraphs can state weather or not they are a continued paragraph.
The second is an interesting issue, the only thing I can think of that would solve this in our system is if you used the expanded xml, rather than the shorthand. The shortened form has no capacity to parse a mulit-paragraph list item. I will look in to how XHTML handles this, to make sure that the xml work around would even work.

Still looking for more people who will look at the documentation and provide comments on them.

[aapezzuto]

We need more feedback, so please take the time to look over the proposal

[pdurrant]

I'd rather is was valid XHTML, just defining standard labels to mark up the various elements.

But, given that's not what you're going for, it looks OK to me. It would be a lot easier to follow with a sample of marked-up text.

Originally Posted by aapezzuto

We need more feedback, so please take the time to look over the proposal

[aapezzuto]

We will have several samples as the first versions of the GUI/Markup part of the application starts to take shape. Though there will no way for it to naively be valid XHTML, there will/is a way to make your marked up files 100% XML. The shorthand is STRONGLY suggested, as every place we have moved from xml is to increase human readability, making hand editing easier.

Also, the first format that we will be supporting for output will be valid XHTML + CSS2 and shortly there after we will include the rest of the trappings for epub.

Remember that the main focus of this is to create a central format, that with small changes to a style sheet, you can output an optimal ebook in any format.

[Jellby]

I don't like the distinction of First/Middle/Last names, that's too "anglocentric". Having Family/Given names would be better (middle name is usually part of a given name, isn't it?).

The dates could include the date of writing, the date of original publication, the date the ebook creation, etc.

[aapezzuto]

Originally Posted by Jellby

I don't like the distinction of First/Middle/Last names, that's too "anglocentric". Having Family/Given names would be better (middle name is usually part of a given name, isn't it?).

The dates could include the date of writing, the date of original publication, the date the ebook creation, etc.

The family and given name is an interesting idea... as far as dates, I will have to mull that over...

Thank you so much for taking the time to review the markup