@france.baril: Keeping headers as H1 (for instance) ensures consistent rendering from e-reader to e-reader; it’s easier to preserve consistently; and it’s easier to port to other formats if need be (Mobi doesn’t support CSS, for example, so styled <span> tags don’t play well).
There is a world of commercial publishing that ePub, KF8, PDF, etc. have been created to allow for ebooks. However, because of HTML being so successful for browsers on computer screens, the aspect of the device has created huge confusion over how to deal with publishing. Steve Jobs created the Next computer with full WYSIWYG screens and printing using PostScript. By equating the two distinct media, CRT and 8.5“x11” paper, was the recognition of power of verisimilitude. Obviously, new viewing devices and new methods to physically interact with data and documents have made the importance of serving content in a multitude of ways.
For example, looking at legislative documents, the issue of authenticity and verisimilitude are much more significant and trump the issues that are driving the ebook issues mentioned in the Publications Standards article. And for these reasons, there is no good answer on formats for legal documents. One aspect is that line and page numbering are artifacts of publishing on paper with typography. And so for legal documents, academic and other crucial document creating communities, the discussion is a lot noise that often misses their issues.
I would say that a single XML file can not meet the needs of publishing. Nor can a simple PDF or any other single file approach. Essentially, there are layers that are often out of sync with each other. Line numbers that correspond with a printed document are hard determine outside of processing the document for publishing. And XML cannot handle the resulting data without breaking nesting. And PDF cannot handle much without including an XML version.
In reality, a document is best described with overlapping onion skins.
*Simple text, illustrations, and typography.
*Publishing artifacts on paper, B&W ereaders, color screens at different sizes, audio/accessible versions.
*Interactive features, dimensional breaks/non-serial narrative breaks.
*Versioning within a document.
*Implicit and explicit metadata about the document.
*Legal aspects, licensing, authenticity, watermarking, branding, and the interactive aspects (limiting views, copying, time restrictions, online …)
*Business model issues, including purchasing information, ISBN, UPC, etc.
*And, oh yes, content, which may be more than simple text (for law there may be cites, a metadata level for hierarchical/jurisdictional/version/authorship/etc) often creating a layer of XML that is XSLTed into ePub or HTML or PDF with or without representation in the presentation layer’s code.
12 Reader Comments
Back to the ArticleNick Disabato
@france.baril: Keeping headers as H1 (for instance) ensures consistent rendering from e-reader to e-reader; it’s easier to preserve consistently; and it’s easier to port to other formats if need be (Mobi doesn’t support CSS, for example, so styled <span> tags don’t play well).
citizencontact
There is a world of commercial publishing that ePub, KF8, PDF, etc. have been created to allow for ebooks. However, because of HTML being so successful for browsers on computer screens, the aspect of the device has created huge confusion over how to deal with publishing. Steve Jobs created the Next computer with full WYSIWYG screens and printing using PostScript. By equating the two distinct media, CRT and 8.5“x11” paper, was the recognition of power of verisimilitude. Obviously, new viewing devices and new methods to physically interact with data and documents have made the importance of serving content in a multitude of ways.
For example, looking at legislative documents, the issue of authenticity and verisimilitude are much more significant and trump the issues that are driving the ebook issues mentioned in the Publications Standards article. And for these reasons, there is no good answer on formats for legal documents. One aspect is that line and page numbering are artifacts of publishing on paper with typography. And so for legal documents, academic and other crucial document creating communities, the discussion is a lot noise that often misses their issues.
I would say that a single XML file can not meet the needs of publishing. Nor can a simple PDF or any other single file approach. Essentially, there are layers that are often out of sync with each other. Line numbers that correspond with a printed document are hard determine outside of processing the document for publishing. And XML cannot handle the resulting data without breaking nesting. And PDF cannot handle much without including an XML version.
In reality, a document is best described with overlapping onion skins.
*Simple text, illustrations, and typography.
*Publishing artifacts on paper, B&W ereaders, color screens at different sizes, audio/accessible versions.
*Interactive features, dimensional breaks/non-serial narrative breaks.
*Versioning within a document.
*Implicit and explicit metadata about the document.
*Legal aspects, licensing, authenticity, watermarking, branding, and the interactive aspects (limiting views, copying, time restrictions, online …)
*Business model issues, including purchasing information, ISBN, UPC, etc.
*And, oh yes, content, which may be more than simple text (for law there may be cites, a metadata level for hierarchical/jurisdictional/version/authorship/etc) often creating a layer of XML that is XSLTed into ePub or HTML or PDF with or without representation in the presentation layer’s code.
Daniel Bennett
CTO, eCitizen Foundation