July 2005 - gutvol-d - lists.pglaf.org

re: [gutvol-d] In-Reply-to
by Bowerbird＠aol.com 27 Jul '05

27 Jul '05

brett said: > Do you know why you don't have > an in-reply-to header in your list emails? nope. could be because a.o.l. didn't implement thunderbird correctly. i always find that blaming a.o.l. is the easiest explanation. :+) but sometimes i am wont to compose a new e-mail -- instead of hitting "reply" -- which could cause that. so this is an experiment where i hit "reply all" instead; let's see if doing it that way will have the desired effect. i don't mind much if my posts appear outside of a thread. most threads here are ones i don't want to be in anyway. ;+) but if this works, and it will make someone's experience here better, i'll be happy to make sure to do it this way. -bowerbird p.s. just so there is some meat in this post, let me say that i think it is rude to flood people's e-mailboxes with _dozens_ of posts on a weekend, when many people don't check e-mail, if you are then going to sit silent for the next two or three days. and it's not only rude, it's ineffective, because most people will just delete all the posts without reading them, which fractures the attention-span of the list. so it effectively sabotages a list. not saying that was anyone's _intention_. but it has that effect.

1 0

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

27 Jul '05

jon said: > This example illustrates that as we begin > considering how the PG collection can > become more useful to more users in the future, > PG will have to require the digital texts to be > more carefully and strictly structured thankfully, that does _not_ require heavy markup, just a consistent dedication to an intelligent design. -bowerbird

5 4

re: [gutvol-d] 600 dpi vs. 300 dpi for text (a quickie visual experiment)
by Bowerbird＠aol.com 26 Jul '05

26 Jul '05

jon said: > Do any of the above mentioned projects have public discussion forums > that match gutvol-d and the DP forums for volume and diversity of topics? it depends on where i'm sending posts at any given time. and not much else. -bowerbird

2 1

Scan file naming -- another comment
by Jon Noring 25 Jul '05

25 Jul '05

