- gutvol-d - lists.pglaf.org

Re: Reporting errors in PG files (was Dim view of P3ers)
by Bowerbird＠aol.com 18 Apr '10

18 Apr '10

al said: > An errata submission webform would be useful. > (Some emailed errata reports are sadly lacking in detail.) > Maybe sometime when Greg has a student intern? my gawd. what a bunch of idiots we have in charge here. who needs a "student intern" to create a darn web-form? i devised a whole error-reporting system for you to use. it's up on my site right now. *** as for the page-images, we have equivalent stupidity... the page-images for the books that d.p. processes are sitting at d.p. for the entire time that the book is there. p.g. could scrape them with the greatest of ease, _if_ it truly wanted them. why should anyone be forced to "submit" them? do we _enjoy_ wasting people's time? look... if y'all are too busy to do things correctly, fine. but at least empower somebody else to do the job, ok? because otherwise your stupidity starts to look _willful_. -bowerbird

1 0

Re: Reporting errors in PG files (was Dim view of P3ers)
by Bowerbird＠aol.com 18 Apr '10

18 Apr '10

greg said: > There is guidance for the file naming convention on images. evidently, as part of his general ignorance of what goes on here, dr. newby missed my recent devastating critique of this "convention". -bowerbird

1 0

Re: DP output is technically obsolete
by Bowerbird＠aol.com 18 Apr '10

18 Apr '10

boy oh boy, it must really be _painful_ to marcello that he has to now be saying the very same things that -- when i said them here for years and years -- he constantly disagreed with, and called me names. assholes really hate to admit that they were wrong... you know he had to resist it for a long time, but still, eventually, one just cannot dispute the truth, can one? *** greg said: > Having a single master format, from which > all subsidiary formats can be derived, has been > a long-time goal. This has not yet been viable > for most titles, despite valiant (and productive) > efforts with HTML and TeX. unfortunately, if you've been _ignoring_ what has happened here over the years -- as dr. newby has, evidently -- then you might not realize that i have already proven z.m.l. can be that "master format"... that's right, greg! while you've supposedly been "looking for" such a format, i've been right here, shoving it up under your nose. do you see it now? -bowerbird

1 0

Typesetting
by Michael McDermott 18 Apr '10

18 Apr '10

Like many I'm sure (all right, I'm not really sure), I like ebooks/etexts but do not like to read them on a computer screen. This is largely, no doubt, because I work with a computer all day anyway--a book should be a place to get away from it all for a little. The natural thing to do is to print the text out and read it. The question then is: how do we typeset it? The first thing I looked at was GutenMark. I was a little disappointed when I tried it on _Gods and Fighting Men_ by Lady Augusta Gregory. The LaTeX it generated was invalid. Then I took the HTML version of said book and ran it through HTML2PS. The results were serviceable, but looked like, well, a printed web page. a2ps worked in the most rudimentary sense. The font was still a fixed width font, the paragraphs were not reformatted, so there was a lot of unused space on the right hand side of the page. One of the last two would, of course, do in a pinch, but I was wondering whether anyone else here had any ideas/recipes on how to automatically or mostly-automatically typeset a PG etext for printing. -- Michael McDermott www.mad-computer-scientist.com

6 6

Re: Typesetting
by Bowerbird＠aol.com 18 Apr '10

18 Apr '10

michael said: > Gods and Fighting Men ok, just so we can all get "on the same page", i've run out a first draft of this book as a .pdf. > http://z-m-l.com/misc/14465-take5.pdf it's got some problems, notably with orphans, including more than one page with one word, but that's ok for the time being. michael, how would this .pdf fit your needs? (you'll need to print a few pages to evaluate.) what, if anything, would need to be changed? -bowerbird p.s. why can't people pick a _short_ book for demo purposes? long books clog the works...

3 2

Re: Typesetting (not really, but nobody seems to read subject-headers)
by Bowerbird＠aol.com 18 Apr '10

18 Apr '10

