August 2005 - gutvol-d - lists.pglaf.org

re: [gutvol-d] About the XML debate
by Bowerbird＠aol.com 21 Aug '05

21 Aug '05

jon noring said something or other. however, since jon is still moderating michael hart over on jon's listserve, i won't be responding to him. -bowerbird

2 1

Another rule 6 question
by Greg Weeks 21 Aug '05

21 Aug '05

When a book is cleared with rule 6, is the artwork cleared also? Can the artwork for the cover and interior illustration have a separate renewal? -- Greg Weeks http://durendal.org:8080/greg/

2 1

re: [gutvol-d] About the XML debate
by Bowerbird＠aol.com 21 Aug '05

21 Aug '05

andrew said: > having a variety of file formats to deal with > does sometimes make quite a headache. yes, having a master-file is indeed a good thing. but it's just not true that x.m.l. is the only form that a master can take. and it might not be true that x.m.l. is even the _best_ form that it can take. again, david moynihan at blackmask.com has proven that x.m.l. isn't necessary to generate lots of formats. through the use of standardized formatting, he has been able to do what none of you have even been able to start. but hey, i look forward to the day when you do get underway, and to the time long after that when all the markup gets done, because then the e-texts will finally be in a regularized format... -bowerbird

1 0

re: [gutvol-d] About the XML debate
by Bowerbird＠aol.com 20 Aug '05

20 Aug '05

