• Print

Keep Your Eye on the epub Ball (But Do Play Nice)

On Peter Brantley‘s Reading 2.0 email list, former IDPF director Nick Bogaty offered a great argument for dialing down some of the pressure aimed at device makers for not yet fully supporting the .epub ebook standard. Nick has kindly given permission to have his comments reprinted here:

While companies like the one I work for have broadly implemented .epub support in its eBook products (in Adobe’s case in InDesign CS3 for making .epub and Digital Editions for consuming it), I think it is too early to question vendor support for the .epub format. The final piece of the .epub specification (which is really composed of three specs) was only approved in September 2007 and it takes time for big companies to digest the implications of .epub on their businesses, integrate it into their products etc.

When we were making the .epub format when I was at the IDPF, we envisioned that eBook hardware and software would handle .epub in one of two ways. The first way is to simply render (in the case of eBooks that means "read") .epub files natively. Personally this is what I think makes most sense and it is what Adobe thinks makes most sense. You get an .epub file, open it in a piece of software or on an ebook reading device, and you’re reading an .epub book. This scenario uses .epub as a consumer format.

The second way is for software or a device to take an .epub file and automatically convert it to a proprietary format. A publisher creates an .epub file, sends it to a vendor or through a channel that they want to sell, and that vendor or channel builds some sort of automatic conversion of the .epub to a proprietary format. There are many reasons for doing this, and all reasons generally have to do with companies thinking the .epub format doesn’t meet the requirements of their hardware or software. This scenario uses .epub as a distribution format.

Either way, the advantage for publishers is very clear. Until now publishers had to convert to X numbers of formats if they wanted to take advantage of X numbers of channels. This significantly raised costs for publishers and forced publishers to make a strategic decision on what parts of their inventory they wanted to convert to an eBook in order to recoup their investment in conversion. And this had depressing consequences for consumers. Imagine going into a Barnes & Noble store with only 10,000 titles available.

What .epub really gives publishers is leverage. They can say to their vendors and channels, "ok, I’m now only giving you .epub and you better either provide software that reads .epub or provides an automatic conversion from .epub to Y format." This tremendously lowers costs and aggravation for publishers and, I strongly suspect, will increase inventory through the channels quite dramatically. The decision to create an eBook is just so much easier to make. And, if a hot eBook startup (or existing non-compliant eBook device/software) comes along to a publisher and says, "I’ve got this great device or software, give me your books in my format," a publisher can say, "you get .epub if you want my books." I strongly suspect that in the coming months, this above scenario of ".epub only" will start to happen more and more as publishers begin to produce .epub and understand its tremendous benefits to their digital businesses. And, publishers can use this leverage to get their software and ebook device partners to implement .epub a little faster.

While people don’t seem quite in the mood these days to do so, I’d give Amazon (and others) the benefit of the doubt and a little time on .epub. The format is clearly in everyone’s best interest.

[Links and emphasis added]

Nick’s comments are reasoned and rational (not unexpected from someone who’s spent time on both the standards side and the vendor side). And while publishers need to be realistic in their expectations for adoption of such a new standard (here at O’Reilly we’re still working ourselves to efficiently retrofit content for .epub), publishers still need to keep the .epub goal in sight, and make sure that our actions continue progress toward that endpoint. As Nick suggests, saying "ok, I’m now only giving you .epub and you better either provide software that reads .epub or provides an automatic conversion from .epub to Y format" is the right way to go, for publishers and consumers.

