- gutvol-d - lists.pglaf.org

Re: [gutvol-d] Crowdsourcing (the magic bullet)
by Bowerbird＠aol.com 27 Jan '12

27 Jan '12

i said: > i'll serve my pudding on my own site... and the first thing i will tell people about each e-text is _exactly_how_my_version_differs_from_the_p.g._version_. even without looking at one, one thing i can say for sure is that these diff reports are going to make p.g look bad. some improvements are one thing -- "legalese deleted" -- but more embarrassing is that your corpus is teeming with obvious o.c.r. errors that are detectable with minimal effort. (if you want a catchy name, i call this the "go clown" effect.) a lengthy list errors, in book after book, one after another, is -- frankly -- going to be extremely appalling to people... you're in over your head, greg. i was 5,000 volumes into redoing the p.g. library years ago, and i quit, because i realized that this would be the result... i didn't want to make p.g. suffer those terrible ramifications. but that was out of respect and admiration for michael hart, which is no longer a consideration. re-think, greg. carefully. or maybe you're thinking you need to confront those errors. but it won't end up to be any help, because your procedure for remounting a corrected book is far too clumsy to enact to repair a couple of errors that occur in hundreds of books, and a few more across a thousand other books, and so on. if it wasn't, you woulda fixed those errors already yourself. it's nice to fantasize that the crowd will solve your problems. but it ain't gonna happen... not the way you'd _like_ it to... and it's kind of troubling to see you do this wishful thinking, because it's not too apparent that you realize that's what it is. i know you want a magic bullet, greg... we all do... you can still count me in. but i'm telling you it's a bad idea. -bowerbird

1 0

Re: [gutvol-d] Crowdsourcing
by Bowerbird＠aol.com 27 Jan '12

27 Jan '12

how do you prevent noise from overwhelming signal? users won't wade through 20 different versions, hoping one of them _might_ be better than the "official" version. even if they find one, the word-of-mouth will be diluted. heck, your own re-done versions find that they suffer a significant disadvantage competing with older versions. and they're at least allowed to engage on the same field. another place is gonna quickly be dismissed as a ghetto. even if the quality is there, the critical mass will not be... roger built a better proofreading machine than d.p., but couldn't attract people to staff it... what reason is there to believe there's anyone to run _multiple_ new systems? i relish the idea of a tournament among new workflows, but if a winner never gets declared, what is the purpose? that doesn't have to mean losing systems got discarded... but it would mean the best one will get some recognition. without some kind of decision on quality, you will just be burning volunteer time and energy; you've wasted enough. i'm all for live-and-let-live. but there's only so much oxygen in the room. count me in... but i'll serve my pudding on my own site... -bowerbird

5 5

a historic quarter, virtually unmatched
by Bowerbird＠aol.com 26 Jan '12

26 Jan '12

apple just announced their earnings for the last quarter. they were monster. huge. historic. $13billion... zowie. it was the biggest quarter _ever_ for _any_ tech company. heck, the biggest quarter ever for _any_ company, except for one other -- a quarter when exxon made $14billion, owing to naked exploitation during a "gas crisis" period, for which it deservedly suffered severe public displeasure. apple's customers, on the other hand? voluntary, happy. considering that, its achievement is virtually unmatched. if you want to get a feel for the immensity, consider that google's _total_revenue_ for last quarter was $10billion... no matter which part of apple's business you look at, it's nothing but sharp upward trends and profit profit profit. anyone who didn't think the iphone would be huge is stupid. anyone who didn't think the ipad would be huge is stupider... -bowerbird

1 0

life on the simple fork -- 001 -- doublequotes
by Bowerbird＠aol.com 26 Jan '12

26 Jan '12

hey, looks like a new series from bowerbird! oh goodie! :+) doublequotes are easy, here on the simple fork of the road. here's a program i wrote to convert and check doublequotes: > http://zenmagiclove.com/dqinsanity.py it'll list any paragraphs that have doublequote problems. it also lists any paragraphs that you've marked with the .zml tag for "dialog continues in next paragraph". the program now works on the "betty lee" book, because that's the one that i happened to be working on recently. and, thanks to this program, that file no longer has any problems in it. (it started with a bunch which were wrong, not just in the o.c.r., but _originally_, in the p-book itself; sometimes the e-book is _more_ correct than the p-book!) if anyone still cares about doublequotes 2 weeks from today, remind me, and i'll rework the program to work on any text from the p.g. library, so you can really see the thing in action. and remind me 4 weeks from today, and i'll rework the code so you can feed it your own text, and it'll do its magic on that. because it's not "magic". it's just common sense, coded out... *** so the merry-go-round riders can talk about something new. i suggest em-dashes -- typographic? or double-dash? begin! -bowerbird p.s. and, after that, _ellipses_... use utf8? or three periods? and what about the 4-dot ellipse, what do we do about that? because if you want life to be hard, it's easy to make it hard. all you have to do is start caring about shit that don't matter.

