- gutvol-d - lists.pglaf.org

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

Re: [gutvol-d] The problems with paragraph formatting at PG
by Bowerbird＠aol.com 16 Dec '11

16 Dec '11

paul flo said: > And yet it is so difficult > to have these ASCII files work for readers. light-markup converts well to any format you want. i'm in the process of demonstrating that, right now. *** > to show that more people would rather work in XHTML > than ZML, I'd only have to find two XHTML people. xhtml? as far as i can read what the wc3 has declared, xhtml is a dead-end. even .epub is leaving it behind. light-markup, on the other hand, has been on a sharp upward slope for years now... even with trendy geeks... heck, _most_especially_ with the trendiest of the geeks. markdown, in particular, is _exploding_ at the moment. but, you know, use what _you_ like the best, eh? :+) *** you know that one of the _output_ formats for markdown is xhtml, right? but the point is, nobody wants to _write_ in an xhtml environment. not any _real_writers_, anyway. real writers want the-words-and-nothing-but-the-words. even the main .epub programmers use asciidoc to _write_. but use whatever you like! what _do_ you use, by the way? -bowerbird

4 4

never bet every bit of your credibility
by Bowerbird＠aol.com 16 Dec '11

16 Dec '11

i said: > last year i did this demo in perl. > wanna see those scripts? > (no, of course you can't have them. > but you can _run_ em.) well, i did do some demos in perl last year... so i poked around, to dig them out for paul, because paul had said that he scripts in perl. but those weren't the first things i did in perl. so i decided to be curious, and see how far back that i started doing perl. i'm not sure even now, but i was definitely actively using perl by 2007, because i still have content dated february 2007. and it's not even in an obscure location, either... it's right off the main page of my z-m-l.com site. > http://z-m-l.com which means that, in 2 months, it will have been up on my site, available publicly, _for_5_years_... and lordy lordy, it's basically the very same demo which i am currently scripting in python. get out! no wonder i am feeling nostalgic -- i'm in a rut... gonna have to take my game up a couple notches. so paul, if you're listening to people who say that i never produce anything, you should know that _they_are_telling_you_lies,_speaking_untruths..._ and just so you know, paul, these were the demos that made my antagonists realize they had _lost_ the little war they'd started against me, and thus they had to sit by and watch in utter helplessness as i showed the winning hand in our poker match and started sweeping the big pot over to my side, a pot which contained every bit of their credibility, which they'd unwisely thrown on the pile in a wager that proved to be _incredibly_ stupid on their part. and thus a very loud silence fell over the crowd... the moral is "never bet every bit of your credibility". another good lesson is that it is always unwise to bet the other guy on what he has in _his_ pocket. he's probably got a much better idea than you do about what _is_ in his pocket, and what is _not_... even if he says he has a perpetual motion machine or a time machine in there, be careful with that bet. it's _safer_ to take a bet on what's in _your_ pocket. because you can check, so you should know, right? regardless, you still shouldn't bet _everything_ on it. because when the time arrives for you to _prove_it_, you just might discover your pocket has been picked. -bowerbird

1 0

abbyy finereader on sale -- last day!
by Bowerbird＠aol.com 15 Dec '11

15 Dec '11

the new version of abbyy finereader -- v11 -- is on sale... but today is the last day of the sale -- at least supposedly. the full version, new, is $119 on sale, reduced from $170. the update is $70 on sale, and it will be $100 afterwards... finereader express, for the mac, is $70 today, $100 later. i don't know if v11 is an improvement on earlier versions or not, so i can't give any advice on whether to _upgrade_. but this is a good price to buy a version if you have none... most _especially_ if you believe the lies that jim and lee have been telling you that finereader does good markup. it does _presentational_ markup, which is well and good -- and honestly, that's all that a regular person needs -- but not what you really want if you have to edit the .html. finereader _does_ give excellent o.c.r., though, the _best_! so again, if you don't have an o.c.r. program, grab it now! > http://abbyyusa.com -bowerbird

3 2