- gutvol-d - lists.pglaf.org

Re: the idiots in charge
by Bowerbird＠aol.com 18 Apr '10

18 Apr '10

greg said: > -- Greg (a.k.a. one of the idiots in charge) well, good, at least you have a sense of humor about it. :+) look, i apologize if i have criticized anyone unduly, as my intentions are not to hurt anyone's feelings... we've discussed some of these topics over and over, and even though some solutions are rather _obvious_ and we seem to have people willing to implement 'em, nonetheless _nothing_ ever seems to get done. _ever._ and when the topics come up again, and again and again, the people in charge act as if dialog has never been held. so the only conclusion that seems plausible out here in volunteer-land is that nobody at the top is _listening_... -bowerbird

1 0

Seeking current/past bookshelf maintainers
by Greg Newby 18 Apr '10

18 Apr '10

We used to have a bookshelf@ alias, but I've lost track of who this is supposed to go to. If it's you, or you know who is (was?) maintaining the bookshelf area of the gutenberg.org wikispace, please drop me a note. This page is all we have for contact info, but it's currently a dead end: http://www.gutenberg.org/wiki/Gutenberg:Bookshelf_Contributions Thanks in advance. -- Greg (a.k.a. one of the idiots in charge)

2 1

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

18 Apr '10

michael mcd said: > the PDF looks quite good. Offhand, though, > the page numbers look like they drop low enough > that they _could_ be out of the printable area. you're right. so i fixed that. download it again... > http://z-m-l.com/misc/14465-take5.pdf > shorter works are poor representatives of the problem still, you don't need 350 pages to cover the waterfront, especially when 315 of them have nothing happening... *** jim said: > First time I tried downloading this is didn’t work. Tried > it again later from a different computer and it worked. don't know what to tell you, jim. > Tried printing out the first 10 pages. > My printer reported that the document requested C5 page size > – but the C series is an envelope size? > I would have expected A4 or US “Letter” size. the pagesize is 5.5*8.5; that's what michael wanted. eventually, how you will print it out will depend on what you intend to do with it in terms of _binding_. for this preview, you have 2 convenient options... you can print it out 2-up, on letter-size, using the "layout" method you should find in the print dialog. for enhanced realism, slice pages down the middle. or you can print it out on 5.5*8.5, which is available at most any office-supplies stores, in my experience. we'll discuss printing and binding more, at a later time. > First Page title appears to print off center to the left. looks pretty dead-on centered to me, at least in the .pdf. did you print to 5.5*8.5 paper? if so, it should be right... > Contents in an unusually small font correct... my preference is for the contents section to be shown on 1 page, 2 pages max, so i had to cramp the font. i woulda reworked it manually if i wanted to take the time. reworking entails moving the chapters to the first page of each _book_ section, so the contents section up front just contains the entries relating to the _parts_ and the _books._ it's issues like these that get into the nitty-gritty questions on how automated you want the whole process to become. the easiest solution would be to run the table of contents over to 3 pages, or 4, or whatever it happens to be... but that approach doesn't produce a lot of satisfaction for me. so the question for me is, "how hard is it to automate what i would _really_ like to do in various situations like these?" since i was doing this by hand, to get on the same page with michael, i was willing to do a little manual massage. > Page numbers in an unusually large font the text-editor i used to create this .pdf does it that way, and as far as i can see, there's no way that i can control it. but that's not the way my program does it. so it's not something we really need to worry about... > Ragged Right is an unusual convention for a PDF document michael expressed no preference; ragged-right was easier. > Body font seems to be unusually small. i think so too. it's 10-point times new roman, i believe. (yep, that's it, checked.) but michael has the young eyes. what i was doing, in case it wasn't totally clear to people, was retaining the existing linebreaks from the p.g. e-text. in order to get (reasonable) half-inch margins on each side, i had to reduce point-size down to what _i_ feel is too small. ...but i wasn't doing this for me; i was doing it for michael... > Line length of approx 70 chars seems unusually long for a > book-like format. Most books use about 50 chars per line > of text because doing so makes the book more readable. so you didn't notice that i was using the existing p.g. linebreaks. there were several tip-offs. first and foremost, the first line of each paragraph is too long, because of the indent i introduced. second, the lines are more ragged than they should be, because line-length decisions are made on a monospace character count, not on a metric based on the line's proportionally-spaced width. (_any_ proportionally-spaced metric is better than monospacing, since the proportions are highly correlated across various fonts.) and thirdly, like i said, and you said, the line-lengths are too long. -bowerbird

1 0

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