- gutvol-d - lists.pglaf.org

rewrapping p.g. to an existing scan-set
by Bowerbird＠aol.com 16 Feb '12

16 Feb '12

focus, kids, focus. think about the objective here. so... why would we want to rewrap a p.g. text to an existing scan-set? well, for two main reasons: 1. to re-proof and correct the text with the scan-set. 2. to use the scan-set as the provenance for the text. the good news is that we only have to do this rewrap _once_ for a book, and we can assume that we'll have volunteers with a reasonable level of skill for the task, so it doesn't have to be idiot-proof or fully automatic. the bad news is that we need to do it for 20,000 books, so the job _can't_ require _too_ much time or energy... moreover, in order to be used in a proofing interface, the output of the rewrap needs to be in a certain form. but the parameters are wide open; as long as you can make your output work in your proofing system, fine. the perspectives offered so far, by jim and carlo, are quite instructive, in terms of striking the right balance. jim commented that the two versions are very similar, while carlo noted that there are many small differences. to my mind, this is exactly how to walk this tightrope... while i would prefer to have the exact same edition of the scan-set/paper-book used to create the text-file, we can never be sure with the project gutenberg files. so if the editions are "reasonably close", that'll be fine. indeed, if they're close enough, but clearly different, then we've gained additional information concerning edits that were made from one edition to the other... (scholars, in particular, go nuts for that type of stuff.) and even as we "correct" the text version into a file which reflects the scan-set -- i.e., _change_it_ from one edition into the other edition -- we'll still keep the original text around, to be used as soon as the scan-set from its actual parent-edition shows up... (this assumes that it was not some mutant hybrid.) the main takeaway here is that the output from the rewrap must be amenable to a proofing interface... and the process can require _some_ expertise, but it can't be one that needs too much time or energy. so, i'll see if i can work through carlo's instructions, and i'll prepare my output for posting, and then we can discuss this some more, probably next week... -bowerbird

1 0

HTML and text statistics
by Robert Gibbins 15 Feb '12

15 Feb '12

Having recently downloaded the PG 2010 DVD (thank you very much PG), I started looking at the books: - The DVD seems to contain about 34,000 zip files. - A small number of these (about 50) seem to be zipped mp3 files (*m.zip). - About 1800 files seem to be zipped html files (*h.zip). Does this mean that PG (at that time) only had about 1800 'real' (as opposed to generated-from-the-text-file) html books, or have I misunderstood something? Presumably many more books have been added since, I think I recall an append from Greg that the number is now more like 40,000, and I get the impression that most of these will come from DP and have html versions. But even so this seems to imply that there are about 28-30,000 books as text files for which no html version exists other than the generated one. Is this number about right? or have I missed something obvious? Bob Gibbins

5 4

Thoughts on Page Images at PG
by Jana Srna 15 Feb '12

15 Feb '12

Hi again, First of all, let me make a suggestion. Greg said there are about 7000 books, if I remember correctly, for which PG has page images. Unfortunately, no-one actually knows about this, and it's hard to find the page images even if one does. It's a hassle to find out for which books they are there, and for which they aren't. Could we perhaps get a line added to the list of available file types, in the catalogue, for books with page images? Something like "Page Images ZIP", that will let you directly download the page images zip file from the book's overview page, instead of having to go through the “More Files…” link and the directory listing there? Secondly, I have noticed an inconsistency in the page images for different books. For the books that got them added back when we (some DP volunteers) uploaded them in bulk, there is only the xxxxx-page-images directory, but no zip file. Here's an example: http://www.gutenberg.org/files/21989/ For the books that Al has posted for me a few days ago (thanks, Al!), there is both that directory, and a zip of it. Here's an example: http://www.gutenberg.org/files/38402/ Why the difference? Personally, I find the zip file more valuable than the directory, so would hope that those could easily be created for the books that don't have them. I do, however, understand that that would take up more disk space, so might not be possible. It would also, perhaps, be possible to combine my first suggestion with this one, and add a line to the book overview page as stated above, but have that point to a script that will create the zip file on the fly (just like the ones for the epubs and mobis and such)—and just cache it for, say, a day, instead of having all those zip files lie around on disk, in addition to the directories. Jana

