- gutvol-d - lists.pglaf.org

aloha-readers and polishing and italics
by Bowerbird＠aol.com 26 Oct '12

26 Oct '12

i've made references to "smoothreaders" lately, mostly because that's a term commonly used over at distributed proofreaders... but i probably need to use some other term instead, because i'm not really talking about the same thing that they do at d.p. over there, "smoothreading" is a download-the-text-only deal. sometimes it can be .html, not just plain-text, but the point is that it _does_not_ involve the actual _pagescans_ themselves... whereas what i am talking about here _most_definitely_does_ involve an actual comparison of the text against the pagescan, albeit if only in those cases where there's doubt about the text. but the interface that i am talking about _always_ has the text displayed side-by-side with the pagescan, for easy comparison. *** also, at d.p., "smoothreading" is considered to be the _end_ of the process of preparing the text. i can see that viewpoint, but that means that the participants are volunteers who're already _embedded_ within the distributed proofreader infrastructure. i envision people who would consider themselves to be outside of such a system. and rather than the _end-point_ of the process, i would think they'd consider themselves to be the "beta-readers" for the e-text as it was _beginning_ its journey out to cyberspace. in other words, it's less of a "graduation" than a "commencement". then again, maybe the best way to think about this stage is as _both_ a "graduation" _and_ a "commencement", so perhaps we should be using one of those hello-goodbye words like "aloha". so i propose we call them "aloha-readers"... *** further, since these extra sets of eyes would be of the most value to _independent_producers_, i'd suggest that project gutenberg itself should recruit and train and enable these "aloha-readers"... i don't know (or care) where it would fit in the workflow that now has whitewashers doing (at least some of) this kind of last-minute checking -- perhaps, in the spirit of "aloha" it could be _both_ -- i'm just saying that it will be extremely helpful to solo producers. *** don said: > In my own proofing the only way I can have > any confidence at all that I'm catching all the italics > is to scan through the entire text looking for nothing but. i think that's true of a lot of people. and even then, any "confidence" might be undeserved. because most people will _still_ miss 5% to 15% of them, and sometimes even more. i have proven it with myself. i have stared and stared at some pages, _knowing_ that it contains one or more italicized words that i'm missing, and _still_ been unable to spot any. it's just the way it is. so i feel the only way to gain a good degree of certainty is to have the pages examined by more than one person -- and i wouldn't _bet_ on 99% accuracy with fewer than three. but of course, if/when you have independent digitizations, you can use the _comparison_methodology_ i'm discussing, and i can guarantee you that it will jack up your accuracy... so far, with this copy of "huck" that i'm digitizing right now, i've used jim's italics _and_ david's _and_ some of the o.c.r., and i am very confident that i'm getting fairly good coverage, although even then you'll notice the hedge with "fairly good". (and i can also report that both david and jim missed "some".) further, i'm making my text available, so you are welcome to take on the challenge of finding any italics that i've missed... > As soon as I start noticing (and marking) anything else, > I start missing them. i can also say that that's true for me too. i need the focus. > It also destroys my accuracy when the text already has > italics markup in it and I must check for false positives. well, there should almost never be "false positives" in a file. not for italics. false positives mean your workflow is flawed. but you bring me to a good point i have been preparing... for the proofing of italics (and other styling) we have a need -- an _overwhelming_ need -- for tools to help us do better. the current methodology -- look at the pagescan and note where there are italics, then check each instance in the text, and mark it in the event that it hasn't already been marked. and then, just to be safe, make sure that every italics word that _is_ marked in the text is actually an italics in the scan. whew! this is tedious, back-breaking work. fatiguing. so, as you might expect, i've got some ideas for a tool. but i'm gonna let y'all think about it for a while first... so see if you can come up with anything, and then i'll dish... -bowerbird

1 0

Basic simple test case.
by don kretz 26 Oct '12

26 Oct '12

Here is a PG project that needs some formatting help. The HTML conversion would probably best be termed "fail". Yet it should be a simple case. How would you want proofers to submit it after "matching the scan"? What would you consider to be a properly marked up copy in the format of your choice? How should it get there from the previous step? http://www.gutenberg.org/cache/epub/14668/pg14668.html

