Bowerbird wrote:

why go through the pain of conversion if you don't have to? and the .pgtei file is the one with all the information in it, not? might as well view that, rather than some pale conversion...

but let's get real here for a minute, ok?

if the only people who can view the .pgtei file directly are the few who happen to be using a specific browser, there's no need to put a lot of resources in that direction.

Browsers are slowly moving towards better CSS2 and even CSS3 support (this is a major component of what is called 'web standards'). So things are not fixed in the browser arena. Overall Firefox and Opera 8 have the best web standards support, but they're not yet 100% (note that Haakon Wium Lie, the CEO of Opera, is one of the principal players in W3C's CSS development.) IE6 is way behind. It is unknown how much better IE7 will be. It doesn't really matter -- Firefox and Opera are plowing ahead, and continue to gain market share across platforms.

no sir.  what lee is _really_ talking about is "openreader", which he has begun programming.  (you _have_ begun, haven't you, lee?  because there's no time like the present.)

Lee is the chair of the OpenReader Development Working Group, which is now working on "Orca", the name we've given to the OpenReader "user agent". I'm not sure where Lee and the WG are at present, although as you are probably aware there's not been much public activity this Summer on the WG list. Summer is usually a slow time in standards and development work. Good thing the principals of OpenReader don't live in Norway. In Norway, everything shuts down for two to three months in the summer, and understandably so. <smile/> Btw, David Teller in France is working on an OEBPS "browser", which could also be used to render OpenReader publications. So there are parallel efforts, which is good!

because, you see, a specialized e-book viewer-program (like openreader) can deliver an e-book experience that _far_surpasses_ the one that an end-user gets in a browser.

That's the plan for OpenReader. Refer to the interim OR site at: http://www.openreader.org/ Also, refer to the page where we discuss the freedom that OR gives us with respect to rendering. We are no longer constrained by the web browser/HTML paradigm: http://www.openreader.org/browsers.html A lot of this "freeing" up comes from OEBPS. The OEBPS "out-of-spine" construct is proving itself to be a powerful feature. There is a reason why I continue to discuss the TEI <note> tag as I do. Since OpenReader will handle "out-of-spine" content (in Orca via "Booklets"), we automatically have a way to beautifully handle inline TEI <note> -- just view it in an optional popup window (or other mechanism). This is one reason why it will be *easier* for OpenReader to support TEI than it would be for current web browsers since Orca and any other OR user agent *has* to handle OEBPS "out-of-spine" content. Interestingly, XHTML 2.0 also plans to introduce a new attribute which is similar (and actually more powerful) than TEI's <note>, and it will force web browsers to render such marked-up content to be displayed outside the main flow of the text. I wonder how Opera and Firefox will do it? <smile/> For the proposal in XHTML 2.0, refer to: http://www.w3.org/TR/xhtml2/mod-role.html#s_rolemodule Look at the 'role' attribute (i.e., 'role="note"'). It is part of the Common attributes collection. With this attribute, one can make just about any tag become a note (annotation, parenthetical content, etc.) In my private chat with Stephen Pemberton, the chair of the XHTML working group, it is intended for web browsers to somehow display to the end-user the content within 'role="note"'. Thus, it appears to not be too different from TEI <note>.

and _that_ is the reason why people would want to view a .pgtei file directly, rather than look at an .html conversion; not because of the files per se -- it's silly to think end-users care anything about formats -- but because of the _viewer_ and the e-book _experience_ that was delivered therein...

The format is integral to the reading experience. One can't really separate them. But the format does come first. It needs to be intelligently designed so as to allow the greatest reading experience, among other things. Fortunately OEBPS has done a lot of the work already. Regarding TEI, we at OpenReader are definitely interested, at some future time, to support TEI in some fashion. The specifics have yet to be resolved. What Lee and I are doing is *learning* about TEI with respect to utilization in ebook presentation. This means we need to learn the vocabulary, learn its limitations and advantages, see how it relates to XHTML/OEBPS, look at direct rendering issues (incl. CSS support), etc. To get a grasp of the major issues. Lee is doing it his way, I'm doing it my way. Obviously, PG-TEI is of interest to us since it is pretty much the TEI implementation closest to our interests.

so, if lee can deliver an openreader that is _cross-platform_ and runs on _older_hardware_, using _minimal_resources_, and can render the .pgtei file directly, giving the end-user a powerful e-book experience, all from a free-beer program, no one will use their funky web-browser to read an e-text...

Define "older" hardware. Our determination is that very old hardware, and low-power hardware, such as older PDAs, simply don't have the horsepower required to deliver a nice digital publication (ebook) reading experience. We are focusing on the future, thus the OR format and Orca (which is intended to be a reference implementation, a demo if you prefer) is going to draw the line somewhere with legacy hardware support. I doubt Orca will be developed to be compiled on older Macs (only OS X), but this doesn't prevent someone else from building their own OpenReader user agent to run on whatever platform(s) they desire. We view Orca to be similar to the early days of the web, when Mosaic was developed to be a reference implementation of an HTML user agent. Mosaic launched the web, and over time there's been dozens of web browsers developed. Notice that Mosaic doesn't even exist any more. For more info on OpenReader legacy support, refer to: http://www.openreader.org/macpalm.html There we talk about Mac (a little) and Palm support. We do note talk about older Mac (pre OS X) support. Whether Orca supports older Mac or not sort of depends upon the final architecture of the code base. We don't deem it important for Orca to support pre OS X Macs (sorry!)

so let's wish lee success in his endeavor, for the ultimate good of all the end-users...

We plan that a group of programmers, working together, will develop Orca. The kudos, should it happen, will go out to all those who contribute. It *should* be a team effort. Of course, if any developer here is interested in helping develop Orca, contact Lee. Jon Noring OpenReader Consortium