- gutvol-d - lists.pglaf.org

Re: [gutvol-d] draft TEI conventions and larger example file
by Jeroen.Hellingman＠kabelfoon.nl 29 Oct '04

29 Oct '04

Op 29-10-2004 01:06, schreef jij: Thanks for your comments. > I have a few comments on the draft guidelines. It'd be nice to have page > numbers printed on the pages. A letter size PDF would be useful, but the > margins on this one seem generous enough to print on letter-sized paper. I follow the ISO standard A4 size, which is an international standard, and offers several benefits to letter, which is only used in the US. I will keep margins generous though. > DP probably will not be preserving the long-s, and I think it a little > unrealistic to expect most of PG's XML documents to preserve it. Also, > the description is incorrect; in English, it's used everywhere except > at the end of the word, and it was used until about 1800, making it > used in the 18th century. Agreed. I will make this optional, and indeed, expect most people to drop it. I normally keep it. > It's always used in Fraktur; are we going to preserve that? Counting > that, it was used until the middle of the 20th century. It's probably > too minor for this document, but several German documents I've seen > use a non-ligatured long-s/s combination for the eszett, while not > using the long-s elsewhere. Even at the most pedantic, it's arguable > whether this should be encoded with the long-s. I would suggest, let the person who prepares the text decide. > There should be an option to preserve running headers where they encode > information not found elsewhere. I did this once, in an easy, but non TEI fashion, the formal method is to use <fw> tags. > I think we should go with standards on the languages section; that is, > RFC 3066 or its successor in draft. That is, #1, #2, #3, #8 with #5 found > in the draft. #4 and #7 can be encoded as en-x-1800 and en-x-Scottish > (how does this differ from sco?) in the draft, and I doubt anything would > choke on it today. #6 is a bad idea, especially as 3 letter 639 codes > sometimes overlap with SIL codes; if you need to encode Gaddang, phi-x-SIL-gad > or x-gaddang is a better idea. Isn't sco gaelic? I agree, and will adjust the guidelines (and the texts and tools I have) > What happened to emph? All I see is rend. Likewise, I'd rather see foreign > do italics and let you mark it with rend="none" if needed, as that would > match how most books do it, and give a guideline to when to use foreign. This is due to the way text are produced from printed sources, and it is often difficult to establish the reason a word is in italics. It could be because it is considered foreign, or for some other reason. I use foreign exclusively as a holder for the lang attribute. If you use the lang attribute consequently, you can use that to isolate fragments in a certain language. > I partially marked up Japanese Literature, and eventually decided not to > mark up all the non-italics Japanese words used in running English text, > like names of plants and such. I think a comment to mark up running > foreign text and italized foreign words, but avoid single words, like > the names of plants and foods, in running text if not italized. The decision to mark up words as foreign is sometimes difficult, and can impose a lot of work in such cases. I normally do this, as it helps much in spell checking. However, I would say, it is not required. Jeroen.

1 0

Working Group comments
by Jon Noring 29 Oct '04

29 Oct '04

