- gutvol-d - lists.pglaf.org

encoding choices
by Jim Adcock 26 Jan '12

26 Jan '12

Stating the obvious, lately we have been having a lot of heat about what I will broadly describe broadly and hopefully without perceived prejudice as "encoding choices" -- a subject which is often described [incorrectly] as "file formats." IE a volunteer transcriber, "at" PG or DP or somewhere else, using a combination of OCR, blood, sweat and tears, and other "helpful" tools, makes choices, independently or directed, about what and how to encode the information which they see in that book, that which they feel is important to record -- or that which they decide is unimportant and should not be recorded. At this point in time one or another persons on this forum immediately jumps up and down and says "I have THE solution!" I would like to suggest that any such proposed "solution" must include a discussion and decision about what to actually encode, and what not to encode, and I would also like to suggest that any proposed "solution" [including those currently in use at PG and DP] should encode that which that format chooses to encode *unambiguously.* IE if a particular format and/or encoding scheme claims to encode a particular piece of information, but does not do so unambiguously, then in fact it is NOT successfully capturing that piece of information. Below, as a reminder, is a list of things that various volunteers choose to encode, or not encode, and which various encoding schemes support encoding unambiguously, or which do not support encoding unambiguously. To state the obvious: At least part of the problem is that the people on this forum have wide DISAGREEMENT about which of the following items should be encoded unambiguously, which is to say successfully, which should be ignored, and which should be recorded ambiguously [???]. [I have cribbed a lot of this from DP, but I could just have well cribbed it from the TEI community, or most good books on typography] As an example, and to start this throw-down, I will simply state from my point of view that "how discolored with age the paper stock is" is really NOT an important thing to encode from my point of view! [Since I would rather see a representation of the book "as-published" not "as-found"] PS: defining "unambiguous coding" means: "those who propose that file format or encoding can write a computer program to extract that particular piece of information from their files 100% successfully 100% of the time without error and without heroic coding efforts." ====== book-title author illustrator translator publisher publication date glyph paragraph blockquote poem-stanza poem-line poem-indentation-level epigrams thought break page break horizontal rule spelling (choice of) capitalization bold italic underline small-cap gesperrt illustrations color of paper stock how discolored with age that paper stock is captions drop-cap alternative font use distinctive font size changes author-specific eccentricities in use of punctuation author-specific eccentricities in use of spelling nationality of spelling, punctuation and/or style of typesetting tables superscripts subscripts page numbers line numbers page references page numbers TOC index Preface left-vs-right alignedness justification letter signature salutation "foreign" words language (of original work) language (of this publication) language (of a subsection of this publication) handedness (of punctuation) Foreword Introduction Front Material Prologue Epilogue Appendix References Conclusion Glossary Summary Acknowledgements Bibliography Advertisements Front Matter Back Matter Ex Biblio decorative marks decorative rules printers' [stock] art illuminated-letter black-letter first-letter-color punctuation spacing line-breaks foot-note side-note end-note all-caps chapter title chapter subtitle section title section subtitle hyphenation half-spaces contractions (form of)

3 6

mistakes as big as the grand canon
by Bowerbird＠aol.com 25 Jan '12

25 Jan '12

al said: > - n-tilde - converted to plain "n". > The only word I'm aware of where > this is incorrect is cañon/canyon. ok. > The example Roger mentions in 35833 is a mistake whew... i was worried there for a minute that there'd be some instances in the p.g. library of "grand canon", you know, the one in arizona... i'm glad to hear that wouldn't hap... oh, wait... > http://www.gutenberg.org/files/756/756-h/756-h.htm > http://www.gutenberg.org/files/15807/15807-h/15807-h.htm those two were done by some "al haines". and don't chuckle too much just yet, d.p., because: > http://www.gutenberg.org/files/12883/12883.txt > http://www.gutenberg.org/files/19479/19479.txt plus, as google will inform you, probably many more... -bowerbird

1 0

Re: [gutvol-d] encoding choices
by Bowerbird＠aol.com 25 Jan '12

25 Jan '12

don said: > Seriously, I rhink you'rre on the right track. now don, surely you don't mean to reward such overloading of the word "encoding"... communication here is _difficult_enough._ -bowerbird p.s. iss yourr kkeyboarrd ffunkky? orr arre youu rrinking?

1 0

now imagine it's 2012
by Bowerbird＠aol.com 25 Jan '12

25 Jan '12

ok, now imagine it's 2012. you're not really gonna follow the same people who have been leading you down the completely-wrong path ever since 2004. are you? no, no, surely they don't think you're _that_ stupid... do they? -bowerbird

2 1

but somebody else should tell him
by Bowerbird＠aol.com 25 Jan '12

25 Jan '12

so... it's been three weeks already... but somebody else should tell him... -bowerbird

1 0

(no subject)
by Jim Adcock 25 Jan '12

25 Jan '12

1 0

Re: [gutvol-d] Producing epub ready HTML
by Bowerbird＠aol.com 25 Jan '12

25 Jan '12

the comic chaotic confusion of a compact car containing clowns who constantly keep on coming has always been the emblematic enduring image reflecting the endless amusement of the circus... --bowerbird

