- gutvol-d - lists.pglaf.org

Re: [gutvol-d] no subject -- the perfect header for that post
by Bowerbird＠aol.com 15 Oct '12

15 Oct '12

don said: > I went through a little exercise to > put myself in the place of a potential volunteer - > someone who would like to contribute a book i have been waiting, very patiently, for such people to start crawling out of the woodwork, since 2006... as time goes by, i have become _less_ convinced that anyone will eventually emerge, not _more_ convinced. but in the increasingly unlikely event someone _does_, you could point them to the posts i made back in 2006 on the bookpeople listserve, where i detail the process. the "feedback to umichigan" thread is particularly good, since i cover a digitization from start to finish, in detail, but the posts titled "monday morning quarterback" and "continuous proofreading" also have additional pointers. and if a dozen such people should (miraculously) appear, let me know, and i will activate my site that allows people to walk through the digitization process step by step, with single-focus web-apps that help them negotiate each task. -bowerbird

1 0

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

14 Oct '12

#7. d.p. post-processors were recruited with "you can do it your way." #8. if your workflow has no supporting tools, you have no workflow. #9. this list has proven it can ignore a solution put right in front of it. #10. that is where these threads always go, and nothing has changed. -bowerbird

1 0

Re: [gutvol-d] A couple examples of lost books
by don kretz 13 Oct '12

13 Oct '12

Sorry, I don't get your point. That I'm wasting your time? Sent from my Phone From: David Starner Sent: 10/13/2012 2:45 AM To: Project Gutenberg Volunteer Discussion Subject: Re: [gutvol-d] A couple examples of lost books On Fri, Oct 12, 2012 at 6:33 PM, don kretz <dakretz(a)gmail.com> wrote: > http://en.wikipedia.org/wiki/Historical_Archive_of_the_City_of_Cologne > > > http://www.smithsonianmag.com/history-archaeology/On-the-Hunt-for-Jefferson… Er, exactly. One is the destruction of not books, but records, and the second is someone having problems buying exact copies of the exact printings that Thomas Jefferson had. There's nothing in the second article to say, of the 297 copies they don't, how many they have either a comparable early edition, or microfilm or microprint or photocopy of a comparable early edition. As they say towards the end of the article, some of them might not even exist at all, or be parts of other works that they and everyone else has copies of. -- Kie ekzistas vivo, ekzistas espero. _______________________________________________ gutvol-d mailing list gutvol-d(a)lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d

1 0

A couple examples of lost books
by don kretz 13 Oct '12

13 Oct '12

http://en.wikipedia.org/wiki/Historical_Archive_of_the_City_of_Cologne http://www.smithsonianmag.com/history-archaeology/On-the-Hunt-for-Jefferson…

2 1

keep yer damn paws off my markup!
by Bowerbird＠aol.com 12 Oct '12

12 Oct '12

carlo said: > Why should you need to reverse engineer epubmaker, > when you can directly read the source code? oh yes, ignore what the program actually _does_, and try to puzzle out, by reading its source code, what it's _attempting_, and why. that's the ticket! but seriously, folks... isn't it spelled out clearly what the program does, in its documentation? oh... right... i see... ok... don said: > Or better yet find out what it wants for input > so it doesn't need to do transformations. my land, yes! engage marcello in some _dialog_! (i'd love to see that; i'd even take him out of my kill-filter to watch the fireworks on that thread.) but seriously, folks... perhaps the .html should have a comment saying: "keep yer damn paws off my markup! no transfo!" -bowerbird p.s. sorry, i've been ingesting too much huck finn.

2 1

blah blah blah feasibility blah
by Bowerbird＠aol.com 12 Oct '12

12 Oct '12

