- gutvol-d - lists.pglaf.org

Re: New Tool "pgdiff"
by Bowerbird＠aol.com 17 Mar '10

17 Mar '10

jim said: > You are attacking my reply re attaching licensing terms > by attaching it to unrelated discussions. jim, i'm not "attacking" anything. let's steer clear of antagonistic language. and if you had quoted what you were replying to, i would have _known_ the scope of your reply. don't blame me because i'm not a mind-reader. > Again, you are assuming the problem presupposes a solution > which is one of "Choose A" or "Choose B". well, since my tool lets a person _edit_ either choice a _or_ choice b, i think i've given the user plenty of leeway. > If you use the tool on other than trivial problems > you will find out that life is not that simple oh please, jim, wake up. i've actually _done_ the kind of comparisons and diff-resolutions that you're just _talking_about_. moreover, i have done them _many_times_. so i think i have much better _experience_ with the actual situation than you do. so don't try to "school me", ok? > frequently both A and B have some degree of errors that need > to be corrected and/or merged to get you where you want to go. now you're just repeating your "frequently" term, which i have already demonstrated to be false, using the most recent example i have shared. in all the resolutions i've done, the vast majority of diffs involved cases where _one_ of the versions was correct. very rarely were both wrong... > If one wanted to make a graphical tool to do this i not only _wanted_ to make such a tool, i actually _programmed_ it... > If one wanted to make a graphical tool to do this > you would not only need the "Choose A" and "Choose B" options > but "Edit in Context while displaying a copy of the original scanned page" you need to read what i wrote, jim. my tool gives people the option to edit either choice a or choice b, before selecting that particular choice. as for displaying the scan, does your pgdiff tool show that information? because if your tool can show that info, my tool can display the scan... but as far as i can see, from your limited example, you don't show that. (and when i say "my tool" in this post, i mean the tool that i wrote that _supports_ your tool. in the tools that i've programmed for _my_use_, i _always_ retain the page-scan information, so i can _display_ the scan.) > and if one wants to make that kind of tool one would be > better off to put the time and effort into figuring out a tool and here we wander off into the land of unnecessary complexity... > This is not my experience i've shared many of my experiences in doing the comparison method. if your experience doesn't match mine, you should share yours as well. > Post a portable version or one compiled for windows > and I will tell you how it works for me in practice. i need to have some questions resolved before i put it out in public. that's why i furnished you some sample texts to get pgdiff output on. -bowerbird

1 0

Re: New Tool "pgdiff"
by Bowerbird＠aol.com 17 Mar '10

17 Mar '10

