- gutvol-d - lists.pglaf.org

p.g. times ten
by Bowerbird＠aol.com 07 Oct '12

07 Oct '12

don said: > Please explain. please explain what? > https://ianews.wordpress.com/2011/09/17/3-million-texts-for-free/ -bowerbird

1 0

p.g. times ten
by Bowerbird＠aol.com 07 Oct '12

07 Oct '12

don said: > PG could be keeping itself busy forever digitizing > some order of magnitude more ebooks than it does today > and still not be catching up. true. > The list is to describe the scope of > what all would need to scale up if PG were > to take the true magnitude of the job seriously. ok. but... > Take a ridiculously low number - say a rate of > 10 times more books than are being added now. so when you say "ridiculously low", you mean that, even at that rate, p.g. would still fall behind badly. but even that kind of jump would be very hard to attain -- in my judgment -- if you were to try to leverage the current pg/dp infrastructure, because it is deeply resistant to _any_ change... so you'd need to start anew. and even that would be difficult to accomplish, if you were to ask me... we see that even wikipedia, an unqualified success, is having trouble maintaining its own participation, since people are more interested in updating their facebook page these days than collaborating online. *** but let's say that you _could_ create "p.g. times ten". that means you'd put up about 25,000 books a year. in 4 years, you'd have 100,000. in 8 years, 200,000. people already have reasonable access to 2 million public-domain books. just the scan-sets, true, but that seems to be all that the average person needs... i argued every step of the way that digital text was superior in just about almost every way to scans... but now that we have these millions of scan-sets, we have to ask if the cost of cleaning the text for a relatively small percentage is worth the benefit. given the current output of d.p., which seems to be polarized, with "campfire girls go horse riding" at one end and "dante's divine comedy" the other, i'd say nobody will be happy with your percentage. if a person _does_ want digitized text nowadays, they want it for a _particular_ book, not a library that's so small and idiosyncratic that the odds are fairly slim that it even contains that specific book. back in 1992, and even in 2002, p.g. made sense. in 2012, a world where we are awash in page-scans, i think you would need to re-think the justification... not just a workflow, but the "why are we doing this?" if you would whip up volunteers, i think it'd be great, because i think there is huge value in digitized text... but that's my personal opinion, and it also recognizes that synergy only kicks in if _all_ our text is digitized. and if your project isn't ever gonna make that happen... *** so i'd say you'd need to be upfront and honest with potential volunteers, about the true value of the deal, to weigh the cost-benefit ratio of their contributions. -bowerbird

2 1

top 10 reasons why this current thread will go nowhere -- #8
by Bowerbird＠aol.com 06 Oct '12

06 Oct '12

#8. if your workflow has no supporting tools, you have no workflow. #9. this list has proven it can ignore a solution right in front of it. #10. that's where these threads always go, and nothing has changed. -bowerbird

1 0

call up your sled-dogs
by Bowerbird＠aol.com 06 Oct '12

06 Oct '12

greg said: > This is, more or less, exactly what I said we needed. > There is no resistance to any of this. then why haven't you put it into place? > I even asked for input on figuring out what the > requirements & enforcement would look like. jim has pointed out examples of problematic .html. many times. so have i. simply remove those negatives. if you would rather have positive examples instead, examine my z.m.l. test-suite, and how it is handled. *** i must add, however, that even though you say that "there is no resistance to any of this," it certainly _seems_ like your whitewashers couldn't care less (as evidenced by that "update" to huck finn), and to describe marcello as anything less than "hostile" would be an injustice to truth, not to mention that the fine people over at d.p. will impasse your ass... so i think that puts you in over your head, greg... and yes, i do remember that you are rather tall. still, over your head. though perhaps you could call up your sled-dogs to pull you out to safety... but how good are they at writing code? and docs? -bowerbird

1 0

top 10 reasons why this current thread will go nowhere -- #9
by Bowerbird＠aol.com 05 Oct '12

05 Oct '12

#9. this list has proven it can ignore a solution put right in front of it. #10. that's where these threads always go, and nothing has changed. -bowerbird

1 0

patches to epubmaker
by Bowerbird＠aol.com 05 Oct '12

05 Oct '12

paul flo williams said: > maybe one of us could > actually submit some patches to epubmaker. i'd love to see that, to see what marcello would do. based on my experience, he'll tell you that it's no good, and you're stupid, and you don't understand the issues, and your interpretation of everything is wrong, and then he'll make the change himself and take the credit for it... but hey, you know, if you're ok with that, then go ahead. -bowerbird p.s. i'm still not reading your posts, marcello, so... you know, don't even bother preparing a "response". or, better yet, attack me with yet another low blow, confident that i won't respond because i won't see it.

1 0

Re: [gutvol-d] blah blah blah blah blah
by don kretz 05 Oct '12

05 Oct '12

So what are you suggesting? I can't imagine people out there saying to themselves"This is simple; I think I'll make it complicated." or"This is complicated. I think I'll oversimplify it." What is a constructive suggestion? Sent from my Phone From: James Adcock Sent: 10/5/2012 9:51 AM To: Project Gutenberg Volunteer Discussion; Tapio Riikonen Subject: Re: [gutvol-d] blah blah blah blah blah >Books are complex beasts, and not always easy to typeset or encode. We have a lot of books which are pretty simple, and could fit into a common methodology which should be able to run successfully "everywhere." We have a few books which are very complicated, and are not going to fit into a common methodology, at least not one which we can teach or motivate the average volunteer to use. There is a strong countercurrent however, who want to take simple things and make them complicated, and well as another thread who want to take complicated things and oversimplify them. _______________________________________________ gutvol-d mailing list gutvol-d(a)lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d