5 4

the word that best describes it
by Bowerbird＠aol.com 15 Feb '12

15 Feb '12

ok, first i wasn't gonna even write this. but then i decided that i had to write it. and then i decided that i wouldn't send it. but now i've decided that i have to send it. but oh lord, i am so tired of the merry-go-round, and re-assert my resolution to get off of the thing. i mean, i do love to say "i told you so", a lot, but after a while, even _that_ gets old. but you guys need to be reminded of the facts of this matter... so i must... *** al said: > This is the convention used by Joshua Hutchinson, > when he provided page scans from DP: oh please. these lame attempts to rewrite history by reporting it selectively are a demand for a slapdown. that file-naming convention is one that _i_ developed, which josh then bastardized because he didn't grok it. and let's not forget that i had to rail for _years_ to install this common-sense file-naming convention, fighting _against_ josh and david "donovan" garcia and _many_ others over at distributed proofreaders, where some idiots _still_ use other naming schemes since d.p. doesn't demand consistent common-sense. (just in case you thought that flaw was unique to p.g.) the archives will prove that this fight lasted for years. ** so, what was the fight about? the basic notion is that the filename for a scan should include the pagenumber of the page the scan captured. d.p. doesn't require this, so there was some question about whether p.g. should also be lax in that regard, and whether d.p. should be "encouraged" to change... as i recently showed, d.p. still allows bad file-naming. you might remember i pointed to scans from the first 8 pages of "when it was dark", which is now at d.p.: > http://zenmagiclove.com/pgstupidity/012.png > http://zenmagiclove.com/pgstupidity/013.png > http://zenmagiclove.com/pgstupidity/014.png > http://zenmagiclove.com/pgstupidity/015.png > http://zenmagiclove.com/pgstupidity/016.png > http://zenmagiclove.com/pgstupidity/017.png > http://zenmagiclove.com/pgstupidity/018.png > http://zenmagiclove.com/pgstupidity/019.png so the scan for page 1 is named "012.png". and the scan for page 2 is name "013.png". and the scan for page 3 is name "014.png". and so on. it's smarter to name the scan for page 1 as "001.png". page 2 will be "002.png", and "003.png" is page 3, etc. and yes, people fought against me for _years_ on this. *** that's right -- i had to _fight_, for _years_and_years_, to get common-sense to prevail. i consider this to be a _victory_, since -- in this one case, anyway -- it did! there are too many others where a fight still goes on... but anyway, so we're in the middle of a years-long fight about this file-naming convention, or the _lack_ of it... over time, i've written up lots of careful documentation for the way that the convention _should_ be construed. and then one day, josh rewrote my careful system, adding a few twists of his own (which screwed it up), and everybody shifted to support "josh's proposal". as if he had invented it. yeah, right. ok, boys, do it your way. you assholes. *** and just to give a flavor of some of the other history around this issue, the page-scan-submission process was the genesis for don kretz writing his "twisted" app. since d.p. refused to require its content providers use smart file-naming in the beginning, there were lots of scan-sets around (then, and now) with bad filenames, so don wrote this tool for people uploading scan-sets. it was originally called "twister", and its purpose was to aid in the file-renaming process. after coding that, don realized it was relatively simple to extend the app, to the point he had turned it into a very good start on a postprocessing program. unfortunately, the "powers" over at d.p. turned their noses up at it, so it never got the adoption that it should have, and d.p. was the loser. and the postprocessing queue lingers to this very day... *** as for the issue of "omnibus" editions -- ones which combine input from several p-books -- i'll say this... in 1992, omnibus editions made sense. for instance, "alice in wonderland" has a few places where it says "later editions added this" and it gives the addition... in that place and time, that was the perfect solution. it would've been stupid to create two different texts, which differed by only a few lines, absolutely stupid. 15 years ago, 1997, omnibus editions still made sense. scans were rare, and even when available, o.c.r. stunk. 10 years ago, 2002, they still made sense. that's why i staunchly defended you, greg, and michael hart, and p.g. in general, when some people (like jon noring and lee passey) were attacking you relentlessly because you weren't being "faithful" to this or that canonical version. o.c.r. had gotten better, and scans were more prevalent, but bandwidth still presented a large logistical obstacle. 5 years ago, 2007, google books and archive.org were still trying to establish a solid footprint on the ground, so omnibus editions could still argue they made sense. but we were starting to swim in scan-sets, and even the longstanding bandwidth logjam was promising to clear. so, today -- 2012 -- there is no argument that can be made in support of an omnibus edition. not any at all. "our policy is what it always was -- it hasn't changed" is hollow once we grant that the world _has_ changed. i've always said that, if the text was indeed based on a specific edition, and p.g. had scans for that edition, you should mount them. (again, just common sense!) indeed, it was my support for _that_ position which led jon noring to say "see, even bowerbird agrees with me" at the 10,000 celebration in san francisco back in 2003. (of course, in typical noring style, jon refused to see that i did _not_ agree with his overall position, which was that p.g. should cease making omnibus editions entirely, and base every book on one specific scan-set, and mount it. i only supported it _if_ a text was based on one p-book.) now, for many books, we have scan-sets for all versions. so project gutenberg needs to point to _one_ scan-set that's "the one" for each and every particular p.g. e-text. the alternative -- that a p.g. e-text is "another" version, but one which has no relationship to any printed book -- dooms the p.g. text to being neglected, then ostracized, because it pretends to document the past, but it cannot point to anything tangible as a proof of its provenance, while the scan-sets sitting online are self-documenting. *** carlo said: > I have two books that are really weird: weird is not a problem. > one in which the page numbers > are out of order in the original the numbers which are actually printed on the pages can be printed in error, just like anything else that's printed. so, were the pages _bound_ in the incorrect order? if so, you should fix that error by rearranging them. but if the content appears in the proper sequence, then it is the _pagenumbers_ which were incorrect, and you would correct that error by changing them. you might also leave a note, to explain the situation, so users aren't confused by the apparent discrepancy. > and another in which a signature > repeats the numbers of a previous one > (after 1...208, we have 197a....208a, > then 209...285). this one is clearly an error. you should renumber the second sequence. in this case, since the extra pages _followed_ page 208, rename them this way: > 197a -> 208a > 198a -> 208a > 199a -> 208c > 200a -> 208d > 201a -> 208e > 202a -> 208f > 203a -> 208g > 204a -> 208h > 205a -> 208i > 206a -> 208j > 207a -> 208k > 208a -> 208l as i will discuss shortly, one purpose of the filenames is to represent the binding order, via a sort of them... and that is the principle which is behind this solution. *** al said: > This is the convention used by Joshua Hutchinson, > when he provided page scans from DP: yeah, right. ok, so let's take a look, shall we? > Basic format: > The prefix for the cover pages is: "c". > The prefix for the roman pages is: "f". > The prefix for the arabic pages is: "p". so far, so good. but, for the record, i had to fight like a dog to get even something as basic as _this_ accepted. really! even after people accepted the general idea that the pagenumber should be reflected in the name, some of 'em wanted to name the cover as "cover", and "back-cover", and "spine", and what have you. they couldn't understand something as simple as _a_need_for_names_to_reflect_the_binding_order_. some of them wanted to prefix the front-matter with "r", to represent the "roman" numerals there. but of course then those files would sort _after_ the "p" prefix that everyone agreed on for "page". but these idiots couldn't grok that simple notion. *** > For blank pages there should be no file > and the page number should be skipped. wrong. wrong wrong wrong. you need to include a file for _every_ page in the book, or else you will ruin the verso/recto left/right nature of the spread. just goes to show how josh failed to grok the basics. and "skipping" is just a big invitation for disaster. because then when you lose a file for any reason, people will just assume that it was a blank page... if a book does _skip_ pagenumbers, you should inject images into that range that inform users "the book skipped pagenumbers at this point", again taking care to preserve your verso/recto. > Optionally an image saying: > "This page is blank in the original." > may be inserted. well, this isn't a "bad" thing to do. but neither is it a _necessary_ one. a blank scan speaks for itself... indeed, if you do things right, the space used by a blank-page scan should make it obvious that that specific page was indeed blank in the book. so a simple look at the size of your scans would be enough to tell an app which pages are blank. > Example of file naming: > front cover c0001.png > back cover c0002.png > spine c0003.png again, more evidence of josh's utter stupidity. the back cover should be given a name that will sort it _after_ regular "p"-prefix pages. (and also after all of the back-matter pages.) c002 must be used for the inside front cover. yes, folks, if you're going to scan the cover, you must scan the verso of the cover as well. indeed, for _any_ thing you scan, you _must_ scan the recto side first, and then the verso, because we need to be able to show spreads. which means that the only logical name for a scan of the spine is the last one in the bunch. (if, as usual, the inside front cover is blank, you should substitute in a table-of-contents. in general, you can substitute in _anything_ that'll be useful to people, for a blank page.) > i title page f0001.png > ii title verso f0002.png > iii dedication f0003.png > iv is blank > v contents f0005.png idiots. oh, and the title-page is usually _not_ roman i. if you really have a roman i (for 1), and the title-page comes before it, then you should use the "c" prefix for the title and its verso. > page 1 p0001.png > page 2 p0002.png > image on page 2 p0002-image1.png > image on page 2 p0002-image2.png > page 3 p0003.png wrong wrong wrong wrong wrong wrong wrong. the image-files for images on a page must be kept separate from the page-scans themselves. not necessarily in another folder -- since that spoils the good idea of all files in one folder) -- but _definitely_ with a different naming scheme, one which sorts those names to a different place, out of the sorting for recto-verso binding-order. *** al doesn't mention another shortcoming of the system that josh "borrowed" (so badly) from me. for any unnumbered "tip-in" illustration pages, my systems had the filenames append a letter... so, for a tip-in between, say, pages 198 and 199: > 196.png > 197.png > 198.png > 198a.png > 198b.png > 199.png > 200.png > 201.png you'll notice this is what i suggested to carlo above. pretty straightforward, eh? hard to screw it up, yes? well, no, not for josh, apparently. he did it like so: > 196.png > 197.png > 198.png > 198-a.png > 198-b.png > 199.png > 200.png > 201.png looks pretty close, don't you think? well, you're wrong. because if you sort those names, you'll find that they don't sort in that order, not on most systems anyway. try it, and you will see that they sort like this instead: > 196.png > 197.png > 198-a.png > 198-b.png > 198.png > 199.png > 200.png > 201.png with that sort, we've destroyed the p197-p198 spread. and, of course, we've rearranged the content's order... it's funny how not understanding something fully leads an amateur to make a fundamental mistake. *** and a couple other notes about stupidities here, which are not just "after-thoughts", but actually are aimed at the _most_ stupid things about this. first, it's stupid to pad the numbers to _4_ digits. since very, very few books go over 1,000 pages... so padding to 4 digits is unnecessary. it is also unsightly. but _worst_ of all, it's ungainly when people have to _type_ it, when they enter a u.r.l. in the extremely rare cases where pagenumbers go over 1000, you just switch from "p" to "q" as the preface, and bingo, you're back in business. (you might even wanna reserve "q" to mean that.) but the most stupid thing of all is something that you can't even see here, because it's _not_ here... one of the most important rules for file-naming -- indeed, it's probably the _cardinal_ rule! -- is that a filename must be unique to its content. a filename _must_ point unequivocally to one thing. the reverse angle -- that each thing must have one and only one filename -- is a good _goal_, even though there are some worthy exceptions. but there is _no_exception_ to the cardinal rule: a filename must point unwaveringly to one thing. or, to put this in a different way, different content _must_always_ have a filename which reflects that. or, yet another way: _different_stuff_must_never_have_the_same_name._ if you look at p.g. image-files, however, you will discover that it has tons of different files that all have been given the same name -- p0001.png... likewise, you will find a ton of p0002.png, and p0003.png, and p0004.png, and p0005.png... it's stupid. it's ridiculous. it's ridiculously stupid. please don't demonstrate your stupidity by trying to argue that this is acceptable, because "the files are in different folders". that shows you miss the point. besides, it just so happens that the _folders_ have _the_same_name_as_well_, for yet another violation. so to differentiate one p0001.png from another, you need the parent-folder name of the parent-folder... holy batman, talk about abstracting the abstraction! and the whole point is that you need to overcome the possibility of confusion in the event that your files are copied to the wrong folder. or to the _same_ folder... a solution is easy. append the 5-digit pg# to each file. so the files for pg#12345 might be named like this; > 12345-f001.png > 12345-f002.png > 12345-f003.png > 12345-p001.png > 12345-p002.png > 12345-p003.png > 12345-p004.png see how easy that is? take a good close look at it... so, did you take a good close look? really? if you did, you should have spotted a bad _error_... i had "12345-f003.png", but no "12345-f004.png". remember, we have to maintain the page-spreads... back to the point, though. this way if these files were to be accidentally copied into the folder for pg#23456, we'd know immediately, and nothing'd be overwritten. with non-unique filenames, you will have a mess and you won't even know right away that you screwed up... *** like i said, getting the pagenumber put in the filename was a _huge_ victory for me, one that i fought hard for, so i'm glad there was _some_ benefit from all my work. but if y'all think you did it right, you're badly mistaken. *** and finally, a few more things, while i'm at it... some of my antagonists try to have a field day with "oh, that bowerbird, he thinks he's so damn smart". and even some newcomers might be led to agree. well, first off, much of this is just _common_sense_. now, if you don't have enough basic intelligence to recognize _common_sense_ kicking you in the shin, don't try and blame me that you are such a retard... and second, the things which aren't "common sense" are things i learned from my _hard-won_ experience. you think i haven't screwed up, and given non-unique names to different stuff, and then overwritten the new with the old? think again. i've done it. several times. enough times that i _learned_ it is a mistake to break the cardinal rule, which is why it _is_ the cardinal rule. if you guys were smart, you'd learn from my mistakes. when i say "you sure don't wanna be doing it that way," you should be able to hear the pain of my experience. and when you ignore me, i just laugh at you, because i know the pain of _your_ experience _will_ teach you. the other thing is "that bowerbird is such a rude guy". and again, i can see newcomers feeling that way too... well, listen up. i explained _all_ of these things nicely. i was polite the first time, and the second, the third, fourth, fifth, and sixth. i was always calm and careful. i am _still_ calm and careful, to this very day, mind you. but -- after a dozen careful and calm expositions that explain little more than common sense and experience, and which were met with knock-down-drag-out _fights_, where i was insulted and my reputation was maligned -- it's no wonder that i've now developed the attitude that i will call _stupidity_ by the word that best describes it... and that is also why i rub it in and say "i told you so..." so if any of you want to indignantly label that as "rude", then i'll humbly suggest that you can take up the issue with the goddesses of honesty and integrity and truth... -bowerbird

1 0

six weeks
by Bowerbird＠aol.com 15 Feb '12

15 Feb '12

six weeks into the cone of silence... -bowerbird

1 0

Re: [gutvol-d] Thoughts on Page Images at PG
by Bowerbird＠aol.com 15 Feb '12

15 Feb '12

don said: > Is anyone other than you familiar with all this magic? does anyone besides the webmaster need any knowledge of such trivia? no. and if you wanted to glorify it, you _could_ call it "technical details". but it is assuredly _not_ "magic", nor anywhere close to that... servers these days automatically compress whatever they send, and your browser then decompresses it at your end; it's faster and uses less bandwidth -- one and the same... with a pre-compressed version of everything, the server is saved the time and cost of doing the compression, which adds up to an amount that can be significant if you serve lots of stuff. but that's all back-end crap, and has nothing to do with the picture you paint on the front, which orients people to your content inside... everyone who thinks about it for a minute will agree that you need to have addressable u.r.l. for each scan, and they should be predictable, from being the result of a known, dependable naming scheme which is simple to understand. how the files are stored is a different matter... what matters to the end-user is what they see, and how they grok it, and get what they want... -bowerbird

1 0

Re: [gutvol-d] Thoughts on Page Images at PG
by don kretz 15 Feb '12

15 Feb '12

Is anyone other than you familiar with all this magic? PG is a little like one big Easter egg hunt. Sent from my Windows Phone From: Marcello Perathoner Sent: 2/15/2012 9:12 To: traverso(a)dm.unipi.it; Project Gutenberg Volunteer Discussion Subject: Re: [gutvol-d] Thoughts on Page Images at PG On 02/15/2012 05:37 PM, Carlo Traverso wrote: >>>>>> "Jana" == Jana Srna<jana.srna(a)gmail.com> writes: > > Jana> Secondly, I have noticed an inconsistency in the page images > Jana> for different books. For the books that got them added back > Jana> when we (some DP volunteers) uploaded them in bulk, there is > Jana> only the xxxxx-page-images directory, but no zip file. > Jana> Here's an example: http://www.gutenberg.org/files/21989/ > > Jana> For the books that Al has posted for me a few days ago > Jana> (thanks, Al!), there is both that directory, and a zip of > Jana> it. Here's an example: > Jana> http://www.gutenberg.org/files/38402/ > > Jana> Why the difference? Personally, I find the zip file more > Jana> valuable than the directory, so would hope that those could > Jana> easily be created for the books that don't have them. I do, > Jana> however, understand that that would take up more disk space, > Jana> so might not be possible. > > The individual files are more valuable if one wants to check a > possible error, since one does not need to download the full zip file, > just to look at one page. You can get the individual files even if you post the zip only. The web server does all unpacking for you. In fact, for every file you get from gutenberg.org, you get the bits out of the zip file and not out of the uncompressed file that is stored along the zip file. (The server would have to compress those bits for every request, while inside the zip file the compressed bits are up for grabs.) All you need is an index of images to post along the zip file, like we do for audio files, and you save half the disk space. -- Marcello Perathoner webmaster(a)gutenberg.org _______________________________________________ gutvol-d mailing list gutvol-d(a)lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d

2 3

Re: [gutvol-d] Thoughts on Page Images at PG
by don kretz 15 Feb '12

15 Feb '12

The cost of storing it is dropping several times as quickly as pg is adding to it. In the formats they are provided the amount of space saved is I would think negligible by zipping them. And perhaps the detailed description of the required format could be reconsidered. The document to me is written to optimize the preferences of pg at one point in time without much consideration for user effort required. wouldn't you get better compliance and more images if you just asked for what they have preferably with file names derived from page numbers? Unfortunately your primary provider has resisted supporting any such useful fi Sent from my Windows Phone From: Carlo Traverso Sent: 2/15/2012 8:38 To: gutvol-d(a)lists.pglaf.org Cc: gutvol-d(a)lists.pglaf.org Subject: Re: [gutvol-d] Thoughts on Page Images at PG >>>>> "Jana" == Jana Srna <jana.srna(a)gmail.com> writes: Jana> Secondly, I have noticed an inconsistency in the page images Jana> for different books. For the books that got them added back Jana> when we (some DP volunteers) uploaded them in bulk, there is Jana> only the xxxxx-page-images directory, but no zip file. Jana> Here's an example: http://www.gutenberg.org/files/21989/ Jana> For the books that Al has posted for me a few days ago Jana> (thanks, Al!), there is both that directory, and a zip of Jana> it. Here's an example: Jana> http://www.gutenberg.org/files/38402/ Jana> Why the difference? Personally, I find the zip file more Jana> valuable than the directory, so would hope that those could Jana> easily be created for the books that don't have them. I do, Jana> however, understand that that would take up more disk space, Jana> so might not be possible. The individual files are more valuable if one wants to check a possible error, since one does not need to download the full zip file, just to look at one page. Your images are 20 MB; assuming that this is representative of the collection, all the 40000 books could fit in one disk of 1 TB. The last time that I bought a pocket one, it costed me 90 Euro, so probably PG can afford two to keep the whole collection zipped and unzipped. But a few years ago, when they started to keep page images it costed much more. Carlo _______________________________________________ gutvol-d mailing list gutvol-d(a)lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d

1 0

Re: [gutvol-d] Thoughts on Page Images at PG
by Bowerbird＠aol.com 15 Feb '12

15 Feb '12

carlo said: > The individual files are more valuable > if one wants to check a possible error, > since one does not need to download > the full zip file, just to look at one page. and, more to the point, mounting them individually means that every page has its unique u.r.l. address pointing to it... you _could_ unzip one page, on-the-fly, and give each page an address that way; indeed, that's what internet archive does. but i think it's better to mount each one, and _zip_ 'em on-the-fly when necessary, as desired for downloading as a package. > Your images are 20 MB; assuming that > this is representative of the collection, > all the 40000 books could fit in one disk of 1 TB. there aren't 40,000 books. more like 30,000. but now that michael's gone, who's counting? > all the 40000 books could fit in one disk of 1 TB. and again, more to the point, my demo showing p.g. could grab the d.p. images via the backbone (and not force volunteers to do 2 slow re-routes) was a solution from a complete outsider like me... but p.g. and d.p. have an ongoing relationship, not? i mean, greg's on the p.g. board of directors, isn't he? so what they should _really_ do is buy a hard-disk and duplicate the entire contents of the d.p. site -- images, text, forums, all of it -- and then send that hard-disk to p.g., where the scans could be mounted the next day. plus d.p. would have another back-up. it's surprising that they haven't already done it, and mind-boggling that it hasn't even occurred to them, at least as far as you could tell from all appearances. > But a few years ago, when they started to > keep page images it costed much more. several policies seem not to have been revisited in many years now. p.g. is increasingly out-of-touch. and, as this very issue indicates so well, when it does try to update stuff, not much thought goes into things. -bowerbird p.s. so carlo, got your rewrap of p&p yet?

1 0

rewrapping p.g. to an existing scan-set
by Bowerbird＠aol.com 15 Feb '12

15 Feb '12

carlo said: > Much simpler, one can use wdiff (or dwdiff) > and preserve whitespace from one > and non-whitespace from the other > through regexp. I am interested in > comparing your tool with my wdiff approach. i'd love to see the results from both of you. and compare it to what my program can do, because, at least thus far in its development, my tool still needs considerable baby-sitting for the level of quality one needs to produce. i suggest everyone use their approach on the p.g. e-text for "pride and prejudice"... > http://www.gutenberg.org/cache/epub/1342/pg1342.txt let's mold it to this version at archive.org: > http://www.archive.org/details/prideprejudiceno00austuoft (or, if some other version was the basis for #1342, or you prefer it for any other reason, say so, and we can use that.) -bowerbird

2 1