April 2010 - gutvol-d - lists.pglaf.org

Cooperative proofreading
by Lee Passey 30 Apr '10

30 Apr '10

Just an update on my cooperative proofreading site (http://www.ebookcooperative.com/) 1. The Java servlets are now connected to CVS, so any changes you make will be persisted to the file system. 2. Registration is now required to proof read pages (just your identity is currently required). This identity is used to add comments to CVS so we can see who changed things. 3. The proofreading system tracks progress, so if you go half-way through a project, exit, and return at some time later and choose the same project you will be taken to the last page you were viewing. 4. Some new projects were added. The project table is generated from a database of projects; no editing of web pages is required. The Kupu-based UI is still a little rough; that will probably be the last thing I tackle. I have not yet written the proofing guidelines. The next step will be to create a servlet that will allow downloading an entire e-book by combining all the pages from the repository into a single file. As always, feedback is welcomed.

1 1

Re: spill baby spill
by Bowerbird＠aol.com 30 Apr '10

30 Apr '10

dakretz said: > s/republicans/politicians/ all of the politicians are rotten, it's true. but the republicans are more rotten. way more rotten. besides, look at the subject-header... -bowerbird p.s. this means if any of you consider yourself to be a republican, you'd better take a good look at yourself. not that democrats couldn't stand a look in the mirror. your whole system is now corrupt, and _you_ made it...

2 1

spill baby spill
by Bowerbird＠aol.com 30 Apr '10

30 Apr '10

the worst slick in human history. so let's all give our thanks to the republicans and the oil corporations who pull their puppet strings. -bowerbird

2 1

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

27 Apr '10

ok, back to work... *** have you ever tried to copy text out of a .pdf? if you have, you know that it can be frustrating. because a lot of information seems to get lost. perhaps the most noticeable are "empty" lines. if you used a blank line between paragraphs, all of those blank lines are lost, which means that your paragraphs are now all run together. compounding that problem is that the "soft" linebreak at the end of mid-paragraph lines is turned into a "hard" linebreak. it's a disaster... you _can_ choose the "export as plain text" item from one of the menus, and that does retain the empty lines. unfortunately, it also strips styling. the copy-text route retains the styling, or at least _some_ of it. but not all of it. italics are often lost. so is the indentation on block-quotes, poetry, etc. so no matter what you do, getting text from a .pdf is a struggle. that's one reason why .pdf is called "the roach motel of documents", because text can go in, but it cannot come out again. you can demonstrate this to yourself by using the .pdf that michael mcd created... *** i do some things with my .pdf tool to solve this little problem. for instance, it doesn't output a "blank" line when it encounters one. instead, it outputs a double-colon -- "::" -- that is white, thus _invisible._ (or i'll often make it light gray.) but it's still there, and gets copied out when you copy the text, so you can then do a global change of "::" to nil, and voila, you have your blank lines. in z.m.l., italics are represented by _underbars_, so i also have my program output the underbars, again turning them white so they'll be invisible... i haven't worked on this for a while, so i cannot remember what state of success it's in right now, but my goal is to create "round-tripping", so that when you use z.m.l. to create a .pdf, the text you copy out of that .pdf, after a few global changes, can be used to create that exact same .pdf again. go ahead and copy the text out of one of my .pdfs, and you'll get a good idea what i'm talking about... *** the tricks that are built into my tool are ones that you can do "manually" in your own wordprocessor, if you'd like to create a "round-trip" capability too. surround your italicized stuff with white underbars, change your blank lines to a white double-colon, and use white periods to create your indentation. i did that in the next two .pdfs i will talk about, so you can copy the text out of 'em to see this at work. *** i used a text-editor to create two more .pdfs for us in our experiments using "gods and fighting men". i unwrapped the text, freeing it from p.g. linebreaks. then i made the fontsize a more-readable 12-point. i also put back in a more-spacious 14-point leading. all these changes pushed the .pdf to some 567 pages, from the previous 391, so that's an offsetting negative, but the positive aspect is a much more readable .pdf... i created a ragged-right version, and a justified one: > http://z-m-l.com/misc/14465-rewrapped-rag.pdf > http://z-m-l.com/misc/14465-rewrapped-just.pdf these two are exactly the same, except for justification, so you might find it odd that the first is just 1.5 megs, while the second is almost twice as big, at 2.9 megs... the reason for this discrepancy is the ragged-right .pdf stores the location of each line, rendering it right there, while the justified .pdf has to store the location of each _word_, to print it in the right place. it's a big difference. at any rate, maybe the mad scientist will look at these and advise us on what pointsize he'd like to see "final", what leading he wants, and if he prefers justification... -bowerbird

1 0

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

27 Apr '10

jim... you just utterly and completely fail to grok the listserve imperative to move threads forward. *** jim said: > I believe I did say something that makes sense, then you have a serious intellectual problem too. > its just that you still do not understand that > your problem was not font size but rather line length. this is now the third time i have said it, twice now directly to you, and you still don't seem to "get it". i retained the p.g. linebreaks. that means p.g. decided the line-length, not me. if you don't understand the exact meaning of that, continue pondering it until you _do_ understand it. because you won't be able to keep up with the thread, let alone advance it, until you've understood that fact. i retained the p.g. linebreaks. that's why each line was as exactly as long as it was. because that's how long it was in the p.g. e-text... (except for lines i rewrapped to get rid of orphans.) are the lines in p.g. files too long, in general? _yes._ does that have any bearing on our experimentation? not really. because we're just trying things out here. nothing is cast in stone. and perhaps, for this book, for michael's eyes in particular, the p.g. lines are fine, even though -- for you, or me, or somebody else -- they might be too long. our opinion doesn't matter, because michael is printing out this book for himself. that's a beauty of print-on-demand -- customization. besides, we're going to do _more_ experiments later... > You also do not apparently understand that > it is not generally true that font size > and line length are inversely related. again, you need to put in some more thought... if we talk about a pre-determined line of characters -- like in this case, where we retain p.g. linebreaks -- it is _absolutely_true_ that the space required will be directly related to the fontsize. _it's_absolutely_true_. the character-count of the line will remain unchanged -- by definition, as it was determined by linebreaks -- but the width of the line printed on a page depends on fontsize. the bigger the size, the more space required. and if we also constrain the size of the space in which we are putting that pre-determined line of characters, we have put an upper-limit on the fontsize we can use. in this case, we are using a space that's 4.5-inches wide, so the biggest fontsize i could use that kept all the lines reasonably within the width of the space was 10.5-point. a smaller fontsize wouldn't have filled up all of the page, plus it would've been less readable, so i used 10.5-point. in other words, all of the other factors were constrained, and fontsize was left to vary, and had to make it all fit... for my next .pdf, and i've said _this_ three times now too, twice directly to you, so it really should've sunk in by now, i will unwrap the text (i.e., free it from the p.g. linebreaks) and jack the fontsize to 12-point, so michael can see that. and then we'll do some more experimentation after _that_. > So you retract your previous statements > when you said that I should have been > reporting to you when your tools fail? just exactly how useful do you think an "it doesn't work" report is, anyway? you never gave one worthwhile report. so no, jim, i don't want any reports from you, none at all... are we clear now? or do i have to repeat that a third time? -bowerbird

1 0

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

27 Apr '10

jim said: > I was paying attention then why didn't you understand the situation? why did you say something that made no sense? > Again, you ask for feedback > but you are not willing to accept any graciously. ok, jim, let me make things perfectly clear. i do not value _your_ feedback. so when i ask for feedback, i am most specifically _not_ asking for feedback from _you_. definitely not you. are we clear? -bowerbird

2 1

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