- gutvol-d - lists.pglaf.org

Many solo projects out there in gutvol-d land?
by Gardner Buchanan 15 Feb '10

15 Feb '10

I've done a few books for PG. I've used DP -- back in the day, but mostly I've been doing solo projects. I don't hear a lot about folks doing projects solo these days. Are there many of us out there? ============================================================ Gardner Buchanan <gbuchana(a)teksavvy.com> Ottawa, ON FreeBSD: Where you want to go. Today.

15 34

Re: When DP started, here was the basic process
by Bowerbird＠aol.com 15 Feb '10

15 Feb '10

see how easy it is to change the subject-header? *** don said: > When DP started, here was the basic process the irony was, back in those olden days, it was actually much more difficult to digitize a text, because the o.c.r. was horrific, and thus it was a pure pain to proof. nowadays, even though o.c.r. is vastly improved, it seems to take forever for a book to transit d.p. here's an illustrative datapoint i just churned... in one of the books that rfrank is using for his roundless experiment, even tepid preprocessing (which is what he practices) combined with o.c.r. to produce 20% of the book's 240 pages perfectly. another 30% of the pages had only 1 error on 'em. and most of the errors failed spellcheck, meaning they could've been isolated and fixed immediately, without need of a word-by-word proofing modality. d.p. uses dozens of volunteers, taking hours of time, to do something that one person can do in one hour. which would, you know, ordinarily be a very sad thing. except what makes it funny, in this particular case, is that the people at d.p. think they're being "efficient"... -bowerbird

2 1

Re: Many solo projects out there in gutvol-d land?
by Bowerbird＠aol.com 15 Feb '10

15 Feb '10

why do you guys insist on hijacking threads? it's rude. -bowerbird

1 0

Re: Many solo projects out there in gutvol-d land?
by Bowerbird＠aol.com 14 Feb '10

14 Feb '10

karl said: > I think we can change this. It would be much better > to do this mysterious PP'ing in a collaborative manner. > To experience this, I created an SVN repository and > started with TEI tagging. I'll add more of > the PGTEI framework soon: that's right. to simplify the job of postprocessing, throw in a dose of s.v.n. and then add some t.e.i., and all the complexities will waft away on a breeze. -bowerbird

3 2

Re: rfrank reports in
by Bowerbird＠aol.com 13 Feb '10

13 Feb '10

what a convoy of clowns... -bowerbird

1 0

Re: Revisting DP
by Bowerbird＠aol.com 12 Feb '10

12 Feb '10

keith said: > It seems obvious to all that > the DP system has severe deficiencies. > The question is how to help. you need to discuss that over at d.p. they don't listen to anything over here. the only reason i discuss things here is because they banned me from there -bowerbird

2 1

Re: rfrank reports in
by Bowerbird＠aol.com 10 Feb '10

10 Feb '10

jim said: > I just checked my previous claims about the problems with P3 > (for example) against a pretty straight-forward text. > I reviewed 200 pages from that text. > P3's made 38 changes on those pages. > Of these changes 7 change represented a positive > contribution towards making the txt correct. > Of those positive changes about a half could > easily be found by a simple tool like guiguts. > 10 of the changes introduced by the P3's were negative changes > -- changes that moved the text to a less perfect state. jim, and others, if you're going to continue to discuss the problems in the current system at distributed proofreaders, please do it in your own thread, and not in my threads, ok? as for your findings, jim, it helps to report the actual lines. but it's probably not necessary. in the past, i have documented the same things you report, in great detail, in book after book after book, with evidence. in comparison, your anecdotal reports are relatively flimsy. i'm not saying you're wrong. indeed, you're absolutely correct. i'm just saying your reports are not going to convince anyone. heck, there are people here who refused to believe what i said, in spite of the fact i piled up enough evidence to choke a horse. (nor did i _create_ the evidence; i used data taken directly from various experiments, performed over at d.p. by other people... the truth is out there, and easy to find, if you just care to look. this is what is so silly about all these "experiments". i've told everyone here the simple correct answers, so all that's needed is to test these simple hypotheses and see they _are_ correct. but instead people are testing overly complicated stuff in ways that are not definitive, leading them to become more confused.) *** perhaps the most impressive findings of my results were these: 1. the best way to know a page is "finished" is when proofers stop making changes to it... up to that point, it's not finished! it's the "best" way to know because a no-diff is easy to measure. 2. 3 rounds of p1 were as effective as a series of p1-p2-p3. (simple solution to queue problems? run the text through p1 until every page comes out repeatedly as a no-diff page.) 3. the third round of p1 found as many additional errors as the p3 round, but _neither_ route found _all_ the errors. the p1(3) proofers found errors that the p3 proofers missed, and the p3 proofers found errors the p1(3) proofers missed, plus there were other errors that both p1(3) and p3 missed. (takeaway: the p1 proofers are not inferior to the p3 proofers, and a "make the page better" philosophy will eventually work to "create a perfect page", without all the attendant pressure.) 4. "parallel" p1 was _not_ useful at turning up any more errors, but it might have value to determine a page is "done", although more research would need to be done to test that hypothesis... -bowerbird