brad said: > As has already been mentioned, > ASCII is an encoding and plaintext is a format. i fail to see how this distinction has any importance to the original point. the user wants the words free of markup. > And ASCII is being replaced with Unicode. Some decades > from now ASCII will gradually go the way of the Dodo. well, if you want to get into this kind of doubletalk -- which i don't because, as i just said, it has no importance -- then it is inaccurate to say that ascii is "being replaced" by unicode, since the bottom 127 characters of unicode are the same 127 ascii characters we've come to know. if we give the original poster a unicode-aware text-editor, and a file that contains no heavy markup, he will be happy. he wants the words, all the words, and nothing but the words. > As for plaintext, one of the core design goals for XML is that > it you'll be able to open it in any text editor and read it. ok, and now here you seem to be trying to say that an x.m.l. file is a plain-text file. it's not. it might consist of nothing more than those 127 ascii characters, but it is decidedly not a plain-text file. the original poster knows it's not plain-text. so does michael hart. most people do. including, i suspect, you. why confuse the issue? > If a file is human readable when it's opened in a text editor > then it's a type of plain text. again, this subterfuge is dishonest. first, it's inaccurate to say that an x.m.l. file is "human readable". and second, it's misleading to say it is "a type of plain text". it might be an ascii file, but it's decidedly _not_ "plain-text". > All XML does is place tags around text in order to > give the text a structure that machines can understand. you give machines far too little credit. they can be made to be far smarter than a dirt-dumb x.m.l. processor, which can _only_ be made to "understand" the structure of text _if_ it is tagged. > As long as you have a text editor, you'll be able to read XML. let's give the original poster an x.m.l. file, and have _him_ say whether he is able to "read it". just because you can load a file into a text-editor doesn't mean you'll actually be able to figure out _how_ to edit the darn thing in the way you want. and _that_ is the real topic at hand here... these semantic games do nothing but cloud the discussion. > A good text editor can clean out all of the tags > with a simple regular expression like "<.*[^>]*>". ok, well at least now you're starting to talk about _issues_. but of course, you're glossing over the reality even here. the inference you are trying to get us to make is that "cleaning out all the tags" will convert an x.m.l. file into a plain-text file, magically. it won't. not in all cases anyway. not unless the x.m.l. file was created -- carefully -- with that specific conversion in mind. i've been writing a separate post that will give details how this careful consideration and crafting must be done. (some hints: whitespace, quotemarks, and tables.) > Script languages like perl, python, ruby or any other language > likely to come down the pike will be able to process XML and > convert it into whatever comes along in the future. it's telling how all of the hype about x.m.l. is in the present-tense, but when you focus down to particulars, it moves to future-tense. pay attention to this, lurkers! it's a sure sign of vapor-ware! > Very few applications render XML directly > (except perhaps word processors), > everyone else converts it into html, pdf > or other formats for display. ask yourself why this is the case. the answer is interesting. > SGML (XML's older sister) has been around for, what, > twenty years or more? And all SGML documents are > easily converted into XML. XML is simplier and > designed to be around as an archive format > for far longer than that. in its day, s.g.m.l. made all the same promises as x.m.l. does now. it couldn't keep them, so s.g.m.l. people had to invent a variant, so they could regenerate all their hype from scratch and reuse it. and sure enough, the public is gullible enough to believe it all again. of course, the same difficulties that thwarted s.g.m.l. back in the day -- sabotaging all their hype -- will return and bite x.m.l. in the butt. but by the time we figure out how we've been had this time around, all the x.m.l. proponents will have carted off their consultant cash... > Most people will never know about the master version in XML, > they only will see the file formats they use to read books. they'll "know about" that x.m.l. version indirectly; it will be the reason their books are so expensive. due to all that cash those consultants carted away. > XML is only a long term and safe archive format hype and marketing. > Once you understand that XML is just plain text, > you can use any software for processing text to work with it. you can save a spreadsheet in "plain-text" form too, and then "use any software for processing" that too. but you're going to find yourself coming up short. likewise when working with an x.m.l. file in a plain-text editor; yes, it can be done, but you will find yourself coming up short. but x.m.l. people will continue telling us this untruth, because they want us to believe that x.m.l. is really simple. but it's not. > As long as there is a text editor, > an XML documment will never be lost. of course, if it ain't human-readable in that form, it doesn't really matter if it "will never be lost". it won't need to be "lost" once it has been "tossed"... *** i will repeat: make x.m.l. work if you want us to respect it. don't come and _tell_ us how wonderful it will be; show us. the proof is in the pudding. not in the hype and marketing. -bowerbird

7 9

re: [gutvol-d] About the XML debate
by Bowerbird＠aol.com 20 Aug '05

20 Aug '05

david said: > So what exactly is your point? my point, exactly, is that a lot of people here tout x.m.l. as the solution, but no one seems to want to pay the cost of actually doing the markup. why is that? as to all the verbiage about what constitutes whether a file is "human readable" or not, if we ask some humans, the answer is clear. > Since < and > are within the 0-127 character limit, > XML is actually ascii text. That means it is "plain text". um, no. an x.m.l. file is not "plain text". ask a human. > How does storing a textual work in XML > in any way increase its price? applying the markup requires expensive expertise. > In fact, it should dramatically decrease the "price", > because it requires less handling to convert to > any of a dozen or more formats. or so the hype goes. but where is the pudding? meanwhile, over at blackmask, daniel has been converting the entire project gutenberg library into a half-dozen formats for several years now, based on the plain-text versions, with zero x.m.l. > And as much as I hate to bring it up, > how many times have you openly exclaimed that > you were leaving for good, and failed to do so? you'll be dealing with me for a long time, david... provide some pudding. don't just talk about it. there are 17,000 e-texts waiting to be marked up. -bowerbird

1 0

About the XML debate
by Brent Gueth 20 Aug '05

20 Aug '05

Going through the archives in my mail box the last few days I wanted to add my .02 as someone who is not as close to the project as any of you. I think that any XML work (if Gutenberg goes that way) needs to be done in addition to, not in replacement of plaintest. I don't care if XML becomes as common as plaintext and everyone uses it, you can run into a problem in 20 years where XML falls out of favor and there won't be software to render it properly. This will lead poor fools having to redo all the documents all over again. This is not a good thing. Picking plaintext is genious in the sense, that unless basic ASCII changes (not likely compared to XML losing favor) plaintext will always be able to be read. This allows it also to be read on older machines. Maybe some of you don't care that the guy with commodore 64 can read plaintext but can't read XML because he is only one person on the planet. But when you see all the other 1 person implementations add together it becomes a decent percentage. My thoughts on a software to do the annotations would be to have a read that could overlay annotations on the screen but maintain the base document in plaintext or maintain a seperate annotated edition. The problem also we come into when we discuss modern annotations is who do we decide who is qualfied to release (write up) the annotations for a certain book. I may not agree with the annotationist that Bob likes, and Sue will hate the choices bob and I will make. The best solution I could honestly see to keep a degree of sanity is to Wiki each book you wanted to annotate. But I'll go back to reading now the archives now, I just though plaintext still needed a champion before the whole world went completely XML crazy. Remember - plaintext was supposed to be replaced by Postscript plaintext was supposed to be replaced by word perfect plaintext was supposed ot be replaced by word plaintext was supposed to be replaced by PDF plantext was supposed to be replaced by HTML plaintext is supposed ot be replaced by XML? Not bloody likely

6 5

How to submit a new file to a posted ebook?
by Joshua Hutchinson 19 Aug '05

19 Aug '05

If I've finished producing a version of a posted text (such as HTML or PDF) and I want to get that submitted and posted ... how would I go about that/who should I bug with my e-mail? I'm thinking it would either me one of the white-washers or the errata e-mail (which ends up in Jim's lap anyway), but I don't want to bother those folks who are overworked already, unless I know I'm supposed to be bothering them. :) Josh

2 1

re: SOPHIE (replacement for tk3 and XML-based) Re: [gutvol-d] Annotations for students
by Bowerbird＠aol.com 18 Aug '05

18 Aug '05

jon said: > Well, I have written over 100,000 lines of code (Fortran) > over the years. I've also written some scripts. > I've edited and compiled some C code. > I've written a bunch of GWBasic programs. > And I have a couple associates in the XML world > who are programming wizards and who I often > consult with regarding what can and can't be done. great! then i'm really looking forward to your program, jon... like i always say, the proof is in the pudding. deliver pudding. > Btw, the tk3 example you gave in the other email > you just sent (and I just read), the replacement for it, > SOPHIE, will be *XML-based*. The developer of tk3, > Bob Stein, is the major player of SOPHIE. He's been > around for years and years -- his partner is very experienced. i brought up tk3 because david rothman mentioned it in his blog, so i took a fresh look at it. and since the topic was annotations, and tk3 is one of the programs with good annotation capabilities, it seemed appropriate. now, as you'll note in comments i made over on david's blog, i know tk3 -- and bob stein -- very well. (not personally, but i've followed his work since voyager days.) i've talked to bob, and steve riggins (and steve's wife) as well. i've even dropped some of my e-book programs on them, and they've been impressed. tell 'em to watch out for me! :+) but even after having visited the website you listed, i am puzzled. "sophie" is actually the name of an e-book viewer-app written by _richard_gaskin_, of fourth-world, another l.a.-based programmer. see it at: http://www.fourthworld.com/products/sophie/index.html so this makes me wonder if gaskin and stein are now teaming up? that would be sweet. i've been looking for a worthy competitor in the e-book viewer-program realm, and openreader has been a huge vapor bust so far, so a stein/gaskin product might be the one! but i don't see anything on either website to indicate a merger?... (after reading the .pdf, i see now that there's probably no merger. riggins works in small-talk, while gaskin uses run-time revolution. so it appears that this is just an unfortunate program-name crash, all revolving around programmers who've been on the left coast.) > Gee, I wonder why they will now change gears > and embrace XML? They are *experienced* developers > with a lot of knowledge of the tk3 product (over 15 years), > and *they* are switching to XML. well, wonder no more, jon, because i can tell you why. they're going for some hefty venture-capital bucks, and x.m.l. is the trend-word of the decade. if i was looking for an investor sugar-daddy, i'd be spouting x.m.l. too! > You better hurry and convince Bob Stein he needs to > get rid of XML and embrace plain text! again, you think i have something against x.m.l. i don't. if x.m.l. gave me useful tools, and hid all the complicated file-formatting under the hood, i'd be happy to embrace it. what i _do_ have something against is _vaporware_. and that's _especially_ true in regard to electronic-books, which have stagnated through cycle after cycle of _hype_ because nobody -- except for adobe -- has made it easy to _author_ electronic-books that work well on all platforms. read the "sophie" website you listed, and their .pdf, and you will find that they both say the very exact same thing: we need easy authoring-tools to make a revolution happen. but instead of delivering honest-to-goodness, simple-to-use authoring-tools, we've wasted the time fiddling with formats! and when someone comes and asks a "how do i do this?" question, we snow them with a bogus vaporware answer. and then we wonder why nothing ever gets accomplished. > You better hurry and convince Bob Stein he needs to > get rid of XML and embrace plain text! Hurry, > before it is too late! Your programming experience > should convince them of the folly of their ways. nah. i'll let bob burn through that investor cash instead; he's already run tk3 through a couple rounds of funding. (and got another quarter-of-a-million from u.s.c. recently. man, i wonder what p.g. could do with a cool $250,000!) yep, i _like_ to see the venture capitalists fall on their ass chasing the trend-word of the decade, i really do... :+) -bowerbird

1 0

re: thad weighs in
by Bowerbird＠aol.com 18 Aug '05

18 Aug '05

thad said: > What I'm thinking about at the moment is just: cool. thanks for weighing in again. :+) one thing i'd suggest to you is to take a look at some of the .html versions prepared by distributed proofreaders where they have used side-notes. it's pretty impressive, considering they are operating without any javascript... (but yeah, your comment about the difficulty of getting well-formatted pages when printing from .html is well-taken...) -bowerbird

1 0

Re: gutvol-d Digest, Vol 13, Issue 10
by Thad Curtz 18 Aug '05

18 Aug '05

It's true - I don't have terribly grand aspirations for now (and I have done a good deal of amateur programming in a variety of languages, so a certain amount of technical overhead probably would be OK.) What I'm thinking about at the moment is just: 1. Some basic text formatting including superscripts for footnotes and italics. 2. Line numbers on the side every five lines for poems. 3. Glosses on difficult words - either as footnotes on the side, or as mouseover popups (with overlib, I suppose), or at the bottom of each page. 4. Longer explanatory notes. I think the longer notes need to be at the bottoms of the pages when they're printed, and it might be nice to have the dictionary glosses there too. (There's really not that much space on the side of the page for them...) And I'd like to do it in some way that's as standard as possible, as fast as possible, as simple for students to access as possible, and that makes it as easy as possible for other people who might want to do more to build on what I've done rather than starting over from scratch. (Eventually I assume people will want to be formatting this stuff for all sorts of digital reading platforms and all sorts of page sizes with cheap automated binding at home or at Kinkos or in college printshops.) The problems about getting it to print as decently formatted pages with footnotes at the bottom on a variety of printers are one big reason I'd rather not do it in straight HTML. The problems about people being able to add to it (and file size issues) are reasons I'd rather not do it with PDFs. But I've got now several leads for other tools and tactics to take a look at from your discussion. (As well as some ideas I hadn't thought of about why Gutenberg isn't already doing it...) I'll keep you posted if I get anything done. Thanks, Thad

1 0