November 2004 - gutvol-d - lists.pglaf.org

Re: [gutvol-d] PG TEI
by Joshua Hutchinson 03 Nov '04

03 Nov '04

----- Original Message ----- From: Scott Lawton <scott_bulkmail(a)productarchitect.com> > > > Also, as noted in http://classicosm.com/xml/feedbackonpgtei.html: In the PG license, section numbers such as "1.A." should appear on the same line as the text that follows -- per the original and to avoid wasting space. > I agree. I'll work on an updated footer to forward on to Marcello. > > > A few notes based on a quick look: > - class=dgp does seem to be overused. > - span class="hi" style="font-variant: small-caps;" is a bit much; how about span class="smallCaps"? > You've got a point. I'll add a todo item to go through the default style and make it more intuitive (ie change the class names where appropriate) and create classes for things like small caps. > I also hate that the HTML is wrapped at 78 (or whatever) chars. I suppose few people will edit the output, but it seems like a wasteful throwback. Don't people have editors that wrap text??? > That you can blame on me. I used Tidy to rewrap everything because of the lots and lots of playing I did with the source code. Marcello's converter leaves the line breaks that were in the original XML source in place. > > Option #1 - Convert the rend="indent" markup to & emsp ; & emsp ; (remove spaces for use). Pro: Degrades gracefully on non-CSS enabled browsers like Lynx. Con: Treats the indent as content. > > I think the XHTML version should be completely modern, e.g. here's one way to indent using CSS: > .indent {margin-left:40px; margin-right:40px} > > There are benefits to an "old fashioned HTML" version, but let's make that a different file, probably 4.01 transitional. > I'm hoping for more discussion on this. I've had fairly heated discussion at DP on it. > > > > >5 - I used <lb /> to indicate a blank line of text (commonly called a thoughtbreak over at DP). Marcello's documentation indicates this isn't what it is truly meant for, though. Anyone see a problem with this implementation? Or see an improvement we should use instead? > > Marcello suggested that a closing and opening div creates a blank line; I'm not convinced that's a good idea in general. > I don't like it definitely from the point of view of having to create the markup. > ===== > > Misc. questions: > > * The following looks like a (minor) error: > <head>Letter XVII</head> > <p>LETTER XVII.</p> > > The latter looks redundant. > My bad. Must have done a copy/paste into the head tag instead of a cut/paste there. > * Was the italics in the original here? > > <p><hi rend="sc">Andover</hi>, <emph>May</emph> 30, 1854.</p> > I went by the text provided by DP on this. I didn't check closely to the original on this type of thing. > * Does the original really have several pages with no paragraph breaks? Yep. Makes for easy reading, huh? ;) Josh

1 0

PG TEI
by Joshua Hutchinson 03 Nov '04

03 Nov '04