1 0

Re: how to make roundlessness work, in one brief post
by Bowerbird＠aol.com 10 Feb '10

10 Feb '10

jim said: > many motivated "early readers" love a particular author, > and would be happy to get early access to the text via > some kind of tool that allowed them to fix or at least mark > the bugs they find as a part of their reading. "Marking" bugs > as a part of reading could be as simple as asking them to > read on a notepad or what have you and put a > Q-mark in the text where they think they see a bug. while you seem to be talking about smoothreading here, the text you quoted from me was about preprocessing... preprocessing happens before the text goes to any proofer -- it's scheduled immediately after o.c.r. has been done -- and it doesn't require reading of _any_ kind at all, which is why it is about fourteen times more efficient than proofing. a preprocessing tool finds glitches that are almost certainly errors, and takes you to them directly in the text-file while displaying the appropriate scan for referral, and often even gives you buttons that will perform the desired correction... some glitches (like spacey quotes) can even be auto-fixed. i have demonstrated here that, for several books i tested, this preprocessing would take the errors down to a rate of less-than-one-error-every-10-pages, which makes the word-by-word proofing rounds almost like smoothreading. check out dkretz's "twisted" tool to see an example of this... -bowerbird

1 0

Re: rfrank reports in
by Bowerbird＠aol.com 09 Feb '10

09 Feb '10

jim said: > Under the *current* DP system i'm steering clear of discussing the d.p. system right now; there's so much cruft over there it's not worth the trouble. i'm either discussing rfrank's experiment, or my own system. -bowerbird

1 0

how to make roundlessness work, in one brief post
by Bowerbird＠aol.com 09 Feb '10

09 Feb '10

here's how to make a roundless system work, in a nutshell... 1. do aggressive preprocessing. 2. use nonintrusive zen markup. 3. submit the page to a p1 proofer. 4. repeat #3 until no change is made. 5. submit the page to a p1 proofer again. 6. if a change is made, go back to step #3. 7. if there is no change in #5, page is done. if you want it even briefer, do aggressive preprocessing, and then repeat processing through p1, until you obtain 2 consecutive rounds of no change, and the page is done. for greater accuracy, or if you have proofers in abundance, repeat until you get 3 consecutive rounds without change. (but the increased accuracy isn't worth the increased work.) for lesser accuracy, stop after 1 round that sees no change, but the decreased accuracy here is too high a price to pay... aggressive preprocessing is the secret, because most errors can be located automatically, so the pages are clean before they even get to "proofers", who are really "smoothreaders". this, of course, is the same formula i've suggested for years. (once you've hit upon the right answer, no reason to change.) you can easily assure yourselves that this is the right answer; track how many errors persist through 2 rounds of no-change. (versus how many persist through 1 round, 3 rounds, 4, etc.) no need to collect any messy stats. just 2 rounds of no-diff. the time you spend exploring other stuff is just wasted time. just watch. this is the formula that will prove to be the best. and when you get around to admitting it, i'll say "i told you so". -bowerbird

2 1