jeroen said: > I know my ePubs are far from perfect, as, > since I am unable to submit them to PG, > I lack some motivation to improve them. your desire to try to improve them is commendable... > I've only been able to test them on PC based readers, > which are in general far more forgiving than > the small devices they are meant to go on. they are often "more forgiving", yes, but the real issue is that the chips in our hand-held machines are weak... a lot of hacking is being done in the reader-programs to offset the major lack of power in those hand-helds. > I normally use Calibre to read, > now have also installed nook for PC and ADE. none of the people who make e-books for a living will have anything to do with calibre, not even to just "read". nook for p.c. is also quite squirrely, and sadly, so is a.d.e. (if it weren't for its d.r.m. lock-in which locks in libraries, a.d.e. would have no customers at all; readers hate a.d.e.) there is really only one .epub platform that matters at all, at least at this time, and that's apple. so you need to test on an ipad. i recall you dissing apple, as proprietary, and i understand that. but if you wanna go where people are... the other thing that most people would have to think about is whether their .epub converts nicely to .mobi by kindlegen. because kindle is where the vast majority of people are now. and if you're gonna feed your .epub to kindlegen, then you will also need to factor that fact into your work-flow as well. but since you're working from a master-file, you should not chain your conversions. instead, write mobi-friendly .html. and feed _that_ to kindlegen. separate it totally from .epub. that will also allow you to generate another version for kf8. don't listen to anyone who tells you that kf8 is just like .epub. to put it bluntly, they do not know what they're talking about. .epub has an .xhtml base, whereas kf8 jumped up to .html5. (people will tell you .epub3 does .html5; don't believe them.) > I have regenerated the file with some fixes you suggest, > and re-uploaded to the same location. a word of warning, just so you know. the state of .epub uniformity is shockingly bad. what "works" on one platform might not work on another one. at some point, you need to shrug it off when something "fails". as long as the file, as a whole, works on _one_ platform, then you've done about all you can be expected to do. seriously... (and, as i said up above, the platform to shoot for is apple's.) each of the viewer-applications -- every single one of 'em -- supports only a subset of c.s.s., and sometimes a small one, so any expectations you might have that something will work -- or "should" work, or whatever -- will need to be _verified_. so don't even bother trying to get _everything_ right, because it's just not possible at this time. and you should be told that. (but again, don't use a.d.e. as a guide, because it's the worst.) > Doesn't reproduce for me on any of the PC based readers. > Probably has to do with the width of the table. whether something works on a pc-based reader means nothing. > (but that is really a task of the rendering device, > I can only add hyphenation hints...) expectations any hand-held viewer-app will handle _anything_ are not well-founded. so you do yourself no favor by trying to shift responsibility to them. they will not honor your to-do list. so if you don't want to -- or cannot -- handle a thing yourself, you need to just tell people "sorry, you cannot have that now"... similarly, it does no good to say "i'm following the specification", since the viewer-apps don't give a tinker's damn about the spec. i know this is not what people would like to hear. but it's true. > Again, I do not observe this with the browsers I use to test. and again, you can't use a browser to test out your e-books... i know, i know, the format wonks tell you that "it's just .html", which leads you to believe that if the .html works "someplace", it should work _anyplace_, including in an e-book viewer-app, but the fact is that that does not accord with our reality today. it would be very nice if you could use a browser to test stuff. but you can't. so don't even try. you will be fooling yourself. > This must be an issue with devices. ok, so i'll say it one more time. if you really want to care about what your e-books look like, you can't use this dodge. better just to say "ok, i don't care." -bowerbird

6 8

huckleberry pudding.003
by Bowerbird＠aol.com 12 Oct '12

12 Oct '12

fresh pudding for your friday night dessert! :+) > http://zenmagiclove.com/huckf/wisdom.py > http://zenmagiclove.com/huckf/huckf-005.zml still no italics, but i do think the paragraphing is good. and i tried out my first pass at layering in the graphics: > http://zenmagiclove.com/huckf/huckf-001h.html room for lots of improvement, but ok for a first draft. have a nice weekend! :+) -bowerbird

1 0

several small-to-medium-size units of work
by Bowerbird＠aol.com 12 Oct '12

12 Oct '12