Marcello wrote: >Jon Noring wrote: >> I would think and hope that DP will convene a formalized working group >> of the various experts and enthusiasts here and elsewhere to hammer >> out the DP Markup Specification based on requirements gathering and >> analysis, which is the proper way to do this. > I think design-by-committee is the wrong way to go about this. > Experimenting markup with more and more complicated books and refining > the specs along the way seems to me far more promising. Experimentation can be done *while* the working group is working on the specification, in an iterative process. It is important that experimentation itself is guided by the requirements established by the working group in looking at the bigger picture which can only be done by formalized collaboration between the members representing the various stakeholders interested in this. Of course, the most important player is DP, which has to implement the spec into their work flow, and they will certainly have their own laundry list of requirements. Anyway, you and others have already made a great head start on the experimental side, as well as establishing the first proposed "beta" specification, PGTEI. The working group will not need to start from scratch, but will be able to build upon the proverbial shoulders of giants. And to address the issue that the working group will likely not get it perfect the first time (it won't) -- in an informal chat I had with Charles a while back, one strategy he brought up is to come up with a "version 1.0" of the DP Markup spec, and implement that in the DP workflow. Then, as production rolls along, continue to update the spec as necessary to handle problem texts. The issue of compatibility (forward/backward) between versions of DP Markup spec will need to be addressed, and may be solved by keeping version 1.0 simpler (a smaller number of tags) and then add tags as needed over time. We don't want to remove tags as time goes on (since we may have finished texts using the deprecated/removed tags), but rather add support over time as needed. > But that's the Cathedral vs. the Bazaar discussion again. Yep. > To see a particularly disgusting example of design by committee just > look at XSLT. And to see another particularly disgusting example of design by committee, look at SGML and XML. And the worst of them all: TEI. Nothing good ever comes out of committees / formalized working groups. <smile/> >> The DPMWG will have a >> more formalized and committed leadership structure, with weekly >> teleconference calls. From my standards working group experience, it's >> amazing how much stuff gets done during weekly teleconferences and the >> occasional face-to-face meeting (biannual or annual), while written >> listserv exchanges in a group like gutvol-* usually ends up going >> around and around in circles. > Teleconferencing will essentially shut out all non-us based people > via the prohibitive costs or via the language barrier. Non native > English speakers like me may have a better standing in a written > discussion channel. This is of course an issue. There are now very inexpensive and free ways to hold a teleconference via VoIP or similar. In addition, all teleconference meetings, typically 1.0 to 1.5 hours in length, will be scribed and written Minutes produced. In-between teleconferences we can discuss details on a group forum. It is possible to hold the teleconferences at a time which is convenient for those in North/South America and those in Europe -- it gets tougher to find a good time when there are those in Australia/East Asia to include along with Europe/Americas, but this can be worked out somehow. >From firsthand experience it is amazing how more effective technical working groups are when they can at least meet by phone on a regular basis. It is a social and psychological thing which enhances working together and group creativity, which I've yet to see in text-only working relationships. At first I was skeptical (being a strong introvert myself who has always worked "online"), but came around as I observed the importance of human interaction by voice and in person for *technical working groups*. It's amazing, really. >> I would even ask someone like C. Michael Sperberg-McQueen to be an >> advisor to the working group > I don't know if the TEI people could advise us much. I think they will be very helpful -- I know a few others who are very knowledgeable about TEI in an XML-based publishing environment who can help establish requirements. A couple people I know are world-class at XSLT/XSL-FO (I think one of them served a while back on the original XSL working group at W3C.) A close business acquaintance presently serves on the CSS3 Working Group at W3C, and is working on high- quality presentation using XML+CSS in his business. Having varied views on the DP Markup vocabulary is important. > What we need is not advice about the use of TEI as markup language but > about the use of TEI as master format for automatic rendition into a > wide variety of output formats. There is the tei-presentation list for > this sort of thing but traffic there has been very light. Yes, definitely! But note that other groups will also be helpful by providing requirements, including end-user requirements. Having sharp tech people from the accessibility, the library/archive, the ebook publishing, and related communities, will contribute to the bigger picture by providing requirements that they see from their unique perspectives (e.g., metadata from the librarian types.) If we want DP-TNG (TNG: The Next Generation) texts to be good for a wide range of uses, then we have to have people representing the various user groups to have their say in the global design of DP Markup. And I need to re-emphasize the importance to the embracement and success of PG/DP by involving the various user groups with PG/DP, and the inclusive working group approach is one of several strategies to achieve this "buy in". > The only person who could really help is Sebastian Rahtz. Yes, definitely. I recall he and I chatted in private email a couple years ago (for what I don't remember). I'm not sure if he is subscribed to this forum. He is definitely very sharp and would make a great addition to the working group if he is able to participate in some capacity, even if only as an advisor. Jon Noring

1 0

Re: [gutvol-d] draft TEI conventions and larger example file
by D. Starner 28 Oct '04

28 Oct '04

