Re: jim replies to his e-mail
jim said:
post actual working programs, along with source code, people can try it themselves and give feedback about whether it actually proved useful or not.
i often post working programs. but i won't post my source code. and sometimes, like with my comparison program, i won't post the program unless/until there is some actual _demand_ for it. i said i'd post my comparison program if 5 people asked for it. so far i haven't heard even one request, other than yours, jim, so i don't see any need to post the program. *** jim said:
Again, post YOUR source code, and working code examples, and then let's talk about it.
well, jim, in the context of posting diffs, i've posted _hundreds_ of examples of the output created by my comparison programs. they take this form:
this line, on the top, came from one file. this line, on the bottom, came from the other file.
*** jim said:
You will find that you your tool whatever it is you eventually post someday will also have to deal with these problems, because they are fundamental to the INPUT domain -- how two different files match or do not match and why and what you want to do about it.
yeah, that's the exact input-domain that i've been handling -- as files move from pure o.c.r. output to finished text -- and i have been handling it with complete ease and fluidity. pgdiff doesn't seem to be able to handle that particular task with the same ease and fluidity. and maybe, as you suggest, it handles some _other_ comparison task in a better way, but i'm hard-pressed to see what that "other" task might be. but, like i said, maybe the failing is with me. as long as _you_ are happy with your tool, that's all that matters, i would think. *** jim said:
I don't actually ignore the things you ask us to try BB, it's just that out of courtesy I don't list here all the PG and DP tools I have tried which really don't work when I try to use them. I'm happy to list the tools that I do use that more-or-less work for me if anyone really cares.
except in this case i'm not asking for "courtesy", jim. i'm asking for feedback. so feel free to give it, _especially_ on the parts that "really don't work when you try to use them." -bowerbird
i'm asking for feedback. so feel free to give it, _especially_ on the
parts that "really don't work when you try to use them." OK, the typical pattern of experience I've had with the programs you have asked us to try in the past is that they appear to install "correctly" and then when I try to get them to work they literally hang forever, or take minutes to update the display. What you ask us to try now works better than that, but see my other email -- there seems to be a disconnect between what you are doing and the rest of us out here on another planet. This compares, for example, to Guiguts, which works more or less like advertised, but when I try it I find that there is enough subtle errors in what it does that it takes more time and effort to try to use it to make books than to not use it to make books. I also use gutcheck etc because the WW insist on it, and find it a huge waste of time, returning literally 100+ false positives per each good catch. Probably faster and more productive to do an additional SR pass. I personally use two tools I have created, performing three jobs: Pgdiff allows me to compare two raw files and allows me using a regex editor to quickly find and fix the differences. It works reliably for big and small differences, including up to whole chapter changes, not just the occasional scanno. Pgdiff allows me to quickly and easily recover linebreaks that have been lost by PG because of their "text70" conventions, such that I can make another pass on the text. (And this obviously is without access to the original text prior to when the "text70" conventions threw away the linebreak info) Smartdehyphen automatically and conservatively fixes hyphens across linebreaks and tightens punctuation. Neither of these tools do a huge part of the job but rather represent "fixes" where I found myself repeatedly needlessly doing the kind of "million-monkey-work" that one finds [needlessly] in P1. Other tools I use "All the Time" for various parts of the job though none works correctly for all of the job include: Notepad Wordpad Notepad++ Winword Adobe Reader ADE Lizard Djvu Vim Abbyy Finereader Mobipocket Creater Calibre Mobigen Kindlegen Visual Studio validator.w3.org Plus all the standard "*nix" cmd line tools. And even just about all these "professional" tools have hung once or twice in the middle of doing some part of the job, and/or corrupted parts of files.
participants (2)
-
Bowerbird＠aol.com -
Jim Adcock