michael said: > Of course, it would all work out better if the minus came first-- hey, that's an idea. have p3 proof first, followed by p2, then p1. *** the p3 proofers asterisk the end-line-hyphenates because that's the one course of action guaranteed not to be wrong. moreover, it's the _only_ one that carries that promise. *** michael said: > there will be dozens, if not hundreds, of iPad eBook readers. and 3/4 of them will claim to support the .epub format, but yet no two of them will do it in the exact same way... but hey, aren't y'all glad that we have a _standard_? i am! *** um, and jim is right about one thing. there's no stanza on ipad. unless amazon changes its mind, and reverses its current stand. *** as for eyestrain, if you have it, explore the various solutions! because it _is_ possible for you to get rid of it, in most cases. it might mean buying better equipment, but not necessarily; the solution might be free, and easy, and improve your life... *** oh, and that .pdf i created? no comments? whatsamatter? is something like that too _tangible_ to be discussed here? -bowerbird

2 1

so let's talk about my collaborative proofreading site, part 3
by Bowerbird＠aol.com 18 Apr '10

18 Apr '10

here's more info on my collaborative proofreading site... *** to see what we're talking about, you can visit this u.r.l.: > http://z-m-l.com/go/sitka/editr.pl *** we've talked about 4 main topics: > navigating the pages... > certifying a page as clean... > searching the book for a string... > feel the power with the "command" field... under the 4th topic -- the command field -- we've discussed these commands you can issue: > showmap... > concat... > showcustom... > blubberbaby... > pairsearch... > end-page-hyphenates... today we'll discuss a few more commands... > copyfootnotes... > movefootnotes... > show-end-line-hyphenates... *** copyfootnotes... some e-book formats want the footnotes collected together into their own section (a la "endnotes")... to accomplish this, enter "copyfootnotes" into the search-field, and then click the "find" button... all of the footnotes will be presented on a screen, so you can copy them en masse. this command leaves the footnotes unmolested on their pages... *** movefootnotes... movefootnotes is another command that does the same as "copyfootnotes", except "movefootnotes" also deletes each footnote from its original page... i'll note that neither of these commands should be used until proofing has been completely finished. until that time, you want to leave the footnote in the one place where it can be most easily proofed, which is right there on that page, next to the scan. for the moment, i have disabled this command... once i've programmed the "mass revert" ability, to reverse any sabotage effort, i will reinstate it. *** show-end-line-hyphenates... you'll probably recall that i encourage people to _retain_ original linebreaks from the paper-book, expressly including all the end-line-hyphenates... this makes it much easier to do proofing, as even distributed proofreaders and project gutenberg acknowledge when it comes to _them_ proofing. (so why they rewrap their text before giving it to other people is a bit disingenuous; but i digress.) at any rate, one slight problem with this approach is that the hyphenated fragments often do _not_ pass spellcheck, and thus are unnecessarily flagged. for instance, you might have the first part of a frag- ment on the top line, and the second on the bottom, and neither "frag-" nor "ment" will pass spellcheck. this command helps you solve that little problem. "show-end-line-hyphenates" will list all of them, as you might expect, but it does a little bit more. first, it tests if the rejoined form passes spellcheck. if so, then it gives you both fragments, so that you can include them in the book's custom dictionary... this command also surveys the full book to see how many times the rejoined form appears in it -- with hyphen, without it, and as two words -- and informs you of the counts, which is good info. i restored all of the end-line-hyphenates on many pages within the "sitka" book, and you can observe the output from "show-end-line-hyphenates" here: > http://z-m-l.com/go/sitka/hyphenates-output.html *** while we're on the subject of end-line-hyphenates, i should briefly address one of the thorny matters... i've always maintained that users should be able to unwrap the text themselves, any time they wanted. indeed, i've said we should give them tools to do it. even more than _that,_ i've _provided_ such a tool: > http://z-m-l.com/go/unwrap.pl in most cases, an end-line-hyphenate is _easy_ to resolve. you eliminate the dash and then bring up the first string from the next line and concatenate it. simple enough. the glitch happens when it was a _compound_word_ -- i.e., a word that includes a dash in it _normally._ in word-processing parlance, this is known as the difference between a "hard" and a "soft" hyphen... so, in order to indicate to the unwrap routine that any particular dash at the end of a line is a "hard" hyphen, to be retained, we need to give it some kind of marker. i've decided -- tentative to testing for problems -- this marker will be the "~" character, after the dash. you can see cases in the sitka book where this happens: > http://z-m-l.com/go/sitka/editr.pl?bpn=sitkap007 > http://z-m-l.com/go/sitka/editr.pl?bpn=sitkap019 > http://z-m-l.com/go/sitka/editr.pl?bpn=sitkap093 > http://z-m-l.com/go/sitka/editr.pl?bpn=sitkap094 > http://z-m-l.com/go/sitka/editr.pl?bpn=sitkap094 > http://z-m-l.com/go/sitka/editr.pl?bpn=sitkap107 the lines from those 6 cases are listed here, respectively: > sions in America. The sails of ships from far-~ > off Kronstadt on the Baltic brought Russian > during the winter the hunters took 40 sea-~ > lions, and in the spring many seals were > of ancient Venice. The picturesque, dark-~ > skinned Thlingit women sit at the doors of > Russian fur warehouse. Next is the three-~ > story building used for courthouse and jail, > and later of the U.S. Marines from the Man-~ > of-War which was stationed here. East of > sea. Eastward crest after crest of glacier-~ > capped peaks rise for a hundred miles, so when these are unwrapped, the words "far-off" and "sea-lion" and "dark-skinned" and "three-story" and "man-of-war" and "glacier-capped" will now be rendered as they should be -- as compound words... *** based on my long observation, i'd say dehyphenation is one of the most _inelegant_ aspects of the d.p. system... first of all, it causes unnecessary work for the proofers, because it's more difficult to proof when the linebreaks have been disturbed in any way. even though the effect is relatively small when it's just on end-line-hyphenates, it still cumulates. (and the dictum against "unclothed" em-dashes at line-ends adds to this cumulative effect.) this shifting of original linebreaks causes line-lengths to become uneven, introducing a variety of problems in that some routines that _could_ be written to help process the text depend on line-lengths, and thus are sabotaged when we change the line-lengths arbitrarily. second, dehyphenation itself is work, because proofers (who do not have access to any book-wide information) have to make a judgment about whether the hyphen is to be retained or not, which is fraught with ambiguity... this leads to diffs, which chew even more proofer time. indeed, in the "perpetual" projects, we saw cases where one proofer would take out a hyphen, and another one would put it back with an asterisk (meaning "check it"). and then the third proofer would take out the asterisk! and of course, if a proofer makes a bad decision, that pollutes the text, which can lead to more bad decisions. decisions on all end-line-hyphenates should be made during preprocessing. then if the proofers challenge any of the decisions, the postprocessor can decide that. that's the only sensible workflow. and this "show-end-line-hyphenates" command shows that it is indeed possible to handle end-line-hyphenates in a manner that is simple, yet adequately sophisticated. *** so those are our 3 new commands for the weekend... more later... -bowerbird