don said: > The path away from the quagmire > needs to reintroduce simplicity, and > especially single simple jobs that > iteratively improve a piece of text, > with immediate gratification. > There probably need to be several simultaneous > small-to-medium-size units of work that > offer closure and positive reinforcement you said all that before. > for the benefit of people who > don't have toolchains they know intimately > and have been refining for years; > and other people who can be > persuaded to adopt and learn them. ok, dude, fine. but i'm guessing that, once you have your little system that everyone buys, your start-up page will look like this: =============================== > > "book-dig" -- for book digitization... > > thanks for helping to digitize books! > > "book-dig" is a system to _finalize_ > a paper-book that's being digitized. > > a person who's done the bulk of the > preliminary prep and o.c.r. clean-up > can then use "book-dig" to let other > volunteers help polish off the book... > > (book-dig also lets you do finalization > by yourself if you prefer to do that, or > don't want to have to "recruit" people.) > > this "finalization" process helps to turn > corrected o.c.r. into a refined e-book... > > in some circles, this has been known to > be called "post-processing", as if it were > just an "afterthought", but professionals > know these tasks _are_ "the processing". > > but that doesn't mean it must be difficult. > > by breaking it into a series of small tasks, > it actually becomes simple (and fun) to do! > > *** > > step through these tasks to polish a book. > > (you probably should do the tasks in order, > since the later ones depend on the earlier, > at least until you have enough experience > to know if/when it's ok to go out of order.) > > * task #01. check paragraphing. > * task #02. check doublequotes. > > * task #03. check any flags left. > * task #04. check formatting. > * task #05. check illustrations. > * task #06. check the styling. > * task #07. check hyphenates. > * task #08. check singlequotes. > * task #09. check look and feel. > * task #10. check dictionaries. > > * task #11. search function. > * task #12. fix flagged items. > * task #13. there is no 13th task. > > * task #14. final certification. > * task #15. prelim read-through. > * task #16. final read-through. > * task #17. mount the book. > * task #18. check the mount. > * task #19. open up champagne. > * task #20. start the next book. > =============================== so, you know, if you need to "borrow" this design, go ahead. i figure you'll get around to it in 8 years. -bowerbird

1 0

several small-to-medium-size units of work
by Bowerbird＠aol.com 12 Oct '12

12 Oct '12

don said: > There probably need to be several simultaneous > small-to-medium-size units of work > that offer closure and positive reinforcement. at the beginning of this year, when we had this same thread, i coded an entire workflow of single-purpose components... mercifully, the thread dribbled away, and i can't even recall if i mentioned it, because i was glad all this misery stopped. and now that it's been started again, i haven't mentioned it, because i'm still hoping this current thread will die as well... (y'all are not just sadists, it seems, you are also masochists.) but perhaps i will show you what i've done the _next_ time someone is foolhardy enough to bring up this b.s. again... which i'm thinking should be right around june of next year. -bowerbird

2 1

huckleberry pudding.002
by Bowerbird＠aol.com 11 Oct '12

11 Oct '12

got a new version of huck finn up... :+) > http://zenmagiclove.com/huckf/wisdom.py > http://zenmagiclove.com/huckf/huckf-004.zml it's getting really clean now. time to splice in the italics. i used a brain-deadish approach with the aux dictionary, partly because i wondered how difficult it would make it, which was _not_ a smart decision to make with this book, and all the funny spellings twain used for the "dialects"... i left a few really bad pages, so you could see the horror. > page 67-73 > page 111-114 > page 151 > page 182 > page 202 lots of words flagged in red on those pages... (at any rate, with the words almost fully correct, and reflecting a very close relationship to the actual scans, what with retaining page-breaks, line-breaks, and even end-line-hyphenates, this particular version of the file is quite close to the type of file jon hurst was suggesting. of course, it's silly not to mark the italics. i'm just sayin'.) *** here's the version of huck finn that i'm using: > http://archive.org/details/adventureshuckle00twaiiala that's the version that has been downloaded most often -- some 14,508 times, according to their listed figure -- and it's also the one which they themselves used for their first demo of their online web-based scan-flip program, for which brewster had been lusting since the first time he saw a similar program running in the british museum. and -- as fate would have it -- it is also a version which has lost its em-dashes from its o.c.r. file, i'm sad to say. (meaning i had to scrape the text from the abbyy.gz file.) > https://ia600506.us.archive.org/5/items/adventureshuckle00twaiiala/adventur… that's right, its most prominent version of "huck finn" is fatally flawed, and nobody cared, or even noticed much. (yet another demonstration that normal people don't even need full clean digital text of a book. which is not to say that society wouldn't benefit by having a complete library of clean digital books; but "society" isn't too willing to pay for such an asset, so i guess we don't really _deserve_ it.) but in spite of my own general preference for digital text, i will admit that the archive.org book-flipper is awesome. > http://archive.org/stream/adventureshuckle00twaiiala#page/122/mode/2up indeed, on an ipad with good wifi, it's a great experience. you can have a 2-up page-spread view, which is nice, _or_ switch over to single-page display if you want bigger text. and, with this huck finn, you get all the great illustrations, plus the lovely design with its rustic olden-dayes feel to it. *** anyway, i wanted a little more than book-flipper offered (such as the ability to save the scan-files to my own site), so i did a primitive-but-with-special-tricks version of it: > http://zenmagiclove.com/scanarchiveorg.py buttons at top-left switch between "huck" and "mcguff"... the "huck" scans are pulled from my site, but the "mcguff" ones are called from archive.org, so you might notice that the page-numbers are incorrect, because archive.org was not smart enough to put page-numbers in its scan names. (the stupidity that i have to deal with is so mind-boggling.) this special-tricks app will be very useful to me long-run... *** more later. because you don't get enough torture... :+) -bowerbird

1 0