jim said: > I decline to attach any verbiage at all. > I tell you I wrote it and you can use it any way you like > -- at your own risk and amusement, obviously. except that some of that "verbiage" was people asking just how exactly your program differs from one that they've been using all along. don't you wanna tell 'em? and as for me, perhaps you noticed i congratulated you for programming a tool. was that just "verbiage" to you? in addition, i will analyze any new tool, to check how well it performs the job for which it is intended. it's fine if you don't want to discuss it, but such a review is not "verbiage". it's necessary to take an objective look at our tools to see if they do the job, how they can do it better, and so on... you specifically said your tool helps in 3 areas: 1. line-break recovery 2. error-flagging 3. versioning you even said: > my new tool has several tricks > that haven’t been seen before (if anything has been "verbiage" in this thread, it's that!) so, at the end of this post, i'll begin to look at those 3 areas. > If you need to get more serious than that > contact me by email and we can talk about it. imagine the d.p. people had told you to make your complaints "via e-mail". i'd venture a guess that you would laugh at that... *** > On Vim I type: > :/[{|}]/ > Which highlights the edits and takes me to the next set of edits but that selects both the options, and the surrounding characters. that's not really what you want -- what _most_people_ would want. and it involves typing. either typing or a lot of delicate deleting. both of which increase the probability that errors are introduced. > When you are versioning it is frequently not as simple as > “choose A” or “choose B” but often a mix of both that > you have to edit. i'm sure i know the reality much better than you do, jim, because i've actually _done_ this resolution job, for lots and lots of books. but maybe rather than schooling me personally, you've said this for the benefit of the lurkers who might not have thought about it very much, if at all. (and that's an entirely appropriate thing to do.) but if we're going to enlighten them, let's do it properly, ok? your word "frequently" is simply (but completely) out of place. in the vast majority of cases (96%) where there is a difference between the two versions, _one_ of the versions is _correct_... there _are_ some cases where both are incorrect, meaning that you need to do some editing, but such cases are relatively rare. in the last book for which i did a comparison, gardner's text, there were 159 differences. there were only _3_ cases where _both_ versions were incorrect. so yes, it happens, but rarely. > And I like seeing each next to each other in context > to help figure out what the “correct” editing moves are. oh yeah, the context is _crucial_. but i'm not sure that your _display_ is the optimal one... it takes a lot of visual parsing to figure out a diff like this: > no way. There { warn't | wam't } a window to it big enough personally, i find this display _much_ easier to understand: > no way. There warn't a window to it big enough > no way. There wam't a window to it big enough > ================^^============================ (i hope the monospaced font came through. if so, you'll see the "^^" markers line up with the diff.) and i believe most users would agree that this display is better. but, you know, if some users like _your_ display better, _fine!_ :+) oh, and one more note on "context". sometimes it can fool you. the choice that looks right might not be what was in the book... that's why it's vitally important that your tool show you the scan. otherwise, you're doing your edits blind... > PS: You criticize me for doing that which the creator of wdiff > said he would do if only he had the gumption. you'll need to provide a little more information to be understood. > How do you use wdiff to recover lost linebreaks? i don't use wdiff for that. i wrote my own program. i asked carlo to explain how _he_ does it, but he never answered. i found it humorous he was willing to come out to challenge you, but isn't willing to come out when he is challenged... *** anyway, in order to "kick the tires" on your pgdiff program, jim, i'll set up some files that we can compare. (real books, real files, and not of my own choosing, either, but from rfrank's test-site.) i'll run the files when i next find myself around a p.c. machine... or, if you feel like it, jim, you can run them and post your output. once i have some real output to look at, i'll be able to do a much more thorough review of this new tool. while you're waiting for that, though, here's a screenshot of a tool that i wrote that makes it easier to work with jim's output. > http://z-m-l.com/misc/jim-tool-addon-screenshot.png basically, when it finds a line with a diff in it, it presents the options to the user, who can then click a button to choose one, or enter a number -- 1 or 2 -- to activate the appropriate button. in the case where editing is needed, either option can be edited before the button is clicked to select it. the "stop loop" button will stop the loop that presents the next diff display; otherwise, the app loops through the entire file, jumping to the next diff. so, you see jim, i'm really trying to _help_ you in your quest here. -bowerbird

3 2

Co-operative proofreading
by Lee Passey 17 Mar '10

17 Mar '10

Inspired by Mr. Frank, Mr. Adcock, Ms. Miske and Mr. Morasch, I decided to try to implement my own vision of a co-operative proofreading process. Anyone wanting to watch me flail about can follow my work at www.ebookcooperative.com. Login as guest, no password. Apparently the engineers at Microsoft have not yet figured out how to implement CSS percentages, and I haven't had the time (or inclination) to build an Internet Explorer-aware implementation yet, so visitors would be advised to use a different browser.

4 4

Re: Co-operative proofreading
by Bowerbird＠aol.com 17 Mar '10

17 Mar '10

i said: > unless i'm missing something, it's just a mockup? while i don't think a mockup is very hard to do, not when compared to the programming per se, it's not like i'm mocking mockups... so if you're interested in mockups, there are more. here's one from dkretz: > http://www.pgdp.org/~dkretz/c/editpagedemo.php?projectid=projectID45c572a14… here's a page giving several from cpeel: > http://www.pgdp.org/~cpeel/prototypes/ -bowerbird

1 0

Re: New Tool "pgdiff"
by Bowerbird＠aol.com 17 Mar '10

17 Mar '10

keith said: > True enough. Yet, the arguement stands. perhaps you didn't catch my entire gist. _of_course_ one needs to allow for the possibility of editing either version, since both might be incorrect. as i pointed out, my tool (which supports jim's tool) does exactly that. > At least in my opinion. The trivial cases are > easy to handle, yet it is always the RARE cases > where tools can shine and set themselves > apart from the rest. but jim's methodology -- where his tool simply _marks_ the differences after which a person uses a reg-ex editor to actually _make_the_changes_ -- handles neither the rare cases nor the trivial well. whereas my tool-in-support-of-his handles both, equally well. a reg-ex editor, by requiring manual editing even in the "trivial" cases, handles neither trivial nor rare very well, in my opinion. my tool-in-support-of-his makes the "trivial" cases, which are by far the most common, trivial to handle, with a mere button-click or keypress. and the user only has to do manual editing in the rare case, where it simply cannot be avoided. > Actually, both methods are kind of primitive > from a Human Interface standpoint. i always appreciate it when someone analyzes my tools. so let's see what you have to say here, keith. > a better way would be having > two windows containing two or more lines > above and below the diff and marking each. a little bit of context can help elucidate the difference. too much context can bury it, depending on the display. i'd have to see exactly what you mean in order to decide. in my-tool-in-support-of-jim's tool, the change-window is a movable modal, so people can simply look back at the main window if they need to see more than 1 line of context. (i could also put multiple content lines in the top box of the change-window, if feedback indicated people wanted them.) > If you ever work with critical editions > you will understand the cavet of this method. if it impossible for you to explain in words? > The changes can then be made in a third. again, not sure what you really mean here... > All can be enhanced with colors and other neat features. you can always "enhance" anything with "other neat features". the hard part is _coming_up_ with those "other neat features". *** we should remember that my tool-in-support-of-jim's tool isn't how _i_ would do the job. i was just trying to show how to make his tool work better. i've shown how i do the job... here's how i showed diffs with gardner's book, on 23 february: > http://z-m-l.com/go/gardn/gardn-hybrid6.html that laid out the entire book, with diffs in different colors... here's a simple reworking of that file, which i just posted: > http://z-m-l.com/go/gardn/gardn-hybrid7.html this version of the file lets you click a link to see each scan, and gives you radio-buttons where you can select the correct alternative for each diff. (or choose neither if both are wrong.) this is how i would approach this task with an _online_ thrust, working in a collaborative manner. but i'd probably prefer to do it with an _offline_ app instead, since that's more efficient. -bowerbird

2 1

Re: Co-operative proofreading
by Bowerbird＠aol.com 16 Mar '10

16 Mar '10

jon said: > Interesting, and it's good to see someone do people really think lee's system is "interesting"? unless i'm missing something, it's just a mockup? it doesn't actually save the text, not that i can see. and the reg-ex cleanup doesn't really work, does it? > Interesting, and it's good to see someone > using a rich text editor for the text, rather than > expecting proofers to mess around with <i>, etc. except there is a tremendous conundrum at work... because we don't want proofers to go "presentational", do we? we want them to make structural distinctions... but with all those presentational w.y.s.i.w.y.g. buttons littering the interface, how would proofers ignore them? > I'm using a widescreen 1680x1050 monitor, and > there was still material off the bottom of the page. > This is using Google Chrome. i had similar problems in safari. camino worked fine. > It would be nice to have (the option of) a horizontal > rather than vertical layout. I used to really like > the vertical layout, but found I was more accurate > at proofing with a horizontal one. i don't understand the appeal of a horizontal interface -- way too much scrolling for me! -- but lots of people seem to prefer it. > I really prefer block paragraphs rather than > indented ones for computer-based text. but you want the display to look like the p-book, not? -bowerbird

1 0

Re: any arguments against "free-range" proofing?
by Bowerbird＠aol.com 16 Mar '10

16 Mar '10

juliet said: > The Australian Newspaper project allows a volunteer to > proof any article from ~100 yrs of lots of newspapers. well, that's quite different from what i'm talking about, which is to allow people to proof any page of a _book_, one that is being actively worked on at the present time. > Also, since there's no information as to whether or not > anyone has looked at (proofed) this article yet, there's > no way to know if one is duplicating work already done. again, quite different. i will explicitly inform people of the exact status of every page. however, if they _want_ to "duplicate" work that is "already done" -- by proofing a page that's already "finished" -- they can certainly do so. indeed, up through the 3rd "confirmation" a page is "done", the person would continue to receive "points" for doing so... the main reason a person would go the "free-range" route, i would think, would be so they could actually read the book in the process of proofing. i think that's a useful perspective. another reason might be to do a "specialized" look at the book. for instance, i think it'd be great for a person to look through the entire book just to find cases of _italics_ and _formatting_. even a pass checking the paragraph-starts at page-tops will be a useful quality-control mechanism i'd want to encourage. > All of this ties in to a sense of progress. indeed. > In a free-range system, there is no such assurance that > anyone else will want to help finish that book. i think it's just the opposite. if i inform people which pages haven't yet been proofed, many people would choose them. if i show people which pages need to be confirmed, i think some people will want to get their "points" that way instead. and other people will want to read straight through the book, without any regard for the state of any one particular page... by letting them choose whatever they like, rather than just _assigning_ them a page, with a choice to "take it or leave it", i think they're going to do a good job of progressing a book. > The only way I can see to achieve that > in a free-range environment is by > limiting the number of books that are currently available. which is, i think, a perfectly good way to achieve that goal. the idea that d.p. seems to have settled upon is that anyone can put a book in the system, without anybody knowing who -- if anyone -- will be there at the end to pick up the pieces. as a consequence, you now have two tons of half-done books. and this has nothing to do with "free-range", as evidenced by the fact that rfrank is using a "limited-number" approach in his system, in order to make sure that books don't get beached. > If no one is likely to look again at whatever page I've just done, > there is nothing to keep me from changing what it says. ok, i guess you're talking about the australian newspaper thing. which, again, has no applicability to what i'm talking about, so i won't bother to address it here, except to say that my system is _expressly_and_extensively_ geared to checking changes made. there won't be any "graffiti" that won't be painted over very quickly. -bowerbird

1 0

Re: Co-operative proofreading
by Bowerbird＠aol.com 16 Mar '10

16 Mar '10

dkretz said: > Nice one! > I can see we're going through the classic learning curve! > Let a thousand flowers bloom! you seem like a nice-enough fellow, don. so why are all those people over at d.p. throwing rocks at you? ;+) *** lee said: > Inspired by Mr. Frank, Mr. Adcock, Ms. Miske and Mr. Morasch who are all these people? hey lee, you left out dkretz. who has done more than anyone, including rfrank. don was instrumental in producing dp-canada. i have not talked about dp-canada because i was banned from it before it even started by one of the crazy people involved with it. but it seems to be limping along just fine, as far as i know, so if anyone wants to start a site, i'd advise you to look at dp-canada. or talk to don. no one has come nearly as close to me in inspiring the d.p. rock-throwers as don; he must be doing something right. > I decided to try to implement > my own vision of a co-operative proofreading process. good luck! i'd give you some feedback, but since you're in my spam folder and all, dialog would be stilted, so you're on your own, passey. it would be nice if a thousand flowers bloomed, but my bet is 999 will die on the vine. which might also be fine, i don't know. i just know i won't bother to keep count until there's a shakeout... but geez louise, even some people from d.p. itself now seem to be newly motivated to _do_something_. which would be a good sign, except they're planning a facelift to a system with structural damage. it might _look_ a little better, but it won't really _work_ any better. but -- largely due to rfrank's competition -- they're now _trying_... -bowerbird

2 1

Re: [SPAM] re: any arguments against "free-range" proofing?
by Greg M. Johnson 16 Mar '10

16 Mar '10

From: "Keith J. Schultz" <schultzk(a)uni-trier.de> > > More interesting would be how you track everything. I > believe you will need some form of a database for > the points system, Could points be *the* problem? I don't think "points" works well in performance metrics for either high-level professionals or in nonprofits (say, the parents of a Cub Scout den expected to contribute so much volunteer effort per year). For one, it creates the expectation that the reason one contributes to humanity is to get recognition for their effort on a piecemeal basis. That the person who puts in 40 hours a week of effort needs more praise than he or she who put in 35, 30, or 10 hours. Secondly, it creates false hierarchies where you don't allow someone into leadership until they've "reached a level". It's just my philosophical bias that the best nonprofits are not those with the best volunteer awards dinners. -- Greg M. Johnson http://pterandon.blogspot.com

1 0

[SPAM] re: any arguments against "free-range" proofing?
by Bowerbird＠aol.com 15 Mar '10

15 Mar '10

nobody came up with many objections to "free-range" proofing... *** keith said: > I do not see anything truely speaking against such a system. > The only problems are the administrative tasks involved. thanks for the feedback keith... > 1) you have to track all this. i think that's pretty easy. when they hit the "save/confirm" button, if there were changes made, then they have _saved_ a new version, which will then set up a "diff appointment" with any prior proofers. or, if there were no changes made, it's registered as a "certification". once a page has two consecutive certifications, it's marked as "done". (any free-range proofers can still proof the page, of course, but once all the pages are marked as "done", the book is ready to be finished.) the "diff appointment" can be resolved in one of three different ways. the first proofer can say "i goofed", or the second one can say "oops!" either of these actions mean one person loses points, and one gains... the third resolution -- when they can't come to a mutual agreement -- comes via a referee, who decides a winner and rewrites documentation so the issue doesn't come up again. points might or might not be lost. (or deducted points might be doubled, if a ref was called unnecessarily.) the purpose of diff review is simply to train correct proofing and coding. people who continue making bad changes might be asked to leave, but i don't anticipate it happening very often. people like to do a good job. > 2) keep everything store somewhere each subsequent saved-text will be stored, for subsequent diff tests. upon saving, it will be compared to all of the earlier saved versions, to see if it is a revert to an earlier save. if it is, it will be dealt with appropriately, depending on the resolution of that earlier version... any proofer will be able to step through all the versions of each file, viewing which changes were made. i expect that some proofers will specialize in this particular tactic, making sure every change is good. > 3) keep everything in sync i've had my share of sync problems in the past, coding e-book authoring-tools, so i think i know where all the pitfalls are now. :+) which is not to say i won't fall in some of 'em again sometimes. but i can usually figure out pretty quickly now what i did wrong. > you will need an authority/ies that finally certify that > a page satisfies your criteria as being done. that's easy. if the text is .zml that creates .html which looks like the page-scan, then that satisfies the criteria. the proofers view .html output, so can see for themselves. > Some may call it a administrative nightmare, > but it should be workable. yes, i think i can make it work. again, thanks for the feedback. -bowerbird

2 1