Hacker News Reader

Comment by gamblor956 | Hacker News Reader

It seems that you've tackled a problem that doesn't really exist. Nobody really cares if the compiler has to manage complex code--that's what its there for. Pushing the work on to a human isn't the solution--the current html+css-based approach of the existing eBook standard already works well enough and there are already plenty of WYSIWYG editors to take care of the underlying source code.

Edit: Note that all of the major eBook standards are variants of HTML, with some specific extensions/modifications that are generally not difficult to deal with when converting between formats.

View on HN

You've possibly never tried to create ebooks then. Even something simple like a table of contents is handled quite differently by different formats. Many convertors aim to convert Word docs into ebooks, for example, and are poor.

But time will tell. You could be right. If there is no demand it will fail to catch on. But the ambition to to provide a single universal format that can then be output to different formats.

Thanks for the feedback though.

Edit: I meant to add; the goal is not for people to hand code it. The ideal is the format is used invisibly by writing software, or perhaps as an export format. Obviously I only "released" it an hour ago, so like markdown, in the first instance its a rough and ready thing, only usable in a text editor.

For the most part it's either epub or mobi at this point in the ebook game, with the rare occasional pdf. Epub and mobi are essentially interchangeable thanks to Calibre, and if you need PDF then you probably need more complex formatting than a Markdownesque language can provide.

Converting from Word is a problem, but that's for different reasons: 1) authors (understandably) have no idea how to typeset, so each author has their own special bizarre style that's almost always wrong, 2) the HTML produced by Word is a hideous wreck no matter how you slice it, and 3) each different version of Word produces wildly different, but equally monstrous, HTML.

Sadly the word processing game has been won by Word. 99% of non-techie authors will use Word (or maybe Scrivener) to write their novel and it's tough to convince them to learn a formatting language when they can just press 'bold' on the toolbar.

In either case we already have a format to be invisibly used by writing software: HTML/CSS. It's the underlying language for epub and mobi, it's well understood and easily learned, it was specifically designed for book-like documents (and not web apps funnily enough), and programs already export in that format. The problem is that some programs (like Sigil) do a better job of exporting than others (like Word).

Things like TOCs can be handled by using an open, easily-editable format like epub as a base format, then using Calibre to invisibly compile to different formats. Calibre does a flawless job 99% of the time.

Edit: My creds are that I run one of the largest writing communities online, briefly ran an online ebook conversion service, and have composed and published ebooks myself.

Sadly the word processing game has been won by Word. 99% of non-techie authors will use Word (or maybe Scrivener) to write their novel

That's because publishers rely on Word for workflow because everyone uses Word and they require interoperability.

They don't actually like Word any more than the rest of us do -- they mostly rely on Adobe InDesign for typesetting, and getting Word docs into InDesign is a bit painful unless the author is au fait with the publisher's own style sheet -- and if you talk to their electronic/internet publications specialists they'd love to find a usable alternative platform. Unfortunately they need such a platform to be universal, to support workflow-specific tasks such as copy editing (handled today, not terribly well, via Word's change tracking) or checking page proofs (handled today by going over PDFs until your eyeballs bleed), and to work for everyone they do business with. Scrivener is great, and generates very clean HTML/CSS/ePub, but it stops at the point when you hit "Compile" -- it doesn't interoperate with the proofing/production side of workflow. As for the rest ...

(Credentials: I write novels for a living and in the past week have been discussing this topic with Hachette's head of digital strategy and one of Penguin Random House's digital production specialists.)

If it is not meant to be hand coded then I would think that starting with Markdown is a bad idea. Markdown was meant to be human readable with minimal markup. This means that there are many limitations as to what you can represent in Markdown.

To me, it would make sense to start with something more expressive. There are many different types of books (fiction, technical, poetry, interactive) and many types of semantic information that you will need to encode that publishers may require. Moreover, it is not just semantic information you need to capture. For some books the placement of the elements on the page, the font used, etc. may be important. If this format is also meant as an intermediate format for printed books then you only need to take a look at LaTeX and its numerous packages to get an idea of all the different things someone might require.

Even if you decide to go with something like Markdown, it makes sense to look at mmd and pandoc extensions (e.g. for tables) before coming up with another syntax.

I liked the $ for use of non-markdown meta-data.. but then you went and changed how paragraphs work. I was also pretty sure that \# was the outline marker..

I feel like you removed a lot of usefulness from markdown with this format.

Yeah, you clearly have never made an eBook. It's a jungle out there.

Reply on news.ycombinator.com