- gutvol-d - lists.pglaf.org

how long does it take to digitize a book?
by Bowerbird＠aol.com 17 Jul '05

17 Jul '05

some reports tell us that the new harry potter is out in digital form already, thanks to "hackers" who digitized it within 24 hours of its release on paper. unknown is whether it has already been converted to a dozen different formats, in the same manner as the books of cory doctorow, who releases his text freely; his books are commonly converted -- by his fans -- in a matter of a week or so... (his sharp-eyed readers also do a great job of proofreading for him, so good in fact that if i were tor -- his publisher -- i would hold off on the first printing until _after_ they had found the few dozen mistakes that were present in cory's latest book...) -bowerbird

2 1

re: [gutvol-d] RFC: Posting Page Scans in DJVU Format
by Bowerbird＠aol.com 17 Jul '05

17 Jul '05

sebastien said: > Now suppose that in a few years time > 1/ this _Study of ancient Greece_ gets into PG, number 78967 > (in the same edition John Smith used) you've swept under the rug what could be a very important disqualifier. > 2/ some text-crawling program detects its fuzzy quotation > in the Smith's essay > 3/ some robot and/or human reworks Smith's essay to include > hyperlinks to PG text 78967, at the correct page number > (which would land at the right paragraph in the HTML) > and checks them one by one why require those changes to be made after-the-fact? why not build a program that can do all of that _on-the-fly_? without requiring any heavy markup? that's what i'm aiming at. (i've got aspects of this approach working already in my stuff.) the ability of the machine to find links like this automatically -- i.e., without us specifying them -- is extremely important! we want an intelligent viewer-program that knows what we want, _without_ us having to spell out every aspect of it in great detail. > That would be a killer ultimate library! well, it's one step _toward_ that killer ultimate library, anyway. there are a lot more steps that need to be taken on that journey. -bowerbird

1 0

DRM and paper books
by Marcello Perathoner 17 Jul '05

17 Jul '05

"A grocery store in Coquitlam, British Columbia, Canada accidentally sold several copies of the sixth Harry Potter book before the authorised release date. The Canadian publisher, Raincoast Books, obtained an injunction from the Supreme Court of British Columbia prohibiting the purchasers from reading the books in their possession." http://en.wikipedia.org/wiki/Harry_Potter_and_the_Half-Blood_Prince http://upload.wikimedia.org/wikipedia/en/8/86/Harry_Potter_Injunction.pdf -- Marcello Perathoner webmaster(a)gutenberg.org

1 0

re: [gutvol-d] RFC: Posting Page Scans in DJVU Format
by Bowerbird＠aol.com 17 Jul '05

17 Jul '05

people who are building the programs that will use the pagescans need to be the ones that specify the conventions in making them, in consultation with the people who are actually doing the scanning. marcello, i don't see that you have much expertise on either end... that's not to say that your set of recommendations is all that bad. it's not that much different from the set i laid out some time back. (although in the places that it is different, mine is the better plan, reflecting experience in scanning and developing scan-using apps.) in direct response to david, just keep scanning the way you want, the way that works best for you. we can deal with what you create after the fact, if necessary. we'll have some feedback on workflow that we think will be mutually beneficial, but whatever you do, know for now that we can deal with your output, so just keep on scanning. -bowerbird p.s. as i feared, the current examples of pagescans in the library are case-studies in how _not_ to do it, for reasons i will list later...

1 0

re: [gutvol-d] RFC: Posting Page Scans in DJVU Format
by Bowerbird＠aol.com 17 Jul '05

17 Jul '05

marcello said: > Suppose we post a multi-page djvu, where > the filenames of the single-page djvu files it contains > are not in sync with the real page numbers. you mean like the one you created and pointed us to yesterday? -bowerbird

1 0

re: [gutvol-d] Initial thoughts on a PG/DP scan repository
by Bowerbird＠aol.com 17 Jul '05

17 Jul '05