11 43

Books in Browsers Conference at Internet Archive
by Alex Buie 25 Oct '12

25 Oct '12

The event is being livestreamed at http://toc.oreilly.com You may find this interesting. Also, tonight, you're all invited to our 10PB party! http://blog.archive.org/2012/10/10/the-ten-petabyte-party/ Just shoot an email to june(a)archive.org. Alex

1 0

kindlegen 2.7
by Marcello Perathoner 25 Oct '12

25 Oct '12

Finally kindlegen groks multiple classes eg. class="class1 class2 class3". https://kindlegen.s3.amazonaws.com/docs/english/Release%20Notes.html -- Marcello Perathoner webmaster(a)gutenberg.org

1 0

blah blah blah elements blah blah blah
by Bowerbird＠aol.com 24 Oct '12

24 Oct '12

don said: > The pglaf archives seem to have biig holes in them try here: > http://z-m-l.com/gutvold/ *** > bird, I can't find the list of elements you provided > that need to be identified. Do you have a date for that? do this: > go to http://z-m-l.com > click the "some z.m.l. examples" link > view the "test-suite" example > view the "11 rules of z.m.l." example if i think it's an element that needs to be identified, then z.m.l. has a way for you to signify it in your file. this might or might not be in accord with your desire, but i'm not sure i believe your desire is well-directed. my system doesn't need an explicit labeling of things; it's more than happy with the user's choice of labels... -bowerbird

1 0

Ipad Mini
by James Adcock 24 Oct '12

24 Oct '12

Ipad Mini has been released. Form factor probably more interesting for most book readers who are Apple-centric. Unfortunately, comes with Apple's new proprietary incompatible GDMF USB cable. http://www.apple.com/ipad-mini/overview/

2 2

powering through the adventures
by Bowerbird＠aol.com 24 Oct '12

24 Oct '12

ok, i powered through those last 1,000 diffs. definitely goes faster once you get the hang, and have sharply focused the displayed diffs. *** so now i turn to the "polishing" aspect... making sure the doublequotes are balanced, one final-final run through the spellchecker, slipping in the runheads, that kind of stuff... and thus, by the time of tomorrow's update, i should have something for smoothreaders. it has definitely been an adventure with huck. as usual, the latest edition is located here: > http://zenmagiclove.com/huckf/huckf-006.zml -bowerbird

1 0

list archive
by don kretz 24 Oct '12

24 Oct '12

Lee, I found reference to a post you made identified by From: Lee Passey <lee(a)novomail.net> To: Project Gutenberg Volunteer Discussion <gutvol-d(a)lists.pglaf.org> Cc: Date: Tue, 29 Jul 2008 18:18:31 -0600 Subject: Re: [gutvol-d] getting my wikisource bearings John Vandenberg wrote: that gave a long narrative of the markup rules you used and are apparently still using. Do you have a copy? The pglaf archives seem to have biig holes in them, one of which includes this time period. Also, bird, I can't find the list of elements you provided that need to be identified. Do you have a date for that? Don

2 2

powering through the adventures
by Bowerbird＠aol.com 23 Oct '12

23 Oct '12