Good afternoon, everyone! I have a few things I want to try to get a consensus on as to HOW we want to handle some aspects of the PG TEI master document. Some of the questions will pertain to specific people (such as the automatic inclusion of the PG header/footer) and some will pertain to everyone interested in PG TEI. The TEI master I am using for the basis of this discussion is available at http://home.alltel.net/hutch2000/sunny/start.xml. So, without further ado! 1 - Currently, Marcello's online converter (TEI -> HTML) automatically adds a PG standard header and footer. (http:\\home.alltel.net/hutch2000/sunny/sunny.html) It looks nicer (to my eyes anyway) than the monospaced header and footer that the whitewashers currently use. However, is this a "bad thing" in the eyes of the whitewashers? As near as I can tell, the only people of information that will need to be manually added by the whitewashers is the EBook number that is assigned to this text. If this is placed in the TEI master, then it is automatically put into the HTML version when it is run through the TEI -> HTML converter. If this is an "ok thing" but needs some work ... what needs changed? Jim, you're a vocal whitewasher! Rip this apart! (This question also includes suggestions for style improvements to the header/footer, too.) *** 2 - The version I have posted above has two rather significant CSS changes from the style used in Marcello's converter. A) The margins have been set to 10% whitespace on the right and left. This is a fairly arbitrary number arrived at because it is the "defacto" standard at DP. Suggestions/comments? B) The paragraph markup has been changed back to HTML standard. Marcello's original style more closely resembles TeX formatting, where there is no white space between paragraphs and each paragraph is indented. This was jarring to me, hence the change. Again, suggestions/comments? The rest of the style is as Marcello's converter made it. It is a bit verbose by some people's standards (almost everything has a class attribute), but this can be a very good thing because it now allows CSS to affect the layout/look of nearly every aspects of the document. *** 3 - The TEI master uses rend="indent" markup in the poetry. This validates fine, but currently the TEI -> HTML converter basically ignores the indent markup. What I want to address here is how we want to have those indents converted. TEI master markup: <lg> <l>"I thank the goodness and the grace</l> <l rend="indent">That on my birth have smiled,</l> <l>And made me in these Christian days</l> <l rend="indent">A happy English child."</l> </lg> Option #1 - Convert the rend="indent" markup to & emsp ; & emsp ; (remove spaces for use). Pro: Degrades gracefully on non-CSS enabled browsers like Lynx. Con: Treats the indent as content. Option #2 - Convert the rend="indent" markup to CSS markup equivalent (my mind is going blank right now or I'd give an example). Option #3 - Any other ideas how to handle this? *** 4 - I used <quote rend="display"> markup for blockquotes. This looks fine to me. However, in previous discussions, some people did not like the rend="display" for this purpose. As far as I am concerned, it works and doesn't seem to be a problem, but I'm willing to hear opposing arguments. *** 5 - I used <lb /> to indicate a blank line of text (commonly called a thoughtbreak over at DP). Marcello's documentation indicates this isn't what it is truly meant for, though. Anyone see a problem with this implementation? Or see an improvement we should use instead? *** 6 - This work has a small example of drama markup. It is very simple markup (verse with no partial lines), but it seems to work well. I don't have any problems with it, but I also know that my experience with drama markup is extremely limited. Any suggestions/concerns? *** 7 - The only other thing I can remember that was at all out of the ordinary with this text was the retention of small caps. I used the rend="sc" markup and it worked just as I expected it to in the TEI -> HTML converter. Any suggestions/comments/improvements? *** I'm sure I'll remember something on the way home tonight that I forgot to mention, but that's what I can think of right now for discussion. I'm looking forward to everyone's input. Josh

3 2

pglaf.org settings might block some messages
by Greg Newby 03 Nov '04

03 Nov '04