2 2

Dumbed-down outline of PG process
by don kretz 05 Oct '12

05 Oct '12

This is absolutely without regard to method, technoiogy, markup, standards, or responsible parties. Those can come later, but this is to enumerate the steps in the PG workflow (although "flow" is a stretch in some cases) in order to provide scope for any discussion of PG workflow per Greg Newby's post. These have to be accomplished one way or another in order for a book to become an ebook in the PG catalog, and support multiple format output and ongoing refinement and error correction. Some can be simultaneous and there's overlap. Some may be provided by external sources (e.g. images.) Participants include volunteers, PG, and customers. 1. Choose a book to digitize. 2. Collect and record metadata, and confirm Public Domain status. 2. Obtain images of all the pages. 3. Produce text with OCR. 4. Refine the text to match the OCR. 5. Locate and mark significant artifacts in the text. 6. Submit package of text(s) and images to PG. 7. PG review and post to catalog. 9. Select layout and format for desired device or application. 10. Select or create layout and format for text and artifacts. 11. Issue ebook per spec (possibly including production.) 12. Identify errors or other revisions to text. 13. Locate and describe revisions. 14. Submit revision to PG. 15. Back to step 7 to validate and apply revision. There are obvious definitions to be provided, including metadata, refine, location and mark, significant artifacts, package, etc. etc. Don

1 0

top 10 reasons why this current thread will go nowhere -- #10
by Bowerbird＠aol.com 05 Oct '12

05 Oct '12

#10. that's where these threads always go, and nothing has changed. -bowerbird

1 0

blah blah blah terminology blah blah
by Bowerbird＠aol.com 05 Oct '12

05 Oct '12

don said: > I've never seen the term "vanity html" before. i've used the term "snowflake" _many_ times before. i'm quite sure jim is using "vanity" in a similar way... > The only effect I see for using it is > to add to the hostility level and > decrease the likelihood you will get cooperation. i am the one who uses tactical means to increase the odds that y'all won't act on my advice, not jim. i do that because i am _amused_ by your resistance to the message due to your dislike of the messenger. i find it quit entertaining that you guys would rather thrash around, back and forth, for _years_ (literally!), instead of adopting a solution i have proven to work. in other words, i don't need any of your "cooperation". i'm doing just fine, _laughing_ here on the sidelines... as for jim, i think the term "vanity" probably represents the fact that he sees the "snowflake" .html as selfish... and i think he's probably right about that. even though i use a different term (one that might be less evaluative), i say jim's entitled to use "vanity" to express his feelings. that doesn't mean he's using it to decrease cooperation. > Same for "dumb-downed" but not as aggressively. i disagree that this term is being used for "spin" either. i think it accurately depicts a viewpoint which is common. i also believe, and feel i have proven, that that viewpoint is not based in fact. you definitely have to change stuff, to make it work on today's somewhat primitive e-readers, but the resultant product still works sufficiently properly to avoid the label of "dumbed-down". indeed, at times, the "fancy" .html used for desktops can get "too cute" and trip over itself, and ends up giving a degraded experience. so i strongly _disagree_ with jeroen, and the other people who use this term, because i believe it reflects a mindset that doesn't have to be held to describe reality accurately. (it's certainly true that one _can_ "dumb-down" the .html. but i say that it's not _necessary_ to do so to make it work. i've been able to make all common book-elements work.) but even though i disagree with the term "dumbed-down", i understand that it reflects the mentality of some people, a mentality which is not accurate, but still one they hold... and thus, i certainly don't think it's being used for "spin", or to increase the hostility, and most certainly not for the purpose of sabotaging any possibilities for "cooperation". indeed, "dumbed-down" doesn't have any ad hominem in it. (and even "vanity" is only ad hominem if you interpret it so.) > I think better terms might be "complex" vs. "simple" > and "portable" vs. "non-portable." those poles are no better. in some ways, they are worse. "conversion-capable" versus "snowflake" is the essence. this stresses that _conversion_ is the main objective... "snowflake" is the obvious word to use for the one pole, because everyone knows that every snowflake is _unique_. there are lots of ways to accomplish something in .html. if you multiply all the possibilities, they become infinite. you need to have common coding conventions in order to chop down that infinity into a number that can be handled. to sum up, it must be _standardized_to_a_limited_palette_. (where the word "limited" pertains to numbers, not quality.) this means that if there are 89 ways to do something, you might have to chop that down to a mere 23. or 7. or, if you can formulate code to handle all 89, then there's no reason from that standpoint to set a limit, although you might impose a limit anyway, so as to make it easy on the humans maintaining the library. for the purpose of computer conversion, then, you'll need to actually _write_the_code_ so you know _how_many_ and _which_ of those 89 different ways your code can handle... avoiding snowflakes is a _necessary_ condition for conversion. but it's not enough, in and of itself. in order to convert properly, you need to understand the structural nature of every single element within the book. now, it's possible to have a complex scheme which is still _incapable_ of conversion because it doesn't communicate the necessary information about the structures in the book. on the other hand, it's possible to have a scheme which is _simple_, yet still manages to communicate the information. sure, there's a possibility for a complex scheme that works. (although then there arises another question about whether that would be a good solution for a volunteer organization. but for this reply, we're concentrating on terminology use.) and there is, of course, the simple scheme that doesn't work. but it's just wrong to think that any simple scheme will fail, and any complex scheme will succeed. so that label is bogus. as for portable/non-portable, i'm not sure what you mean. i suppose you could say you meant "convertable/snowflake", but if that's what you really meant, then don't be ambiguous, say it in a way that doesn't require the internal interpretation. -bowerbird

1 0