- gutvol-d - lists.pglaf.org

Re: Typesetting (back on track, calling the mad scientist)
by Bowerbird＠aol.com 27 Apr '10

27 Apr '10

michael mcd said: > That can be arranged: > http://www.mad-computer-scientist.com/files/14465-8.pdf that's serviceable output. the book designers won't be giving it any awards. but if it meets your needs, that's pretty much all that counts. as the object was a hard-copy printout, i didn't even talk about things like a hotlinked table of contents or footnote presentation, but i _can_ deal with them if you want to discuss the pdf qua pdf. just from an ink-on-paper perspective, though, if you were to critique any of the output, exactly what points would you make? -bowerbird

1 0

Re: Typesetting (back on track, calling the mad scientist)
by Bowerbird＠aol.com 27 Apr '10

27 Apr '10

mike said: > Leslie, leslie is my girlfriend, not me. sometimes she checks her e-mail when i'm away from the machine, so when i come back i end up sending a message from her account. oh, but you probably got her name from the "author" box of the .pdf, now that i think about it. that was filled in by the text-editor i used... if you check out the later .pdfs, you should find that that metadata is supplied correctly by my authoring-tool. (unless i forgot to specify it.) > The leading is perfect. oops... i took it up considerably in the newer version i just posted... it has 10.5-point type, with 12-point leading; and still runs 400 pages. and bigger leading means fewer lines per page, and thus more pages. which might or might not be a big deal to you. all of these variables make it complicated to know how to create a .pdf for somebody else. which is why a cyberlibrary needs to put .pdf/hard-copy output creation ability into the hands of its end-users, so they can _customize_ it fully... > if I had an ebook reader I probably > would not be bothering with any of this. that's why i make many of the decisions according to a smart default. > I also conducted some more experiments with CSS stylesheets for on > the html2ps side of things (using txt2html so that the chain looked like: > txt2html -> html2ps -> ps file -> printer/screen). i'd love to see a .pdf representing your output from that... -bowerbird

2 1

Re: Removing spurious break lines
by Bowerbird＠aol.com 26 Apr '10

26 Apr '10

jim said: > Perhaps you should start by examining what PG has *already* > implemented for txt unwrapping to generated HTML, > find out what works and what doesn't work, and > what requirements this puts on txt submission > in order to make it all work right? the code that does unwrapping right now is marcello's. i don't know if he has updated it since i looked at it, but when i did, it was just what i'd expect from a technocrat: he made the problem much more difficult than it is, and subsequently his code is overwrought, _and_ it backfires. (for instance, he was using a rhyming dictionary to try to determine if a set of lines constituted a poem; good luck.) all in all, once you approach the problem intelligently, it's not that difficult to unwrap most p.g. files correctly, even the ones which have not been formatted correctly, because you can detect the lines that should be indented. i could run a script that auto-fixes most p.g. e-texts, with few introduced errors; too bad p.g. doesn't work that way; the whitewashers insist on fixing the books one-at-a-time. > Otherwise PG will end up with > two conflicting text unwrapping standards, > which will make the submitter's task > even more confusing. marcello had to code his unwrapper precisely because p.g. doesn't enforce its existing policy on text indents, or have the foresight to expand it to cover other cases. his code won't scale. and the indentation policy _will_... (and it'll replace his kludge code with something simple.) so there's no issue with "two conflicting standards" here. > To the extent that you guys are heading more-and-more > towards the "unobtrusive" marking up of txt files, please > note that Python has already got very good efforts in this regard > called "reStructured Text" -- and the tools existing to support it! you're a few years behind the threads here, jim... "restructured text" is a light-markup format, just like z.m.l. the main difference is z.m.l. is geared directly toward p.g., whereas restructured text has a provenance that's muddled, so if you were gonna choose between the two, choose z.m.l. (tools for any light markup system are _not_ hard to build.) but hey, if you can get p.g. to go for restructured text, do it! -bowerbird

1 0

Re: Typesetting ("gods and fighting men")
by Bowerbird＠aol.com 26 Apr '10

26 Apr '10