8 15

!@! #17135 Twas The Night Before Christmas
by Michael S. Hart 17 Apr '10

17 Apr '10

***** This file should be named 17135-h.htm or 17135-h.zip ***** This and all associated files of various formats will be found in: http://www.gutenberg.org/1/7/1/3/17135/ Produced by Janet Blenkinship, Suzanne Shell and the Online Distributed Proofreading Team at http://www.pgdp.net Where the first characters of stanza were "illuminated" they were eliminated and never replaced in the htm. version.

9 10

Re: !@! #17135 Twas The Night Before Christmas
by Bowerbird＠aol.com 17 Apr '10

17 Apr '10

dakretz said: > How accurate is this assessment? it's half-assed accurate. mostly because it's looking at the p.g. corpus from the standpoint of its two major file-types. but we'll want to look at it from the perspective of the users who will access it, and how... (the answer to that is mobile, mobile, and mobil.) moreover, some of your points, even as given, are wrong... > 1. original plain-text. significant but declining strongly. no. significant and _increasing._ (a rising tide lifts all boats.) > 2. original .html files. significant but declining slightly. no. significant and _increasing._ (same tide, different boat.) > 3. plain-text derivatives. declining. dead wrong. this is the segment that is increasing fastest. most of the places that make derivatives use the plain-text. > 4. .html derivates. significant and increasingly so. well, not quite "dead-wrong", but still wrong nonetheless. the .html files have far too little consistency to be used in a systematic creation of derivatives, not without glitches... some places use the .html file, but then "fall back" to the plain-text version if they see problems with the derivative. but most can't spend that much energy on quality-control, so they've resigned themselves to using the plain-text files. which is not that big of a sacrifice, to be perfectly honest... indeed, the system giving the most consistently best results is the iphone viewer-app "eucalyptus", which utilizes _only_ the plain-text files; his converter is giving very good output. and, to help get people's heads on, and completely straight, it's good to do the reminder that many of the .html files are the result of a straight-out conversion of the plain-text file. and these files, because they're machine-generated, _are_ consistent enough to be used in a systematic conversion... it's the "hand-crafted" ones that cause all of the problems, which is something that i first pointed out many years ago. when problems with the auto-generated .html files do occur, it's usually due to an underlying glitch in the plain-text file. so auto-conversion of plain-text is the best way to proceed. and i've maintained for 7 years now that such a conversion is not just _possible_, but our best course of action to follow... for several years after i started, i left my argument unproven, just to see who would jump at the bait and try to dispute it... after destroying all that opposition, i have since proven that it is indeed possible to use a plain-text file as your "master". why y'all continue to ignore this proof, i simply do not know. but i'll keep making the case, until all of you can see it clearly. -bowerbird

