- gutvol-d - lists.pglaf.org

OpenReader announcement: Open-standards eBook Format and Reading System Development Discussion Groups
by Jon Noring 04 May '05

04 May '05

Quick Summary (including how to subscribe): ------------------------------------------- You are invited to subscribe and participate in one or both of the following discussion groups (hosted at YahooGroups) supporting the ongoing activities of the OpenReader Consortium: 1) "openreader-format": OpenReader Format Specification (an open-standards ebook and digital publication/document distribution format), and 2) "openreader-devel": Development of an open-source, license-free, multi-platform reference implementation of an OpenReader reading system ("user agent"). (Both projects will be summarized in the next section. For more detailed information, refer to http://www.openreader.org/ .) If you have a supportive interest in either topic, we invite you to subscribe to the group of interest. (Those who subscribe to the "user agent development" group are strongly urged to also subscribe to the Format group.) By joining either of these groups, there is no implied commitment to become an active participant in either of the associated Working Groups, although we certainly hope you will. We welcome your thoughts and insights, even if you choose not to actively participate in formal Working Group activities. The home pages to the two groups are found at: http://groups.yahoo.com/group/openreader-format/ http://groups.yahoo.com/group/openreader-devel/ There is a link to subscribe to each group at the group's home page. Or, you can subscribe to either using the following email addresses: openreader-format-subscribe(a)yahoogroups.com openreader-devel-subscribe(a)yahoogroups.com If you prefer not to go through the process of subscribing yourself to either group, I'll be more than happy to subscribe you. Just email me (jon(a)openreader.org or jon(a)noring.name) your request to join -- be sure to specify which group(s) -- along with the email address you want to use to receive group messages. More Detailed Information about OpenReader: ------------------------------------------- As noted in the prior section, the best online resource explaining OpenReader is the current OpenReader web site (planned to soon undergo a much-needed major update and upgrade): http://www.openreader.org/ OpenReader is a cooperative project to create an open, standards-based digital publication distribution format to facilitate current, continuing, and long-term access to ebooks and other types of digital publications and documents. The OpenReader distribution format will be based on well-established XML vocabularies, publication frameworks, and W3C technologies. This includes OEBPS (the Open eBook Publication Structure framework), XHTML, CSS, MathML, SVG and XLink, to name the more important ones. Our current plans also include eventual native support for TEI, NewsML, and possibly other advanced and specialized document markup vocabularies and publication frameworks. The OpenReader Consortium will also support the development of reference implementations of programs to render OpenReader-compliant documents on a number of devices, and to convert OpenReader-compliant documents to other publication formats, such as PDF/A. There is a clear need for such a distribution format, given the present anarchy of multiple, incompatible, inflexible, and proprietary publication formats which do not provide the reading experience consumers want and publishers strive for. David Rothman, in his TeleRead blog covering the ebook, digital library, and related industries (http://www.teleread.org/blog/) aptly describes this situation as the "Tower of eBabel". While the initial focus of the OpenReader Consortium is primarily on ebooks, we intend to make the distribution format flexible enough to be applicable to a wide variety of digital publications and documents, such as periodicals, newspapers, document collections, white papers, many types of business documents, etc. We even envision the OpenReader format to be quite useful for encapsulating and archiving standards- conformant Web sites. When the HTML format and HTTP protocol were developed more than a decade ago, NCSA developed a "web browser", Mosaic, to support the format and protocol. The success of the World Wide Web was due as much to the wide-spread availability of the NCSA Mosaic browser, as it was to the openness and availability of the HTML and HTTP specifications. Similarly, we believe that it is important to develop, in conjunction with the OpenReader Format, a cross-platform, open-source, license-free reference implementation of an OpenReader rendering program, which will make the OpenReader Format Specification truly useful, to establish uniform rendering behavior, and to spur others to build their own conforming OpenReader user agents. ***** We look forward to your joining either or both groups, even if to lurk. If you know of others who may be interested in OpenReader, feel free to forward this announcement to them. We are also building a Consortium of interested companies and organizations in the digital publication and document universe who see the open-standards OpenReader as furthering their business and institutional objectives. Of course, we are looking for dedicated individuals, who agree with the OpenReader philosophy, to become leaders and help to make OpenReader a success. Thanks. Jon Noring OpenReader Consortium jon(a)openreader.org jon(a)noring.name

1 0

Format for corrections to etexts
by Tom Harris 02 May '05

02 May '05

Can someone point me to documentation for the format for submitting corrections to an existing etext? Regards Tom Harris BeacyBooks beacybooks(a)bigpond.com

1 0

Re: More than you ever wanted to know about XHTML and CSS (gutvol-d Digest, Vol 9, Issue 26)
by Lee Passey 29 Apr '05

29 Apr '05

Marcello Perathoner wrote: > In the end you came out right, Precisely. Hopefully, this little quibble will not distract people from the larger issues, which is that the file at PG is still broken and needs to be corrected, and that the W3C's validator does not necessarily guarantee a fully conformant file.

1 0

Re: Re[2]: [gutvol-d] More than you ever wanted to know about XHTML andCSS (gutv
by Joshua Hutchinson 29 Apr '05

29 Apr '05

----- Original Message ----- From: "Jon Noring" <jon(a)noring.name> > > On another matter, how Firefox handles multiple <style>'s is way cool. > Is there some mechanism using Firefox to also select one among several > supplied *external* stylesheets? > Yes! You can define a virtually unlimited number of styles, one after another, in the beginning of your HTML file. Firefox will default to the first one, but you can switch on the fly under the View -> Page Style menu. Just to make it more frustrating, IE picks the LAST style out of the list to display. *rolls eyes* Disclaimer: I may have the first and last backwards. Firefox may pick the last and IE the first. I just know they never AGREE on which one to display by default. Josh

3 2

Re: [gutvol-d] More than you ever wanted to know about XHTML and CSS (gutvol-d Digest, Vol 9, Issue 23)
by Lee Passey 29 Apr '05

29 Apr '05

Marcello Perathoner wrote: [restatement snipped] > It is not! (People should really read the specs!) If it were #PCDATA > (*Parsed* Character DATA) the validator would find the error because > it would parse it. Its because its CDATA that the validator doesn't > parse it and in consequence cannot find the "error". In CDATA < has no > special meaning at all. True. In my original analysis I was looking at the DTD declaration for file number 15701 which is XHTML Strict as opposed to file number 15698 which is indeed HTML 4.01 Transitional. But in this case the distinction between #PCDATA and CDATA is inconsequential, because for this bug to manifest itself we are dealing with a User Agent which either does not support the <style> element, or has implemented that support incorrectly (as in the case of Opera 7.11). Thus, my analysis, and your restatement, are still correct. Hopefully, this little quibble will not distract people from the larger issue, which is that the file at PG is flawed, and needs to be corrected. David A. Desrosiers wrote: > The balance has to be consired: Is it worth it to incur >another socket connection and round trip from the client (more server >hits to retrieve resources) or is it better to have a larger >byte-per-hit (but less socket connections) per-client? > > This objection, and Marcello's response, are both based on a faulty assumption: that the primary use of HTML files will be online, served up by some sort of HTTP server. I would bet that the vast majority of all HTML files offered by Project Gutenberg are downloaded to a local computer, and then read while offline. I know that _I_ have never read a PG e-text directly from the web server. Fetching multiple files from the local file system is simply a non-issue. And if I want to substitute my own styles for those of the original poster, downloading to a local file system is required. If you're going to insist that user selection of styles is not possible, the question of whether they are internal styles or external styles is irrelevant, but if you're going to permit user flexibility in selecting styles, the issue of multiple GETs is irrelvant. This is one of the reasons that it is important that all HTML files be offered in ZIP format: because it is likely that a user will be reading offline, s/he should be able to fetch all the files associated with a work (styles and images) in a single download.

4 4

re: this, that, and the other thing
by Bowerbird＠aol.com 28 Apr '05

28 Apr '05

josh said: > *rolls eyes* > Disclaimer: I may have the first and last backwards. > Firefox may pick the last and IE the first. > I just know they never AGREE on which one to display by default. i would imagine the spec specifies, but if it doesn't, then it's not obvious whether to pick the first or the last, is it? so why roll eyes at one way or the other? anywho, it doesn't really matter either way, since you can make the last a duplicate of the first if you have several... meanwhile, even though the experts have had their conclave, and discussed this,that, and the other thing, and then retired to their corners, these .html files _still_ don't work for me... -bowerbird

1 0

Re: [gutvol-d] More than you ever wanted to know about XHTML andCSS (gutvol-d Di
by Joshua Hutchinson 28 Apr '05

28 Apr '05

----- Original Message ----- From: "Marcello Perathoner" <marcello(a)perathoner.de> > > <HEAD> > <STYLE type="text/css" title="red"> > P { color: red } > </STYLE> > <STYLE type="text/css" title="blue"> > P { color: blue } > </STYLE> > <STYLE type="text/css" title="green"> > P { color: green } > </STYLE> > </HEAD> > <BODY> > <P>Don't show this to any DP Project Manager. > </BODY> > Too late. We know all about that trick! :) The problem is that some browsers, whom shall remain nameless (*cough* IE *cough), go into "quirks" mode when there is multiple style sheets defined. Things that worked fine with just one style sheet defined now quit working correctly with multiple style sheets defined. Nevermind the fact that IE refuses to let you switch styles on the fly. Now, IE *shouldn't* switch to quirks mode base on multiple styles, but it seems to anyways (at least in the limited testing I did on the subject). It is also extremely annoying that IE triggers quirks mode if you include an XML prolog at the beginning. <?xml version="1.0" encoding="utf-8"?> (BTW, Marcello, the TEI conversion currently puts that prolog in ... which triggers IE to quirks mode DESPITE the Strict statement in the next line. We should see if we can safely remove it.) See http://www.quirksmode.org/css/quirksmode.html for a quick and dirty primer on quirks mode and why it exists. Josh

2 1

info on clearances
by N Wolcott 28 Apr '05

28 Apr '05

Is thee any central place to see the results of a copyright clearance request or do they just go into a hole somewhere? N Wolcott nwolcott2(a)post.harvard.edu

3 2

Re: [gutvol-d] More than you ever wanted to know about XHTML and CSS
by Joshua Hutchinson 27 Apr '05

27 Apr '05

----- Original Message ----- From: "Robert Shimmin" <shimmin(a)uiuc.edu> > > > Now, do I agree that we will eventually find something that goes beyond > > what we've covered in the TEI spec? You better believe we will. But when > > that day comes, TEI can be expanded to cover the situation. Do I think this > > will be a common occurance? Not a chance. > > This is just off the top of the stack of projects I would like to put through > DP, but hold off on because they contain elements I consider presently > unmanageable. > > http://www.ews.uiuc.edu/~shimmin/almanac.PNG > > Today, if I could figure out a good way to handle it, I would write some > styling for it, submit it, and be done with it. Tomorrow, I will have to bug > some element of the PG bureaucracy to patch my styling into their code, which > it may not be compatible with, or may disagree with their notions of markup > elegance. A tool that works 90% of the time is a wonderful thing. A rule > that works 90% of the time is not. > I can think of a few ways to do this. The easiest (and how I'd probably do it if I was in a hurry), is to just insert the whole figure as an image. <p rend="center"> <figure url="images/image01.png"><figDesc>A Table for the Sodaies letter and Leapeyear.</figDesc></figure></p> If I was a little more energetic (but still fairly lazy), I'd insert the circular part of the figure as an image with the text cut out and added as a blurb below it. <p rend="center"> <figure url="images/image01.png"><figDesc>A Table for the Sodaies letter and Leapeyear.</figDesc></figure></p> <p rend="center">A Table for the Sodaies letter and Leapeyear. blah blah blah</p> If I was REALLY energetic, I'd redo the graphic in SVG (a vector graphic image format), embed that within the TEI and be done. Since SVG is vector based, it has the nice side-effect of scaling very nicely to any output size, whether it is for printing through a PDF, or display on a monitor through HTML. Really, Robert, this one wouldn't have been a show-stopper for DP even without TEI. Josh

1 0

Re: [gutvol-d] More than you ever wanted to know about XHTML and CSS
by Joshua Hutchinson 27 Apr '05

27 Apr '05

----- Original Message ----- From: "Robert Shimmin" <shimmin(a)uiuc.edu> > > > The "standardization" is there ... it just doesn't go as far as to specify a > > standard style sheet. > > > > Now, the TEI has a "working" standard style sheet, but there have already > > been some changes identified in testing. > > > > Once, we have the final transforms worked out, I plan on having an open call > > for style sheets on DP. > > I've worked on enough 'quirky' projects to think this a bad idea. The > typesetters of the past did things that often make it a complete judgment call > where the content stops and the presentation begins, and many projects will > not fit on someone else's Procrustean notions of how a PG project 'should' be > styled. > >From my experience, this is not the case and I've put together some very quirky ones into TEI already. I've picked one text with over 1,000 footnotes and over 500 sidenotes. It is complicated, but it renders beautifully. I've picked another text that uses editorial sidenotes running throughout a Middle English poem. Both of these were great test cases that helped us identify bugs in the transform. Now, this isn't to say the layout looks exactly like the original. It does not in many cases. A sidenote in the margin is functionally the same as a sidenote that is floated as an inset on the side of the page. Worrying that the presentation of one matches the original book and one doesn't is irrelevant. The publisher probably didn't slavishly follow the layout the author wrote his original manuscript in either. Now, do I agree that we will eventually find something that goes beyond what we've covered in the TEI spec? You better believe we will. But when that day comes, TEI can be expanded to cover the situation. Do I think this will be a common occurance? Not a chance. Josh

3 2