I have a few comments on the draft guidelines. It'd be nice to have page numbers printed on the pages. A letter size PDF would be useful, but the margins on this one seem generous enough to print on letter-sized paper. DP probably will not be preserving the long-s, and I think it a little unrealistic to expect most of PG's XML documents to preserve it. Also, the description is incorrect; in English, it's used everywhere except at the end of the word, and it was used until about 1800, making it used in the 18th century. It's always used in Fraktur; are we going to preserve that? Counting that, it was used until the middle of the 20th century. It's probably too minor for this document, but several German documents I've seen use a non-ligatured long-s/s combination for the eszett, while not using the long-s elsewhere. Even at the most pedantic, it's arguable whether this should be encoded with the long-s. There should be an option to preserve running headers where they encode information not found elsewhere. I think we should go with standards on the languages section; that is, RFC 3066 or its successor in draft. That is, #1, #2, #3, #8 with #5 found in the draft. #4 and #7 can be encoded as en-x-1800 and en-x-Scottish (how does this differ from sco?) in the draft, and I doubt anything would choke on it today. #6 is a bad idea, especially as 3 letter 639 codes sometimes overlap with SIL codes; if you need to encode Gaddang, phi-x-SIL-gad or x-gaddang is a better idea. What happened to emph? All I see is rend. Likewise, I'd rather see foreign do italics and let you mark it with rend="none" if needed, as that would match how most books do it, and give a guideline to when to use foreign. I partially marked up Japanese Literature, and eventually decided not to mark up all the non-italics Japanese words used in running English text, like names of plants and such. I think a comment to mark up running foreign text and italized foreign words, but avoid single words, like the names of plants and foods, in running text if not italized. -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

Re: [gutvol-d] on the question of sidenotes, footnotes, and end-notes
by D. Starner 28 Oct '04

28 Oct '04

"Joshua Hutchinson" writes: > (I think if I had a scan of the original, I'd probably more > fully understand what you were trying to do.) Take a look at any of the EETS works by PM EETS (that is, all of them except the book titled Early Middle English). They've got good examples of where you'd want to attach a note to a strech of text. -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

re: Re: [gutvol-d] Final PGTEI... page numbers
by Bowerbird＠aol.com 28 Oct '04

28 Oct '04

brad said: > Detractors of XML on this list have brought up > the fact that the TEI manual is 1400 pages long > as a negative. Why? actually, it was jeroen who initially mentioned that fact. but since you asked, the reason this is seen as a "negative" is because we think that precious few of the volunteers who have traditionally shouldered the effort of creating e-texts will continue to do so if an understanding of those 1400 pages of t.e.i. documentation were to become a prerequisite. but maybe now distributed proofreaders has enough people on-board that they feel less uncomfortable taking that risk... or maybe not, as their tentative plan thus far involves adding two "markup" rounds (at least, and maybe more) to their existing two "proofing" rounds, so as to minimize the number of people who need to be concerned with markup. > This shows that TEI is well documented. um, well, yes, i guess it does. although _more_ documentation is not _always_ a good sign of _better_ documentation, is it? > As a general rule, the more documentation that is available > for a spec the more mature and useful the standard > and the easier it is to learn and implement. i'm not quite so sure i agree with that "general rule", brad... i think it would be just as possible -- and more compelling -- to formulate a "general rule" that the more documentation that a spec needs, the more complex it is, which means that it is _harder_ to "learn and implement"... i'm not afraid of documentation. indeed, quite to the contrary, i'm one of those rare people who often prefers reading it _first_, because if you can stomach it, it'll save you lots of fiddling time. and i'm a word geek too. so i find the massive t.e.i. documentation -- and indeed the whole framework itself -- to be a remarkable and fascinating piece of work. it is mind-boggling to witness how _complex_ and _variegated_ a comprehensive examination of text can become, once you pour a foundation and start building a building. on the other hand, i can equally admire a system that boils things down to their essence, and creates great benefits with few costs. if all the volunteers contributing their efforts to project gutenberg were word geeks as willing to throw themselves into a devotion of documentation, like you and me, brad, it might not matter whether we went with the complex system or one that is a lot more easy. but given that they probably aren't, we should think very carefully before committing them to a world with a high degree of difficulty. as you put it, the learning of a complex system like t.e.i. is often "a gradual process of incremental epiphanies". can we _survive_ the situation where thousands of volunteers are put through that? with perhaps many becoming alienated in the course of doing so? unless i miss my guess, just the last few days of "how do we do this?" posts on this listserve have tried the patience of most subscribers... (which leads me to suggest that perhaps there is another listserve that is more appropriate for that, where the markup geeks can go?) -bowerbird

3 2

Re: [gutvol-d] on the question of sidenotes, footnotes, and end-notes
by Joshua Hutchinson 28 Oct '04

28 Oct '04

----- Original Message ----- From: Brad Collins <brad(a)chenla.org> <snipped explanation of using <seg> vs using <note> > OK, the gist I got was that you want to be able to tie the information from the margins to specific sections (a beginning and ending point) rather than tie to a single spot and assume it applies to some indeterminate length ahead. I can see where <seg> allows that. Is that much fidelity in the original? For instance, the <seg> marks you applied ... is there something in the original that says this segment stops *right here*? I ask because while the beginning of the <seg> seems clear, in the text I'm picturing in my head, the end of the segment would be kinda of fuzzy. (Unless the text used a marker or line break or something at the same spot you are using <seg> breaks.) If it is fuzzy, it seems the <note place="margin"> markup provides the same "here forward to some point" fidelity in information. (I think if I had a scan of the original, I'd probably more fully understand what you were trying to do.) Josh

