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

Re: [gutvol-d] Found an indention example in TEI...
by Joshua Hutchinson 27 Oct '04

27 Oct '04

I found another example of using the rend attribute. <l rend="indent1">As he landed his crew with care;</l> <l rend="indent2">As he landed his crew with care;</l> etc. The indent level would indicate number of tab stop indentions for that line. Not in the TEI spec itself, but seems to be widely used modification/addition. Josh ----- Original Message ----- From: Andrew Sly <sly(a)victoria.tc.ca> To: Project Gutenberg Volunteer Discussion <gutvol-d(a)lists.pglaf.org> Subject: Re: [gutvol-d] Found an indention example in TEI... Date: Tue, 26 Oct 2004 10:31:28 -0700 (PDT) > > > Some recent texts coming from dp have had css used for indicating > indentation in verse. They use class selectors such as i2, i4, i6 > to indicate various levels of indentation. Could something similar > be adopted in this case? > > Andrew > > On Tue, 26 Oct 2004, Joshua Hutchinson wrote: > > > <l rend="indent">As he landed his crew with care;</l>

2 1

Re: [gutvol-d] (Fwd) FW: Copyright Infringement of Gone With the Wind
by Dennis McCarthy 27 Oct '04

27 Oct '04

Have they claimed that the cab driver who hit Margaret Mitchell at 13th and Peachtree in 1949 was also working for the vast P.G. conspiracy? Perhaps if she had know how it would have affected her copyright term in Australia, she would have been more careful crossing the street. Has anyone looked into rewriting the Gutenberg License to prohibiting inherited copyright holders and their attorneys from downloading PG works? --------------------------- Dennis McCarthy nihil_obstat(a)mindspring.com

1 0

Found an indention example in TEI...
by Joshua Hutchinson 27 Oct '04

27 Oct '04

Google is such a wonderful thing... :) I did some further digging and found an example (of the exact poem I was using for an example, no less) from the Electronic Text Center at the UofVirginia. They use a simple rend element within the <l> tag to mark an indent. Anyone have a problem with that? It keeps the indention information, but does it within the XML tag element. The only possible issue I see if that it doesn't allow for variable length indents. Josh **** Lewis Carroll's The Hunting of the Snark <div1 type="fit" n="1"> <head> Fit the First: THE LANDING </head> <pb n="45" /> <lg type="stanza"> <l>"Just the place for a Snark!" the Bellman cried,</l> <l rend="indent">As he landed his crew with care;</l> <l>Supporting each man on the top of the tide</l> <l rend="indent">By a finger entwined in his hair.</l> </lg> <pb n="46" /> <lg type="stanza"> <l>"Just the place for a Snark! I have said it twice:</l> <l rend="indent">That alone should encourage the crew.</l> <l>Just the place for a Snark! I have said it thrice:</l> <l rend="indent">What I tell you three times is true."</l> </lg> [ETC....] </div1>

3 2

re: [gutvol-d] (Fwd) FW: Copyright Infringement of Gone With the Wind
by Bowerbird＠aol.com 26 Oct '04

26 Oct '04

frankfurtkurnit klein & selz said: > Tel: (212) 980-0120 x6735 michael, whenever you want us to call these guys, you just let us know... :+) -bowerbird

1 0

Re: [gutvol-d] Final PGTEI run-thru for a while...
by Joshua Hutchinson 26 Oct '04

26 Oct '04

