August 2005 - gutvol-d - lists.pglaf.org

newbie question: copyright editions of public domain works
by Greg Smith 25 Aug '05

25 Aug '05

I inherited from my grandfather 25 years ago 4 collections from his library. He was a Baptist minister (read poor). The first collection is the 11th edition of the Encyclopedia Brittanica published 1910-1911. The other three collections are editions of works that were public domain at the time of the edition (eg `Best Known Works: Defoe'). The copyright dates range from the mid teens to the early forties. But what are these copyrights copyrighting? I can understand editor comments, translations, pictures, etc. But what if spelling/grammar was modernized? Or, portions cut or moved? Would these books (~120 volumes) be of any use? Apologies for my ignorance, Greg Smith

2 1

Re: [gutvol-d] on viewing the .pgtei file directly (gutvol-d Digest, Vol 13, Issue 23)
by Lee Passey 25 Aug '05

25 Aug '05

Bowerbird(a)aol.com wrote: > p.s. when i try to view 16523-x.xml directly in firefox, it says: > "this xml file does not appear to have any style information > associated with it. the document tree is shown below." and > then it shows me the document tree. how can i fix this problem? Download the file 16523-x.zip, and extract the files. Hopefully, the file "persistent.css" is still part of the package. Edit the .xml file with a simple text editor (beware Microsoft tools!) to add the line: <?xml-stylesheet href="persistent.css" type="text/css"?> immediately after the line: <?xml version="1.0" encoding="utf-8" ?> Save the file, and hopefully your editor won't have screwed up the utf-8 encoding. Now view the file from your local file system with Firefox. You should see just a bunch of run-on text, because the styles in 'persistent.css' are designed to be used with the XSL transformation to XHTML, and so none of them apply. But the document structure will disappear. You can experiment by adding new styles to 'persistent.css' (don't forget to save the file and reload your browser after adding rules). For example, add "p { display:block; text-indent: 3em }" and all of a sudden you will get distinct, indented paragraphs (and some non-paragraphs will also become distinct and indented). Add "teiHeader { display: none }" and all the Gutenberg legal cruft, together with the metadata which is typically only of interest to archivers, will disappear (it's still there, it's just not "in your face" anymore). Add "head { display:block; font-size: x-large; text-align: center }" and the headers will pop out. Add "hi { font-style: italic }" and highlighted text will become italicized. Use "hi { background: yellow }" instead and the highlighted text will look like you have run over it with a yellow highlighter. Or combine them both: "hi { font-style: italic; background: yellow }". The TEI markup used in this file is fairly simple, so you could probably get a pretty good looking file by using no more than a dozen or so CSS rules. Mr. Perathoner's TEI version of Alice in Wonderland (http://www.gutenberg.org/tei/marcello/0.3/examples/alice/) looks like it is much more complex, and would be funner to play with. I really like _Alice_ as an experimental text because it has quite a few typographical oddities which make it a good test case. Unfortunately, I haven't been able to figure out how to tell Firefox how to use a user specified css file (I've got version 1.0.4). If anyone can enlighten me on this score, I would be most grateful. Mr. Noring tells me that I can do it with Opera, but I've yet to try it.

2 1

re: [gutvol-d] ANNOUNCEMENT: XML has hit the PG archives! (gutvol-d Digest, Vol 13, Issue 25)
by Bowerbird＠aol.com 25 Aug '05

25 Aug '05

andrew said: > A brief explanation here of > the historical edition numbering of PG texts. > Every text was released initially in a version "10" > (Think of that as 1.0) And then subsequent "editions" > would be numbered 11, 12, etc. If you look hard enough > in the pre-10,000 files, you can find a couple of exceptions, > but that will cover most cases. Also note that the consensus > that emerged was that a small number of minor corrections > could be made without increasing the edition number. it is this last "consensus that emerged" that is most troublesome. as long as the filename stays unique for each different version, at least people can depend on the name to identify the version. when you substitute in a different file without changing its name, you've introduced unnecessary ambiguity into the situation, and thus made it extremely difficult for people to keep track of things. and when you fail to provide changelogs on the entire process, the difficulty-factor starts to climb into the "impossible" range... apologies for spoiling your fun... -bowerbird

1 0

Re: [gutvol-d] ANNOUNCEMENT: XML has hit the PG archives! (gutvol-d Digest, Vol 13, Issue 25)
by Lee Passey 25 Aug '05

25 Aug '05

Jeroen Hellingman wrote: [snip] > Some have argued (with valid reasons) that the entire idea of TEI > markup is broken, and have proposed systems > in which the mark-up is separated from the text (stream of > characters), in such a way that multiple, parallel systems of > mark-up can exist. Think of a separate (part of a) file, saying > characters 21 to 34 are italics, and so on. This may sound > odd, but it is the way the old Macintosh wordprocessor MacWrite worked. > > Jeroen. This is also the way HTML Tidy works, internally. As an HTML file is parsed (and fixed, if necessary) a DOM tree is built. But when a text node is encountered rather than malloc'ing a potentially small amount of memory and storing a pointer, the text is copied into a pre-allocated text buffer, and the start and end points of the fragment are saved in the node structure (the start and end points are actually saved in every node, so you can grab any node in the tree and know that it encompasses "this much" of the actual text.) When 'pretty-printing' the tree, text is grabbed from the buffer as needed. Having created this structure in memory, there is no reason at all it couldn't be saved out separately, with text nodes simply referring to an offset and length in a separate file which receives the entire text buffer, or a separate segment in the same file that contains the text. Likewise, if someone wanted, hypothetically mind you, to write a set of annotations and footnotes to classic literature found at Gutenberg, the same sort of strategy could be used; the annotations would be in a separate file and refer to text at a certain offset in the base file. You'd have to write a small application to merge the two files for presentations, but that sort of thing is trivial, perfectly suited for perl, awk or python. This type of division between markup and content is also perfectly suited to writing an application to display e-books in a low memory/low power device. The DOM tree could quickly be loaded into memory and remain resident, permitting fast navigation and styling, but the actual text could remain in static storage, only being accessed when needed. One of the downsides to this sort of system is that the base content _must_ remain 1. accessible and 2. inviolate. The Gutenberg edition of _The Adventures of Sherlock Holmes_ was first released in 1999 and has gone through 12 revisions, the most recent being in 2002. Version 10 is still available at gutenberg.org, but I can't find any earlier versions (this is not a criticism; PG is not an archive, after all). So if I were to write an annotation designed to be overlayed over the PG text I would want to have some assurances that the base text were always available, or I would want to be sure that the base text was always physically attached to the annotation file (to the extent that anything digital can be said to be physical). If I were to write a separate HTML markup file for TAOSH, I would want some assurance that the base text would not be altered in any way which would change the position of any character in the file, otherwise my markup would break. So there are definitely problems with this sort of application, but there are real benefits too, in some circumstances.

2 1

re: [gutvol-d] on viewing the .pgtei file directly
by Bowerbird＠aol.com 24 Aug '05

24 Aug '05

hey jon noring, as long as you're still moderating michael hart over on your listserve, i'm still declining to talk with you here... but please, do have a nice day anyway... :+) -bowerbird

1 0

on viewing the .pgtei file directly
by Bowerbird＠aol.com 24 Aug '05

24 Aug '05

i think it would be marvelous to view the .pgtei file directly. 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. however, that's not really what lee is talking about, is it? no, it isn't. 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.) 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. 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... (savvy lurkers will recognize this as a straightforward variant of the argument i have been making all along...) 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... so let's wish lee success in his endeavor, for the ultimate good of all the end-users... -bowerbird p.s. when i try to view 16523-x.xml directly in firefox, it says: "this xml file does not appear to have any style information associated with it. the document tree is shown below." and then it shows me the document tree. how can i fix this problem?

2 1

Re: gutvol-d Digest, Vol 13, Issue 24
by Lee Passey 24 Aug '05

24 Aug '05

David A. Desrosiers" <hacker(a)gnu-designs.com> wrote: >> I've learned the fear the <div> container. Let me show you why using >> a <div> container for "non-specific" blocks of text won't work. > >> <div> >> <head>Level 1</head> >> <p>Paragraph 1.</p> >> <div>Block o' text.</div> >> <p> Paragraph 2.</p> >> </div> > > > Improperly nested tags will never validate. You can't have a bare > string inside the <head> tag like that, and <head> isn't a child of > <div>, so that won't work either. After correcting those errors, it > validates fine. > >> The above will not validate. Once you go one deeper in a nest, you >> cannot come back up just one level. You have to close the whole >> nesting. > > > Nope, this is completely untrue. > >> The above would work if changed to: >> >> <div> >> <head>Level 1</head> >> <p>Paragraph 1.</p> >> <div>Block o' text.</div> >> </div> >> <div> >> <p> Paragraph 2.</p> >> </div> > > > You're still producing invalid markup. Try something like this: > > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> > <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"> > > <head><title>Level 1</title></head> > <body> > <p>Level 1</p> > <div> > <p>Paragraph 1.</p> > <div>Block o' text.</div> > <p> Paragraph 2.</p> > </div> > </body> > </html> I fear that Mr. Desrosiers has made the classic error of confusing varieties of fruits, which is third only to "never become involved in a land war in Asia." and "never bet with a Sicilian when death is on the line." Mr. Hutchinson's code snippet was encoded using the TEI vocabulary of XML, not the XHTML vocabulary. In TEI the <head> tag is analogous to the HTML <h1> tag, and the HTML <head> tag is analogous to the TEI <teiHeader> tag. Apples and oranges. On the other hand, I don't see how Mr. Hutchinson's second example could validate if the first does not, particularly given the fact that DTD's are not structured in such a way to permit a validator to make that kind of a judgment ("if a <div> contains a <div> it must be the last element of the first <div>" or "if a <div> contains a <div> it may be preceded by a <p>, but not followed by one"). I'm not that great at deciphering DTDs, but I don't see anything in http://www.tei-c.org/P4X/DS.html which would cause me to believe that example 1 is not valid. In this particular case, I suspect a bug in the validator program. I mean, writing validators is hard, and I am aware of at least one bug in the W3C's online HTML validator. Supposedly, Xerces is a validating parser. Maybe I'll see if I can find the time to run the snippet through Xerces and see if (and where) it breaks.

2 1

Re: [gutvol-d] ANNOUNCEMENT: XML has hit the PG archives! (gutvol-d Digest, Vol
by Joshua Hutchinson 24 Aug '05

24 Aug '05

----- Original Message ----- From: "Lee Passey" <lee(a)novomail.net> > > Joshua Hutchinson <joshua(a)hutchinson.net> wrote: > > When in doubt, use <div>. I've learned the fear the <div> container. Let me show you why using a <div> container for "non-specific" blocks of text won't work. <div> <head>Level 1</head> <p>Paragraph 1.</p> <div>Block o' text.</div> <p> Paragraph 2.</p> </div> *** The above will not validate. Once you go one deeper in a nest, you cannot come back up just one level. You have to close the whole nesting. The above would work if changed to: <div> <head>Level 1</head> <p>Paragraph 1.</p> <div>Block o' text.</div> </div> <div> <p> Paragraph 2.</p> </div> *** The problem is that now you have two distinct blocks of text that should really be treated as one block. *** NOTE: None of this is to argue that the more correct way to handle the example you gave would be to mark it as something other than <p> chunks. You are right there. Just that your counter example of <div> wouldn't work at all. Josh

4 3

re: unluckily for us
by Bowerbird＠aol.com 24 Aug '05

24 Aug '05

lee said: > Unluckily for us, Bowerbird has not yet > released his algorithm for determining whether > a block of unstructured text is a paragraph. oh gee, i'm sorry. i thought i had. in z.m.l., anything surrounded by two or more blank lines is a paragraph. for counting purposes, this works just fine, even if your english teacher might not "approve" of it... a z.m.l. viewer-app will display the paragraph numbers, so there's absolutely no ambiguity about what they are... as long as the programs you are using count the same way, there's no reason to get strung out in definitional sand-traps. any more questions? -bowerbird

2 1

Re: [gutvol-d] ANNOUNCEMENT: XML has hit the PG archives! (gutvol-d Digest, Vol
by Joshua Hutchinson 24 Aug '05

24 Aug '05

----- Original Message ----- From: "David A. Desrosiers" <hacker(a)gnu-designs.com> > > > Dave, we're talking about TEI/XML. Nothing of what you said applies here > > (but you would be absolutely right on a HTML document, as I understand it). > > ;) > > Its not even well-formed XML, and fails XML validation (as the doctype shown > below shows). Perhaps the TEI/XML needs to start conforming. > > My example is perfectly legal XML. Follow the TEI DTD. Your example uses: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> That is a xhtml1-strict.dtd. Completely different DTD and hence completely different set of markup rules. For instance, <head> means VERY different things and is used in VERY different ways between a TEI document and a XHTML document. Josh

1 0