3 ms·

I haven't played much with any of this stuff, but one thing that I'm curious about is what is the advantage of having a container format like this, rather than

I haven't played much with any of this stuff, but one thing that I'm curious about is what is the advantage of having a container format like this, rather than just having a single giant HTML file (with embedded CSS & data: uri images)? For editing this would be ridiculous, but for transport and presentation it seems much more compact and useful. It is easy to target as an output format for a variety of tools, without understanding a bunch of quirks of the format. It would be easier to render, since the application has to make all the decisions about where to place content and support reflowing anyway.

hombre_fatal 6y ago
An .epub is already what you describe; it's a .zip of .xhtml, images, and supporting files you edit directly seen in the sidepanel: https://i.imgur.com/tdCGcqS.png https://i.imgur.com/tdCGcqS.png An ebook editor just entails helping you edit those .xhtml files in a slightly more domain specific way, generating a few extra files (like table of contents), and producing the distributable zip. Though I may have misunderstood which "container format" you were referring to.
- andrewla 6y ago
  No, what I'm describing is a single .html (or .xhtml file, if you like), compressed and sent on its way. Editing it as a series of xhtml, css, img, and manifest files makes perfect sense -- it allows a human to craft a book using the level of tooling that makes the most sense for them (from a word document to raw html to markdown to more sophisticated tools) but all of those tools can then retarget to a monolith that is easy to define and consume.
  - hombre_fatal 6y ago
    One big file is hard to handle. Ereaders choke on them just like the browser does.
    - andrewla 6y ago
      They do; probably xhtml/XML is not really an ideal format because it isn't easily linearalizable, but if ereaders are using a reduced set of the functionality, then they can probably safely assume that they can just split the file at a <p> or <mpb:chapter> tag without loss of fidelity, and just consider that all style-related content needs to occur in <head>. My comment below has some remarks on pagination and reflowing that mean that a reflowable HTML file capable of being rendered by an ereader is likely subject to certain restrictions on the content to make it work. There would probably have to be a one-time indexing job (noting paragraph and chapter breaks to allow random-ish access into the file) but I think that's not crazy even for a very large document.
Someone 6y ago
For long books or books containing large images or videos, that giant HTML file would be so gigantic that many e-readers would be slow at loading them or even fall over (the average e-reader doesn’t have a fast CPU or loads of memory). I also expect data URIs for images would make the HTML file, even if gzipped, larger than the equivalent ePub. HTML also isn’t good at doing the book-like things such as pagination, tables of content and on-page footnotes.
- andrewla 6y ago
  Videos? I guess for some applications. Either way, the giant HTML file is nasty, yes, but the epub would be the same size [1]. It would be harder to process, though, because even XHTML has a nesting structure that doesn't lend itself to decomposition easily. For the most part ebooks are reflowable, so pagination only matters in the sense of manual page breaks, and HTML has to be extended to handle that even for epub. Similarly on-page footnotes (<aside> in iBook epub and <a href><sup> for Kindle) need to be handled now in HTML extensions. Tables of contents and indexing content is a little harder, but if the format were well-defined (something like <chapter> tags, or just using <h1> as semantic tags) then it would be easy to generate as well. Or it could just be done using a bunch of <a href> in an explicit TOC -- easy enough for a compiler to handle. Metadata is in theory more difficult, for things like author, etc., but defining tags in the <head> of the document would be just as easy as the manifest definitions that readers have to deal with now. [1] gzipping random data base64 encoded is ~3% increase in file size.
jasonv 6y ago
I'm writing a book with three levels out output, think "simple" then "medium" then "advanced". Writing it in sections and assembling the sections for rendering allows me to also export for multiple targets, and multiple versions. Think "build" for books.
- andrewla 6y ago
  For authoring without a doubt having multiple sections makes perfect sense. But as a target a monolith is fine and reduces complexity.

hombre_fatal 6y ago

An .epub is already what you describe; it's a .zip of .xhtml, images, and supporting files you edit directly seen in the sidepanel: https://i.imgur.com/tdCGcqS.png https://i.imgur.com/tdCGcqS.png An ebook editor just entails helping you edit those .xhtml files in a slightly more domain specific way, generating a few extra files (like table of contents), and producing the distributable zip. Though I may have misunderstood which "container format" you were referring to.

andrewla 6y ago
No, what I'm describing is a single .html (or .xhtml file, if you like), compressed and sent on its way. Editing it as a series of xhtml, css, img, and manifest files makes perfect sense -- it allows a human to craft a book using the level of tooling that makes the most sense for them (from a word document to raw html to markdown to more sophisticated tools) but all of those tools can then retarget to a monolith that is easy to define and consume.
- hombre_fatal 6y ago
  One big file is hard to handle. Ereaders choke on them just like the browser does.
  - andrewla 6y ago
    They do; probably xhtml/XML is not really an ideal format because it isn't easily linearalizable, but if ereaders are using a reduced set of the functionality, then they can probably safely assume that they can just split the file at a <p> or <mpb:chapter> tag without loss of fidelity, and just consider that all style-related content needs to occur in <head>. My comment below has some remarks on pagination and reflowing that mean that a reflowable HTML file capable of being rendered by an ereader is likely subject to certain restrictions on the content to make it work. There would probably have to be a one-time indexing job (noting paragraph and chapter breaks to allow random-ish access into the file) but I think that's not crazy even for a very large document.

Someone 6y ago

For long books or books containing large images or videos, that giant HTML file would be so gigantic that many e-readers would be slow at loading them or even fall over (the average e-reader doesn’t have a fast CPU or loads of memory). I also expect data URIs for images would make the HTML file, even if gzipped, larger than the equivalent ePub. HTML also isn’t good at doing the book-like things such as pagination, tables of content and on-page footnotes.

andrewla 6y ago
Videos? I guess for some applications. Either way, the giant HTML file is nasty, yes, but the epub would be the same size [1]. It would be harder to process, though, because even XHTML has a nesting structure that doesn't lend itself to decomposition easily. For the most part ebooks are reflowable, so pagination only matters in the sense of manual page breaks, and HTML has to be extended to handle that even for epub. Similarly on-page footnotes (<aside> in iBook epub and <a href><sup> for Kindle) need to be handled now in HTML extensions. Tables of contents and indexing content is a little harder, but if the format were well-defined (something like <chapter> tags, or just using <h1> as semantic tags) then it would be easy to generate as well. Or it could just be done using a bunch of <a href> in an explicit TOC -- easy enough for a compiler to handle. Metadata is in theory more difficult, for things like author, etc., but defining tags in the <head> of the document would be just as easy as the manifest definitions that readers have to deal with now. [1] gzipping random data base64 encoded is ~3% increase in file size.

jasonv 6y ago

I'm writing a book with three levels out output, think "simple" then "medium" then "advanced". Writing it in sections and assembling the sections for rendering allows me to also export for multiple targets, and multiple versions. Think "build" for books.

andrewla 6y ago
For authoring without a doubt having multiple sections makes perfect sense. But as a target a monolith is fine and reduces complexity.