marcello said: > I don't want to unload hundreds of image files on the user. except that's precisely what happens when you bundle them all together. the user who only wants one of the pagescans has to download them all. there are a raft of good reasons why a person might want a single scan. lets think in the pluralistic mentality for which project gutenberg is known. there's no reason you can't have one place that has the individual scans, one that has them zipped up, another that has them as a djvu (both forms), one that has them as a .pdf, and even one where they are a quicktime movie. per lockss, you want multiple copies scattered throughout cyberspace anyway. speaking of pluralism, any all-image format that can't play on a playstation, or on machines like that new nokia770 that's coming out, is a non-starter. > Can you imagine reading Ulysses from 1.000 tiff files? why not? the person is only looking at one or two pages at a time, so the viewer-program only has to open one or two files at a time, who cares how many there are in the whole book? > Is there even any picture gallery software that can handle that gracefully? i'm sure there is. but why use that? instead, use e-book viewer software that's geared for scans. my viewer-program can use scans _or_ text, or even _both_, in combination, for people who want to view them side-by-side (e.g., to do proofing). *** this is a good demonstration of one problem with project gutenberg: you don't have any application programmers helping you lead the way. so you are forced to settle for the least worst program at your disposal, instead of grabbing the bull by the horns and creating the best program. i would suggest that the next time a programmer like me comes along, you be nice to him or her, instead of spitting in their face. -bowerbird

2 1

re: [gutvol-d] XML: Interpublication and deep linking
by Bowerbird＠aol.com 16 Jul '05

16 Jul '05

i'm off the merry-go-round for this round. let me know when the library is marked up. -bowerbird

1 0

re: [gutvol-d] XML: Interpublication and deep linking
by Bowerbird＠aol.com 15 Jul '05

15 Jul '05

