November 2012 - gutvol-d - lists.pglaf.org

replicating the print-book's pages
by Bowerbird＠aol.com 19 Nov '12

19 Nov '12

for roughly the first decade or so of my research on e-books, i was content with an absence of concern for the printed page. this was just a bit disconcerting, because i'd previously been involved with desktop publishing, and derived great pleasure from the act of laying ink on paper, and doing it beautifully... and especially because i had a smattering of contact with the practices of the past -- such as paste-up boards and hot wax and color-separations -- i _marveled_ because the computer empowered me to do and re-do, simply, accurately, and fast. so, particularly because of the ease and power of the machine, it was hard to leave behind all of my obsession with the page... but eventually i could forget about the trappings of that past, throw 'em all out and start anew. and it was quite refreshing to work from scratch, to have a blank slate, an empty canvas, a reason to have to decide everything from the very beginning. one of the first things to go was the notion of "the page" itself. the mantra was clear -- "electronic-books don't _have_ pages." so all of the fussing that i had done before, on run-heads and drop-folios and fretting over widows and orphans, all of that, margins and gutters and page-counts and such -- _all_ of it -- was just thrown out the window, never to be thought of again... and to be truthful, it _was_ liberating, very much so, for a while. then some cracks began to appear, around the corners at first... for instance, even if you don't have the notion of "pages" per se, sometimes the number of lines in a field of content still can run _one_too_many_ for the current screen, and slop on to the next. so even if you don't _call_ it a widow (or an orphan, or whatever), that's what it _is_. and it is still upsetting to your obsessiveness. and page-count? well sure, it felt good to give up the arbitrary monster that used to say "this book is a few pages too long" or "dummy, there is no way to make money on a 70-page book"... now you could say "i made it exactly as long as it needed to be". but it also meant that sometimes you had to keep on wondering whether a book was "exactly" as long as it "needed" to be, or not, or whether you maybe should flush out that one little vague bit with a few more pages, or just decide that it was "good enough". sometimes having a hard target can save you a lot of fretting... *** but without question, the most troubling thing to discard was the noble page-number, with all of the utility that it provided. it's not that a page-number per se is all that useful. it's _not_. once you're inside a book, you don't look at the page-numbers. if you do stop and ask "how many pages are left in this book?", it's because the story lost the rivet fastened to your attention... and even further, the page-number is more than a gauge of how far you've moved along in the course of the entire book. we can put "page-numbers" in an e-book ("screen-numbers?") very easily, and they serve some useful purpose as milestones, but since we know they are so arbitrary (change the fontsize, and the number of "screens" changes accordingly), we _know_ that they don't have any lasting value in a cross-person sense. and the "location numbers" that the kindle uses are consistent, but they're spongy because they don't delineate a clear portion. we do not easily see where one starts, or the next one kicks in. and _that_ is the main purpose that page-numbers really serve -- the ability for one person to communicate them to another, and have the second person know the place in the book where the first person is talking about. ok, yes, it's a _general_ place, but that's sometimes exactly what we want, and even when not, it's usually _sufficient_. (and we _can_ be even more precise, such as specifying "the top of the page" or "the eleventh line".) more importantly, the page-number successfully encapsulates a _range_, and the range is _known_ and _specific_, because we can tell you the first word on the page, and the last one as well. so that's why the page-number became the canonical "pointer" for print-books, employed by _indexes_ and _references_ and the classroom-teacher who says "now please turn to page 69." there are some books, like "the social science citation index", which is entirely composed of collections of page-numbers... and thus, page-numbers are the print equivalent of the "link". not quite as handy as point-and-click, nope, but just as useful. because inherent with the page-number is the _certainty_ that this information points to one specific part of a book's content. and it is that _certainty_ that is the most important thing here; a page in a book, named via number, is a _known_commodity._ we know the first word, the last, and all the words in-between. and thus has the page come to be a precious commodity to us. it's so well-known that the page itself has become an icon -- words in lines, running across the page, from top to bottom. or -- as an icon -- a series of squiggles from top to bottom. but an e-book is formless; it's "free" to "reflow", like water. what that means, though, in the end, is that it's just a blob, which runs through our fingers, like sand, instead of being a solid tangible _goblet_ which could _hold_ water (or sand). *** having abandoned the page, there were times when i would wish to bring it back. not on a permanent, exclusive, basis. it's clear that we need for our e-books to be able to reflow. but rather as an _option_, something that can be _chosen_. however, i'm stuck with the formless blob of free-flow text. or am i? to answer, and cut directly to the chase, _no_, i'm not stuck. i can formulate the e-book such that it replicates the pages of the print-book, but then can reflow_ out_ of that goblet... and that's precisely what i do, with my paginated .zml files. all the page-boundaries are marked with information giving the filename of the page-scan (at the top of each page) and the page-number (printed or not) of the page (at the bottom). and the line-breaks, of course, are indicated with line-breaks. this information allows us to clone the look of the print-book. but it's also entirely easy to provide the reflow, when needed. remove page-boundary info and mid-paragraph line-breaks, and voila, you've got reflowing text, just like that, easy-peasy. (well, yeah, you gotta mark "soft" hyphens versus "hard" ones, and do something to indicate lines that shouldn't rewrap, but it's entirely do-able, and it's not even all that difficult, really.) this gives us the ability to replicate the print-book if desired -- such as, for instance, to make print-on-demand copies -- but also to reflow the book when that's the best thing to do... *** ok, so this is brain-dead simple to do on straight-text books, but when there is something else on the page, it can become more difficult. the common "something else" is illustrations. the version of "huck" which i worked on did have illustrations, so i've taken a whack at the task of replicating the print pages. the results i got were "good enough", considering that the graphics-files seem to have been collected in a fashion that is not very conducive to what i was trying to accomplish, so i've decided to settle on "good enough" and proceed on, but i am still happy to show you these less-than-perfect results. it's also the case that this attempt works reasonably well on _my_ screen, but _might_ fail _miserably_ on a screen which is not a 23-incher. you can adjust the size of the graphics by adjusting the size of the browser-window, but it won't mean you will end up with something "reasonable", just "different". because this is just a trial, i'm not interested in reworking it so as to ensure the results will be impervious to screen-size. therefore, if it doesn't work for you, i give my apology to you, but not anything more. but if you still wanna see my results, just say so, and i'll post screenshots instead of "live output". (probably what i should've done anyway, so do let me know.) *** there were three ways illustrations were displayed in this book. the first was on chapter-headers. the chapter-header _itself_ was rendered as a graphic and incorporated into an illustration which was laid in to the left of the text that opened the chapter. you can see these chapter-headers beginning with chapter 1: > http://zenmagiclove.com/huckf/wisdom.py?whatpage=17 click the "cplus" button to jump to the next one, and the next... i think these screens were sabotaged by the fact that the scans were not terribly consistent in their vertical placement, which is crucial here to matching up the graphic with the (separate) text. *** the second basic way an illustration was placed on these pages was centered in the measure, displacing text above and below. examples can be seen here: > http://zenmagiclove.com/huckf/wisdom.py?whatpage=21 > http://zenmagiclove.com/huckf/wisdom.py?whatpage=25 > http://zenmagiclove.com/huckf/wisdom.py?whatpage=43 these pages were, of course, very simple to replicate. (in cases when the picture had been presented mid-paragraph, i moved it so that it was displayed between paragraphs instead.) *** and finally, the third way illustrations were placed was as an "inset" -- placed up against one of the margins, with the text being wrapped to a rectangular edge along the opposite side. you can see this type of placement here: > http://zenmagiclove.com/huckf/wisdom.py?whatpage=18 > http://zenmagiclove.com/huckf/wisdom.py?whatpage=19 > http://zenmagiclove.com/huckf/wisdom.py?whatpage=24 the tradition is that illustrations are put on the outside margin -- left side on a verso/even page, right side on a recto/odd -- so they are more easily located when a person riffles the book; and i coulda done that, but i just put them all on the right side. the problem was that the graphics seem to have been resized. they weren't consistently sized the same as on my page-scans. perhaps this is because they were from a different edition, or maybe david widger resized them for his convenience, i dunno. but it caused something of a problem in placing them correctly; most of the time they were too small for the "hole" in the text... so i wrote a routine to up-size them, which i think worked well, at least for the particular window-size i was using at that time, although i have no assurance the routine will work on any size. but since there should be no need for any resizing at all, i am not willing to spend any more time changing this one-off code. what i _did_ do, though, is make the inset graphics draggable. so if they happen to bump into some text, or obscure any text, you can just drag the graphic out of the way, where you want it. a more-advanced version of this positioning routine will install some "collision detection" routines in the code, so the graphic will "move itself" if it detects any collision with any of the text. this notion that a graphic will "find some available whitespace" and adjust itself into it appropriately is one i have entertained for a long time now, and i continue to believe it's a great idea. so i'm happy to have taken a first step toward implementing it. i also believe it is important that we create the capability of "replicating" the printed canonical versions of classic books, in modern-day digital equivalents that also have the ability to break out into reflow mode whenever we want 'em to, so i took on the illustration challenge which huck presented me. -bowerbird