I've heard in the past 2 weeks from two people who discovered that their mail server settings resulted in pglaf.org bouncing their messages to gutvol-d(a)lists.pglaf.org (not necessarily through fault of their own). If you've sent messages to pglaf.org, but are not sure if they got through, you might want to send a test message or check the list archives (http://lists.pglaf.org) You can set your own list settings to get your own messages, and/or an acknowledgement message. The setting we use is to enforce the standard that mail servers (aka MTAs) must have reverse DNS entries (also known as PTRs). Several of the big ISPs, such as AOL, enforce this rule. Others don't. Mail from addresses with no corresponding PTR is (at pglaf.org) well over 99.9% likely to be spam. Over 10,000 such messages are blocked per week on the pglaf.org server using this single rule. The postfix server at pglaf.org has had this setting since the spring, and while I'm sure it has bounced some legitimate messages, it's only recently that anyone has brought any false positives to my attention. -- Greg

6 7

Re: [gutvol-d] jeroen's even-handed analysis
by Gutenberg9443＠aol.com 02 Nov '04

02 Nov '04

In a message dated 10/19/2004 12:16:07 AM Mountain Standard Time, Bowerbird(a)aol.com writes: Doing fully automatic convertion to good paged PDFs for > printing nice copies (and I mean good, as different from workable) > will probably always remain a dream This is A goal. It is not, and cannot be, THE goal. It would be great to have everything in printable PDF for people who want printable PDF. If you want to keep ten thousand books on your computer, printable PDF isn't worth the end product of bovine digestion. I loathe PDF. I'm sure I'm not the only person who uses Gutenberg who is in my situation: I'm going blind--slowly, fortunately, unlike a neighbor who went blind overnight--and I can't get PDF documents on my Rocket, which means that as my vision continues to deteriorate I'm going to have to read sitting in front of my computer if I want to read something that is not available in a format I can convert to text or HTML in order to convert it to Rocket. I agree with Michael. Post everything in TXT first AND THEN do anything else you want to do with it. I believe that is one of the goals of of the DP team, which has all the scanned pages on computer to work from. HTML, even the "Save As" kind of HTML, can maintain formatting if you tell it to; I know because I've done it often. A basic problem in this entire discussion is that there are a lot of people here who are program-happy, as opposed to computer-happy. I'm computer- happy, but like the vast majority of people who use Gutenberg, I'm really not interested in umpteen different programs. I just want a book I can read. As a scholar, I might at times need the specific coding which will tell me what used this punctuation mark or that whatever that doesn't come across on txt, but if I need that, I can obtain the book someway and reinsert the punctuation and formatting and whatever. The village schoolmaster in a third world village, who has two hours of electricity a day, one cellular phone for the entire village, and an obsolete laptop donated to him by a first world company with a connection from the phone to the laptop cobbled together by a gadget-minded Peace Corps volunteer or church or UN aid worker, doesn't give a squiddly about umlauts and grave accents. He just wants BOOKS that he can READ to his students during the two hours a day that the electricity is on. The cowboy who's going to be stuck all winter in a back-country cabin looking after a herd of cattle in a snowed-in high pasture, or the astronaut, or the submariner, or the scientists in a South Pole research station, or the kids going to bush- school on the radio in Australia or Alaska--these people don't need pretty pages. THEY NEED BOOKS. They need good books. That's all. If we go back to the very basics, this is the goal of Project Gutenberg. It is no mistake that the very first things Michael posted were the most important documents of freedom. An educated populace can be kept enslaved for only so long, and then the privy hits the fan. We are the world's free public library. We do not serve, nor do we even NEED to serve, the few people in elite professions who want, and need, to be able to account for every comma and every umlaut. People who are arguing their heads off about ten different ways to format are losing sight of the goal. It is hard to remember that your goal was draining the swamp if you are up to your a** in alligators. Stop creating alligators. If YOU--whoever YOU happens to be--want to create all kinds of pretty formats, do it. That's grand. But don't try to inflict your vision on all of PGLAF. The TXT versions MUST come first. Then people can be joyfully reading the new books, while other people create other formats for those nice new books. Now can we go back to draining the swamp? Notice I said "can," not "may." We Ph.D.s in English know our grammar. I MEANT "can." Anne

20 53

Re: [gutvol-d] author lookup [was: pglaf.org settings might blocksome messages]
by Joshua Hutchinson 02 Nov '04

02 Nov '04

But what happens when you have two different authors that share the same name? It will happen (if it hasn't already). Using a forward from a deprecate author number is probably not a bad idea... Josh ----- Original Message ----- From: "Joel A. Erickson" <joel(a)oneporpoise.com> To: "Project Gutenberg Volunteer Discussion" <gutvol-d(a)lists.pglaf.org> Subject: Re: [gutvol-d] author lookup [was: pglaf.org settings might blocksome messages] Date: Tue, 2 Nov 2004 11:06:45 -0800 > > I'm assuming numbers are used because it's easier on the programming side. > But wouldn't it be easier for the users if it was the name instead. It > probably has its downsides, but if author lookup was based on a name, then > when the name was modified, the system could just look for the closest > match(es). Or, I suppose, the author number could be forwarded, 3505 -> 744. > > On a side note, the cookies for personalizing the PG skin seem to teminate > rather quickly. Usually they last less than a day, it seems. Has anyone else > noticed this? Perhaps I should ask Marcello. > > Joel > > ----- Original Message ----- > From: "Andrew Sly" <sly(a)victoria.tc.ca> > To: "Project Gutenberg Volunteer Discussion" <gutvol-d(a)lists.pglaf.org> > Sent: Tuesday, November 02, 2004 10:43 AM > Subject: Re: [gutvol-d] pglaf.org settings might block some messages > > > > > >>From the catalog point of view, this has been settled, but it does bring > > up a point... > > > > I've seen in wikipedia and a few other places URLs constructed like the > > two below, using an "author number". After amalgamating the two > > author records below, one of them will no longer link to > > William Joseph Long. > > > > So this is just a warning that URLs formed like this are not necessarily > > permanant. > > > > Andrew > > > > On Tue, 2 Nov 2004 bkeir(a)pgdp.net wrote: > > > >> I had repeated bounces of the following message, as described. This was > >> sent to catalog twice and help once... > >> > >> > >> Hi > >> > >> Sorry, I know this isn't the correct address, but this mail has bounced > >> twice now from catalog AT pglaf.org > >> > >> My original message was: > >> > >> Hi > >> > >> Perhaps > >> > >> Long, William Joseph (1866 - 1952) > >> > >> http://www.gutenberg.net/catalog/world/authrec?fk_authors=744 > >> > >> and > >> > >> Long, William J. (1866 - 1952) > >> > >> http://www.gutenberg.net/catalog/world/authrec?fk_authors=3505 > >> > >> are the same person? > >> > >> Cheers! > >> > >> Bill > >> > >> Here's the second bounce report: > >> > >> > >> Your message did not reach some or all of the intended recipients. > >> > >> Subject: FW: Duplicate author? > >> Sent: 27/09/2004 12:51 PM > >> > >> The following recipient(s) could not be reached: > >> > >> 'catalog(a)pglaf.org' on 29/09/2004 12:51 PM > >> The message was undeliverable because the recipient specified > >> in the recipient postal address was not known at this address > >> The MTS-ID of the original message is: c=AU;a= > >> ;p=Matrikon;l=EXCHANGE-NCS-040927025037Z-16573 > >> > >> > >> > >> _______________________________________________ > >> gutvol-d mailing list > >> gutvol-d(a)lists.pglaf.org > >> http://lists.pglaf.org/listinfo.cgi/gutvol-d > >> > > _______________________________________________ > > gutvol-d mailing list > > gutvol-d(a)lists.pglaf.org > > http://lists.pglaf.org/listinfo.cgi/gutvol-d > > > > _______________________________________________ > gutvol-d mailing list > gutvol-d(a)lists.pglaf.org > http://lists.pglaf.org/listinfo.cgi/gutvol-d >

1 0

re: Re: [gutvol-d] Page Breaks
by Bowerbird＠aol.com 01 Nov '04

01 Nov '04

hugh said: > However, on page breaks, I have for some time (I'm my own webmaster) > adopted the practice, in putting books (not short articles) on our website, > of inserting the page numbers of the original in {curly brackets} which I > generally don't use for other purposes. This not only identifies the page > from the original one is reading (helpful both for checking and for > bibliographic reference) and, because it is surrounded by {curly brackets} > is easy to search for without finding other materials. that's a pretty good strategy. it's still fairly obtrusive on the reading experience -- we need to recognize most users don't want to see this info -- but i could live with that method if it became the policy. what i would do, with my viewer-program, is to "vanish" them; that is, i'd display them only if the user specified to show them, and even then, i'd move them out to the margins to be discreet... what i suggest, instead, for a standard for project gutenberg, would be to use some of the under-32 ascii-characters to indicate the various types of page-breaks, so they would be invisible to an ordinary end-user with an ordinary text-viewer, while a savvy viewer-program would be able to discern them and show them to the occasional reader that might want them. also -- and i'm sorry i haven't mentioned this up until now -- i think it's very important that these page-break indicators not gunk up the text. again, for the average user, they will be a nuisance in most cases, and we need to minimize that nuisance. for instance, consider the current practice in the .html versions coming out of distributed proofreaders with page-number info. even when the page-number display is moved out to the margin, with c.s.s., they are still there right in the middle of the text! so when a person selects a range of text including a page-number, and copies it out of the browser-window, boom, that page-number is sitting right in the middle of it. and it's a hassle to get rid of it. (and, as far as i know, that's the case even when you have elected to "turn off" display of the page-numbers, but i could be wrong on that.) one of the basic aspects of project gutenberg e-texts has always been that you could easily copy out the text and repurpose it, and i believe that is an important asset to protect... -bowerbird

1 0

re: talking to the walls
by Bowerbird＠aol.com 01 Nov '04

01 Nov '04

carlo said: > How do you include the information in the files > if it has been removed? go back to a source and get it, that's how. where applicable, information about page-breaks can be obtained from the d.p. proofed text-files; it's a simple matter of matching up image-scans with the text they contained. (see the page that contains a table of the scans with their text-files.) that's why i offered a demo using that specifically. (nonetheless, it's positively _criminal_ that we should even have to do _anything_ to re-gain this information, since it was _willfully_ discarded. when is this bad practice going to be halted?) for books not done by distributed proofreaders, it's as easy as loading the text-file into my viewer and clicking on each word that starts a new page as you get that information by viewing a paper-copy. (my viewer will then save an updated copy of the file.) this process can be facilitated by setting the leading so the lines-per-page is equivalent to the paper-copy, making the task almost trivially easy (but still useful!). > And moreover, how do you find the correct page > when some material (e.g. the footnotes) has been moved, > and the page contents are no longer consecutive? footnotes are easy. (my viewer displays them on the page where they are called anyway, so there's no problem there.) and if you point me to some examples of the other "material" that is moved, i'll be happy to tell you how i'd deal with that. > I have a solution of both problems for DP-produced books > using the files output by DP before the post-processing stage; right. > these files correspond to individual pages of the original book, > and you can find the image corresponding to a fragment of text > through a grep on the DP-file. that's one way of doing it. but why not run the process systematically, one time, restoring the page-break information in the text-files, and incorporating the ability to grab the image-scans -- automatically and simply -- using that information. i'm sure you know that the eyes of most users glaze over when you start talking about "grep". besides, what needs to be done is to _thoroughly_incorporate_ the error-reporting process _into_ the end-user's reading-experience, so as to maximize the eyeballs of all the people reading the e-texts. it's just a shame that -- at the same time readers are condemning the e-texts because "they are full of errors" -- practically _nothing_ is being done to harness their ability to _catch_ and _report_ errors. > The concept has been implemented recently by a student, > and a test of 300 recently posted PG ebooks should be > publicly available before the end of this week. This is > a part of a system for ebook maintenance (an user can > submit a proposal of correction of a text through a web page, > after consulting the original images, and an administrator later > can accept - or reject - the proposals and obtain automatically > a corrected version). sounds like a process i described in great detail months ago here. i'm glad somebody is programming it for you guys, because i'll be leaving here shortly. but i intend to write the app anyway, because users who want to grab content from the million-book-project will need it to turn those scans into nicely-proofed and formatted text... -bowerbird

