- gutvol-d - lists.pglaf.org

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

RE: [gutvol-d] barriers to XML posting
by D. Starner 24 Oct '04

24 Oct '04

"James Linden" writes: > Yes, I have blocked Bowerbird from joining the PGXML list, but he is the > _only_ person that I've blocked. The only reason for this is because of > other people's reactions to him, not because of Bowerbird himself. Just like we innocuate against polio, not because of polio itself, but because of other people's reactions to it? > You can at > least try to extract the useful information that he does give from the flame > wars they often come in. This way, you might actually LEARN something. My stress level is high enough without listening to a self-centered egomaniac who has repeatedly stated his unwillingness to work with me. > More mud is slung on this list than on ANY other list that I'm subscribed > to, but I have to admit, I'm only subscribed to about 200 active lists, so I > may be missing the mud-slinging ones. I haven't seen that at all. It really doesn't compare to debian-devel and other lists I've been on at all. > I've made no secret of my personal opinions of PG: > > 1) the website is a disgrace > 2) the archive is poorly organized > 3) the catalog system is a hack job done by unqualified people > 4) the PG text format is extremely disgusting > 5) PG makes volunteers work uphill to get anything done > 6) the lack of quality in our content offsets any gain from it [More wild criticisms of PG] What makes you think this is at all constructive? You use emotionally charged words--"disgrace", "hack job", "disgusting"--and criticize almost everything about PG. I think it would be much more constructive in the future to deal with one issue at a time. > We don't even provide well-suited tools for the volunteers to use to > improve PG, because, oh my god, maybe the tool isn't 100% open-source! Maybe > the tool has been offered to PG on a perpetual right to use for PG status, > but oh, lordy, that's just not good enough. I have no idea what the context was on this, and that would be terribly helpful. I'm sceptical to the idea that PG would turn down a great improvement on our current tools merely because they aren't open source. However, open source is about the flexibility to get the job done. There was a non-web based frontend to DP, but it had to be abandoned because the author disappeared and nobody had the source to fix it as the site changed. Having an open-source program means we can fix it, we can port it, and we don't have to worry about whether we're using it for "PG status" or for Rastko or for our private project. That's a valuable thing, and something that PG should push for when possible. -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

2 1

Re: [gutvol-d] barriers to XML posting
by D. Starner 23 Oct '04

23 Oct '04

Scott Lawton writes: > During my learning process, I came across an interesting > comparison of Shakespeare marked up using TEI and an "ad > hoc" markup used by Jon Bosak (a key inventor of XML). > Though the comparison was done by a TEI advocate, I think > Jon's is a much better model for our purpose. > > http://www.tei-c.org.uk/Sample_Manuals/mueller-main.htm > A very gentle introduction to the TEI > (the comparison is near the end -- look for the garish background colors) I'd disagree. The bibliographic information in Jon's is insufficent; it doesn't even give us an author, much less the rest of the information we need to have computer readable. Once we've dumped the <hi rend="i"> lines in the TEI, the main difference is the line numbers (which are optional in TEI and necessary for some books) and the capacity to do split metric lines, which is again necessary for some books. -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

Re: [gutvol-d] Re: barriers to XML posting
by Joshua Hutchinson 23 Oct '04

23 Oct '04

----- Original Message ----- From: Steve Thomas <stephen.thomas(a)adelaide.edu.au> > > A question (possibly better put over on the DP list): > > Is it possible to OCR a scan directly to XML? Or is the output > from OCR always going to be text? > That is a very DP related question, but I'll answer here as best as I understand the future plans (and let others correct me where needed). The plan at DP is to move from the current 2 round proofing model to a (probably) 4 round proofing/markup model. The content provider will take the scans and OCR them normally. That part doesn't change. Then, there are 2 rounds of proofing that concentrate on typos, spelling, etc. Very similar to the 2 rounds we have now. Then, there are 2 MORE rounds of markup. Here is where all the markup like poetry, italics/bold, footnotes, chapter headings, thoughtbreaks, etc, etc are done. Then, when the final result gets out of 4 rounds, it is nicely marked up (in theory) XML. The post-processor does his/her normal magic, combining all the pages, running validators on it, etc. As far as the OCR process, we currently run some pre-processors on text to fix common scannos, etc. I'd be surprised if those pre-processors didn't improve/change as the XML world emerges at DP. Josh

5 5

re: the king of vaporware
by Bowerbird＠aol.com 23 Oct '04

23 Oct '04

james said: > More mud is slung on this list than on ANY other list > that I'm subscribed to, but I have to admit, > I'm only subscribed to about 200 active lists, > so I may be missing the mud-slinging ones. yeah, it's tough to keep up. :+) and those are just the listserves. don't forget the forums... like the one over at distributed proofreaders... why just the other day (maybe yesterday?), two minutes after you posted a message where you mentioned pgxml.org, someone -- who must not know that kodekrash is you -- said, "last i heard, pgxml was being run by james linden, the king of vaporware..." i guess he didn't know that's supposed to be _my_ title... :+) anyway, like i said, it's tough to keep up... ;+) -bowerbird

2 1