- gutvol-d - lists.pglaf.org

Re: [gutvol-d] book of james -- 001
by Bowerbird＠aol.com 20 Dec '11

20 Dec '11

i said: > http://z-m-l.com/go/bhaga/bhagap123p.html oops! i got an extra "p" in there. try this instead: > http://z-m-l.com/go/bhaga/bhagap123.html -bowerbird

1 0

Re: [gutvol-d] book of james -- 001
by Bowerbird＠aol.com 20 Dec '11

20 Dec '11

james said: > It will take me a LONG time to finish this text. no it won't... :+) > I'm using archive.org's text file and > I use Jedit and guiguts to get it in shape, > one page at a time. well, with those tools, it might take a long time. but if you instead use a system i'll build for you, you could whip the book out before you know it. but i won't get to it until after christmas... -bowerbird

2 1

a review of some digitization tools -- 024
by Bowerbird＠aol.com 20 Dec '11

20 Dec '11

let's discuss, for a minute, how to prepare a .zml file... for fun, we'll contrast it with how to code an .html file. *** we'll start with something basic -- simple italics. let's say that a word is _italicized_ in the p-book. to do that markup in .zml, you surround the word with _underscores._ you can type 'em in manually, or you might have a tool that has a button that you can click to have the tool insert them automatically. in .html, you'd surround the word with italics tags, so an [i]italicized[/i] word looks something like that. (i changed the angle-brackets to straight-brackets, so an .html viewer-tool will not be confused by it.) again, you can type the brackets-plus-tag manually, or you might have a tool to insert 'em automatically. most .html authoring-tools have an [i] or [em] button. so in this case, for italics, there's not much difference between .zml and .html... one uses underscores and the other uses bracket-commands, but -- essentially -- there's no difference between them. i might think that underscores are easier to type, and easier on the eyes, and thus less obstructive when it comes time to _edit_, but it's hard to argue that there's much difference here. and thus it is with a lot of the mark-up you might do... in .zml, you indicate a blockquote with a leading " > ", whereas in .html you use [blockquote]xyz[/blockquote]. and in .zml, you indicate a list item with a leading " * ". while in .html it's more like this: [ul][li]abcdef[/li][ul]. again, i think the .zml looks a lot less obtrusive, and that is indeed part of the big appeal of "zen" markup, but if zen doesn't matter to you, there's no difference. *** however, there _are_ some cases where it does make a difference when you're tagging in .zml versus .html. for instance, take the case of _headers_... on the face, it might appear to be a similar situation. in .zml, you indicate a header by 4 or more blank lines, follow it with exactly 2 lines, and precede it with a space. so, aside from the blank lines above and below it, which "sets it off" such that the header will gain your attention, a header has a pretty ordinary appearance in your text: > > > > > chapter 7 header > > in .html, you tag a header thus: [h2]chapter 7 header[/h2] so if it was merely a matter of the tagging of the header, this case is exactly like the previous: not much difference. but various other factors come into play involving headers. first, the table-of-contents should _link_ to every header... at a bare minimum, this means your header has to have an "id" that is attached to it, to which the link is directed. so in addition to the _header_ tag, you must make an "id", with another bracket-command, which might look like this: > [div id="chapter_7_header"][/div] so now the header, with its matching "id" spec, looks like: > [div id="chapter_7_header"][/div] > [h2]chapter 7 header[h2] you could leave it just like that. many people do, actually. but .zml does more -- by default -- to aid in navigation. every .zml header links _back_ to the table-of-contents, so a person who is at any header can _jump_ to the t.o.c. to do the same kind of back-link in .html, you'd do this: > [div id="chapter_7_header"][/div] > [a href="#table_of_contents"] > [h2]chapter 7 header[h2] > [/a] that's a little more work, but very few .html tools do this, so you'd have to do it manually. but it's still manageable. but there's more. .zml also generates automatic links to the _previous_ and _next_ chapters, so a person can easily "skim" from one chapter to the next, which comes in handy. in order to do this in .html, you'd have to do this: > [div id="chapter_7_header"][/div] > [a href="#chapter_6_header"]prev[/a] > [a href="#chapter_8_header"]next[/a] > [a href="#table_of_contents"] > [h2]chapter 7 header[h2] > [/a] note that this raises the level of complexity quite a bit. the "id" was based on the header itself, so that was easy to generate, because the two are so close to each other. so it would be rather easy to code a reg-ex for the task. but when each header has to know the id of the header which came before it, and the one which comes after it, we have experienced an increase in the difficulty factor, to the point where the reg-ex is gonna get pretty hairy. you will also need some tagging in there to get the links _positioned_ in the exact way that you'll want them, but i won't bother to put in that clutter too right now, as... ...i wish to point out that, all of a sudden, our header has gotten _buried_ inside a lot of .html-tag clutter... which makes it difficult if you need to do more editing. (a rule of thumb is you always need to do more editing.) so again, let's take a look back at the .zml header... > > > > > chapter 7 header > > very clean. everything is automatic. breath of fresh air. *** we can go through the very same exercise for footnotes. in the body of the text, where you have the footnote,[1] you will need to do the .html coding to create that link. [1] at the footnote itself, which might be in the "footnotes" section, you'll need to form an "id" for the link to jump to. and likewise, it's usually nice to have a _back-link_ too. which means you need to have an "id" in the body-text, and code the back-link in the footnotes section as well. and, seriously, that's more than you wanna do by hand. and thankfully, most of the time, you won't need to... many .html tools make it relatively easy to make a link. you just click where you want the link to be, and then click again where you want that link to jump to. easy... at least, it's easy if you only have a few such links... but if there's 580 footnotes, like a book i did a while back, you _will_ want these steps to be performed automatically. my .zml converter does that for you. *** now, don't get me wrong. there is absolutely _nothing_ in my converter-tool that some programmer could not clone in an .html authoring-tool. nothing at all. zilch. indeed, it wouldn't surprise me if it's already been done. (well, actually, it would. a little bit. but i'd get over it.) for instance, the text-to-html converter inside guiguts, the d.p. postprocessing tool, does good on footnotes... it'd even be possible to build an .html authoring-tool which inserted all of this code automatically and _also_ removed it from the file when you wanted to do editing -- so you wouldn't have all that crud distracting you -- only to re-insert it once again after you were finished... it's even possible this tool could be offered at no cost... it's even possible it could be an open-source creation... you will let us know if you find such a tool, won't you? :+) *** z.m.l. input file: > http://zenmagiclove.com/test-suite-2012.txt python script to create .html output: > http://zenmagiclove.com/cgi-bin/t2.py -bowerbird