1 0

PGTEI and more
by Scott Lawton 28 Oct '04

28 Oct '04

My feedback on PGTEI is too long for email, so I posted it here: http://Classicosm.com/xml/feedbackonpgtei.html Sections include: PGTEI Vocabulary PGTEI Examples PGTEI Documentation Generated HTML Default CSS Generated PDF Generated Text PGText to PGTEI I also put together a (rough draft!) Quick Reference table, including a comparison to XHTML http://Classicosm.com/xml/pgteiquickreference.html To help explore alternatives to TEI, I critique a side-by-side comparison to a dedicated vocabulary for plays: http://Classicosm.com/xml/tei-vs-play.html Feedback welcome!!! -- Cheers, Scott S. Lawton http://Classicosm.com/ - Classic Books http://ProductArchitect.com/ - consulting

2 1

re: Re: [gutvol-d] Final PGTEI... page numbers
by Bowerbird＠aol.com 28 Oct '04

28 Oct '04

jon noring said: > for most of DP's volunteers, the markup will be > "under-the-hood" and largely invisible -- most of the > volunteer work anyway is for copyediting the text > (correcting OCR errors), not markup insertion, > so no need to require these volunteers to learn > the gory details of TEI. actually, that represents a poor understanding of the work-flow at distributed proofreaders, under the current system anyway, where the proofers are using a clumsy system of pseudo-markup. > Only the most experienced and interested of the DP volunteers, > who do the final cleanup/finishing stages, will actually > play with the markup itself. well, now you're talking about the system that will be created, and what that will ultimately look like has not yet been decided. the way you've put it here is, to some degree, what is desired, but there's some question about whether proofers can do their job prior to the introduction of any markup at all. of course, there is _also_ some question about how easy it will be to do the proofing if any obtrusive markup is "inflicted" on the text prior to proofing. further, at present, "proofing" -- the act of catching and correcting errors, either in the text or in the formatting -- happens right up until the end of the text's processing, and i think the finding will be that obtrusive markup, whenever it occurs, will short-circuit that. whether the early rounds can be improved to the point that this "short-circuiting" causes no problems is yet another open question. > Aside: the DP-produced XML Master texts will certainly be > used for many purposes, all of which instill requirements on > the markup specification, and which must be considered -- > this is the biggest missing area not being discussed on gutvol-*. well, the discussion _here_ carries absolutely no weight at all. if you want to know what d.p. is going to do, you'll have to go over to their forums, where they're batting abut these issues right now. (look under the "everything but distributed proofreaders" section, which is an odd place to put such a discussion, wouldn't you think?) > The most exciting of these is where the DPXML texts will be > archived into a special library-like repository which allows > a very high-level of end-user interface and customizability > to the collection (e.g., bookmarking, annotation, interlinking > within the repository and to other content repositories, blogging, > etc. -- all things several associates and I are now working on. sounds like you're off and running. perhaps you could teach people here how to crawl first. -bowerbird

1 0

Re: [gutvol-d] Final PGTEI... page numbers
by Joshua Hutchinson 28 Oct '04

28 Oct '04

----- Original Message ----- From: Jon Noring <jon(a)noring.name> > <snipped a lot of good stuff> I just wanted to address the DP/PG TEI Working Subcommittee idea. Probably not going to happen. Things tend happen like this around DP: One or two people see something irritating they want to scratch badly enough to start working on it themselves. Then, they come up with a workable implementation that is put out as a "test" of some sort. It gets refined and used more and more until it becomes a defacto standard. (See our current proofing guidelines at DP for a prime example of this process.) In this case, TEI was talked about but no one wanted to "scratch the itch" enough to take it on as their baby. I'm finally irritated enough by multiple formats that I've decided to get something going. With Marcello's invaluable technical expertise, I'm trying to keep the ball rolling. It's slowed down by the fact that I am NOT a TEI/XML expert, but I am making some progress. I've already learned a ton in the last week ... enough to be impressed by the TEI spec and by Marcello's work on the transforms so far. My goal is to have a working XML->HTML and XML->TEXT conversion for 90% of the texts that go through DP sometime before Christmas. The caveat here is that I'm still learning and while it looks doable to me now, I may learn something tomorrow that makes me revise my estimate. So, for now, I guess I'm the "unofficial" working committee (well, Marcello, too, since I keep bugging the poor guy constantly and he's still nice enough to respond to my e-mails). Others have provided very helpful pointers and advice, too, but I'm hoping to push this past just talking about it and into actually having something that works at some level. (Right now, the XML -> HTML conversion is "almost" there ... the XML -> TEXT conversion needs more work.) Josh