1 0

(no subject)
by Carlo Traverso 01 Nov '04

01 Nov '04

Bowerbird> greg said: >> We're planning to include the scanned page images along with >> eBooks. In fact, this is part of the intent with the new >> directory structure for the PG servers (the /1/0/8/0/... >> structure). >> >> We haven't done any (or many, anyway) because we're still >> trying to figure out how to best name the page files, and how >> to link them on a page-by-page basis into the (marked up?) >> eBooks. Jim Tinsley drafted some general guidelines for the >> image files themselves, but linking them to the eBooks is >> something we need to figure out still. >> Bowerbird> greg, i can give you this capability _right_now_, with Bowerbird> your plain-text files (i.e., the whole library), if you Bowerbird> would only make it your policy to: (1) include Bowerbird> page-break information in the files, How do you include the information in the files if it has been removed? This can at best be valid for future production. And moreover, how do you find the correct page when some material (e.g. the footnotes) has been moved, and the page contents are no longer consecutive? I have a solution of both problems for DP-produced books using the files output by DP before the post-processing stage; these files correspond to individual pages of the original book, and you can find the image corresponding to a fragment of text through a grep on the DP-file. The concept has been implemented recently by a student, and a test of 300 recently posted PG ebooks should be publicly available before the end of this week. This is a part of a system for ebook maintenance (an user can submit a proposal of correction of a text through a web page, after consulting the original images, and an administrator later can accept - or reject - the proposals and obtain automatically a corrected version). Carlo