1 0

we have come to a fork in the road
by Bowerbird＠aol.com 26 Jan '12

26 Jan '12

the d.p. foundation board had a meeting recently. the general manager: > was unanimously re-affirmed for a period of > two years, ending 12/31/2013; it's good to know that everything's going great at d.p. stay the course! she was also charged with this: > The GM will collaborate with volunteers to > produce a draft of Best Practices for HTML versions > of our e-texts which will, by their nature, > facilitate better conversion to ePub format. so i guess you guys here don't need to bother with that, since it's being covered over there... *** unless, of course, you guys are having fun with all your complex discussions of unnecessarily complicated stuff. i hope so. masochists and sadists always seem to find each other... but for everyone else... *** the time is right now. we have come to a fork in the road. you can take that tortured path of those sadomasochists. or you can come with me on the sweet path of simplicity. *** here is an extremely brief recap of what i've done: 1. i studied books to survey features they contained. 2. i created zen markup language to tag the features. 3. i edited a test-suite which contains those features. 4. i wrote code to convert the test-suite into e-books. so, the "master" file is z.m.l. -- a light-markup format which is so simple a 4th-grader can understand it -- and all of the other formats (including plain old .html) are generated from that .zml master, via a button-click. there's even an authoring-tool, so you can verify that your book is being handled correctly _as_you_write_it_. this is the simple fork, folks. this is the way it should be. *** so, i generated the .mobi and .epub from the test-suite. the e-book output is basically correct, as far as i know, but the formatting needs some rough edges smoothed. (actually, i didn't even look at it, but i assume that's so.) if anyone has criticism in that regard, i'd love to hear it. (don't even have to be "constructive" criticism, although any attempts to put me on a merry-go-round will _fail_.) i am shifting my focus -- from old books to new ones, born digital, from the self-publishers of the future -- but cloning these public-domain books is easy enough, so my system should work just fine for your purposes... *** here's the test-suite: > http://zenmagiclove.com/test-suite-2012.txt here's the script that converts the test-suite into .html: > http://zenmagiclove.com/cgi-bin/t2.py here's the .mobi version of the test-suite: > http://zenmagiclove.com/suite/suite.mobi here's the .epub version of the test-suite: > http://zenmagiclove.com/suite/suite-epub.epub here's the folder holding all of the conversion files: > http://zenmagiclove.com/suite/ here's a .zip file containing all of the conversion files: > http://zenmagiclove.com/suite/suite-all.zip *** you're now at a fork in the road. which way do you go? -bowerbird

1 0

Re: [gutvol-d] Producing epub ready HTML
by hmonroe.pglaf＠huntermonroe.com 26 Jan '12

26 Jan '12

Roger, Someone is working on adapting gutcheck to handle UTF8 as a spinoff of the effort to improve Guiguts' handling of languages other than English (following up on a suggestion you made to me); see below. Could the wwers please liaise with him on whether this could be a sanctioned project and also whether it should work under the gutcheck sourceforge project (if not we can do it under the guiguts project). Also are better tools needed to convert UTF8 to Latin-1 and ASCII. The same individual has compiled aspell 0.6 for Window which offers Unicode normalization. All are welcome to contribute views in the fora below. Developers in C and Perl are needed. Hunter http://www.pgdp.net/phpBB2/viewtopic.php?p=820092#820092 http://www.pgdp.net/phpBB2/viewtopic.php?t=50082 From: Roger Frank <rfrank(a)rfrank.net> I work in UTF-8. It would be easiest for me to send up UTF-8. But the WW tools to check the submission, like gutcheck, struggle with UTF-8

10 14

everyone give a big wave to jim tinsley
by Bowerbird＠aol.com 26 Jan '12

26 Jan '12

greg said: > Jim Tinsley isn't really active as a WWer any more ... > He will probably be thrilled > to have someone do development. actually, jim posted just yesterday in a d.p. forum, and advised that "development" should start from scratch... it's sad, isn't it, that we all agree p.g. and d.p. need to improve their tools, but nobody volunteers to _do_ it... i offered to write stuff, on many occasions, but i was ignored and/or scorned, to the point i got alienated, and now you couldn't pay me enough to code for you, even if you had a ton of money, but you have _none_. -bowerbird