Bowerbird's thoughts on scanning is a good summary of some of the issues. And despite his view that we've gotten off-track on the discussion, his points about filenaming, image processing (deskewing), etc., align pretty well with the ongoing discussion. Regarding scan filenaming, he rightfully notes that a source book (or Work) identifier be prepended to the filename. This is what I have also proposed. Where we differ in filename convention is that I believe right after the source ID be a sequential number which describes where the page side is in the linear order of all the page sides in the book (totally independent of how the publisher may have paginated the book.) This way one will unambiguously and immediately know the position of every page scan in the bound book (starting with the inside of the front cover, which can be "side 1", and end with the inside of the back cover -- alternatively we can start with the front cover as "side 1" which has some advantages with respect to the dominant recto/verso page numbering convention.) All blank pages will be included. Now, this sequential number will not correlate at all with whatever pagination the publisher uses to 'id' the pages. So, after the sequential number we have a third field in the filename which gives the actual publisher supplied page number (if any; can be implied). This way we decouple the publisher pagination with the page sequence in the book, thereby simplifying the system and making it more flexible. It will be able to handle *any* bizarre pagination system the publisher/author dreamed up (the publisher could number the pages backwards for all we care, and this system will handle it without any complications -- yet we preserve the publisher-supplied page "number" in the filename which is important for referencing/citation.) Example: DP0000239-00125-106.png "DP0000239" is the source book identifier, here a DP identifier. If the scan project is independent of DP, it could be 'PG0014239' to associate the scan set with PG text number 14239. "00125" says this is the 125th "side" in the full sequence of sides in the book, starting from the front cover or wherever else is considered the starting point. "106" is the string (which can be more complicated like "A2", "5-4", "ix", "ABCD" whatever), which the publisher printed on that page to identify it (that's really what a publisher-supplied page "number" is: a page identifier.) (My proposed system has a couple more fields after these three, dealing with exceptions and generation of the scan set from the original, which aid in keeping tracking of multiple derivative scan sets and a few other oddities. The details are described in previous messages.) Jon Noring [Note: In the "My Antonia" project, it is interesting that there is no "Page 1" and "Page 2". The book starts (after the Roman numbered foreword section) with Page 3! Now imagine getting a scan set of "My Antonia" where we have defined page scan sequencing using the page numbering the publisher used (which are the systems proposed by Marcello and Bowerbird.) The first question I will have is "where are pages 1 and 2? Are they missing from the set?" However, if the scans are sequentially numbered based on their position in the book (with the knowledge the book passed QC checking), then I would know that at least the project saw this, too, and likely there were no missing pages, thus it is likely Page 1 and 2 never existed. And for those who will ask, before scanning the book I took it apart to determine if there was a page which got ripped out there, but there definitely was no ripped out page. There might have been an inserted/ glued plate which "fell out", but checking with the "My Antonia" experts there definitely was no such insert in the First Edition. How many other books start pagination of the body with something other than 1?]

7 25

re: [gutvol-d] re: greg offers diskspace for real live examples
by Bowerbird＠aol.com 25 Jul '05

25 Jul '05

greg said: > If you'd like to just make smaller stuff > available to me via email, I can upload it there. > Or, I can set up a username for you to ftp/scp > or otherwise get content to. thanks. probably better if i can do it myself, so as not to trouble you. thank you very much. -bowerbird

1 0

re: greg offers diskspace for real live examples
by Bowerbird＠aol.com 25 Jul '05

25 Jul '05

greg said: > The "say" is that we're all anxiously awaiting any completed eBooks > demonstrating any or all ways of doing things. ok, i will take you up on that. i've prepared some material, and programmed a demo app. where can i upload it? > There will not be any decision about the official way of doing things > (if there ever is) until some people create demonstrations. well, i've created one demo already, and will make more. but... how about if you correct the examples you've already got up, on the basis of the constructive criticism i've already offered? until you've done that, you're not really ready for many more... > It's clear that light programming at gutenberg.org > to make a given demo work is available. i don't need any programming help, thank you, just some server-space to upload my examples. and, so that i can make examples using your content, i need for all of your scans to be individually available, rather than bundled up into a .zip file, or a djvu file... > So is server space there or elsewhere. just give me a u.r.l. where scans will be located. one thing that hasn't been discussed thus far is the generation of a "scan-set" for the e-texts that are a "new" project-gutenberg publication, i.e., an amalgamation of _several_ source-texts. (jon, try to control that sputtering that is about to well up in your throat right now; it will soon pass...) ;+) for the sake of completion across the library, they should have an associated "scan-set" too. *** nonetheless, greg, i think you're getting a bit ahead of yourself here, aren't you?, and falling behind at the same time. or at least doing things in the wrong order. there's lots of scan-sets sitting around. it won't do much good to put more up until you know what you want to _do_ with them once they've been put up... i know what you _should_ want to do with them, but i don't get the feeling that _you_ do. (or they'd _be_ up.) so why don't we all discuss _that_? once you've got that figured out, then i'll deliver to you the app that you need, and the decision about how to structure your scan-sets will be a lot easier to make. it's been rather entertaining to watch the silliness of people making design decisions without much awareness at all of the tasks for which those decisions are being made. and no, i'm not going to "just tell you". (well, i already have, several times now, but i guess that's beside the point, since nobody appears to be listening very well.) you don't deserve to have the answers handed to you. further, if you have to tell me what you want before i deliver it, you won't be able to deny that it is right once i have delivered it to you... so c'mon, show me you're smart enough to figure out on your own what you need here... -bowerbird

2 1

here are the suggestions that should be accepted
by Bowerbird＠aol.com 25 Jul '05

25 Jul '05

jon said: > Well, we've both had our say, > so let the few others who > are following this topic > decide for themselves. how about instead we have people forget about what you said so they can pay attention to what i said? :+) the system you want to lay on people is so convoluted from the standpoint of their _actual_ workflow right now that they reject what you say out of hand, and end up unwilling to discuss the topic. and that makes it all that more difficult to get them to accept reasonable ideas. as david put it: > That is true. That will continue to be true > what ever standard is agreed upon, since > people aren't going to suddenly change > their scanning patterns based on what the > final product, a long ways down the line, looks like. now, the reality of the situation is that a change in their "scanning patterns" might well _improve_ their work flow, make them more efficient, and so on. but since you don't understand that flow -- and since they know that you don't -- you can't really hope to talk at that level. i'm sorry to have to keep on harping that you don't know what you're talking about. i'm aware that some people hear that and think i'm some mean person dumping on you. the truth of the matter is i don't like saying it. i don't like that you make it necessary to do so. but _somebody_ has to level with you, jon. take another example, from your latest post: > But your system requires that each image, > when it is first saved, needs a human being > to eyeball the page, determine the publisher > supplied page number (if any; may be implied), > and then manually save the page > using the publisher number. so i tell you again that you need to look at the auto-naming feature in your scanning program. it saves the page automatically, then increments the page-counter in anticipation of the next file. (if you don't have such a capability, you really need to get yourself a more modern program. but since it was common even a decade ago, i assume that your program has this feature.) auto-naming is what most all d.p. scanners use. they don't enter a name for each individual file, as that would waste energy and slow them down. they get into a dream routine where their body is flying in a ritual of page-turning and positioning. some of 'em can scan hundreds of pages an hour. if you had scanned in more than a few books, and scanned 'em in the manner that d.p. scanners do, you would know this, and you wouldn't say things so inconsistent with the reality of their processes. *** here's what _really_ needs to be done to take page-image scan-sets public... 1. scanning should be done such that the auto-naming of the scanned images fits the outcome we want them to have. however, if the scanner for some reason cannot or did not do this, it's no problem, as our tools can rename the files _easily_. i developed such a renamer using an e-text that had unnumbered plates and blank pages (some of which were scanned and some not), plus a whole raft of missing pages (part of an english/hawaiian facing-translations section), and so on. and the renaming tool worked fine. 2. quality-control needs to be done _during_ the process of scanning, so errors (like missing pages or duplicates) are caught when they can be fixed easily. i believe d.p. scanners have learned this. you do a visual inspection of each page, to make sure it is acceptable quality, and then a check where you step through all of the images checking their page-numbers to confirm you got every single one of 'em. again, regular d.p. scanners do this already, because they've learned that it's worthwhile. finding bad pages after fact = pain in the ass. 3. all of the scans need to be _cleaned_. they need to be deskewed and regularized, both in terms of size, and placement of text. since this job can be done fairly automatically, without much need for human intervention, and since it will help the o.c.r. accuracy, it should be done _before_ the o.c.r. the original files can be discarded; the foibles of scanning are unimportant. i have not lobbied on behalf of such cleanup before because i figured d.p. would learn it sooner or later. (now if only the large scanning projects would too!) but if you take scans public, they must be cleaned. but again, if this wasn't done originally, it can easily be done later, since it is generally rather automatic. 4. the o.c.r. process should output individual files, so as to retain the linkage between text and its scan. at this point, any weirdnesses in the page-numbering can be addressed, and blank scans inserted if needed. i won't get into the reasons why now, but these files should have all styling (margins, italics, etc.) saved! folks, do _not_ strip your o.c.r. files to plain-ascii! 5. the posted e-text-files -- ascii, html, all of 'em -- need to have the page-breaks indicated in some way, so that end-users and their tools can easily correlate the text with the exact page-scan from which it came. so pagebreaks must be retained every step of the way! stop discarding this useful information from the files! if you need input on how to represent them, ask me! 6. all the way through the cleaning-up of the text, a person should be able to deal with one page of text _or_ with the entire book, whichever is convenient for the particular clean-up task at hand at the time. this is, of course, a function of the _tools_ they use, rather than the scan-set per se, but i mention it now since the implication is you'll need to be receptive to feedback and requests you get from your toolmakers; an example of that is my input on naming of the files. 7. every page-scan should be accessible separately. bundles -- such as djvu and .zip -- can also be made, but the world must be able to grab each page-scan _individually_ when one is all that they want to see; it's unreasonable to expect 'em to download 'em all. 8. a system of "continuous proofreading" should be initiated to make the best use of these public scans, as it will leverage the immense power of user eyeballs to march the e-texts toward an error-free perfection. 9. any all-image-format should be easily ported to the current and future platforms that can utilize it, like the sony playstation portable and the nokia770. it would be great if you offered such porting online. i'll be offering it as a feature in my viewer-program, with the text-file as input, but it would be nice if you could offer it using the original page-scans as well... 10. whenever possible, the converted e-text should accompany the scans, to overcome the weaknesses of an image-format (e.g., the lack of searchability, the inability to copy-and-paste text, and so forth...). -bowerbird

1 0

re: [gutvol-d] why is michael hart being censored?
by Bowerbird＠aol.com 24 Jul '05

24 Jul '05

not good enough, jon. not even close. i see no long-timers on your listserve being moderated _except_ michael. you are not wise enough to judge him; his visionary status is too well-proven, while your crystal ball is badly cracked. you've got 21 hours left to right the wrong. -bowerbird

1 0

why is michael hart being censored?
by Bowerbird＠aol.com 24 Jul '05

24 Jul '05

a rather alarming thing has come to my attention. it seems that michael hart is being censored by jon noring over on jon's listserve. messages from michael appear to have to be "approved" before they are posted to the list. the evidence is sitting right there in the "headers" to see. jon, is this actually the case? i demand you confirm or deny. if so, i find it quite preposterous. love him or hate him, michael hart _invented_ e-books. when a lot of people were just flapping their mouths, michael sat down and started _typing_ various books into the computer and making them available globally, for _free_. and that's as in beer _and_ as in speech. if any person has earned the right to speak freely about electronic-books, michael has. (and let us remember that no one needs to "earn" this right in the first place; the right to speak freely is an inalienable human right -- one recognized in the charter of the united nations.) unless michael is allowed to post freely on jon's listserve, without having to go through the "mother may i" routine of having posts "approved" by jon or any other moderator, i -- for one -- will cease to converse with noring in any way. you've got until noon on monday to fix this egregious error, jon. -bowerbird

2 1

Who would like to donate page scan sets? (Independent of DP)
by Jon Noring 24 Jul '05

24 Jul '05

Obviously, there's significant interest among many PGers to submit scan sets of books to the PG archive to be linked to (augment) the etext versions. Thus I am doing a preliminary survey of those who work independently (that is, who don't submit their work through DP) who have scan sets of books that they'd be willing to donate to the cause. If you have scan sets to donate, let me know in private email what you have. Include number of books, the approximate total disk space they take up, and the general properties of the scans (resolution, color depth, image format, how they were created, file naming convention, etc.) Of course, Don't Send Me Any Scans At This Time! I'm not prepared to take donations until I get a better idea of the magnitude of what's out there, and its general condition. Then it will be clearer as to how to proceed with the submission stage. Thanks! Jon Noring

1 0