Re: [gutvol-d] [Press Release] OSoft Partners with OpenReader
----- Original Message ----- From: "Lee Passey" <lee@novomail.net>
What you are suggesting here is a recipe for inaction. The OpenReader format can hardly be called a standard, as widespread recognition, adoption, and employment is still a way off, but _proposals_ must always precede adoption.
You are right in that the proposal comes first. But anyone can propose anything. (See: bowerbird) Granted, the openreader proposal is well documented and from what little I've seen, well-though out. BUT... It is still nothing more than a proposal because no one can really DO anything with it. Let me draw a parallel. The MPEG standards were first a proposal (draft) and then a crude implementation was created by the group. It was by no means a fully realized application, but it was enough that people could see what the heck the long dreary draft was talking about. THEN other groups created bazillion different implementations that we have today. Put together a crude OpenReader compliant application so that people can see what the heck it is. Josh PS And you could say that the lack of a reader IS a red-herring ... it is distracting from the fact that there is proposed standard because no one can ACCESS texts marked in the proposed standard.
Joshua Hutchinson wrote:
Granted, the openreader proposal is well documented and from what little I've seen, well-thought out.
BUT...
It is still nothing more than a proposal because no one can really DO anything with it.
Let me draw a parallel. The MPEG standards were first a proposal (draft) and then a crude implementation was created by the group. It was by no means a fully realized application, but it was enough that people could see what the heck the long dreary draft was talking about. THEN other groups created bazillion different implementations that we have today.
Put together a crude OpenReader compliant application so that people can see what the heck it is.
I suspect we are in violent agreement on this point. The OpenReader proposal is even now in the early stages of exactly the same historical process you have described for the MPEG standard. The proposal has been made, and is being discussed. The very announcement that started this thread is an indication that a first implementation is being worked on. The Thout Reader developed by OSoft is, in fact, an open-source, GPLed, User Agent written in Java (see http://sourceforge.net/projects/thout/). Of course, as the new Thout Reader develops, some content will have to be made available in the new format so that the implementation can be tested, but I suspect that will be easy enough seeing as how the OpenReader format is likely to be a relatively minor variation on the existing OEBPS format. My only point is that the OR format should not be dismissed merely because it is still early in the process, and that those people who believe that a standardized format is a good idea should step up to the plate and support the format _now_ to improve the likelihood that it will become a widely adopted standard in the future.
Lee Passey wrote:
The Thout Reader developed by OSoft is, in fact, an open-source, GPLed, User Agent written in Java (see http://sourceforge.net/projects/thout/).
Nothing in there for you :-)
the OpenReader format is likely to be a relatively minor variation on the existing OEBPS format.
Question: why this new format if it is only a minor variation of an existing format? -- Marcello Perathoner webmaster@gutenberg.org
Marcello asked:
Lee Passey wrote:
the OpenReader format is likely to be a relatively minor variation on the existing OEBPS format.
Question: why this new format if it is only a minor variation of an existing format?
Good question. First, OEBPS is not a distributable consumer format. Rather, it is best described as a publication framework which will comprise multiple files. A minimal OEBPS Publication will comprise a Package document (the "control center" of the publication), at least one XML content document, and possibly a CSS style sheet. It can comprise multiple content documents, multiple style sheets, image files, etc. (just like a web site might) -- if one wants, an OEBPS Publication may comprise hundreds and even thousands of files. OEBPS does not (nor does any other recommended specification of IDPF) specify an encapsulation format (e.g., like zip), which is obviously needed if one is to distribute an OEBPS Publication to a reader. So, OpenReader delves into the issue of the best way to encapsulate a XML-based publication framework such as OEBPS and its cousins. Second, the current OEBPS spec, version 1.2, is pretty much the same as version 1.0 released in 1999. Since then, a lot has been learned as to what works and doesn't work in OEBPS, and how it can be improved to meet present and future needs. Primarily, the biggest changes will be in the Package file, but there will also be added support for SVG, MathML and XInclude (and there's no clean way to augment OEBPS 1.2 to support these features without actually breaking OEBPS 1.2 conformance.) With regards to the additions/changes in the Package file, the following are noted (it is to be considered a partial list): 1) Add a required hierarchical table of contents (OEBPS currently has no machine readable table of contents.) The accessibility community needs such a table of contents (see, for example, the 2005 Digital Talking Book NISO specification.) 2) Provide for element fallbacks. That is, the reading system may substitute an element in some content document with a fallback, such as to an image. This will be especially useful for islands of SVG and MathML, and even for complex tables. The current OEBPS does not provide for element fallbacks and trying to "shoe-horn" it into OEBPS has proven essentially impossible without mangling the purpose of OEBPS or even breaking conformance. For example, in the document 'example.xml' we may have: <table id="table65"> ... </table> In the package we may specify the backup of 'example.xml#table65' to be an image, say 'table65.png' The user agent, may, at its discretion, replace the <table> with the image table65.png, or provide it in addition to trying to render the table. This is especially useful for lower resolution, smaller screens where complex tables just may not render well. The idea of OpenReader is that it is intended to be a typographically-rich format, but which will gracefully "lean out" for viewing on limited resource hardware. It's like buying an audio CD. You can play it on $500,000 audiophile systems and it will sound awesome, but you can also play it on a $10 Walmart special with crappy fidelity yet still enjoy the music, even if muffled and distorted. 3) Strengthen the feature of "out-of-spine" content. It is implied in OEBPS, but needs to be formalized in OpenReader. Interestingly, once "out-of-spine" is handled by OpenReader user agents, they will now be able to trivially and natively handle things like the TEI <note> tag and other inflow amplifications of text intended to be rendered separately, such as in a popup, footnote or sidebar. For example, we might have the following TEI-like markup: <p>An example paragraph with an inline note.<note>This is the inline note.</note> We'd like the user agent to extract the note from the main flow and present it in a popup or as a footnote.</p> OpenReader user agents will now be able to *natively* (without CSS) handle markup like this. Web browsers can't. This is side-benefit which the OEBPS "out-of-spine" construct gives us. 4) Create a mechanism to embed fonts which user agents can optionally install and use. 5) Create a formal mechanism for a publisher to include cover art and later multimedia. 6) Provide a way that a publisher can "linearize" all the content in a publication, both in-spine and out-of-spine. Useful for printing out an entire publication which has out-of-spine content. 7) More powerful CSS style sheet assignment mechanism. Essentially all style sheets will now be specified in the Package and eliminated from the content documents entirely (in HTML no more <link>, <style> and the 'style' attribute.) This provides all sorts of cool possibilities which cannot be done with the current hodge-podge system found in HTML while simplifying everything. It also makes it easier on reading system developers -- no more need to extract CSS styling stuff from content documents. Publishers and developers win. 8) Character set manifest so reading systems will know, without having to query the documents, what characters are specified. Good for international support. Hope this helps. Jon Noring speaking for the OpenReader Format Working Group
participants (4)
-
Jon Noring -
Joshua Hutchinson -
Lee Passey -
Marcello Perathoner