1 0

encoding choices
by Jim Adcock 26 Jan '12

26 Jan '12

Stating the obvious, lately we have been having a lot of heat about what I will broadly describe broadly and hopefully without perceived prejudice as "encoding choices" -- a subject which is often described [incorrectly] as "file formats." IE a volunteer transcriber, "at" PG or DP or somewhere else, using a combination of OCR, blood, sweat and tears, and other "helpful" tools, makes choices, independently or directed, about what and how to encode the information which they see in that book, that which they feel is important to record -- or that which they decide is unimportant and should not be recorded. At this point in time one or another persons on this forum immediately jumps up and down and says "I have THE solution!" I would like to suggest that any such proposed "solution" must include a discussion and decision about what to actually encode, and what not to encode, and I would also like to suggest that any proposed "solution" [including those currently in use at PG and DP] should encode that which that format chooses to encode *unambiguously.* IE if a particular format and/or encoding scheme claims to encode a particular piece of information, but does not do so unambiguously, then in fact it is NOT successfully capturing that piece of information. Below, as a reminder, is a list of things that various volunteers choose to encode, or not encode, and which various encoding schemes support encoding unambiguously, or which do not support encoding unambiguously. To state the obvious: At least part of the problem is that the people on this forum have wide DISAGREEMENT about which of the following items should be encoded unambiguously, which is to say successfully, which should be ignored, and which should be recorded ambiguously [???]. [I have cribbed a lot of this from DP, but I could just have well cribbed it from the TEI community, or most good books on typography] As an example, and to start this throw-down, I will simply state from my point of view that "how discolored with age the paper stock is" is really NOT an important thing to encode from my point of view! [Since I would rather see a representation of the book "as-published" not "as-found"] PS: defining "unambiguous coding" means: "those who propose that file format or encoding can write a computer program to extract that particular piece of information from their files 100% successfully 100% of the time without error and without heroic coding efforts." ====== book-title author illustrator translator publisher publication date glyph paragraph blockquote poem-stanza poem-line poem-indentation-level epigrams thought break page break horizontal rule spelling (choice of) capitalization bold italic underline small-cap gesperrt illustrations color of paper stock how discolored with age that paper stock is captions drop-cap alternative font use distinctive font size changes author-specific eccentricities in use of punctuation author-specific eccentricities in use of spelling nationality of spelling, punctuation and/or style of typesetting tables superscripts subscripts page numbers line numbers page references page numbers TOC index Preface left-vs-right alignedness justification letter signature salutation "foreign" words language (of original work) language (of this publication) language (of a subsection of this publication) handedness (of punctuation) Foreword Introduction Front Material Prologue Epilogue Appendix References Conclusion Glossary Summary Acknowledgements Bibliography Advertisements Front Matter Back Matter Ex Biblio decorative marks decorative rules printers' [stock] art illuminated-letter black-letter first-letter-color punctuation spacing line-breaks foot-note side-note end-note all-caps chapter title chapter subtitle section title section subtitle hyphenation half-spaces contractions (form of)

3 6

mistakes as big as the grand canon
by Bowerbird＠aol.com 25 Jan '12

25 Jan '12

al said: > - n-tilde - converted to plain "n". > The only word I'm aware of where > this is incorrect is cañon/canyon. ok. > The example Roger mentions in 35833 is a mistake whew... i was worried there for a minute that there'd be some instances in the p.g. library of "grand canon", you know, the one in arizona... i'm glad to hear that wouldn't hap... oh, wait... > http://www.gutenberg.org/files/756/756-h/756-h.htm > http://www.gutenberg.org/files/15807/15807-h/15807-h.htm those two were done by some "al haines". and don't chuckle too much just yet, d.p., because: > http://www.gutenberg.org/files/12883/12883.txt > http://www.gutenberg.org/files/19479/19479.txt plus, as google will inform you, probably many more... -bowerbird

1 0

Re: [gutvol-d] encoding choices
by Bowerbird＠aol.com 25 Jan '12

25 Jan '12

don said: > Seriously, I rhink you'rre on the right track. now don, surely you don't mean to reward such overloading of the word "encoding"... communication here is _difficult_enough._ -bowerbird p.s. iss yourr kkeyboarrd ffunkky? orr arre youu rrinking?

1 0