jon said: > One argument brought up here yesterday is that > the interlinking of publications, especially deep linking > to spots within documents, is so brittle as to be useless > (e.g., move the resource, the URL changes, voile' the link is broken.) that wasn't my "argument" at all. my argument was that people who make promises about their ability to pull off deep linking cannot back them up _unless_ they posit a means of dealing with impermanence. but if such a means is accepted, _anyone_ can do deep linking. > It does, however, require a unique identifier for each resource. and here it is in jon's post: weaseling via a "unique identifier". heck, if everything has a "unique identifier", _i_ can give you a deep-linking system based on zen markup language. easily. and -- as always -- _without_ the cost of any heavy-markup. you're just shifting the permanence requirement from the u.r.l. to the unique identifier. it's sleight-of-hand, and nothing more. > the W3C suite of related technologies of XLink/XPointer/XPath/xml:id/etc. -- one trick that a hand-waver counts on to distract you is to point to a bunch of acronyms as if _they_ solve the problem. but if you look at them closely, they're mired in the same muck. > It is not *my* system at all (as the poster alluded to), > and makes no difference whether I myself > build some sort of linking system or not. it makes a difference whether _anyone_ builds such a system or not. considering how widespread and well-developed you claim x.m.l. to be, why isn't such a system _already_ developed and out proving its worth? as it is, i see the ability to link to paragraphs, but _only_provided_that_ every paragraph that you want to link to has heavy markup attached. i suppose we could deep-link to every darn _character_ if we wanted to, provided we were willing to bloat up every file to an unbelievable level. (in this regard, see > http://diveintomark.org/archives/2004/05/30/pink-numbers#w200405302127-53 for a silly word-based version.) > To reiterate, XML provides standardized and convenient hooks > for linking and deep linking into publications. you always _state_ that x.m.l. solves the problems. but you never tell us _how_ it solves the problems. you drop acronyms, wave your hands, and that's it. as usual, you're asking people to buy a pig in a poke. and as usual, i'm asking to see the pig, not the poke. -bowerbird

2 1

re: [gutvol-d] Scans and Texts (Re: Copyright Verification?)
by Bowerbird＠aol.com 15 Jul '05

15 Jul '05

greg said: > An automation process, to pull all images from DP > at a time an eBook is posted, is very much non-trivial. copying images from one place to another seems "trivial" enough to me. the non-trivial part will be setting up the ground-rules for the page-scans, and then making the current set of scans conform to those ground-rules... although i would imagine (or hope, anyway) that are smarter now, as recently as last year, i encountered _extremely_ stiff resistance at d.p. for suggesting even such _basics_ as file-naming conventions (e.g., that the scan for page 87 should be named "rootname087.png" not something like "rootname094.png", as was typical.) in a nutshell, if page-scans are maintained in the chaotic way that many other files are being handled in the library, you'll have a nightmare on your hands. one e-text can have literally hundreds of page-scans associated with it; thus, with 17,000 e-texts, we're talking now about 2-4 _million_ files. if you approach a task like that haphazardly, it will bite you back _bad_. simply put, the scans weren't created and haven't been maintained with an eye toward making them publicly available. that's not the _fault_ of the d.p. people, because that was not their concern, but it is a reality that needs to be faced if we want to make them public. it's going to be a _lot_ of work to mold them into something useable. juliet recognizes that -- that's precisely what she was telling people. > But just doing one or two titles as a sample would help. well, that would depend on whether wise conventions are adopted first, or develop out of those samples. if these samples instead merely boost the "do it however you want" idea that permeates the rest of the library, they will do more harm than good. it's also very important to understand that the stimulus here is all wrong. rather than driven by some vague notion that scans "should" be available, a "needs analysis" has to be done to determine _who_ will use the scans, and _how_, so that the policies that are put into place are _wise_ ones. for instance, i might be wrong about this, but i think the current policy is to wrap all the page-scans up into one zip file. there are merits to that, but it's also the case that a zip file is not the best thing for many useful applications, not the least of which is checking the scan of a single page (e.g., to see if an error-report is supported or negated by the page-scan). (in regard to this specific point, i think scans should be stored both ways -- as individual files and as a single zip-file -- perhaps on different servers.) as there is, at present, no user clamor for the scans, we _do_not_know_ how the end-users might want to use the scans, so we're _in_the_dark_ about the factors that we should apply in the development of any policies. so if i were a decision-maker, i would wait until a clamor actually developed before i moved forward on this. perhaps the absence of many volunteers who are willing to actually expend their energy on this project will serve as the brake necessary to keep it from lurching ahead prematurely. > As Juliet & others mentioned, the *archiving* is already being done. > The next step is distribution. well, i would imagine (or hope anyway) that a formally-trained librarian would use the term "archiving" with a little more sensitivity. the scans are being _saved_, but there is a huge gulf to cross before they can be considered to have been "archived". the page-scans as they are now are a _very_ long way from being ready for the "distribution" step... maybe jon can mobilize some volunteers to do all the work necessary. but otherwise, i don't see any people stepping forward at this time... -bowerbird

2 1

XML: Interpublication and deep linking
by Jon Noring 15 Jul '05

15 Jul '05

One argument brought up here yesterday is that the interlinking of publications, especially deep linking to spots within documents, is so brittle as to be useless (e.g., move the resource, the URL changes, voile' the link is broken.) Thus, it is concluded, this particular advantage of XML to enable interpublication and deep linking systems, is not pragmatically an advantage at all. (With XML documents, deep linking can be accomplished using the W3C suite of related technologies of XLink/XPointer/XPath/xml:id/etc. -- in XHTML there is the well-known "id" attribute to enable deep linking using fragment identifiers, which web browsers *now* use.) A recent article by Sam Vaknin shows, however, that there are clever ways to maintain the integrity of links even if target resources are moved around: http://www.webpronews.com/ebusiness/contentandcopywriting/wpn-6-20050712Dig… DOI was brought up as one solution, and DOI is certainly powerful. In addition, the Publication Structure Working Group at OeBF delved into this issue a couple years ago, and although issued no specs, concluded that linking (both interpublication and internal) using a special URI (with embedded XPointer stuff) is possible where the target resource does not have to exist at a particular spot in some network. It does, however, require a unique identifier for each resource. (PG already has a crude identifier system, but because of how it is assigned/structured makes it somewhat more difficult to use for interpublication linking purposes -- a WEMI-based modularized system for identifiers is definitely more powerful and flexible.) The important point is that XML markup provides the needed hooks to enable all kinds of systems to interlink between, and deeplink into, publications. It is not *my* system at all (as the poster alluded to), and makes no difference whether I myself build some sort of linking system or not. To reiterate, XML provides standardized and convenient hooks for linking and deep linking into publications. That's all. This is an advantage, one of several, of using XML for mastering PG's digital texts. That's why mastering the PG texts in XML makes sense: we are preparing the texts not only for benefits today, but for yet unforeseen future uses. Jon Noring

1 0