tags: ,
  • http://www.threepress.org/ Liza Daly

    I’m a little surprised to see .epub offered as a publisher’s source format rather than the end product of a workflow. .epub’s source markup is just XHTML, and XHTML is still largely based on loose semantics that could apply to any type of electronic document. I imagine most publishers would want a source format with a richer, more book-like vocabulary — TEI or DocBook come to mind — and only convert to something like .epub for distribution to an ebook reader.

    Going from .epub to Y format — where Y format is semantically richer than XHTML — would be difficult to do automatically.

  • bowerbird

    > What .epub really gives publishers is leverage.
    > They can say to their vendors and channels,
    > “ok, I’m now only giving you .epub and you
    > better either provide software that reads .epub
    > or provides an automatic conversion
    > from .epub to Y format.”

    of course, they could do that with _any_ format…

    -bowerbird

  • http://toc.oreilly.com Andrew Savikas

    @bowerbird: Sure, but the point is that it’s a “good enough” and transparent standard that publishers can agree on. If we all just assume ePub, then we can get on with more important things. When launching a new website, there’s no discussion of what “format” to use — HTML/CSS/JavaScript are assumed. ePub could be the same for book-style content.

  • bowerbird

    i strongly disagree that epub is “good enough” right now
    — would you like me to go through all its shortcomings,
    one by one, to demonstrate you are wrong about that? –
    but even if i did agree that epub is “good enough”, then
    there are many other formats that are “good enough” too.

    so if we would all “just assume” any one of them, we could
    “get on with more important things”…

    but premature optimization is not a good thing.

    where are the free and open-source epub reader-programs?
    where are the free and open-source epub authoring-tools?

    we don’t have many good solid ideas about what the _library_
    of the future will look like, so how can we even decide what
    variables we need to use to evaluate a format’s effectiveness?

    anyway, i’m sure the publishing industry will indeed settle
    on some “standard”, and i’m sure that it will be a format that
    requires expensive authoring apps with steep learning curves,
    so as to raise the cost of entry for all those new small upstart
    publishing companies that want to take advantage of the new
    level playing field, so i’d say that epub likely has a good shot.

    but if you think the people out here doing research on formats
    that can maximize the possibilities while minimizing the costs
    are gonna _stop_ doing our work, just because “the industry”
    has decided on _their_ “standard”, i will say that you’re wrong.

    the dinosaurs passed a law. but the mammals ignored it…

    -bowerbird

  • http://toc.oreilly.com Andrew Savikas

    @bowerbird: Sure epub has shortcomings, but so does HTML and so does DocBook XML (or PDF for that matter), formats we use extensively here at O’Reilly. If the content producers don’t push for adoption of an open standard, then I fear that a device will establish a de facto one, which is bad for publishers and in my opinion bad for readers. I disagree that we’re headed for expensive authoring tools — but I also don’t see ePub as an authoring environment anymore than HTML. I see ePub as a delivery format. As for open source options, our engineers have (in collaboration with engineers at Adobe) developed new stylesheets for the DocBook XSL package to allow for ePub output from DocBook source.

    As for open source options, our engineers have been collaborating with Adobe on new stylesheets for the DocBook XSL project to allow for ePub output from DocBook source. The initial work on that is complete and will be in the next release of the stylesheets, but you’re welcome to check out the code from Subversion today.

  • http://kfahlgren.com/blog Keith Fahlgren

    bowerbird wrote:
    > where are the free and open-source epub reader
    > programs?

    As you know, Adobe Digital Editions is free but not open-source. The FBReader project is the most widely-known open-source .epub reader.

    > where are the free and open-source epub
    > authoring-tools?

    The wonderful part about the .epub standard is how trivial it is to make .epub files without any expensive authoring tools. The best introduction to that topic is Bob DuCharme’s Creating epub files with nothing but free tools.

    > a format that requires expensive authoring apps
    > with steep learning curves, so as to raise the
    > cost of entry for all those new small upstart
    > publishing companies that want to take
    > advantage of the new level playing field, so
    > i’d say that epub likely has a good shot.

    Just the opposite. Building an .epub delivery channel will be much easier for upstart publishers than any print channel.

  • bowerbird

    docbook? oh boy, that gives me a good chuckle… :+)

    adobe’s digital-editions would be a respectable effort
    if it had come from some hacker working by himself…
    but one of the biggest software companies in the world?
    well, it’s kind of embarrassing…

    fb-reader is quite an achievement, but it still hasn’t
    implemented the css part of xhtml/css, which means
    it’s about half-way to where it needs to be…

    yeah, it’s “trivial” to make .epub files with “nothing but
    free tools” just as long as you’re a whiz with xhtml/css,
    which is exactly why i say the learning curve is too high.

    i think the non-technoids will see things the way i do…
    and i don’t think you technoids will be able to sway them,
    no matter how much you and i “debate” the situation here.

    -bowerbird

  • bryce

    @bowerbird
    “yeah, it’s “trivial” to make .epub files with “nothing but
    free tools” just as long as you’re a whiz with xhtml/css,
    which is exactly why i say the learning curve is too high.”

    Actually, I do web design in my spare time, not professionally, and (X)HTML/CSS is not that difficult to learn. The hard part is getting the OPF file and NCX file typed up properly, as well as compressing it correctly. There are programs that can export to epub for you, but it is best to make it yourself. So far, I’ve made 2 epub files and I did not shell out a dime.

  • bowerbird

    it’s nice to revisit threads after a year… :+)

    on the one hand, things sure have changed.
    last april, there was no such banana as stanza.
    so, at least in terms of a somewhat-respectable
    viewer-program, we’re a little better off today…
    (although the “progress” that’s been made on
    digital editions by adobe is quite frightening.)

    on the other hand, .epub still doesn’t have a
    decent authoring-tool, let alone one that is
    free-as-in-speech and free-as-in-beer too,
    let alone a pair of such open-source programs
    — each with a solid core of sharp contributors –
    that would be pushing each other to get better,
    which is what a healthy “standards” plan would
    start with in terms of reference implementations.
    but the publishing industry decided to bankroll
    efforts by shortcovers and scrollmotion instead.

    so, all in all, not much progress in the last year.

    -bowerbird

  • Bryce

    “on the other hand, .epub still doesn’t have a
    decent authoring-tool, let alone one that is
    free-as-in-speech and free-as-in-beer too…”

    Decent authoring tools may not exist, but you can always reuse the important files and edit them, if necessary for the new ebook. You can even write up a batch file or shellscript to get the proper compression done, especially since Info-Zip is free-as-in-beer and under an open-source license. I never memorized the commands needed to make an epub from the terminal, I just use a shellscript. You could suggest it to be included as an export option from OpenOffice too. After all, the only software that really is free-as-in-beer and free-as-in-speech are those programs that come with the Linux operating system out off the box (with a few distributions that are exceptions).

  • bowerbird

    bryce said:
    > Decent authoring tools may not exist,
    > but you can always reuse the important files
    > and edit them, if necessary for the new ebook.

    bryce, you act like you don’t need an authoring-tool.
    and maybe _you_ don’t. but most authors _do_, and
    that means the people who are trying to get authors
    to adopt a standard should provide authoring-tools.

    the .epub people have put the cart before the horse.

    instead of providing the tools, and giving end-users
    experience with the tools, and improving those tools
    in reaction to feedback, to the point where the format
    is enthusiastically adopted by so many people that it
    becomes the “standard” by default, .epub supporters
    are trying to ram the standard down the public throat
    with only the crudest of tools available to make it real.

    > You could suggest it to be included
    > as an export option from OpenOffice too

    see, this is the kind of garbage that comes from this
    approach that concentrates on adopting the format…

    openoffice is not _designed_ as the type of program
    that would lead to the kind of _structured_semantics_
    which formed the appeal of the original call for .epub.
    it’s fully possible to code gibberish using x.m.l./c.s.s.

    > After all, the only software that really is
    > free-as-in-beer and free-as-in-speech
    > are those programs that come with the
    > Linux operating system out off the box
    > (with a few distributions that are exceptions).

    there are lots of _free_ programs out there,
    where i mean _free_ in the stallman definition.
    and even more under the diluted “open source”
    definition. but in my own mind, i’m happy to
    settle for cost-free (free as in beer), even if i
    don’t have access to the source-code, as long
    as the program continues to work as intended
    on whatever machinery is sitting on my desk…

    but…

    if a big part of the appeal of your advocacy of
    a specific format is that it is “an open standard”,
    then i believe that you are _obligated_ to provide
    reference implementations that are “open source”,
    and which are backed by solid programming teams,
    rather than spewing out the line that “they will come”.

    the “open standard” on which .epub was built has
    been around for about a decade now, and it _still_
    doesn’t have an open-source authoring-tool for it.

    and let’s not even get into the ugly discussion about
    whether we want _adobe_ to have its finger in the pie,
    because i can guarantee you that _some_ of us think
    that that would be a _very_ stupid route long-term…

    -bowerbird

  • Bryce

    “openoffice is not _designed_ as the type of program
    that would lead to the kind of _structured_semantics_
    which formed the appeal of the original call for .epub.
    it’s fully possible to code gibberish using x.m.l./c.s.s.”

    Maybe, but you were referring to making things simplified for the end users to save to the format. If you don’t want the gibberish you get from programs like MS Office or OpenOffice, then you better do the CSS, XML, and HTML coding yourself and use the W3C validators and epubcheck to flesh out the code to make it clean and valid.

    “bryce, you act like you don’t need an authoring-tool.
    and maybe _you_ don’t. but most authors _do_, and
    that means the people who are trying to get authors
    to adopt a standard should provide authoring-tools.”

    Authoring tools are just simply a word processor (e.g. MS Office and Openoffice) and/or desktop publisher (e.g. Scribus and InDesign) and HTML/Text editor (e.g. Dreamweaver, Notepad, BBedit, TextEdit, Smultron, gedit, pico), if you are just looking at epub. Why would it be even more that? After all, you can’t rely on a program’s builtin grammar, as everyone knows those won’t help you write a good book. If you wanted something more, then you could just program it in Java or Python. there are also GUI front-ends to Info-Zip, so that can simplify the process. Which is it that you want? none of the gibberish or something simpilified for exporting to the format, because you can’t have it both ways when it comes to XML and HTML?

  • bowerbird

    bryce said:
    > you were referring to making things simplified
    > for the end users to save to the format.

    that’s one of the design imperatives, yes. but not the only one.

    > If you don’t want the gibberish you get
    > from programs like MS Office or OpenOffice,
    > then you better do the CSS, XML, and HTML
    > coding yourself and use the W3C validators
    > and epubcheck to flesh out the code
    > to make it clean and valid.

    no. emphatically not. a dedicated authoring-tool
    would be incapable of creating “non-valid” output,
    if it was worth its salt. moreover, it would be built
    from the ground to work on a _structural_ basis
    — some people would say “semantic” here, but
    that shows they don’t know what that means –
    rather than operating on a _presentational_ level…

    > Authoring tools are just simply a word processor
    > (e.g. MS Office and Openoffice) and/or
    > desktop publisher (e.g. Scribus and InDesign)
    > and HTML/Text editor (e.g. Dreamweaver,
    > Notepad, BBedit, TextEdit, Smultron, gedit, pico),
    > if you are just looking at epub.

    well, you threw a lot of programs into that mix, but
    most of ‘em are purely presentational w.y.s.i.w.y.g,
    so they simply can’t do the job that should be done
    if you’re going to shepherd people into x.m.l./c.s.s.

    and if you ain’t gonna do that right in the first place,
    there’s little reason to call in x.m.l. complexity at all.

    what we’ve got right now is a good share of the costs
    and very few of the benefits, so it’s an all-around loss.

    > Why would it be even more that?

    well, if you don’t understand, i’m sure i can’t explain it.

    > If you wanted something more, then
    > you could just program it in Java or Python.

    i think you have me confused with an .epub supporter.

    > Which is it that you want? none of the gibberish
    > or something simpilified for exporting to the format

    both. and a whole lot more than that.

    > because you can’t have it both ways
    > when it comes to XML and HTML?

    is that a statement, or a question?

    -bowerbird

  • Bryce

    “no. emphatically not. a dedicated authoring-tool
    would be incapable of creating “non-valid” output,
    if it was worth its salt. moreover, it would be built
    from the ground to work on a _structural_ basis
    — some people would say “semantic” here, but
    that shows they don’t know what that means –
    rather than operating on a _presentational_ level…”

    I beg to differ. epubcheck checks both the xml and HTML and most editors that output what you type in will add in stuff that should not be there, especially things that are only meant for special circumstance like “” and ““. Most editors will use those or the depercated “” and “” tags, which are invalid in XHTML 1.1. This is because epub is a zip container with XML and HTML files that validate according to the XHTML.

    “well, you threw a lot of programs into that mix, but
    most of ‘em are purely presentational w.y.s.i.w.y.g,
    so they simply can’t do the job that should be done…”

    And that is what authoring tools will do. Do you really believe that any program to simplify the export to epub will put you into code view? No, it won’t. In fact, people will most likely be working in the WYSIWYG mode.

    “if you’re going to shepherd people into x.m.l./c.s.s.

    and if you ain’t gonna do that right in the first place,
    there’s little reason to call in x.m.l. complexity at all…”

    That is why you use a document as a template and edit the necessary info, it is more likely to be correct that way.

    “well, if you don’t understand, i’m sure i can’t explain it.”

    Again authoring tool for epub would just be a word processor and/or desktop publisher and Text/HTML Editor bundled together. If it was not that way, you’ll get gibberish, unless W3C was behind the program. The word processor and/or desktop publisher gives you want the contents should be presented as, then you go onto the text editor and make sure that the code is valid XHTML, as well as look at the XML data, such as table of contents, container.xml, and content.opf. Editing them accordingly. After that, the program will need to generate the proper mime type. Also, one thing that could go wrong is that, when making the spine, how will you that the program used itemref and idref.

    “think you have me confused with an .epub supporter.”

    No, I have not confused you with a supporter. I just can’t believe that you don’t realize that authoring for the epub format would be just like an IDE in programming and those don’t even get their job done the proper way.

    “both. and a whole lot more than that.”

    Sorry to break it to you, but that is not possible, unless you hand code and use old files as template files for other ebooks.

    is that a statement, or a question?

    What sentence would start with the word because and have a question mark? It was part of the question you just answered

  • Bryce

    it looks like the tags were done wrong in the output, so what was supposed to be there was supposed to be the emphasis tag, the strong tag,the italics tag (deprecated), and the bold tag (deprecated).

  • bowerbird

    bryce, i don’t understand the nature of the position you’re arguing.

    sometimes i think you’re saying that people should use _existing_
    authoring-tools, like ms-word or even bbedit, but then i seem to
    hear you saying that these programs won’t do the job correctly, so
    again, i’m not sure what you’re saying, or why you’re saying that…

    (i do agree with the side that says that those programs will _not_
    do the job correctly, which is why they don’t qualify, in my book.
    and throwing in things like hand-coding and recycling old files
    turns your workflow into a full non-starter from my perspective.
    self-publishing authors don’t want to have to deal with all that,
    and they don’t want to have to hire technoids to do it for them.)

    so…

    what i do understand is that i program e-book authoring-tools,
    and viewer-programs, which can demo _exactly_ what _i_ mean.

    i mean that you can type your book in, from scratch, according to
    an easy-to-use format that i’ve developed, and then click a button
    to output versions of the book in .pdf and .html (of various kinds).

    along the way, while you’re writing and rewriting, you always have
    a wysiwyg display showing you exactly what your book looks like,
    and of course you can output “in-process” .pdf and .html if desired.

    if i wanted to, i could have it output the book in .epub format too.
    but i don’t. still _that’s_ the kind of authoring-tool that is needed,
    if the .epub supporters would like to prove the value of the format.

    plus, of course, you need viewer-apps that are state-of-the-art,
    because that is the sine qua non of an e-book format, is it not?

    -bowerbird

  • Bryce

    “you’re saying that people should use _existing_
    authoring-tools, like ms-word or even bbedit,”

    I would not consider ms-word an authoring tool. BBedit is more of a text editor than a word processor or desktop publisher, so your indents won’t show up in the output.

    “throwing in things like hand-coding and recycling old files
    turns your workflow into a full non-starter from my perspective.”

    You sure you want to retype all that XML yourself? Reusing old files saves you time, when hand-coding. After all, I doubt even professional web developers/designers hand-code the entire page of every web page for a site. It makes more sense and is more productive to reuse old files and edit them as necessary for the new work.

    “plus, of course, you need viewer-apps that are state-of-the-art,
    because that is the sine qua non of an e-book format, is it not?”

    If you look at what an epub is, which is just HTML, CSS, and XML inside a zip, you really only need a web browser to preview the content (other formats would hold true to your statement though). Using a viewer won’t give you a good preview because each viewer will divide up the pages differently, as well as display the text differently (just like web browsers display content differently than other browsers). There is also the fact that those viewer apps would need epub input, which means that you’ll need to export the epub more than once. True, you could probably load the HTML file into those viewers, but what if the whole book were in separate HTML files, instead of just one? After all, there is hardly an viewer that gives you the ability to use tabs, so you can open multiple files in the reading view at once, like a web browser can.

    “self-publishing authors don’t want to have to deal with all that,
    and they don’t want to have to hire technoids to do it for them.”

    Not all self-publishing authors are like that. Not all self-publishing authors are novices to web design and XML. Since you say you’re a programmer, you should know that it is easier to reuse the old XML files. Yes, you probably don’t want the HTML to have the same stylesheet as a previous book, but let’s say you’ve got a 39-40 chapter ebook, each chapter is separated out into separate HTML files whether grouped by part or each chapter really is its own file and each part or chapter used the same formatting. Do you really want to type out the entire HTML, as well as the XHTML doctype and link or import the stylesheet or type the CSS into the HTML file itself each and every time? I would rather do the entire coding for only one of those parts or chapters and save it as whatever I named the next part or chapter, so I don’t need to keep typing the link tag or the import statement in between the style tags, if each of those parts used the same formatting. The only thing I’d need to change would be what is inside of the body tag. This also saves time, because XHTML 1.0 and XHTML 1.1 don’t allow quotation marks to be present in the document expressively, you need to enter it in a special way, and you also need the force the viewer to do a double space after every sentence. So really you’ll not only be typing up another HTML page entirely, you’ll also be spending a lot of time replacing quotation marks with the special code for them and the special code to make a double space instead of single between sentences.

  • bowerbird

    bryce, i do believe this conversation has become unworthy of
    the attention of the lurkers, which is a bad place to be in, but
    i will try this one more time as an assumption of good faith…

    > I would not consider ms-word an authoring tool.
    > BBedit is more of a text editor than a word processor
    > or desktop publisher, so your indents won’t show up
    > in the output.

    none of the programs you’ve mentioned — with the exception of
    indesign — qualify, so there’s no need to talk about them at all.

    > You sure you want to retype all that XML yourself?

    no. i want the authoring-tool to do it. that’s the whole point.

    > Reusing old files saves you time, when hand-coding.

    right. but i don’t want to do hand-coding. very few people do.

    > I doubt even professional web developers/designers
    > hand-code the entire page of every web page for a site.

    there’s no need to talk about hand-coding at all, because
    that’s not a workflow that will work out in the real world…

    the only people doing hand-coding are the ones who are
    too cheap to buy indesign to save themselves some time…

    the problem is, indesign costs too much money, and there is
    no reason an “open format” should have to cost people money.

    > It makes more sense and is more productive to
    > reuse old files and edit them as necessary for the new work.

    no, it makes more sense for an authoring-tool to prompt you
    for the information that’s particular to the book, and then plug
    that unique information into its tested internal x.m.l. template.

    it’s not just a waste of your time to have to do that _manually_,
    it’s also a deadly invitation for errors to creep into the process.

    > If you look at what an epub is, which is just
    > HTML, CSS, and XML inside a zip, you really only need
    > a web browser to preview the content

    except a web-browser won’t preview .epub content, because
    — as you said — it’s inside a zip. and even if a web-browser
    _would_ do the unzipping, and understand the package files,
    it still wouldn’t necessarily be a decent e-book viewer-program,
    not without considerable additional programming, of the type
    that liza daly has just _begun_ to start doing with “bookworm”.

    again, what you’re doing is suggesting some kind of workflow
    built on a bunch of half-assed hacks that work marginally well
    (which is to say, “not too well at all”), which is fine for technoids,
    but will never be suitable for the majority of authors out there.

    > Not all self-publishing authors are like that. Not all
    > self-publishing authors are novices to web design and XML.

    you don’t build a workflow for the most-sophisticated users…
    you build it for the _least_ knowledgeable people in the group.

    > Do you really want to type out the entire HTML,
    > as well as the XHTML doctype and link or
    > import the stylesheet or type the CSS
    > into the HTML file itself each and every time?

    no, bryce, i don’t. i want the authoring-tool to do it for me.
    i want the authoring-tool to perform _all_ the tedious stuff.
    i repeat, that’s the whole point of having an authoring-tool.

    and this is pretty basic stuff, bryce. it’s certainly nothing that
    we need to be discussing in dialog here. so i’ll opt out now…

    if you wanna educate yourself about .epub authoring-tools,
    i suggest you try the ones offered at feedbooks.com, and
    bookglutton.com, and azardi at infogridpacific, and “ecub”.

    after that research, you should have a much better idea on
    what an authoring-tool would do for people, and why they
    would want to use such a tool rather than do it all manually.
    none of the tools is very good, but they’ll give you the idea.

    -bowerbird

  • Bryce

    “no. i want the authoring-tool to do it. that’s the whole point.”

    In other words, you want an IDE for ebooks.

    “none of the programs you’ve mentioned — with the exception of
    indesign — qualify, so there’s no need to talk about them at all.”

    Funny, I thought you did not want Adobe to be involved with epub, yet you say InDesign qualifies for what you want. Quite ironic.

    “except a web-browser won’t preview .epub content, because
    — as you said — it’s inside a zip. and even if a web-browser
    _would_ do the unzipping, and understand the package files,
    it still wouldn’t necessarily be a decent e-book viewer-program,
    not without considerable additional programming, of the type
    that liza daly has just _begun_ to start doing with “bookworm”.”

    You use the web browser to get the formatting correct. Why do I want to export an epub, without seeing the output in a browser first? Why would I want to upload epub to W3C, when I need the HTML validated?

    “you don’t build a workflow for the most-sophisticated users…
    you build it for the _least_ knowledgeable people in the group.”

    True, but your statement assumed all self-publishing authors are novices at coding files.

    “no, bryce, i don’t. i want the authoring-tool to do it for me.
    i want the authoring-tool to perform _all_ the tedious stuff.
    i repeat, that’s the whole point of having an authoring-tool”

    That is the exact definition of an IDE and like I told you time and time again, it won’t be done properly, because no editor can make the valid XHTML required for epub in WYSIWYG mode, which is what the non-sophisticated users will use.

    “if you wanna educate yourself about .epub authoring-tools,
    i suggest you try the ones offered at feedbooks.com, and
    bookglutton.com, and azardi at infogridpacific, and “ecub”.”

    They all stink. Bookglutton is pretty close to good in idea (requires an HTML input though), but each of them either won’t let me upload a source file or they make me use their interface. Also, how do you know those will be valid? I know for a fact that Stanza Desktop and Bookworm will not read invalid epub files, and since feedbooks uploading process is pathetic, then its not worth my time either.

    “the only people doing hand-coding are the ones who are
    too cheap to buy indesign to save themselves some time…”

    Or maybe they want to be sure their epub is actually valid the first time around, instead of needing to manually flesh it out in the end anyway. This statement is similar to saying the only people who hand-code HTML are too cheap to buy Dreamweaver.

    “no, it makes more sense for an authoring-tool to prompt you
    for the information that’s particular to the book, and then plug
    that unique information into its tested internal x.m.l. template.

    it’s not just a waste of your time to have to do that _manually_,
    it’s also a deadly invitation for errors to creep into the process.”

    First, errors are not that likely to occur reusing old files. Second, after the XML is first handed, it can itself be used as a template, hence the reason why reusing files is more productive, especially if the code file has comment about the entries typed.

    “right. but i don’t want to do hand-coding. very few people do.”

    Then how would you know how to create valid epub. Hand-coding helps you to know what to look for to ensure that you get a valid epub every time.

    “i do believe this conversation has become unworthy of
    the attention of the lurkers, which is a bad place to be in…”

    that depends on the reader about whether or not it is worthy. There is balanced between ease-of-use and practicality, which some people don’t see clearly. You can’t have both and one needs to be sacrificed to satisfy the other.

  • bowerbird

    > that depends on the reader about whether or not it is worthy.

    i want to reach the vast majority of sophisticated readers here,
    so i must maintain the standard i would expect of such readers,
    so they will continue to read the threads in which i am involved.

    this conversation has not been at that level. best of luck, bryce.

    -bowerbird

  • Bryce

    “this conversation has not been at that level.”

    It has not been that way because you can’t look at look at the fact that authoring tools will always have faults. You have kept forgetting that to make something easier, you give something up. There is no programmer or company that will go to W3C and make sure that the HTML is valid XHTML in the output the program creates. That is the reason IDEs and programs like Dreamweaver have a code view as well as WYSIWYG mode, so you can fix the code before the file or project is exported. I am pretty sure you can make such a program, but one thing I know from doing a bit of programming myself is that unless you understand how the format is made manually, you will never be able to implement it properly in a custom program. This is true for both programs that make web design easier, as well as the epub format.

    While you did have good arguments, you need to realize what is possible and what is not possible, in maintaining ease-of-use.

  • bowerbird

    bryce, i’m a programmer. i _know_, with very great certainty,
    exactly what is possible. and, with less certainty, what is not.
    and i don’t ask anything of anyone else that i can’t do myself.
    i always practice what i preach, and i preach what i practice…

    now, if you’ll excuse me, i really must be going…

    -bowerbird

  • JamesH

    Sorry Bryce, but I have to agree with bowerbird on this argument. You need to have the tools to build the book if you want it to be the standard. I sure don’t know why you have a hard time grasping that concept.

  • Bryce

    “Sorry Bryce, but I have to agree with bowerbird on this argument. You need to have the tools to build the book if you want it to be the standard. I sure don’t know why you have a hard time grasping that concept.”

    It may appear that I was having a hard time grasping the concept, but my reasoning is that it cannot be done because epubs need to have valid xml and valid HTML 4.x or valid XHTML and right compression options to work across different software platforms. In other words, a valid epub file.

    Yes, having the tools to build it is going to make it easier, but there is no program that generates perfectly valid epub files. In fact, not even Adobe gave Indesign an exporter that sends out valid epubs. After all, I do have a copy of the epub checker Java program, which anyone can download, and there is one site that uses it internally, so there is no excuse to come out with a program that can’t make them perfectly valid. After all, I could do it by editing xml files from already existing and valid epubs and creating the (X)HTML files myself, especially if the document is commented like a program source file. The only thing that can be done without any problem is getting the mimetype right.

    This is practically the same as WYSIWYG editors and hand-coding in HTML. You can use which ever one you want, but only doing it manually will guarantee a standard-compliant (aka. valid) file, web page, or website.

    In fact, if anyone wants to see why valid epub files are more important than just exporting as an epub, look at O’Reilly’s bookworm service. You can only upload valid epubs successfully, because it gives the errors if it is not. On the other hand, that site uses the epub checker Java program internally, so you know where the problem is.

    That is where my main point.