5 5

Re: !@!!@!!@!Re: Re: so what is so important about pagination?
by Bowerbird＠aol.com 17 Apr '10

17 Apr '10

michael said: > I had to have read the whole thing > to get to the part I quoted. . .duh! you can quote something without reading it. but i should have said i wish you would have _understood_ what i was saying, because then you would have understood that your response didn't address the point that i was making. > When you ask people to pay attention, it helps to PAY ATTENTION. i am paying attention, michael. even though i've heard what you're saying lots and lots and lots of times before. and it makes sense when you are addressing the people who are making _other_ points. but they left long ago... > It addresses EXACTLY the point you made that I quoted. . . . no, it doesn't. > Then SAY that!!! Right up front in plain language!!! i _have_ said it, every time i've talked about this issue... including once when marcello brought up this same point you brought up (think about that, michael), about editions. (it was back in september of 2007, if you're curious.) marcello pointed out that the various different editions of "pride and prejudice" had different pagination, and he asked which of the editions should be used to do the pagination... here's the reply i made to marcello's point: > http://z-m-l.com/go/pap/pride%20and%20prejudice(4).txt if you don't care to read all of it, here are the guts of that reply: > the answer to the question as to which set of linebreaks and > pagebreaks to use is this: the ones in the edition you digitize. > > plain old common sense. if you didn't already know the answer, > perhaps you might want to exercise your brain a little bit more... > > if you're digitizing the 1844, use its linebreaks and pagebreaks. > if you're digitizing the 1853, use its linebreaks and pagebreaks. > if you're digitizing the 1870, use its linebreaks and pagebreaks. > if you're digitizing the 1892, use its linebreaks and pagebreaks. and here is a web-page showing the first page of those 4 editions: > http://z-m-l.com/go/pap/pride_and_prejudice(4).html and yes, in case you're wondering, if a p-book was important enough to go through different editions, we should digitize _every_ edition... i'm not going to tell you which of those 4 editions you _should_ use, which one is the "right" one. whichever one you want to use is "right". and you should be able to determine if any specific e-book _does_ or _does_ not match the edition you want to use, or some other edition. *** by the way, there's another web-page of interest in this directory: > http://z-m-l.com/go/pap/jose(4).html this fascinating page shows some work done by jose menendez. jose adopted my suggestion that the e-book be able to mimic the p-book, and he created a series of .pdf books that did just that... shown on this web-page are some screenshots of his .pdf-books, compared to the page-scans from those pages. he did a great job. of course, since a .pdf-book is unable to reflow its text, jose's work doesn't fit the more-important criterion of reflowability, but it does show that the ability to mimic the original can be extremely valuable. > However, that still relegates us to being a Xerox machine, no? no. because a xerox machine can't do reflow. or fix typos. or pull in spacey contractions. or change the font, or size. look, i understand the appeal of digital text _extremely_ well. i've made all of the arguments myself, so there's no need for you to repeat 'em back at me, you're just wasting your breath. but there's a problem looming here, a problem that the future will have to face, and solve, and i'm telling you what you need to do, so that you can _help_ the future _solve_ that problem, such that your e-texts will continue to be used, and not tossed. i'm on _your_ side, michael... i've got your back, good buddy... so you need to get that through your skull and start listening... > I'm never going to get into any of these semantic arguments!!!!!!! > Mimic means to copy as closely as possible. . . . Synonym: copy. it's not a semantic argument, michael. it's protective coloration. if your copy isn't capable of _assuming_the_look_and_feel_ of the thing that it _purports_ to be copying, nobody will trust it. you seem to be forgetting that you are claiming to _be_ a copy. perhaps you are an "improved" copy, but you are _still_ a copy. certainly if you came out and said "we rewrote parts of the middle, because the original was too boring", you would expect that people would throw you away. but what if someone points out a few errors in your work, and says "see, you can't trust this work, it hasn't been faithfully transcribed," then what is your defense? you can say that "it was just a few errors", but what if they then point out a few more, and a few more after that? at what point can you no longer expect the end-user to believe you? > As I have said before, if you would listen, > I am not AGAINST keeping a copy with such pagination > for such purposes well, good, and bully for you, and all that, but the fact of the matter is that project gutenberg is not, at this point in time, actually doing that. > but I draw the lines, pun intended, at keeping every character > in the same page position when there is no need for pages, > in all available PG editions. and, as i have said before, if you would listen, i'm not suggesting, in any way, shape, or form, that pagination and linebreaks need to be kept "in all available p.g. editions". that'd be stupid, absolutely and totally and ridiculously _stupid_, and i don't usually feel a need to rule out stuff that is absolutely, totally, ridiculously stupid... > I want our eBooks to be optimally readable: > Minimal end of line hyphenation. > No page headers or footers. > Just plain reading. i'm 100% in favor of that. and i have demonstrated before, and will be happy to demonstrate once again, any time that you like, how p.g, could save its texts in a format that allows verification of the type that i am talking about, _and_ allows the end-user to have the text exactly like you specify. > Once again, I have no stance AGAINST people who want pagination, > I just don't want for force any such arbitrary formats on anyone > and neither should you or anyone else. > STOP TRYING TO FORCE YOUR OPINIONS ON OTHERS, > MAKE THEM OPTIONS! see, that's precisely why i said you're not listening to me, because there's no way in the world i would try to "force" this on end-users. i've never, ever, said _anything_ even _remotely_ like that, in all the years i've been on this listserve, or the decades i have done e-books, so i don't know who you're having this conversation with, michael, but it's obviously not me. > I CAN tell you that most of the paper editions' page numbers > will fade along with the hyphenation. no, they won't. because our cultural heritage is full of references to page-numbers, and it'll be several orders of magnitude cheaper and more efficient to keep track of those page-numbers than to attempt to re-do all those references using hyperlinks or whatever. > Last time I looked there were still pretty ubiquitous programs to > lay out all such differences. > > IFF you have such deep interests, you can simply put up two editions > side by side when you look at them. . .I do. . . . > > If not, then you aren't really that interested. . .it's all smoke. this is very amusing. i do this kind of work, michael. regularly. and i can tell you that it's not nearly as simple as you make it sound. > "_RIGHT_" copy??? > Now you've contradicted yourself back into the ivory tower. . . . > "_RIGHT_" copy, indeeeeed. . . . you just can't _wait_ to jump to the wrong conclusion, can you? by "right" copy, i mean the one that the person _wants_ to see. > This will ONLY do you any good if you manage to find > that edition, out of all the other paper editions in the world. again, "that edition" is whatever edition the person wants to use. i have a paper copy of "catcher in the rye" on my bookshelf now. let's say, 10 years on, i can find a dozen digital versions online. let's also say that some analysis shows differences between them. i haven't compared all, not in full, but i know there's some diffs. i don't want a dozen different versions. i want the one that matches the paper copy that has been sitting on my bookshelf for 4 decades. how do i determine which one -- _if_any_ -- is the same version as the one that is sitting on my shelf? that's the difficult question. > Sorry, but I anticipated ALL of these questions when I first started, > and have answered, and will continue to answer, at length. no, you didn't answer the question. so i just asked it to you again. > Why can't you just propose your ideas as OPTIONS, > not CARVED IN STONE? stop making the thread ridiculous. no one can carve anything in stone any more. -bowerbird

5 5