- gutvol-d - lists.pglaf.org

re: [gutvol-d] Re: unluckily for us (gutvol-d Digest, Vol 13, Issue 30)
by Bowerbird＠aol.com 26 Aug '05

26 Aug '05

jon noring said: > It is NOT trivial as Lee explained. as i explained, jon, i'm not speaking with you here. as usual, all of your points can be addressed. if anyone cares to hear them being addressed, they will have to make the points themselves. but i think most people just want this thread to go poof... -bowerbird

4 3

re: [gutvol-d] Re: unluckily for us (gutvol-d Digest, Vol 13, Issue 30)
by Bowerbird＠aol.com 26 Aug '05

26 Aug '05

josh said: > "this thread" is code for "Bowerbird", actually. now that's funny. i like funny. :+) but most people want the _conflict_ to go poof. and once i start delivering the pudding to y'all, the reaction will be silence from the other side, pure silence, so the conflict will indeed go away. -bowerbird p.s. oops. posted from my girlfriend's account. but from me, without a doubt, that tone is unique. :+)

1 0

re: [gutvol-d] Re: unluckily for us (gutvol-d Digest, Vol 13, Issue 30)
by Bowerbird＠aol.com 26 Aug '05

26 Aug '05

lee said: > Sure, but you don't get to call a lemon purple, > just because that's the way you see it. and if i _do_ call a lemon purple? or you call it chartreuse? who cares? if it ain't important in rendering the e-book, it makes absolutely no difference what color anyone calls it. > I can't see why this particular wheel needs re-inventing. and your obsession with paragraphs strikes me as being as unimportant and trivial as the number of angels that can dance on the head of a pin. so, lee, are you up for our usability challenge on alice? or is this little exercise your attempt to deflect attention? -bowerbird

2 1

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

26 Aug '05

Jon Noring <jon(a)noring.name> wrote: >Lee Passey wrote: > >>I would really like to know what the rationale for this rule is. >> >> >I suggest that you repackage your inquiry and post it to TEI-L. That's >where the bulk of the TEI experts, including those involved with TEI >development, hang out. Sebastian Rahtz is one of the brilliant people >there who is interested in a more constrained TEI subset for ebook >use. > > http://www.lsoft.com/scripts/wl.exe?SL1=TEI-L&H=LISTSERV.BROWN.EDU > >Maybe this time around the TEI mavens will be able to cogently explain >(at the highest abstract level) why one should not have a <p> after a ><div> within another <div>, but can have a <p> before the <div>. I'm >still quite perplexed, as it appears Marcello is as well. > > OK, so I guess I really don't want to know that badly. Everyone has to select from among those things they feel passsionate about, which ones they are going to spend time working one, and for me this is not one of those things. Besides, if they're not going to listen to Mr. Perathoner, or Mr. Collin, or even, apparently, Mr. Rahtz, one more random voice crying from the wilderness is not going to make much difference. Besides, being the anarchist that I am, my solution would be just to grab the TEI dtds from tei-c.org, rename them to "pg<whatever>.dtd", replace the one offending comma with a space, and then validate to that instead.

2 1

Re: unluckily for us (gutvol-d Digest, Vol 13, Issue 30)
by Lee Passey 25 Aug '05

25 Aug '05

Bowerbird(a)aol.com wrote: > > In z.m.l., anything surrounded by > > two or more blank lines is structured text. > > wait a minute! _i_ make the rules for z.m.l., not you. :+) Sure, but you don't get to call a lemon purple, just because that's the way you see it. So if you require that paragraphs in your markup language be segregated from the surrounding text by one, and only one, blank line you have forced a structure on the text. Hence, it is, by definition, a structured text. [snip] > in z.m.l., blank lines are the very thing that _define_ > paragraphs -- and titles too. so i am afraid that z.m.l. > will never "be able to" do what you are asking. but... Precisely my point. I was hoping that you were coming up with an algorithm that would identify _real_ paragraphs (as defined in the English language) inside unstructured text (human beings are pretty good at it, but even they are not infallible), and instead you have told me that you can detect blocks of random text which are delimited by blank lines (which we shall refer to as bns-paragraphs, for "bowerbird new-speak paragraphs") from inside of z.m.l.-structured text. The µBook ebook reader can do that right now (PG simplified text looks really good in µBook). I can't see why this particular wheel needs re-inventing.

1 0

Re: [gutvol-d] Re: prank someone is pulling
by Gutenberg9443＠aol.com 25 Aug '05

25 Aug '05

In a message dated 8/24/2005 2:16:34 PM Mountain Daylight Time, jon_niehof(a)yahoo.com writes: >Hmm. If someone faxed him Julius Caesar, I wonder* if he'd be >mad at ol' Will. Or Caesar. >It annoys me no end that the good names of volunteers are >besmirched in this fashion (or via google spamming, as posted >earlier). >(*but not enough to try it or recommend someone else try) Good question! I reassured him about three dozen times that nobody in our organization did it, but I don't think he believed me for the first two and a half dozen times. Anne Anne Do you like to breathe? Then save the trees! Begin a personal relationship with an ebook TODAY!