2 1

linking page-scans to the text
by Bowerbird＠aol.com 01 Nov '04

01 Nov '04

greg said: > We're planning to include the scanned page images > along with eBooks. In fact, this is part of the intent > with the new directory structure for the PG servers > (the /1/0/8/0/... structure). > > We haven't done any (or many, anyway) because > we're still trying to figure out how to best name the page files, > and how to link them on a page-by-page basis into the > (marked up?) eBooks. Jim Tinsley drafted some general guidelines > for the image files themselves, but linking them to the eBooks > is something we need to figure out still. > > (BTW, the Million Books project at archive.org uses djvu > for this purpose. It's not bad, but I like our intended solution > of XML markup much better. Plus, of course, the MBP is mostly > working with relatively poor quality proofreading. For PG, > the text has taken the main emphasis, not the appearance.) > > My notion is that the PGTEI and TEI lite solutions I've been > reading about in this list will be easily adaptable to > including links to specific page image files, so I've > not mentioned it until now. sometimes i feel like i'm talking to a wall... greg, i can give you this capability _right_now_, with your plain-text files (i.e., the whole library), if you would only make it your policy to: (1) include page-break information in the files, and (2) use a sensible and consistent naming standard; neither of these is difficult to realize in the slightest. (if you need some input on them, i'll be happy to give it.) if you'd like to see a demo program that does this -- using the page-scans and text-files over at d.p. -- say so publicly (before thursday) and i'll put one up. or continue delaying, it makes no difference to me... -bowerbird

1 0

The release of PG etext #7000
by Michael Dyck 01 Nov '04

01 Nov '04

For those of you who wish to celebrate the release of PG etext #7000 ("The Kalevala"), today would appear to be the day: http://www.gutenberg.org/etext/7000 -Michael Dyck

1 0