jim said: > The Studs Turkel however has 60 chars per line > compared to 70 chars per line in your example PDF -- > and as compared to 50 chars per line or less for historical novels. jim, you need to pay better attention. > Less chars per line tend to make things more readable > while taking more paper. Too many chars per line > make things very painful to read ... > http://desktoppub.about.com/cs/finetypography/ht/line_length.htm yes, jim, i know all about line-length and readability... (and if you do a citation, quote _bringhurst_, not about.com) *** those who _were_ paying attention know that i said explicitly i retained the p.g. linebreaks, accounting for the long lines... it's also the case that michael mcd seemed to accept the fontsize and the margins and the pagesize, which means that his eyes didn't particular mind the long lines, and since the .pdf was intended for him, he's the ultimate judge here. even more so, people who were paying attention also know that i said i would be rewrapping the text and doing a .pdf with a bigger fontsize. since the pagesize and the margins will stay the same, that means shorter lines _by_definition_, bringing them to the 50-65 characters bringhurst suggests. in other words, jim, your post was completely unnecessary. -bowerbird

2 1

Re: Removing spurious break lines
by Bowerbird＠aol.com 26 Apr '10

26 Apr '10

al said: > However, it seems to me that simply indenting > not-to-be-formatted lines, and doing nothing else, > is at least somewhat pointless. it's not "pointless" to make _some_ "corrections", but not all, to a text. that's what whitewashers do quite often, when _you_ "correct" a text... > Many of PG's older texts have other problems than that > (missing illustrations, ASCII only rather than Latin1 or UTF8, > missing/incomplete indexes, etc, etc, etc.) that's right. but you whitewashers don't fix all of those problems. you apply the corrections that've been submitted, and you run the text through the new version of your tools, and you might also do some other checks (and thanks for doing that), and then you post it. > A far more desirable approach would be to > pick an old PG text, find a scanset in IA/Google/wherever, > get a copyright clearance, and do a new version of it, either > from scratch, or a complete re-proof of the existing file(s), > doing whatever is needed to bring it up to current standards. i fully agree that that would be "more desirable". it would also be a heck of a lot more work. and that's the trade-off, is it not? still, someone who does _some_ of the "corrections" -- whether that is to make the text robust to rewrapping or some other subset of stuff -- is not engaging in a "pointless" exercise. they're improving the text, and -- just as i thank you whitewashers for improving the text when you do _your_ "corrections" -- i would thank any other person who improved the text when they do _their_ "corrections". i fully approve of an iterative process that steadily cumulates "partial corrections"... > Note: Complaints that the Repost team (mostly myself and > David Widger, between us doing considerable clean-up work > on several thousand of PG's old files) "should have done more" > will fall on deaf ears. We're only two people, we're also 2/3 > of the Whitewashers, and 2/3 of the Errata team, and we both > produce independently. Back off. i have never "complained" about the "corrections" by whitewashers. i _have_ pointed out that these "corrections" are _not_ complete, in the sense that many errors and inconsistencies and omissions _survive_ this "correction" process. but again, i do not condemn any "corrections" because they are not complete. i welcome and appreciate _all_ "corrections", even incomplete ones, because they move the text closer to _perfection_, and that's what i advocate... i wasn't "complaining" to report your corrections" are incomplete. i felt the need to point that out because you _do_not_ point it out. you say that "errors were corrected" and you simply leave it at that. i believe that many people probably conclude, from your statement, that you've made a good-faith effort to actually _find_ all the errors -- such as by comparing the text with a newly-obtained scan-set -- when, in point of fact, you have not actually gone to those lengths... nobody is "blaming" you, or "criticizing" you for doing what you do, or for not doing what you're not doing. so there's no need to tell us to "back off". that's insulting, and you really shouldn't be so sensitive. we're just stating the facts. _clearly_. because you haven't done that. so, can we all agree that "partial corrections" are _not_ "pointless"? because that would be a huge step in the right direction, yes it would. -bowerbird

2 1

Re: Typesetting ("gods and fighting men")
by Bowerbird＠aol.com 26 Apr '10

26 Apr '10

looks like we lost our mad scientist... or perhaps he's off deep into programming mode, creating wondrous new tools for project gutenberg. at any rate, for anyone out there who's interested, here is my latest .pdf of "gods and fighting men": > http://z-m-l.com/misc/14465-take6.pdf feedback, public or private, would be appreciated... this version retains p.g. linebreaks, for the most part. (i did some rewrapping, to remove egregious orphans.) the use of 10.5-point type made even the longest lines manageable, given the 4.5-inch measure that i used... that's obtained by .5-inch margins on a 5.5-inch page. (if you were printing this at lulu.com, you could specify a 6*9-inch page, which would allow a bigger fontsize.) however, as you'll see, the lines are extremely ragged, with many short lines, since they were wrapped by the character-count, not the length of a proportional font. (furthermore, there was some real weirdness on this, in that many lines seemed to have been counted short; in particular, it was as if the algorithm was _trying_ to create very short lines as the last line of the paragraph. i don't recall having seen this before; it was _strange_.) anyway, because many of the lines were counted short, using full justification on this text would be a disaster. but otherwise, this is a _respectable_ job of typesetting. i'm gonna rewrap this text, using a bigger fontsize, and i'll mount that .pdf later this week. enjoy this one now... -bowerbird

2 1

Re: Removing spurious break lines
by Bowerbird＠aol.com 26 Apr '10

26 Apr '10

al said: > I've contacted Joaquin directly. well, i agree that there's no need to engulf an innocent newcomer in an involved discussion about p.g. policy. but that doesn't mean the discussion should be swept under the rug, eh? we'll need an answer to the question: will p.g. accept e-texts that have been "corrected" by virtue of having their not-to-be-unwrapped lines indented? transparency is the new black. sunshine is the best disinfectant. the most colorful fish deserve the most apparent aquarium. so... what is the p.g. policy on this? -bowerbird

3 2

Re: Removing spurious break lines
by Bowerbird＠aol.com 26 Apr '10

26 Apr '10

jim said: > In general, if derived formats including ePUB and MOBI from HTML, > also HTML from txt, also unwrapping txt from wrapped txt, > are to work “correctly” then there needs to be *some* degree of > expectation on the formatting of the incoming texts. Otherwise > these tasks cannot be successfully automated. that's true. but i'm not talking just about "derivative formats", because there's no need to create a "derivative" if you'd rather just use the .txt file itself to drive the display, a la "eucalyptus". however, the .txt file does have to be formatted "correctly" if it is to be _displayed_ correctly. that's what's driving my motivation... > Going the other way, the automated wrapping of txt is has > built-in support by most (all?) modern text tools, including > web browsers, e-book readers, text editors, etc. stop trying to derail the thread, jim. there's no way that project gutenberg is going to mount files that don't have mid-paragraph hard linebreaks... _no_way_... so that's not what we're talking about here. and we aren't _going_ to talk about that here, no matter how many times you try to bring it up. so stop trying. what we _are_ talking about now is formatting the .txt files _correctly_, so that they can be unwrapped automatically... -bowerbird

2 1

Re: DP Archives/OLS (Was: Re: DP output ...)
by Bowerbird＠aol.com 26 Apr '10

26 Apr '10

dakretz said: > Except for the ones that are purportedly in Charlz' garage "purportedly"? tone down the skepticism, man. save it for when it's needed. > and/or they have a policy not to make available. well, um, yeah... d.p. made a policy decision to "respect" the wishes of some institutions _not_ to repost the scans, even though those "wishes" have no basis in legal rights... in other words, d.p. traded away your public-domain rights for the purpose of maintaining "friendly" relations. oh well. the good news is that, for the most part, anyone else can retrieve the scans from the same place where d.p. got 'em. i don't know if the "o.l.s." tells where the scans came from, but the "credits" portion of the posted e-book often says so. > donovan - are they in fact available somehow from within DP? it probably depends upon who is asking, and for what purpose. then again, don, i'm sure you're well aware of _those_ caveats... -bowerbird

1 0

Re: Typesetting (back on track, calling the mad scientist)
by Bowerbird＠aol.com 26 Apr '10

26 Apr '10

we seem to have lost the mad scientist. mike mcd, are you still out there? if so, i have some questions for you... here's another take on "gods and fighting men": > http://z-m-l.com/misc/14465-take6.pdf this .pdf just has the first page of each chapter, but it came outta my program, not a text-editor. as we can see, the p.g. linebreaks make this text practically unusable, so we'll have to do a rewrap, especially if you want to have the text _justfied_... (if not, i can just rearrange the unwieldy lines and leave the vast majority of p.g. linebreaks in place.) going on, is this text-size (10-point) good for you? (again, print out some pages so you know for sure.) how about the leading? it's 15-point leading, so that's generous for 10-point type, and you might feel it's _too_ big, but i thought i'd show it to you. on pages 12 and 101, you'll see _blue_ headers... those are lines that needed to be _shrunk_ a bit, so they would not spill over into the margin area. on page 12 it's 15.5-point instead of 16-point, and on page 101 it's 13-point instead of 14-point. (and that latter one still intrudes on the margins.) the program attempts to "copy-fit" all the headers to the same size, but i'm experimenting here with allowing slight variations in size on freakish lines. (rather than letting the freaks dictate that the other header-lines be smaller to accommodate the freaks.) so the question is, are these small variations bad? noticeable? too much so? do they bother you much? -bowerbird

2 1