1 0

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

25 Aug '05

Marcello Perathoner <marcello(a)perathoner.de> wrote: > Lee Passey wrote: > >> On the other hand, I don't see how Mr. Hutchinson's second example >> could validate if the first does not, particularly given the fact >> that DTD's are not structured in such a way to permit a validator to >> make that kind of a judgment ("if a <div> contains a <div> it must be >> the last element of the first <div>" or "if a <div> contains a <div> >> it may be preceded by a <p>, but not followed by one"). > > > This simple declaration does exactly that: > > <!ELEMENT div (p*, div*)> > > "A div may contain zero or more p followed by zero or more div." Well, I carefully decomposed the TEI DTD and discovered that you're absolutely right (but you knew that already, didn't you :-)). As I understand it, a <div> can contain just about any other element, but once you include another <div> you can't include anything else (almost). What the hell were they thinking? I don't see anything in the English spec that would have led me to this conclusion, and I can't think of any rationale why it should be this way. Is it possible that the DTD has incorrectly implemented the TEI spec? Or did the authors really intend this inane result? I have to admit, this requirement (and the fact that <div> is not allowed inside <p>) really makes me have second thoughts about the usefulness of TEI as an encoding (because it hinders you from making a level-one, incomplete, encoding). I would really like to know what the rationale for this rule is. >> In this particular case, I suspect a bug in the validator program. I >> mean, writing validators is hard, and I am aware of at least one bug >> in the W3C's online HTML validator. > > > No bug. The TEI dtd is broken as designed. Well, at least I was able to figure out that _something_ was broken.

4 4

re: the proof is in the tarts
by Bowerbird＠aol.com 25 Aug '05

25 Aug '05

lee said: > Mr. Perathoner's TEI version of Alice in Wonderland > (http://www.gutenberg.org/tei/marcello/0.3/examples/alice/) > looks like it is much more complex, > and would be funner to play with. > I really like _Alice_ as an experimental text > because it has quite a few typographical oddities > which make it a good test case. alice is one of the most-frequently-used e-texts for e-book demos. maybe _the_ most. i worked up a z.m.l. version a while back. perhaps you'd like to create a version, too, in whatever format you like (openreader?), and we can do some real-world user testing? the proof _is_ in the pudding, don't you know... -bowerbird

1 0

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

25 Aug '05

lee said: > What the hell were they thinking? c'mon lee, don't spoil their fun... ;+) actually, the infighting on that one was pretty fierce. and a good part of it was frontchannel and archived, so you can read through every bit of the gory details. (gee, according to branko, it's still going on! well, you know how a good argument is, you just can't stop talking about it. maybe you can go talk some sense into them, lee.) -bowerbird p.s. and yes, branko, you're absolutely right, this thread should be on the x.m.l. list, not here!

1 0

Re: [gutvol-d] Re: unluckily for us (gutvol-d Digest, Vol 13, Issue 24)
by Bowerbird＠aol.com 25 Aug '05

25 Aug '05

i said: > in z.m.l., anything surrounded by two or more blank lines > is a paragraph. pardon me. that's a goof. anything preceded by _one_ or more blank lines is considered to be a new paragraph in z.m.l. i sometimes accidentally mix up "blank lines" and "line-endings". _two_ consecutive line-endings (i.e., _one_ blank line) delineates a new paragraph. two blank lines constitutes a "thought break". three or more blank lines constitutes a new section. (three is more like a "subsection", while four marks the lowest-level section, five the next-lowest, etc.) > In z.m.l., anything surrounded by > two or more blank lines is structured text. wait a minute! _i_ make the rules for z.m.l., not you. :+) > When you can recognize a paragraph, i can recognize a paragraph. i just explained how, up above. > and distinquish it from a title "distinquish" is a nice word. what does it mean? to distinguish and then squish? :+) i can recognize a title too, and thus "distinguish" it. i just explained how, up above. > or a block quotation inside of a paragraph, what's so hard about that? it's very easy to recognize the block quotation -- because those things are indented in z.m.l. -- and if the paragraph above it was not terminated, then the block quote is "inside" of it. (well, due to how z.m.l. defines "a paragraph", the block-quote itself is its own "paragraph"... but there's no need to discuss these semantics.) at any rate, the z.m.l. viewer-program is happy to show you a listbox of all the paragraphs in the file, nicely numbered and everything. or it will show you a list of all the words in the file, also nicely numbered. and at the bottom of each page that it shows you, it gives the character-numbers and line-numbers of the range of text on that page. so an end-user will have an easy time quantifying exactly where they are. but you know what? very few of them ever have a need. > no matter how many blank lines surround them in z.m.l., blank lines are the very thing that _define_ paragraphs -- and titles too. so i am afraid that z.m.l. will never "be able to" do what you are asking. but... > then I'll be impressed. ...my goal is to render e-books properly, not impress you. -bowerbird

1 0