----- Original Message ----- From: Jon Noring <jon(a)noring.name> <snipped poetry indent discussion> Fundamentally, it comes down to whether the indentation is structual (it provides some author intended meaning to the poem) or simply presentational (the type setter put those indents there to make everything "pretty"). First argument for structural ... The author can use indention differently for different poems within the same book. That, to me, means that the indention pattern has some meaning for that author. Eg: It was intentional that the third and fifth lines are indented and the seventh and ninth lines were double indented. Yet, in the next poem, every other line is indented equally. That is an intentional indentation and implies meaning to it. Second argument for structural ... In the Chicago Manual of Style (reference I used is here: http://nutsandbolts.washcoll.edu/chicago.html) it does include an indent in the quoted poem it gives as the first example. Since the style guide thinks that indention is important and should be preserved, I think that argues for the preservation in our texts as well. Argument for using   (non-breaking space) or &emsp; (quad space) ... The full TEI spec (much less TEI-Lite) does not seem to have a tag element to control indents in a poem. Hence, the use of spaces to specify those indents. With the added benefit of being XML format independent. If our text is converted to some other flavor of XML, the indents are kept intact. Whereas if we tried to create a custom tag element to control indention, that tag element (and hence the information) would most likely be lost if the text was convert to some other flavor of XML. Josh PS After reading the full TEI spec section on poetry, I'm not sure at all anymore on how to tag an entire poem as a single entity. ie, if you have two separate poems in a book of poetry, what element(s) do you use to mark one poem as a separate from the other? <lg> markup seems to indicate "a stanza, refrain, verse paragraph, etc." (http://www.tei-c.org/P4X/VE.html) it mentions using <div> to mark off sections of a long poem into Cantos or Books... Should I use the same <div> markup for setting off individual poems as separate entities?

1 0

Re: [gutvol-d] Final PGTEI run-thru for a while...
by Joshua Hutchinson 26 Oct '04

26 Oct '04

----- Original Message ----- From: Jon Noring <jon(a)noring.name> To: gutvol-d(a)lists.pglaf.org Subject: Re: [gutvol-d] Final PGTEI run-thru for a while... Date: Tue, 26 Oct 2004 09:39:13 -0600 > > Joshua wrote: > > > This e-mail concludes the "common" items I want to check in PGTEI. > > > > ... > > > > 1 - How should we markup poetry indents? In HTML, I use > > toput two spaces for indents on the text.... *edit* I > > just found in Marcello's guide that he suggests using   as a quad > > indent. Works for me, unless someone has a different suggestion. > > As we've discussed (and argued) before, it is my belief that, except > where typography is integral to the poem itself ("poetry as visual > art"), that poetry should be marked up in a structural, not > presentational, sense. This means text characters should NEVER be used > for visual layout purposes -- characters should be used only for > representing textual content. Using text characters for layout mucks > up usability, repurposeability, CSS styling, and accessibility. > > Use XSL*, CSS or other styling language to effect the desired output. > End-users will now have more ability to tailor the verse to their > particular reading devices. Of course, a non-parsed comment could be > added to the markup explaining how the original was typeset for those > wishing to try to duplicate the original layout (but then, that's one > purpose for having access to the original page scans.) > The big difference here is that the indent spacing in lines of poetry is NOT just presentational. It can and has been argued that the spacing is INTENTIONAL and STRUCTURAL to the poem. Hence, the addition of the leading spaces, either through   (non-breaking space) or &emsp; (quad space). Your example of the layout of the quatrains is purely presentational. They do not provide any structural meaning to the poem, whereas poetry indentions often DO provide structural meaning. I'll let David argue the case further if necessary, as he's been the biggest proponent of poetry indents as structural vs presentational in the DP forum discussions on the subject. Josh

2 1

Re: [gutvol-d] Critique of automated conversion of PGTEI on PG website
by Joshua Hutchinson 25 Oct '04

25 Oct '04

----- Original Message ----- From: Jon Noring <jon(a)noring.name> > Marcello wrote: > > Joshua Hutchinson wrote: > > Certainly, how PG would enable style sheet swapping may be different > than how CSS Zen Garden does it, but that's beside the point. The > important point is that it can be done, and will be an exciting > addition to PG by allowing readers to "have it their way" rather than > "having it our way." We will not have to argue on whether we want 10% > or 20% margins, etc. This will also entice many to submit their own > CSS designs for people to use. But it all starts with the Master > markup being done *right*. > I agree that the CSS provides a powerful and easy way to have different formats. However, we need a "standard" format as a base. The default style is the one that Joe Sixpack, for instance, will see when he clicks on the HTML doc link at the main PG website. We can then have the ability to "swap" CSS at the click of a button, but that functionality is somewhere down the road. We need a functional style in place now for this to move forward (back to Marcello's baby steps). Some of the issues I brought up are purely presentational and fall under the CSS heading. Some are functional (ie, the extra PG header at the beginning of the TEXT version). I think both need to be addressed and a "fix" decided on before XML can move forward. Currently, I'm working on marking up The Hunting of the Snark in PGTEI to see what further issues are introduced by poetry markup. As expected, there are a few and they are largely presentational in nature (CSS), but they need to be addressed to make sure that the XML itself is sufficient to the task of handling the content. Josh

1 0

Critique of automated conversion of PGTEI on PG website
by Joshua Hutchinson 25 Oct '04

25 Oct '04

Continuing my evalaution of Marcello's PGTEI setup on the gutenberg website (http://www.gutenberg.org/tei/) I used the same Declaration of Independence file I used last week to comment on the XML markup itself. This time I'm converted that XML file to HTML and TEXT using the online services section. Below are the bulleted items that *I* believe need some improvement. If anyone wants to duplicate my conversions, see my post from last week that contained the XML I used (or send me a quick e-mail and I'll forward the file on). Josh *** HTML conversion items: 1 - First thing that jumps out is the need for bigger left and right margins. This is a simple CSS change. Currently, DP has *mostly* standardized on 10% margins on the left and right. This gives some nice white space for easier reading and gives room for things like original source page numbers and sidenotes to be put in the margin area. 2 - If the author field is left blank, the conversion shouldn't put a "by" out there all by itself. Both the HTML and the TEXT version have this dangling word. 3 - The publication and edition date are both being printed, but it isn't clear which is which. Maybe put "Original publication date:" label before the date itself? 4 - Since the title, author, etc. is already list in the first few lines, the second listing below the gutenberg disclaimer line is redundant. Also, in that same spot, the language code is printed, which is nice, but I would suggest changing the format slightly. Namely, put the language code in brackets after the written out language. i.e.: English-United States [en-us] For most of us normal humans, the language codes are not intuitive. 5 - In the CONTENTS section, if there are no footnotes/endnotes, don't list a NOTES section. 6 - Use standard HTML paragraph spacing. Right now, the CSS specifies no blank line between paragraphs and an indent to the beginning of each paragraph. While this matches the original paper source, for me at least, it is jarring to read on a computer screen. This type of formatting would make perfect sense in the PDF conversion, since that one is geared for printing on paper. 7 - Need a horizontal rule (75% width seems right to me) between the CONTENTS section and the first section of the text. Right now, they run together. 8 - Need horizontal rule between major divisions of the text. Currently, the large type header gives a visual indication, but I don't believe it is enough. 9 - No need for the extra horizontal rule to mark off the FOOTNOTES section if there is no footnote section in that text. Currently, this situation makes for two horizontal rules in a row in a text with no footnotes. *** TEXT conversion items: 1 - It lists "The Project Gutenberg EBook of" twice. 2 - Has a dangling "by" line even when no author is specified. 3 - Same redundant title/author info as in the HTML conversion. 4 - Notes section appears whether there are any footnotes or not.

3 2

Re: [gutvol-d] Critique of automated conversion of PGTEI on PG website
by Joshua Hutchinson 25 Oct '04

25 Oct '04

----- Original Message ----- From: Marcello Perathoner <marcello(a)perathoner.de> > > Joshua Hutchinson wrote: > > > 1 - First thing that jumps out is the need for bigger left and right > > margins. This is a simple CSS change. Currently, DP has *mostly* > > standardized on 10% margins on the left and right. This gives some > > nice white space for easier reading and gives room for things like > > original source page numbers and sidenotes to be put in the margin > > area. > > OTOH I like to read texts in a small (horizontally) browser window so I > can put a shell window and the browser window on one screen. The shell > is usually compiling something or doing boring work. If the shell > stumbles over something I can immediately switch over, correct and > switch back to my reading. > > Big margins in the browser window would definitely be a major annoyance. > > I think, the CSS provided is just an example. Everybody here has enough > skills to build a CSS he/she likes. For the end user we may consider an > "alternate stylesheet" model where she may switch between a set of > predefined ones. > That is why a 10% margin is used instead of a fixed value. On a small window, the margin almost disappears, while on a "normal" sized window, it provides the white space. Also, while I agree CSS changes are the fix for these, what I am trying to do here is help to create a "standard" conversion that is workable. We don't really want the volunteer to HAVE to create their own CSS. We want them to have the ability to, of course, if they want to, but the standard conversion should have a baseline that is the best we can do. NOTE: Many of my suggestions are my personal opinion, such as the margins, and part of the purpose here is to get conflicting opinions for others. So, coming to a baseline style consensus is also a dual objective here. > > > 6 - Use standard HTML paragraph spacing. > > Same as above. > Which should be our baseline style, though? If other people like the printer style paragraphs better, that's fine. This is, again, my opinion here. > > > 7 - Need a horizontal rule (75% width seems right to me) between the > > CONTENTS section and the first section of the text. Right now, they > > run together. > > > > 8 - Need horizontal rule between major divisions of the text. > > Currently, the large type header gives a visual indication, but I > > don't believe it is enough. > > Use the rend="newpage" or rend="newdoublepage" attribute on a div, > front, back element like eg.: > > <div rend="newpage" type="chapter"> > > This will start a new page on paginated media and put a rule on HTML. > Cool, I learned something here. That takes care of that concern (at least to my mind, it does). Josh

2 1

Request for a PGTEI web form developer...
by Joshua Hutchinson 25 Oct '04

25 Oct '04

The hardest part of creating a PGTEI text right now is the header information. It is simply confusing to parse for a human and is very dense in information. This will be the section that most quickly kills people enthusiasm for the format. However, this section is very important because there is SO MUCH good information stored there. And it is information that needs to be in XML because it is exactly the type of information most likely to be accessed by a computer indexing program or something similar. That said, I am asking for someone with good web developing skills to set up to the plate and create a web page that allows a human to enter information in a nicely formatting web form and then spits out the PGTEI compliant header to be included in the beginning of a converted text. I am very willing to help test such a beast and provide whatever help I can, but my HTML skills don't extend beyond the normal layout variety. I've never played with forms, much less a backend that can create output from the web form input. Thank you in advance to any willing to take this on! Josh

1 0