!@!Re: [gutvol-d] blah blah blog

mikey said:
Please keep comments on issues raised in bowerbird's "blah blah blog" off this list.
sorry to disturb your sleep, mikey. but you can go back to bed now... *** bastien said:
Can we see the code?
no.
Can we use/test/improve it?
i'll release an app sooner or later that you can use. as far as the routines themselves, creating them took a _persistent_ application of common-sense and a lot of elbow-grease. that's all. which means you can generate them yourself, if you really want. i'll also be willing to give you some pointers if you should happen to hit a wall at any point, once you have shown me you are willing to take on the job. or, if you prefer, you can take the shortcut, and buy my source code. the price is in the 6 figures. i can't afford to give away something that valuable. if you can, i suggest you buy it and give it away... but really, what i want you to take away is that you _can_ do this, and it's really not even all that _hard_. for instance, i've talked about using the number of preceding blank lines as an indicator of heading level. assuming that such consistency has been maintained, even a beginning programmer could write the code to ascertain the structure of a book. care to try it? write it in pseudo-code first, and then in a language, any language with which you are comfortable, be it perl or python or ruby or basic or whatever you like. it might be better to take it over to gutvol-p, so we don't put a coding session in all the gutvol-d boxes, but if you show me you're willing to do some work, i'll be more than happy to show you what will pay off. if you're not, then i'll refer you to the fables of aesop, specifically the one about the little red hen... *** michael said:
There's nothing wrong with what such people are asking, other than that they are asking someone else to do it for them, free of charge.
i know that michael is talking about "such people" as a general class, and i'm fairly confident he doesn't lump me in that class. but other people here might. so let me be absolutely clear here for them... i'm not asking anyone to do anything "for" me. and i am more than willing to do the job myself. i said so, directly, on my blog, and i repeat it here. what i am doing is suggesting you make these changes for _yourselves_ and for _your_readers_, simply because consistency in the e-texts leads to greater functionality... my experience is that this greater functionality would benefit you with increased efficiency in the preparation of the e-texts, and benefit your readers in greater total usability of the e-texts.
Those of us who have been on this list, and others, for very long these days have no trouble remember any number of people who have had variety upon variety of requests that Project Gutenberg should be run in such a fashion as to meet with their demands.
again, i make no "demands". just giving you tips. for your own good.
The response is always to invite the creation of some examples, along a suggested pathway for future efforts, to be accompanied by your request for others to assist you in making such future efforts.
it is also the case that i _am_ putting examples online. i've already pointed to some, and more will come soon.
http://snowy.arsc.alaska.edu/bowerbird/alice01/alice01/alice01.zml http://snowy.arsc.alaska.edu/bowerbird/alice01/alice01/alice01.html http://snowy.arsc.alaska.edu/bowerbird/alice01/alice01/alice01.pdf http://snowy.arsc.alaska.edu/bowerbird/alice01/alice01/alice01b.pdf
other examples will be "my antonia", "books and culture", "free culture", "the universe or nothing", "the secret garden", and a handful of books by cory doctorow, for starters. as z.m.l. requires just a smattering of changes to the markup-free version of an e-text, hundreds of examples will follow before long, and thousands once my processes are refined... if i don't lose interest, i might have most of the library converted in a year. from these plain-text .zml "masters" will emerge automatic .html versions -- from which a plethora of other formats will be able to be generated -- and automatic creation of .pdf versions according to user specifications... other sweetnesses might follow too, like ipod versions and p.s.p. versions. and last but not least, the z.m.l. viewer-app will create a kick-ass powerful high-functionality electronic-book experience using these .zml "masters". enough so that you'll wonder why you ever thought you needed "markup". (there's more -- scansets and banana-cream -- but that's enough for now.)
Describe how these examples are better than previous examples
have done, and will continue to do, as appropriate times arrive... -bowerbird

On 2/1/06, Bowerbird@aol.com <Bowerbird@aol.com> wrote:
bastien said:
Can we see the code?
no.
We'll just have to take your word for how good these "routines" are then.
Can we use/test/improve it?
i'll release an app sooner or later that you can use.
or, if you prefer, you can take the shortcut, and buy my source code. the price is in the 6 figures. i can't afford to give away something that valuable. if you can, i suggest you buy it and give it away...
You're kidding right ? Your code might be fantastic but you're deluding yourself if you think anyone will pay you six figures for a text processing app.
what i am doing is suggesting you make these changes for _yourselves_ and for _your_readers_, simply because consistency in the e-texts leads to greater functionality... my experience is that this greater functionality would benefit you with increased efficiency in the preparation of the e-texts, and benefit your readers in greater total usability of the e-texts.
This I agree with. Although with an all-volunteer project its hard to define and enforce the format. Tools like gutcheck are a start along this road.
it is also the case that i _am_ putting examples online. i've already pointed to some, and more will come soon.
http://snowy.arsc.alaska.edu/bowerbird/alice01/alice01/alice01.zml
http://snowy.arsc.alaska.edu/bowerbird/alice01/alice01/alice01.pdf
http://snowy.arsc.alaska.edu/bowerbird/alice01/alice01/alice01b.pdf
I assume the pdf there is generated from the zml ? via what mechanism ? a single conversion step or via somthing like latex ? Any reason to not go with one of the existing plain-text markup languages that already exist and have existing conversion tools ? reST, asciidoc and others. Is there a format description for z.m.l ? Do you have existing tools/parsers for z.m.l with freely available code ? Or is that another 6 figures ? :)
from these plain-text .zml "masters" will emerge automatic .html versions -- from which a plethora of other formats will be able to be generated -- and automatic creation of .pdf versions according to user specifications...
and how is this different from what gutenmark does ? Apart from hopefully fewer errors in the html or latex output ?
other sweetnesses might follow too, like ipod versions and p.s.p. versions. and last but not least, the z.m.l. viewer-app will create a kick-ass powerful high-functionality electronic-book experience Surely this is competely orthogonal to the choice of markup language.
using these .zml "masters". enough so that you'll wonder why you ever thought you needed "markup".
uh - just because you use whitespace instead of <h> to indicate headings doesn't mean its not markup. The very fact that you are pushing for consistent format for conversion means that it *is* markup - oh and the fact that you've named it Zen *markup* language :) Ian
participants (2)
-
Bowerbird@aol.com
-
Ian MacLean