3 2

Re: [gutvol-d] Recommendations on handling family tree tables - critique wanted
by James Simmons 19 Dec '11

19 Dec '11

Al, I've started on the pages with family trees and I have some samples that I'd like to get some feedback on before I do too many more of them. There are a LOT of family tree tables in this book. TABLE A. (Transcriber's Note: In the original book some tables were turned sideways. For reading as an e-book, these tables have been modified to read left to right rather than top-down). SVÂYAMBHUVA MANU _m.__ SATARÛPA -----+---Priyavrata | +---Uttânpâda | +---_Akûti__ | _m.__ Ruchi +--- KAPILA | | +---_Devahûti__ | | _m.__ Kardama ----+--- _Kalâ__ | | _m.__ Marichi +---_Prasûti__ | _m.__ Daksha +--- _Anasuyâ__ | _m.__ Atri | +--- _Sraddhâ | _m.__ Angirasa | +--- _Havirbhu__ | _m.__ Pulastya | +--- _Gati__ | _m.__ Pulaha | +--- _Kriyâ__ | _m.__ Kratu | +--- _Khyâti__ | _m.__ Bhrigu | +--- _Arundhati__ | _m.__ Vasistha | +--- _Sauti__ _m.__ Atharvan TABLE B. RUCHI _m.__ ÂKÛTI --- YAJNA --------------+ (married his |--+--- Tosha sister) Dakshinâ. --+ | | +--- Pratosha | | +--- Santosha | | +--- Bhadra | | +--- Sâuti | | +--- Idâmpati | | +--- Idhma | | +--- Kavi | | +--- Vibhu | | +--- Svâhra | | +--- Sudiva | | +--- Rochana N.B. The sons of Yajna are the Sushita Devas of the 1st. Manvantarâ. TABLE C Marichi _m. Kalâ__ | | --+--+-----------------+----- | | Kasyapa Pûrnimâ | +--------------+------------+-------- | | | Viraja Visvaga _Devakulyâ__ (River Ganges in subsequent incarnation). TABLE D. Atri _m. Anasûyâ__ | +----------------+--+------------------------+ | | | Datta Durvasas Soma (Rudra) (Brahmâ) TABLE E. Angirasa _m. Sraddhâ__ | ---+----------+-------+-+--------+----------+--------+----- | | | | | | _Sinivali__ _Kuhû__ _Râkâ__ _Anumati__ Utathya Vrihaspati TABLE F. Pulastya _m. Havirbhu__ | -------------+------------+----------------+ | | Agastya Visvaras _m. (1) Ilavila m. (2) Kesinî__ | | Kuvera +------+------+-------------+ | | | Ravana Kumbhakarna Vibhisana TABLE G. Pulaha _m. Gati__ | -----+---------------+-+---------------+--- | | | Karma Sreshtha Bariyas Sahishnu I hope the samples above are acceptable. The only other option I can think of is to treat every diagram as an illustration. Since this book is a translation of a Hindu scripture the diagrams are something we might live without in the plain text version. The samples above should use the Courier font, and there are no tabs in my file. Thanks, James Simmons On Fri, Dec 9, 2011 at 5:26 PM, Al Haines <ajhaines(a)shaw.ca> wrote: > > James, to say you've bitten off a mouthful would be an understatement <g>! To answer your question... > > Highly structured material (trees, tables, etc) (such as that on page 13 and elsewhere) can exceed 70 characters. For reproducing trees in HTML, the simplest method (and the one I've used), is to take the text version of the tree, copy/paste it into your HTML file, and wrap it in <pre></pre> tags. > > For trees with preceding diagrams (page 13 again) insert something like "[Illustration: Purusha]" in your text file, and the actual diagram in your HTML file. > > For extremely wide trees/tables, if any (more than 100 characters, say), split the tree into left and right halves for the text file. At the end of the file, include a transcriber's note mentioning which tables have been treated this way. For HTML, you can rejoin the halves, or leave them as in the text file, again using the <pre></pre> trick. > > I notice that some tables (pages 58, 59) are split across pages. Unless you can figure out how the two portions are joined, it's probably best to treat them as two separate tables. If you can figure how they're joined, it's acceptable to join them, but it looks as though you might end up with an extremely wide table. I'd say to keep things simple, and don't attempt a join. > > From what I've seen of the book, you should be able to render all trees/tables with alpha-numerics. > > Good luck! > > Al > > > > -----Original Message----- > From: gutvol-d-bounces(a)lists.pglaf.org [mailto: gutvol-d-bounces(a)lists.pglaf.org] On Behalf Of James Simmons > Sent: Thursday, December 08, 2011 11:56 AM > To: Gutenberg Volunteers > Subject: [gutvol-d] Recommendations on handling family tree tables > > I am working on transcribing this book: > > http://www.archive.org/details/studyofbhagavata00benaiala > > This is a translation into English of an important Hindu scripture, originally in Sanskrit. Now that I have committed myself to transcribing it I find that it has many, many family tree tables in it. These are not part of the scripture itself, but were added to clear up who begat who. (All mythical characters). Some of these stretch out so wide that the page is rotated in the original. Others could easily be duplicated with ASCII characters in 80 columns or less. > > I've looked at some PG titles with geneologies like this one about Bach: > > http://www.gutenberg.org/files/35041/35041-h/35041-h.html#toc49 > > In this one the family tree tables are treated as illustrations. That would certainly be a simple way to deal with them, but again about half of the diagrams could be done with ASCII text. It would be painful, but it could be done. So do I do half and half, or try and do all text, or just do illustrations all the way? > > Thoughts? > > James Simmons >

4 10

let's get some tutorials from the xhtml crowd
by Bowerbird＠aol.com 19 Dec '11

19 Dec '11

the xhtml crowd needs to do some tutorial threads. you guys seem to have all the answers. so spill 'em! :+) *** i've been showing people to proceed from "raw" o.c.r. but evidently that's old-fashioned... nowadays we just wave our hands in the air, and out pops finished .html. i'm sure all of those poor people over at d.p. would be full of gratitude if you were only to elucidate for them. so teach us the incantations and spells, oh wise ones! (pointers to all those "existing tools" will be good too.) *** meanwhile, alex, what's the story with this script? > http://www-kenh.archive.org/download/artofbook00holm/artofbook00holm_abbyy.… i don't need it myself, because i wrote an app for that. but i seem to remember someone was whining for it... -bowerbird

4 6

a review of some digitization tools -- 023
by Bowerbird＠aol.com 19 Dec '11

19 Dec '11

ok, so let's regroup once again for this new week... this thread's purpose is to review digitization tools. so we need to know what's involved in "digitization". our analysis gave us this: > 1. obtain the text (via scanners, and o.c.r. software) > 2. clean the text (the first set of tasks for our tools) > 2a. do a spellcheck > 2b. fix spacey punctuation > 2c. restore styling, e.g., italics > 3. turn the text into e-books (the second set of tasks) > 3a. tagging the structural aspects of the text > 3b. converting the text into .html (intermediate and final) > 3c. converting intermediate .html into e-book output-files task #1 is largely taken care of for us, thanks to the public output of the major scanning projects. (although sometime this week i'll discuss the issue of how to get the best results from abbyy's output.) task #2 is something we discussed earlier, finding that the jobs can be done fine in a wordprocessor. that leaves us with task #3. on some day this week, i will discuss the specifics of applying zen markup, and that post will cover the main thrust of task #3a. and then, of course, the two "conversion" tasks -- #3b and #3c -- are being performed by the script which we're in the process of discussing right now. *** so we need an application that does #3b and #3c. i do programming. so my first instinct is to code. so if i have a job which needs to be accomplished, once i've coded something -- or tried to do so -- i can compare it with the tools that exist out there, and do an assessment of how everything stacks up. what we'd like, for this app, is one that: 1. creates good html. (gotta do the job, and well.) 2. is cost-free. (because we don't have a budget.) 3. is user-friendly. (because we rely on volunteers.) 4. runs online and off. (so we have multiple options.) 5. is open-source. (because why not ask for it all?) those are listed in decreasing order of importance. but everything through #4 is pretty much required. we need an online component, because we will want our system to be capable of being used in a setting like project gutenberg or distributed proofreaders, a cyberlibrary meant to digitize and display e-books. an online presence is required by such a cyberlibrary. at the same time, it would be best if the tools used by this cyberlibrary could also be run by people offline... if we can meet all of our desires with our own code, it's gonna be hard for any other tool to get traction. so let's see how we do... *** up to this point, the sample content for this thread was "books and culture", by hamilton wright mabie, a book that is distinguished by the fact that it was the very first public-domain book released by the big library scanning project being done by google. it was a simple book, so it was good starter content. but now we want to work on more complicated stuff. what we need, as a "proving ground" for our script, is a good test-suite, with the structures we require. fortunately -- if you ascribe luck to elbow grease -- we have such a test-suite, one that i created in 2005. i've updated it a bit for this thread, and put it here: > http://zenmagiclove.com//test-suite-2012.txt so now let's give our script a new name as well: > http://zenmagiclove.com/cgi-bin/t2.py that's just a first pass, so everything might not look exactly right just quite yet while we get started, but we'll work our way up to handle everything we need. so look at that input test-suite, satisfying yourself that it doesn't have any sneaky tricks up its sleeves, and then take a look at the .html the script creates -- feel free to view the source too, and comment -- and then you'll be ready as we depart on this ride... *** z.m.l. input file: > http://zenmagiclove.com//test-suite-2012.txt python script to create .html output: > http://zenmagiclove.com/cgi-bin/t2.py -bowerbird

1 0

a review of some digitization tools -- 022
by Bowerbird＠aol.com 19 Dec '11

19 Dec '11

keith said: > The convert code has to be substatially equivalent HTML. it will be. > Beware! That is a very strong factor. try it before you ramble off into the hypothetical brambles. > And that prize would go to the developers of pandoc. i have no quarrel with that. but... john is a professor of philosophy at california berkeley. so i sincerely doubt he needs a hundred bucks from lee. somebody should take his money, though, if he'd gonna be dumb enough to leave it laying in the street like that. -bowerbird

2 1

Re: [gutvol-d] let's get some tutorials from the xhtml crowd
by Bowerbird＠aol.com 18 Dec '11

18 Dec '11

paul flo said: > As a PG newbie, I've found the "do what you want" > attitude to be one of the biggest barriers to entry. > I prefer instruction, guidance and examples of best practice. if i would have known you are a "newbie", i wouldn't have even bothered to ask you about your workflow, because you really haven't even developed one yet... still, you did seem to be very firmly convinced that your way was the correct way, and my way was not. > (Another barrier was my own dumb choice of > a 700 page two volume work to start on. Ho hum.) it sounds like the content of the pages is probably even more daunting than the sheer number of 'em. but, you know, that's how you learn... :+) > It's been a 15-month labour of love, > but I'm nearly there now! ouch. if i had known _that_, i definitely wouldn't have asked about your workflow. except as a bad example. i certainly hope that time included several months-long gaps where you did no work except to regain motivation. xhtml crowd: get to work on those tutorials, right now! because your followers seem to be wasting a lot of time! -bowerbird

1 0

a review of some digitization tools -- 021
by Bowerbird＠aol.com 17 Dec '11

17 Dec '11

this week, we looked at the e-book file-formats which were auto-generated for our sample book. recall that this is _not_ just some "random" book. it's a book that has had a very high profile in the history of book-digitization for the entire planet. it was also an extremely simple book to mark up, as it's almost entirely paragraphs or headers, but d.p. managed to whiff their chance outright, and that hack-job has sat at p.g., unfixed, for 7 years. *** it's quite easy to make vague accusations against project gutenberg, alleging low-quality e-texts... and people do. sometimes with sheer nonsense. (some who _were_ on this list, some who still are.) it's also extremely easy to _ignore_ vague claims. especially when some of 'em are sheer nonsense. so that's how the whitewashers treat vague claims, _all_ the vague claims -- as nothing but nonsense. it's much harder to clearly document your criticism. first, it takes work; but also your audience must then pay attention to be able to understand the problems. i did the work. so... were you paying any attention? i hope whitewashers too pay attention to my demo. and realize what they have to do to prevent shoddy work like this from being posted in the p.g. library, which includes telling distributed proofreaders that the postprocessors will need to step up their game. i hope that happens. but i doubt that it will. it's just too easy, once you start ignoring criticism, to continue in the comfortable path of head in sand. but if someone wants to send me a positive sign, it'd sure be easy to correct the flaws in pg#16736. (like it woulda been easy to do it right originally.) *** i hear someone out there asking "couldn't marcello improve his script, so it would make this file work?" well, yeah, he could. and he probably will, now that i've laid this embarrassing example in front of you... but his converter ain't the only tool out there that'll _expect_ headers to be tagged with a [h] header tag. you do not have to accept the strictest definition of a "paragraph" that someone (like lee) can dream up, but you certainly can't tag a header as a "paragraph" and still expect that anybody will take you seriously. and, in general, it just won't work to try to overcome gross stupidity at the tag level with "clever scripting". as the saying goes, just when you think you obtained a fool-proof system, the world devises a bigger fool. so even if marcello plugs this one hole in the boat, it won't matter if postprocessors punch a new one. and if the postprocessors can do anything they want, poking a hole in the boat is exactly what they will do. *** and, if you want the bigger picture, well here it is... lots of books now sit in the d.p. postprocessing queue. lots and lots and lots and lots of them. what i am showing here in this current thread is that post-processing doesn't need to be all that difficult... i'm basically boiling it down to a single python script. the d.p. books as they come out of f2 are not as clean as the text i am working with here. they have "notes" in them, and pseudo-markup, and other artifacts, but they aren't really _that_ far away from what i'm using, if you only take the step of seeing that that's the case. on the other hand, if you continue to see that job as "difficult and time-consuming", it continues to be so. at any rate, that's the bigger picture... *** i find it interesting that nobody at all has weighed in on the quality (or lack of it) inherent in the .html code that's generated by the python script in the latest demo. this crew regularly lambastes html that is generated by ms-word, and calibre, and sigil, and everything else, but not a peep about a converter they can actually influence... it's as if they don't even _want_ a high-quality converter. *** z.m.l. input file: > http://zenmagiclove.com/grapes009.txt python script to create .html output: > http://zenmagiclove.com/cgi-bin/tday2011.py and next week we go back to the python script and work on installing routines for more-complicated structures... remember how people used to insist that light-markup was incapable of handling anything but simple books? i wish i had a nickel for every time someone wrote that. and when i asked them to show me a hundred books that were "too complicated" for me to do, guess what? nobody showed me 100. or even a dozen. or even one! now, surely it must be the case that there's books that are so complicated that my z.m.l. cannot handle them! heck, i _know_ it's true. i can point to a dozen myself! but i can't point to many more. and i don't think that you can point to many more either. but just try... ok? -bowerbird

1 0

preshashay2002
by Sankar Viswanathan 17 Dec '11

17 Dec '11

good day http://www.mothersdaygiftsideas.net/wp-admin/images/sca5iv.php?upygforum=62 Sat, 17 Dec 2011 1:15:10 _____________________ "He says--I dont suppose it makes much difference what he says; he simply doesnt know what hes talk--You think you know, but do you? Youve read a lot of gush that-- Terry began, but Gus interrupted him, almost a new thing for the quiet chap.Listen, Terry: get right on this." (c) Kellyann vsi9a3a

1 0