well... "the adventures of huck finn" has certainly given me some "adventures" in creating my new, accurate, digitization... and i'll document them all in a summary. *** but for today, it's refreshing to know that i am finally _powering_through_ the book. you might remember that, as of yesterday, i'd reduced the comparison diffs to ~2000. and i was contemplating a shift away from my current "clean" text, since it's based on _a_different_edition_ than what i am using, one that has heavily edited the punctuation. that's why there are so many paired diffs... usually, with a book this clean, there might be 1% to 3% of the lines that would be diffs. in this book, completely due to punctuation, it's almost _20%_ -- ~2,000 out of ~11,000. and, in about ~92% of those diffs, the o.c.r. is correct, so the diff is being caused by the _edit_, rather than an o.c.r. misrecognition. the thing is, the comparison helps to catch the _other_ ~8%, which are real o.c.r. errors. so even though it's tedious to step through ~2,000 diffs, to find some ~160 o.c.r. errors, it is _still_ a rather efficient way of doing it... so i'm gonna stick with this different edition. but i adopted some "tricks" to power through. and those are going very well. i'm now down to ~1,000 diffs, so i'm sure i will finish soon. so i thought i'd tell you about these "tricks"... *** i didn't mention one of these "tricks" earlier, but it was the one where i focused in on the _words_and_letters_ instead of punctuation. i did that using the following trick... after finding a diff -- a pair of relative lines from the two files that were not the same -- i culled out the non-letters from each line... if, after culling, the 2 lines were the same, then that meant the letters were the same, so the diff was entirely due to punctuation, and -- since in that pass -- i was _focused_ on resolving differences in the words/letters, i could skip over such punctuation-only diffs. but if the lines were _different_ after culling, then i _would_ examine and resolve the diff. in the first round of this pass, a refinement is that i'd ignore the diff if the culled punctution was different as well, so i was only looking at diffs where _the-letters-and-only-the-letters_ were different, allowing a very-specific focus. after all those diffs were resolved, i looked at lines where letters _and_ punctuation differed. thus, when all of _those_ were resolved too, i knew that i'd resolved all letter-based diffs. (a further refinement, which retains spaces when the culled-lines are created, helped to find words where the letters were the same, and in the same order, but _words_ differed, such as when words were improperly joined, which can happen on rare occasions in o.c.r.) *** this methodology of narrowing the focus of the _type_ of diff being displayed, to assist your attentional focus in the resolving of it -- by letting you know what to "expect" -- can lend itself to a variety of these "tricks". for instance, earlier work on the files had shown me that one of them _hyphenated_ the expression "by-and-by", but the other did not. so i did a search just for that diff. it was quite easy to see that every instance (but one, which i considered "printer error") was hyphenated in my edition, meaning that i did a global-change to the "clean" text so those instances would not be flagged again. with my mind on the one track, it went fast. *** another trick was to present only the diffs where the diff lines were the same length. this usually meant that a punctuation mark had been misrecognized as another mark... e.g., a semi-colon misrecognized as a colon. this trick was very good at providing focus, so i expanded it, and displayed only those diffs where the line-length was off by one. then by two, and so on, until all were done. for instance, if the line-lengths were off by one character, that often meant that one of the two lines had a comma the other lacked. once you know that this is the nature of the diffs you are looking at, the resulting focus in your attention can speed up the process... some of you might see that this variable of line-length serves as a _proxy_, of sorts, for what is termed "edit distance" -- defined as the number of edits that needs to be made to one string to change it to another string. so using "edit distance" might be a further refinement that i could use the next time... and after that, i might examine the diffs, to categorize them, and then present only one specific type of diff, like when one line has a comma while the second line doesn't. another difficult situation is when the lines differ at one point, and then at a later point, and one line is correct at the first difference, while the second line is right on the second. in these cases, it would be good to _split_ the diff lines into the two respective parts. it will take a bit of coding, but it's doable... anyway... all of this new experience indicates to me that there are many things to do that will allow me to make the comparison process easier, speedier, and much more efficient. at any rate, we're close to finishing _huck_. -bowerbird

1 0

apple puts all the other companies in check
by Bowerbird＠aol.com 23 Oct '12

23 Oct '12

with its announcements today on "ipad mini", as well as its other advances, apple has now placed all of its chess competitors _in_check_. and now that the form-factor gap between the iphone and the ipad has been plugged, apple can look to the horizon to go bigger. because once apple creates the "ipad giant"" -- with a form-factor of 9*12, meaning that we can finally map our 8.5*11 paper-world onto it in a full-size, non-compromised way, for "all-in" on our paper-to-digital switch -- then it will be _check-mate_ and game-over. -bowerbird p.s. which doesn't mean that it'll all stop... the next step is for apple to put a _handle_ on the imac, so you carry it like a briefcase.

1 0