1 0

imagine the year is 2004
by Bowerbird＠aol.com 25 Jan '12

25 Jan '12

al said: > It'll be interesting to see who, if anyone, steps up yes indeed. but let's take a look back... *** imagine the year is 2004. p.g. just hit the magic 10,000. and bowerbird comes along telling you that you can use light-markup as your "master" to generate other formats. instead of throwing rocks at him, you actually listen, and even try it out, and -- lo and behold -- it actually _works_. from then on, the library is powerful and state-of-the-art. none of your people have to waste any of their time making .html versions, because that's done for them automatically... same with the .pdf versions, which were big in the early days, and various other formats which people wanted at some time. and because p.g. is the go-to source for _all_ of the formats, there's no niche for the repackagers to get a toe in the field... especially as the conversions become extremely well-honed. this means when google and internet archive start scanning, project gutenberg is the clear leader, so they both fall in line, because hey, there's no need to "fix it" since it ain't "broken", meaning those projects end up with very different workflows, which prioritize text over scans, and exalt cleaned-up o.c.r. moreover, when amazon decides to get in the game big-time, with the .mobi format they bought, p.g. is the place which has "been there, done that" all along, so p.g. remains out in front. plus, everyone knows -- they can see it with their own eyes -- that a plain-text format can still provide us with e-books that are beautiful, functional, and powerful, so there is no need to use clunky formats like .html or .xhtml or .epub or .whatever. further, since e-book authoring is a breeze -- because p.g. has paved the way to show how simple it can be -- self-publishing takes off sooner, so the money-grubbing corporate publishers go down faster, and we get a jump-start on a new cultural era. it's win-win for everyone, with p.g. up at the head of the class. that's what _could_ have happened. what happened instead is that many people here were stupid, and stubborn, and mean enough to form an attack-pack, and the result is a confused mess which persists to this very day... so i really hope you people -- and you know who you are! -- are proud of yourselves. because you messed up really badly. -bowerbird

1 0

whitewashers don't have to put up with real solutions
by Bowerbird＠aol.com 24 Jan '12

24 Jan '12

someone nested in several layers of quotes said: > Is this an exclusive 'or' or an inclusive 'or'? to which there is only one good reply: who's on first! *** al said: > Much of PG's assorted FAQs > might be candidates for update, but > the bulk of them have stood the test of time. > The questions are, who's going to update them, > how much argument from the cheap seats is going > to ensue, and since two of the three main complainers > in this forum don't submit anything anyway, > why should any updater put up with those complaints? hey wait, al, am i one of those "three main complainers"? if so, mr. haines, am i one of the two who "don't submit"? because, technically, i _have_ actually made a submission. moreover, i don't think i've ever lodged a complaint about a _f.a.q._, because i'm not sure what the point would be... and -- you know, i do really hate to be a nitpicker, but -- i think it's important to note that i don't just "complain", i also offer an _alternative_ that will _solve_the_problem_. finally, _i_prove_it_works,_right_in_front_of_your_face._ too bad that you'd usually stopped listening much earlier -- meaning you often miss the fact that proof is given -- because why should you "put up with those complaints"? -bowerbird p.s. that's what i'm asking! who's on first? p.p.s. yes! p.p.p.s. the cyberarchaeologists will have a field day with this thread. i swear they will laugh for a week and a half! i mean the _inclusive_ "and" when i say "week and a half".

2 1

Re: [gutvol-d] Producing epub ready HTML
by hmonroe.pglaf＠huntermonroe.com 23 Jan '12

23 Jan '12

There is a golden opportunity here for someone to create an automated tool to assess the use/misuse of HTML which PG could use to screen submissions--see my earlier post with some simple tests written in Perl. I would be happy to host development of the tool under the Guiguts sourceforge project. Also badly needed is an update of gutcheck the corresponding tool to evalute .txt submissions--it has not been changed since 2005 and cannot even count the number of characters per line if the line contains Unicode. Provide me with your sourceforge ID and I will give your access rights. If it were up to me I would write these tools in Perl not C (since Guiguts is in Perl), or it could be an enhancement to HTML Tidy but my only request is that the errors/warnings generated look like "linenum:columnnum This line is wrong: <h1>Chapter</h2>" (this allows Guiguts users to double click on an error report to jump to the errors). Guiguts has a "Check All" button which runs W3C validation, W! 3C CSS check, Link Check, HTML Tidy, Image Check, and the rudimentary Epub Friendly check I sent earlier--perhaps these could be part of an HTMLGutcheck tool. I could bundle the tools with Guiguts so they would reach a broad audience even if PG does not immediately adopt them. Hunter > Why aren't WWers send back projects that include destructive layout > tagging, or don't include important structural tagging? I can think of any > number of reasons for rejection that are less disruptive to the reader's > satisfaction. Because we have automated checks for validity and good spelling. We don't have automated checks for (mis-) use of HTML for layout. If we had some sort of automated and relatively unambiguous checks for such things, I'm sure that many submitters would strive to comply. -- Greg

4 6