2 1

Final PGTEI run-thru for a while...
by Joshua Hutchinson 28 Oct '04

28 Oct '04

This e-mail concludes the "common" items I want to check in PGTEI. With the items in my previous tests and the ones today, I could mark up 95%+ of what I see in DP. So, my next step is to start trying to understand how the transforms work and see what *I* can do to improve things. Expect this to be slow going, folks, I'm an old English major who likes computers, so I have to puzzle things out as I go! :) **** For this one, I create a hodge-podge of stuff from the beginning of The Hunting of the Snark and my own gibberish additions to get to all the features I wanted to test. The XML file is attached at the end for anyone wanting to reproduce my tests. As before, the conversion was done with Marcello's online transforms at http://www.gutenberg.org/tei/services/tei-online. **** Table markup: 1 - XML was very straight forward. It is similar to HTML table markup, just with slightly different tag words. <row> instead of <tr>. <cell> instead of <td>. All in all, the more human friendly tags in the XML are easier to parse than the HTML. Under the HTML conversion, the tables came out well. No complaints there. Under the TEXT conversion, the small table came out well. However, when I used longer data items in the second table, the TEXT conversion did not do so well. Basically, the text conversion does not try to line wrap the table cells at all, the table grew to be extremely wide. This one is a bit of a show stopper as far as automated conversion is concerned. Granted, the tables could be manually edited, but that hurts the whole reason for using a master document format. ** Footnote markup: Again, no real complains on the footnotes/endnotes. It is pretty straight forward once you read the formatting rules. The nice thing is that the conversion process handles moving the notes to their proper location for you. However, I did have one question that I couldn't find the answer to. How would you handle sidenotes? It looked like you could put a place="left" (or "right") in the <note> tag, but PGTEI doesn't support that. Is that even the right semantic tag for a sidenote? TEXT conversion had one glitch. For some reason, the footnote listing at the end of the text did not put a number 1 in front of the first footnote. The second footnote was labelled with a 2 correctly. This problem was not present in the HTML conversion. ** Page number markup: No complaints. I'll be looking into a transform that will place the numbers in the margin, but that is a secondary concern. ** Blockquotes: I wanted to markup a blockquote example, but I didn't see how. Anyone out there know how to handle a blockquote with a text? ** Poetry markup: I had the most notes for poetry, so I left it for last in the markup. 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 &emsp; as a quad indent. Works for me, unless someone has a different suggestion. 2 - It was unclear to me at first, that a poetry fragment still needed <lg> around it. <l> which marks off one line of poetry is insufficient, because the poem line would still be treated as inline in the sentence with just <l>. Putting <lg> around it set it off on its own line. 3 - If I understand the markup right, <lg> represents a portion of the poem, such as a single stanza. To represent the whole poem in one structural element, you need a higher level tag. Would <div1> work ok here? Or is the some poem tag I'm missing? HTML results - Poetry is not marked off well. The poems are flush with the left margin. Adding a larger margin around the poem will help it appear distinct from the prose text around it. Also, the paragraph indenting is affected by poetry. Since the conversion only indents a paragraph if the previous line was the end of a paragraph, it doesn't indent after a poem. This is taken care of if we revert to standard HTML paragraph spacing. **** Josh **** source.xml-- ============ <?xml version="1.0" encoding="iso-8859-1" ?> <!DOCTYPE TEI.2 SYSTEM "pgtei.dtd"> <TEI.2 lang="en-gb"> <teiHeader> <fileDesc> <titleStmt> <title>The Hunting of the Snark</title> <author><name>Lewis Carroll</name></author> </titleStmt> <editionStmt> <edition n="12">Edition 12 <date value="1992-3">March 1992</date> </edition> </editionStmt> <publicationStmt> <publisher>Project Gutenberg</publisher> <pubPlace><xref url="www.gutenberg.org">www.gutenberg.org</xref></pubPlace> <date value="1992-3">March 1992</date> <idno type='etext-file'>snark12</idno> <availability> <p>This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included online at <xref url="www.gutenberg.org/license">www.gutenberg.org/license</xref></p> </availability> </publicationStmt> <sourceDesc> <bibl> THE MILLENNIUM FULCRUM EDITION 1.2 </bibl> </sourceDesc> </fileDesc> <encodingDesc> <classDecl> <taxonomy id="lc"> <bibl> <title>Library of Congress Classification</title> </bibl> </taxonomy> </classDecl> </encodingDesc> <profileDesc> <langUsage> <language id="en-gb">British</language> </langUsage> <textClass> <classCode scheme="lc"> ***  </classCode> <keywords> <list>  </list> </keywords> </textClass> </profileDesc> <revisionDesc> <change> <date value="1992-3">March 1992</date> <respStmt> <name>unknown</name>  </respStmt> <item>Project Gutenberg Edition</item> </change> <change> <date value="2004-10">October 2004</date> <respStmt> <name>Joshua Hutchinson</name>  </respStmt> <item>TEI markup</item> </change> </revisionDesc> </teiHeader> <text> <front> <divGen type="titlepage" /> <divGen type="pgheader" rend="newpage" /> <divGen type="toc" rend="newdoublepage" /> </front> <body> <div> <index index="toc" /> <index index="pdf" /> <index index="pdb" /> <head> THE HUNTING OF THE SNARK </head> <head type="sub">an Agony in Eight Fits</head> <head type="sub"> Lewis Carroll </head> <head type="sub"> THE MILLENNIUM FULCRUM EDITION 1.2 </head> </div> <div rend="newpage" type="preface"> <index index="toc" /> <index index="pdf" /> <index index="pdb" /> <pb n="i" /> <head> PREFACE </head> <p> If—and the thing is wildly possible—the charge of writing nonsense were ever brought against the author of this brief but instructive poem, it would be based, I feel convinced, on the line (in p.4) </p> <lg><l>"Then the bowsprit got mixed with the rudder sometimes." <note place="foot"> This is an example footnote. </note> </l></lg> <p> In view of this painful possibility, I will not (as I might) appeal indignantly to my other writings as a proof that I am incapable of such a deed: I will not (as I might) point to the strong moral purpose of this poem itself, to the arithmetical principles so cautiously inculcated in it, or to its noble teachings in Natural History— I will take the more prosaic course of simply explaining how it happened. </p> <p> The Bellman, who was almost morbidly sensitive about appearances, used to have the bowsprit unshipped once or twice a week to be revarnished, and it more than once happened, when the time came for replacing it, that no one on board could remember which end of the ship it belonged to. They knew it was not of the slightest use to appeal to the Bellman about it — he would only refer to his Naval Code, and read out in pathetic tones Admiralty Instructions which none of them had ever been able to understand — so it generally ended in its being fastened on, anyhow, across the rudder. The helmsman used to stand by with tears in his eyes; he knew it was all wrong, but alas! Rule 42 of the Code, "No one shall speak to the Man at the Helm," had been completed by the Bellman himself with the words "and the Man at the Helm shall speak to no one." So remonstrance was impossible, and no steering could be done till the next varnishing day. During these bewildering intervals the ship usually sailed backwards. </p> <p> As this poem is to some extent connected with the lay of the Jabberwock, let me take this opportunity of answering a question that has often been asked me, how to pronounce "slithy toves." The "i" in "slithy" is long, as in "writhe"; and "toves" is pronounced so as to rhyme with "groves." Again, the first "o" in "borogoves" is pronounced like the "o" in "borrow." I have heard people try to give it the sound of the "o" in "worry. Such is Human Perversity. </p> <p> This also seems a fitting occasion to notice the other hard works in that poem. Humpty-Dumpty's theory, of two meanings packed into one word like a portmanteau, seems to me the right explanation for all. </p> <pb n="ii" /> <p> For instance, take the two words "fuming" and "furious." Make up your mind that you will say both words, but leave it unsettled which you will say first. Now open your mouth and speak. If your thoughts incline ever so little towards "fuming," you will say "fuming-furious;" if they turn, by even a hair's breadth, towards "furious," you will say "furious-fuming;" but if you have the rarest of gifts, a perfectly balanced mind, you will say "frumious."</p> <p> Supposing that, when Pistol uttered the well-known words — </p> <lg><l> "Under which king, Bezonian? Speak or die!" <note place="foot"> <p>This is, hopefully, an example of a multi-line footnote.</p> <p>Here is where the second line of the footnote should be.</p> </note> </l></lg> <p> Justice Shallow had felt certain that it was either William or Richard, but had not been able to settle which, so that he could not possibly say either name before the other, can it be doubted that, rather than die, he would have gasped out "Rilchiam!" </p> </div> <div rend="newdoublepage"> <pb n="1" /> <index index="toc" /> <index index="pdf" /> <index index="pdb" /> <head> Fit the First </head> <head type="sub"> THE LANDING </head> <lg> <l>"Just the place for a Snark!" the Bellman cried,</l> <l n="2">As he landed his crew with care;</l> <l>Supporting each man on the top of the tide</l> <l>By a finger entwined in his hair. </l> </lg> <lg> <l> "Just the place for a Snark! I have said it twice:</l> <l>That alone should encourage the crew. </l> <l>Just the place for a Snark! I have said it thrice: </l> <l>What i tell you three times is true."</l> </lg> <lg> <l>The crew was complete: it included a Boots — </l> <l>A maker of Bonnets and Hoods — </l> <l>A Barrister, brought to arrange their disputes — </l> <l>And a Broker, to value their goods. </l> </lg> </div> <div rend="newpage"> <pb n="2" /> <index index="toc" /> <index index="pdf" /> <index index="pdb" /> <head>Example of a Table</head> <table rows="2" cols="2"> <row role="label"> <cell>Column 1 Heading</cell><cell>Column 2 Heading</cell> </row> <row role="data"> <cell>Column 1 Data</cell><cell>Column 2 Data</cell> </row> </table> <table rows="2" cols="2"> <row role="label"> <cell>Column 1 Heading - REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY LONG</cell><cell>Column 2 Heading - REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY LONG</cell> </row> <row role="data"> <cell>Column 1 Data - REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY LONG</cell><cell>Column 2 Data - REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY REALLY LONG</cell> </row> </table> </div> <div> <index index="toc" /> <index index="pdf" /> <index index="pdb" /> <head> THE END</head> <p> </p> </div> </body> <back rend="newdoublepage"> <divGen type="footnotes" /> <divGen type="colophon" rend="newpage" /> <divGen type="pgfooter" rend="newpage" /> </back> </text> </TEI.2>

4 5