1 0

cleaning up after a car-crash can be so tedious
by Bowerbird＠aol.com 18 Nov '12

18 Nov '12

ok, jim, i'm sending you back to my kill-filter, for the same reasons you always get sent there, namely that you are mush-mouthed and two-faced, and you constantly try to put stupid words in my mouth, and you don't know when someone is arguing on your side and thus you shouldn't pick a fight with 'em just because you feel like a fight. so i'm done talking to you, again, jim. no need for you to respond. instead, i'm talking _about_ you, to everyone else. you can talk to _them_, about what i said, if you want. but do not respond to me. because, once again, jim, you've forced me to stop listening to you. *** jim said: > I suggest you give the list to PG, and ask them to verify and fix > any bugs you found BB. i could do that. or i could just offer them my new version, all fixed. indeed, i've _already_ informed p.g. that it is welcome to my work. i'm not gonna "submit" it to them, but they're welcome to go get it. but as they haven't picked up anything else i have done, i doubt it. > Once a book goes to PG I have no more ability to fix that book > than you do. i'm not sure that's true. in fact, i'm pretty sure that it is false. i believe that corrections are often accepted much more readily if they are submitted by the person who did the book originally. besides, jim should have the intellectual curiosity to want to face errors directly, so he could learn their lesson from them. when it came to david widger's errors, jim didn't hesitate to smear them in his face. jim posted a list of diffs, back when jim did 'em, and then he pointed _again_ to the list the other day in this thread. so it appears that jim wants david's errors to be flaunted publicly, but he wants his own errors hidden in an e-mail to the back room. we'll see about that. > press by my wife and children that I feed them and clothe them i should hope that i won't interfere with jim's feeding and clothing of his wife and children. that's not something i'd want to disrupt. i want no responsibility at all for his family being hungry or naked. > I found and fixed many bugs in the PG version, and at least > in my version got rid of the annoying ALL CAPS SHOUTING in 76. that jim did. and i have made sure to give jim full credit all along. indeed, i was probably the only one on this list who gave jim props. if there was anyone else who did, i would appreciate a link to that... > I hope in turn that you are able to build on my efforts, i was indeed able to build on jim's efforts, by using his digitization as a comparison-text that _sharpened_ my digitization effectively. heck, it was because i knew that i had two existing digitizations -- david's and jim's -- that i decided to work this specific book. > and that you find personal pleasure in donating your version > forward to the world i have made my version available "to the world". whether the world is smart enough to pick up on it or not. (and no, i don't generally think "the world" gives a damn. so no, that's _not_ a big generator of "personal pleasure", not for me. as i have said, i clean up text because it's fun, for me, in the same way that my girlfriend likes sudoku, so i'll probably keep doing it, just as long as it _remains_ fun.) > and try not to spend too much time vacuously > tearing down the efforts of others gawd, jim is such an idiot some times. well, rather frequently. (remember, jim, that i warned you that if you said _enough_ idiotic things, people will have to start calling you "an idiot".) i don't spend _any_time_ "tearing down the efforts of others". let alone "vacuously". (does jim even know what that means?) i truly and honestly appreciate all of the time and energy that is donated by the volunteers who are helping to digitize our books. and i have offered my constructive criticism towards those efforts for a long time, and been slapped down repeatedly for doing so, but i have continued on anyway, because what i say is worthwhile, because if you do truly value what the volunteers contribute, then you have a desire to maximize the efficiency of their contributions. moreover, i've even offered to build tools to help with digitization, but again, my offers have been rebuffed, so i build 'em for myself, because i like the programming challenge, which is another puzzle. and, getting back to the case of jim, i studiously _avoided_ saying much of anything about errors in jim's work. i knew jim had made _well_over_a_hundred_ errors -- because i had to go and confirm that each one was an error -- but i never listed them, or even the raw number itself, out of simple courtesy. (although jim _himself_ had no qualms about attacking the quality of david's work before.) i appreciate what jim did. i appreciate what david did. i appreciate the work of ron burkey on an early version of this "huck finn" book, and i appreciate the work done originally, by an anonymous person. but did jim appreciate my simple courtesy? well, no, no he didn't. he posted that he had found "one" of the errors, as if that implied there weren't all that many of them, so as to minimize the issue... jim's version has over a hundred errors. literally. i will post them. then, if he wants 'em fixed, jim can send that list to david widger. however, since david doesn't even fix errors in his _own_ version... > those who are not in any way stopping you from doing that which > you think you need to do to make a contribution to the world. it's interesting that jim doesn't see himself as an obstacle to me, but he does indeed see david widger as an obstacle to him, even though jim's relationship to my new version is almost exactly the same as david's relationship to jim's new version of the work that david did. i guess it depends which foot the shoe is on. but no, i don't see jim as "stopping me", in any way, shape, or form. not any more than a fly prevents me from enjoying my nice picnic... especially once i have swatted that fly with the print-book i brought (to weigh down one of the corners of the blanket). irritant removed. (but hey, maybe the fly thought that he was important.) > It has never been my claim, but rather yours, > that volunteer efforts should be flawless. what a stupid thing for jim to say. not just stupid; absolutely idiotic. first of all, i have _never_ever_ said that. never did. never would. what i _have_ said -- and heck, even jim should be able to tell the difference, since it's pretty obvious, and not all that subtle at all -- is that p.g. should attempt to make books as flawless as possible... in other words, you take whatever you get, and you make it better. because it's never going to be "flawless" from the get-go, you idiot. and once you've made it better, then you try to make it even better. and even _that_ gets a disclaimer, because i've explicitly recognized that -- at some point in time -- the _cost_ of attaining better accuracy outweighs the _benefit_ of that accuracy, and thus we should _stop_. so i have a very-finely-tuned position that both recognizes an _ideal_ and, at the same time, acknowledges the _reality_ which surrounds it. it is a very clear-cut position which gives outstanding guidance about exactly what procedures p.g. should install in its workflow, and _why_. which is what has allowed me to offer very specific advice concerning exactly what kind of changes i suggest to the existing p.g. workflow... indeed, most of the time i am talking about the "best practices" for a workflow that _any_ cyberlibrary could and should be adopting today. so, what has jim offered instead? nothing. except trying to put stupid words in my mouth. shameful. > Rather, my claim has always been that PG ought to invite efforts > by volunteers to fix bugs, improve the quality of the collection, > and move it forward, rather than have it frozen forever > at one snapshot in time. well, that _sounds_ good. as far as it goes. but how far does it go? p.g. would respond that it does indeed already do all of those things. and what jim has said is _squishy_ enough that p.g. might be right, that they already do that, and it's hard for jim to argue they don't... so jim and p.g. effectively have a stand-off about whether p.g. is doing what it should in order to meet a vague mission-statement. while i am suggesting concrete alternatives. so i can argue that p.g. isn't even _close_ to where it should be... has jim ever offered any demo of a system that will "invite efforts" by volunteers "to fix bugs"? no. he simply said that p.g. _should_. has jim ever described a full system that will enable volunteers to "improve the quality of the collection, and move it forward"? nope. but i have. jim just mouths the platitude. i build an actual system. > the concept of a "high priesthood" of insider volunteers > vs. an outside "unwashed mass" of volunteers > is a very destructive conceit. in ways i agree with jim. but in ways, i don't, because jim has not explicitly recognized that the "high priesthood" of "insider volunteers" are people who have donated tens of thousands of hours of their time and energy to p.g. jim, on the other hand, has offered a few hundred hours of bitching. i fully agree with jim that p.g. _should_ listen to his bitching, and try to find something worthwhile in it. because there's value there. likewise, _i_ have done a ton of bitching myself, and p.g. should be listening to _my_ bitching, because there is valuable stuff there too. the same with most of the bitching that people do. it has _value._ and p.g. is deaf to all of it. (or at least they _pretend_ to be deaf.) when what p.g. should do is actually _listen_ to it. and carefully! or, at the very least, they should _pretend_ to be _listening_ to it. so this is one of those cases where jim and i actually agree on this, but jim acts like it's a point of difference between us. jim is an ass. > I certainly agree with you that > having a provenance for a PG book is a good thing ok, well, at least here, jim has enough presence of mind to realize that he's playing on my side of the tennis court on this specific issue. but again, jim just mouths the words; he doesn't really believe 'em. jim's right as far as his words go, but doesn't do the follow through. because i'm not _just_ saying every e-book should have provenance. i'm saying that _every_line_on_every_page_ should have provenance that's thrust unavoidably in a user's face with the pudding of proof. i'm saying that a display for _every_ cyberlibrary e-book should be a view that puts text for every specific page right alongside its scan. (this shouldn't be the only view, but it must be one that's available.) and i don't just _say_ that, either. along the course of the last 5 years or more, i've actually _mounted_ many e-books in a text-next-to-scan mode. action, not just words. real-life examples, accumulated over the course of many years now. so, tell me, how many e-books has jim mounted this way? or tell me this instead: out of the books jim has submitted to p.g., for how many of them has he submitted scans as well? how many? heck, even tell me this: in his p.g. books, how many of 'em has jim explicitly stated and pointed to the scan-set he used as the source? go ahead, give me a link to every single one, and i'll acknowledge it. but i'm guessing you won't find even one that's specific, not general. so, does jim really believe that an e-book should show provenance? or is he just _saying_ it, now, so he can squeeze out of a tight spot? > and where the oldie-moldies lack that provenance, > I believe PG should encourage efforts by volunteers > to go back and provide and match that provenance, > rather than preventing such now jim appears to be tearing down p.g., who is not in any way stopping him from doing that which he thinks he needs to do to make a contribution to the world. p.g. even mounts his books... > and doing so should not require issuing a new number. what a whiner. *** every time i talk to jim, it ends up being a waste of time, and i wonder why i let the value of the thread degenerate. so it's back to the kill-filter for you, jim. and good riddance. sorry, lurkers, car-crash is over. nothing to see here. move along. -bowerbird

2 1

jim found one of his errors
by Bowerbird＠aol.com 15 Nov '12

15 Nov '12

jim said: > People who are interested in figuring out > the real "main point" should, again, take a look at: > http://www.freekindlebooks.org/Dev/HuckDiff.txt > which should give people some idea how many errors > there are in the older PG texts. jim seems intent on pointing out the utter deficiency of the widger version of "huck finn", so let me support that. oh yeah, i already have, in a post to this very listserve, less than 6 weeks ago, where i detailed the problems... > http://lists.pglaf.org/mailman/private/gutvol-d/2012-October/010169.html to refresh your memory, here are the biggest flaws: 1. the italics are indicated by upper-casing, which means that all the uppercase-i personal pronouns that're _supposed_ to be italics are unrecognizable. 2. the headers are mistagged as plain paragraphs. (and not even bold, or big, or centered -- nothing!) 3. no scan-set is given as the source of the text. i believe jim that there are plenty of errors in #76, since i found a number of probable missing italics. but the bigger problem is that we can't even _check_ the text's accuracy, since we don't know the source... so, it should be clear that i support jim's contention, as far as it goes, but i don't think it goes far enough. *** if the only thing you have to say about the earliest p.g. e-texts is that lots of 'em are flawed, _big_deal_. we know many are flawed, and they need to be fixed. so the more important questions are the follow-ups. that's where my posts kick in. i'm sharing the details about what i believe will need to be done in order to make p.g. e-texts competitive with other digitizations. p.g. has a sad reputation for inaccuracy in its e-texts. so that has to be one of the biggest issues on its plate. there are other big issues as well, of course, such as the poor quality of the p.g. conversion to .epub/.mobi. but even if conversions are flawless, that's not gonna excuse the fact that the text itself is often incorrect... however, let's even go a step beyond _that_, as well... because even if your conversions are good, and your text is totally and completely accurate, if you do not have a way to _show_ your text is fully accurate, then you're going to lose out the competition to the entity who _does_ have a way to show their text is accurate. and the way to _show_ your text is "fully accurate" is to mount it side-by-side with the relevant page-scan. it also helps to have a comments section on the page, where people can leave error-reports, or discuss any anomalies in the text, or changes made from the scan. (people could discuss the _content_ on the page too.) this error-reporting functionality serves another need which p.g. has, to bring great transparency to _that_... *** but hey, i know you lurkers... ;+) you're not here for the _philosophy_, are you? heck no! you're here for the train-wreck... you wanna gawk at the car-crash, don't you? so far be it from me to deprive you of your desires... let me stir up some tempest in this teapot. hey, jim, i found over 20 differences between my "huck" and your "huck" -- in the _paragraphing_ alone. over 20! and my rough check says that about 2/3 are your errors, with about 1/3 being actual differences between editions. (i'm not ruling out the possibility that i made some errors; also, it is fully possible you're wrong and i'm wrong too.) so, jim, would you like to do the work to find those diffs? or do you want me to give you the list? let me know, jim. -bowerbird

3 2

i'm sending jim back to my kill-filter again
by Bowerbird＠aol.com 14 Nov '12

14 Nov '12

i'm sending jim back to my kill-filter again. once again, he has demonstrated that it is a waste of time to try to converse with him. i'll respond to his latest post -- in a reply addressed to everyone _but_ him -- later. but for now, this notice will have to do... -bowerbird p.s. it will be a long time before his next parole hearing. he wasted many chances.

1 0

jim found one of his errors
by Bowerbird＠aol.com 11 Nov '12

11 Nov '12

jim said: > It looks like you are dropping one-letter words > that are coming at the end of your lines, BB. i appreciate all error-reports. please give the page-number (as shown on the page) and the dropped word -- along with its line-number, which you can obtain by using the provided interface: > http://zenmagiclove.com/huckj/wisdom.py thanks. > I did notice what looked like one real 'jim' error in there. i didn't count, but there's a lot more than one. nonetheless, i will appreciate any error-report, whether your error, or mine, even newly-found. > Not sure what your "main point" was? i'll discuss it in some detail in an upcoming post, but the thrust (which i have already provided, in the past and quite recently) is that anyone who wants to prove that they're confident their digitization is dependable will provide an interface that allows the end-users to directly compare the text with its relevant page-scan. end-users will naturally gravitate to the digitizations which _do_ furnish such a comparison interface, and therefore come to be skeptical of those which do not. for instance, you have an error in the first paragraph of chapter 14, jim. document explicitly how a person would check it, if they happened to suspect an error, and then how you would confirm or deny their report. (do it, jim, and be explicit, because if you won't, i will.) then consider my response, which is this u.r.l.: > http://zenmagiclove.com/huckf/wisdom.py?whatpage=110 that's how i would _prove_ that my text is _correct_. as we will see, my methodology is better than yours. it's far _simpler_, and much _faster_, for _everyone._ > People who are interested in figuring out > the real "main point" should, again, take a look at: i suppose everyone defines "real" in a different way... > People who are interested in figuring out > the real "main point" should, again, take a look at: > http://www.freekindlebooks.org/Dev/HuckDiff.txt ...but i doubt that a confusing page of one-word diffs is gonna be convincing about _anything_ to _anyone._ > which should give people some idea how many errors > there are in the older PG texts. [this is cross versioning, > of course, so some of these differences are legitimate, > such as spelling of character names "Jo" v. "Joe" > for example.] it could be the case that every single one of those diffs is actually a "legitimate" difference between the versions. and you have no way of proving that that is not the case. especially since you haven't provided a way for people to easily check that _your_ text is accurate to the scan. _or_ to verify the widger text is inaccurate to _its_ scan. which, by the way, is going to be _very_ difficult to do, since david has never specified which edition he used. and yes, since david never bothered to do that, people will _not_ take his digitization seriously down the line. but they are not going to like _your_ pg#32325 either, not if they don't know what version you used, but also because i've posted a version of it that makes it _easy_ to compare the text directly to the relevant page-scan. it boils down to this: if you believe in your accuracy, you will expose yourself to the test of transparency... you'll post the text, with its original line-breaks, right next to the page-scan from which that text was taken, coming from a scan-set which is canonically mounted. anything short of that is gonna be too little, too late. people are not going to jump through hoops just to verify the accuracy of your text, so even if it happens to _be_ accurate, you won't have sufficient evidence. so if you _don't_ expose yourself, nobody is going to believe that your text is accurate, not in the long run. -bowerbird p.s. that's if people _care_ about accuracy long-run. they are currently drowning in so much _inaccuracy_ they might just tune it all out and go to the movies, where they know it's all fake and they like it that way.

1 0

too bad he pooped out
by Bowerbird＠aol.com 11 Nov '12

11 Nov '12

it's really too bad that jim pooped out just when he was about to make his version of "huck finn" more valuable by allowing each page of the text to be directly compared to the relevant scan. so i did the work to restore pagebreaks. and then mounted the book in my interface: > http://zenmagiclove.com/huckj/wisdom.py as usual, you can adjust the size of the scan in your browser by resizing the window, and, of course, by the various other zoom modes. jim's errors are, for the most part, still there. as are any new ones which i have introduced. plus the end-line hyphenates were joined, so verisimilitude is not exactly what it should be. but i'd say that the main point has been made. -bowerbird

2 1

Re: [gutvol-d] about to finish up with huck
by Bowerbird＠aol.com 09 Nov '12

09 Nov '12

gee, jim, even when i specifically frame the issue, you seem incapable of acting in an intelligent way. the time-stamps _prove_ you spent _less_ than 10 minutes reading my post, thinking about it, and composing a reply. perhaps you need to read a little bit more carefully, and think about the conversation a little bit more thoughtfully. (right. like that's ever gonna happen. nice try, bird.) > Sure you are BB, go back and reread what you wrote > way back when I introduced this tool to this thread. i'm quite sure i was supportive of unwrappers back then, because i have _always_ been supportive of unwrapping... > Not at all, its trivial to find where a line of text > matches are particular page "matches are particular page"? what does that mean? > Not at all, its trivial to find where a line of text > matches are particular page since any modern > text display tool, including DJVU and PDF/A displays > include a "find" option to allow you to search on text. when the text was embedded in the .djvu or .pdf, yes... but that's not always the case. besides, you're then advocating that a search be run -- with the person entering a chunk of text from the line -- for every line you want to check. that's not optimal. i've done it that way. after a while, it gets to be painful. it's doable. but it's a far cry from being the _best_ way. (especially since you're juggling different applications.) it's far better to set up some kind of search criteria -- "show misspelled words", or "show italicized words" -- and have the tool automatically summon the scan for the appropriate page at the next hit on the search. (just the fact that you've integrated your text-handler and your scan-handler into _one_ app is a huge win.) the way you do it might "work", but it's not _efficient_, in the sense that it would scale into a process that can handle hundreds of books, let alone tens of thousands, in a way that the human cost justifies the digital benefit. (and you know we have millions of books online, right?) oh, and by the way, maybe just maybe if jim would have spent a minute to think about it, he would have realized that the reason a text-search in .djvu or .pdf _can_ lead you to the page-scan that contains that text is _precisely_ because those formats _retain_ that page-number info... if they tossed it out, the same way that jim tosses it out, then they would be in the same situation that he is in... then again, maybe just maybe jim could've spent _years_ thinking about that issue, and never had that realization. > Again, BB, the problem is that you live > in a BB-centric world where you believe > that the BB-approach is the "only way to fly." well, that certainly added to the value of this dialog, jim. (oh, and jim?, it's a good thing that .djvu and .pdf _also_ seem to live in my bb-centric world where we keep track of the relationship between every line of text and its scan, or you wouldn't have had anything idiotic to say up above.) > Well, again, PG could start by fixing their > on-going paragraph formatting problems. > That ain't exactly a high-tech problem! right after -- and i mean _right_after_ -- you talked about me "living in my own world", you went off and climbed up on your good ol' paragraph hobby-horse. i guess anything that allows you to make a connection, no matter how tenuous, to go off and ride that thing is all that you need, jim. but hey, at least we're done here. -bowerbird

1 0

Re: [gutvol-d] about to finish up with huck
by Bowerbird＠aol.com 09 Nov '12

09 Nov '12

jim said: > You are only interested in > wasting other people's time. jim, i think it's quite amusing, and very interesting, to be reminded why i stopped talking to you at all... because you act so idiotically some times. actually, make that _most_ of the time. so even when you make good points -- and you do, at times, make good points -- it's still not worthwhile to step through the manure of your obstacle-course... the new version of your text that you created there doesn't do _me_ any good. but it does lots for _you_. so i didn't "waste" your time. it's the exact opposite. to the contrary, i had you engage in a little task that upped the value _considerably_ for your pg#32325... (at least for the people who can locate your new file, and know that it has value in relation to pg#32325.) because now your "huck" can be directly compared to a scan-set archive.org essentially makes "canonical", by virtue of its being known and available world-wide. in comparison, the pg-rewrapped version of that text -- albeit otherwise exactly the same -- is _worthless._ so you didn't "waste" your time. you spent it _wisely_. > I seem to remember Marcello expressed an interest in it > [if only like BB to tear down the efforts of other] again, jim, stop with the idiotic actions/expressions. because, you know, if you do _enough_ idiotic things, people will start to _call_ you an idiot. for good reason. because only an idiot will do idiotic things _repeatedly._ i try to avoid such an attribution, because it is based on your _personality_, rather than your _actions_ -- like christians say, "hate the sin, but love the sinner" -- but you know that when you persist, it's difficult... so... i am certainly not "tearing down your efforts"... indeed, i'm just about the only person here who is making any argument that an unwrapper is useful. > for simple tasks such as unwrapping Huck it takes > literally about two seconds when run on a slow machine unwrapping could take two hours, and still be worthwhile. since it could save people about twenty hours in proofing. (and since we're talking about two hours for the computer, while we are off having a long lunch or a nice dinner, then it's merely a good excuse for a long lunch or a nice dinner.) > http://freekindlebooks.org/Dev/32325_unwrap.txt great. except that doesn't have any pagebreaks in it. makes it hard to check a line of text with the pagescan if you don't know what page the line of text occurs on... so, you know, you missed the whole point of the exercise. > I leave you to do the pagebreaks, why would i do them? i'm not interested in your e-book. > I leave you to do the pagebreaks, > if you were actually really interested, > which you aren't. i'm not interested in making your e-book more valuable. why would i be? i'm interested in the general question of what p.g. needs to do to make its e-books valuable enough to care about. but any particular book? well, not so much. especially not your version of "huck", since i already have _my_ version of "huck", which i know is the superior one... remember? i found a bunch of italics you had missed? > The point being that you keep trying to claim that > wrapping/unwrapping is some kind of impediment. i don't need to "claim" there is value in the ability to verify some digital text by comparing it to the relevant pagescan in a manner that is as direct as possible. that's _obvious_. the benefit derived from such functionality is clear and huge. only idiots would try to contest the worth of that capability. and yes, without any shred of doubt _whatsoever,_ having rewrapped text does indeed hinder such direct comparison. so, again, only an idiot would ever question that assertion. now, whether unwrapping can be done in such a way that it is so quick-and-easy that it fails to be any "impediment", i'm wide open to being convinced of that. i _hope_ it's true. but i've spent enough time unwrapping text that i'm skeptical you have made it quick-and-easy enough for "anyone" to do. but again, i _hope_ you have. i _want_ to believe you. i do. still, you haven't yet shown that to us. you've shown us that _you_ can do it. not that _anyone_ can. don't get me wrong. it's a great first-step. and it provides fantastic promise that we _could_ make it easy for anyone... but it's only the first step of the journey, not the end-point. you need to have other people do it, and say "it was easy", if you want to be convincing with your assertion that it's so. as it is, you have left much of your process enshrouded. we know that one of your files was the p.g. text. but what was the file that gave you the linebreaks? what kind of prep did you need to do to these files? (as a for-instance, did you delete the p.g. legalese?) how long did prep take? the entire process? and so on. give us the answers to these types of questions, jim, and have someone else do it, so we can hear their answers... > The point being that you keep trying to claim that > wrapping/unwrapping is some kind of impediment. it _is_. anything that gets in the way is an impediment. show us that you can _remove_ that impediment easily. > The point being that you keep trying to claim that > wrapping/unwrapping is some kind of impediment. > It isn't. Neither are pagebreaks, obviously, > because if one can put back in the original whitespace > known as "linebreaks" then it is even more trivial to > put back original whitespace known as "pagebreaks" and again, if it's _trivial_, then why didn't you do it? > which your workflow is interested am, and I am not. if you're uninterested in creating the best workflow, what are you even doing in this conversation at all? > You are only interested in wasting other people's time. the only waste of time that's happening here, now, is the one where i'm wasting my time responding to you. if you want to be productive, jim, you can do any of these: 1. restore the pagebreaks to the file you just made. 2. document the process you used to unwrap "huck". 3. write up a manual for your unwrapping program. 4. publicize your unwrapping program to the world. 5. rewrite your unwrapping program as a web-app. 6. describe the pseudo-code used in your program. and again, jim, just so i don't have to say it -- again! -- in my _next_ reply to you, should i be stupid enough to disregard the task of extraction from the adkins tar-pit, i know fully well that it's _possible_ to do unwrapping... i have done it, myself, countless times. i also know that the task can be relatively simple (emphasize "relatively"), because sometimes i have been able to make it simple... (i also know that sometimes it can be a bear.) _further_, i ascribe value to unwrapping, and will _welcome_ a tool that makes the task more quick and easy and transparent. i care about this; i spend my _own_ time on these matters. i may be the _only_ person on this list who cares about it. so don't take the stupid route of arguing these points, jim. because i don't have the patience to let you waste my time. if you want to do any of the 6 things above, then have at it. otherwise, opt out. -bowerbird

2 1

Re: [gutvol-d] about to finish up with huck
by Bowerbird＠aol.com 09 Nov '12

09 Nov '12

i said: > even there, the information isn't _that_ useful, > primarily because it's extremely difficult to > proof a rewrapped text against its scan-set. jim said: > It would be if there weren't software to > automatically unwrap the wrapped text. well, except your program doesn't run on my machine, jim. :+) besides, i don't think you've released your program, have you? not even to the list here, let alone to the world at large. right? further, although i have written such a program several times, i am still not satisfied that it is friendly and transparent enough, even for the relatively sophisticated person i'd expect as a user. and the brief exposure i had to some output from your program seemed like it was even more unfriendly than what mine gives... so i'm kinda skeptical. but fine, i'm always open for a demo. wrap your p.g. version of huck to the scan-set you used. better yet, give your app to someone else, and write up instructions for them (and all of us) how they can do it. don't forget that you need to include the pagebreaks too. and it would be best if you got the end-line-hyphenates exactly right, but it's ok if you join them on the top line or the bottom line, as long as it's consistent throughout. you just do the text. i'll code a tool to splice in the scans. take your time, jim. but if it's as quick-and-easy as you say... -bowerbird

2 1

about to finish up with huck
by Bowerbird＠aol.com 08 Nov '12

08 Nov '12

i said: > so it appears italics might be harder than we think. > even two passes, or three!, doesn't assure success. carlo said: > Something that DP discovered in 2004, and has led to the 2005 > reorganization making proofreading and markup separate tasks. um, perhaps i wasn't clear, or maybe carlo just missed the point, but i was saying that, even when we limit the focus to formatting, heck even _just_ italics, two or three passes might not be enough. now, if he needs me to be even more blunt, i'll say for carlo that even the two rounds of formatting at d.p. _might_ not be enough to assure a questioning observer that all of the italics were found. (and in case anyone might want to include the proofing rounds, you should know that proofers are instructed _not_ to do _any_ marking of italics, an instruction which is enforced quite strictly; moreover, many of the formatters _remove_ formatting that was done by proofers; there's even a button to erase it automatically.) i don't believe anyone has checked d.p. output thoroughly enough to make a judgment as to the completeness of their italics markup. (and here i'm not talking about the so-called "semantic" markup of italics which the so-called "best practices" document over there is now trying to install. i mean _missing_ the markup, _completely_.) so, no, carlo, your observation here has no relevance to my point... *** i understand that jim has informed the list which scan-set he used for his "huck". that's good information. but i don't intend to use it. my intent wasn't to criticize his performance, or in any way judge it. i don't think he did worse than any regular person, certainly not me. (i haven't even done a systematic search for italics myself, and won't. because i know i'm not too good at it; learned that a long time back.) the point is, though, that it doesn't do any good for this list to know the scan-set he used; that information needs to be in the p.g. e-text. and even there, the information isn't _that_ useful, primarily because it's extremely difficult to proof a rewrapped text against its scan-set. in other words, it's not enough to just tell us the scan-set you used. unless you give the end-users a version of your text which they can quickly and easily compare to the scan-set, they'll gravitate toward the entities that _do_ give them the basic capability of confirmation. but once again, i'm getting slightly ahead of myself. so, until later... -bowerbird p.s. robert, are you getting all your markup questions answered? because this probably isn't the best place to be asking about what needs to be done to make stuff work in the world of .epub/.mobi. i suggest you instead follow the #eprdctn twitter hashtag, which is used by people who are actually marking up e-books for a living...

2 1