ian said:
>   We'll just have to take your word
>   for how good these "routines" are then.

well, until i release the app, yep.

or you can not believe it,
don't matter much to me.

you're obviously new around these parts,
as these points have been made before,
so i'll 'splain you something simple here.

i'm not asking you to "take my word".

i'm telling you that you can prove this
for yourself, to yourself, by yourself...

write the routines.  you'll see they work.

keep track of the time you spend doing it.
after it ends up as a few years of your life,
you'll think it's worth a piece of change too.
how big the piece of change depends upon
how much you think a few years of your life
is worth.  so, how much _is_ your life worth?


>   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.

it's a marketplace.  sellers charge what they want.
buyers decide what price they will pay.  if the two
find a mutual ground, the sale will be made, and
if they do not, then no sale will be made that day.

ok?

for the record, though, amazon.com bought mobipocket
for about 3.5 million dollars, u.s., according to estimates.
by my count, that is 7 figures.


>   Although with an all-volunteer project
>   its hard to define and enforce the format.

i think you'd agree my format is an easy one,
and could be "enforced" with little difficulty.
it's actually very close to the format that is
even now being "enforced", in most regards.

judge for yourself, though, by reviewing the
test-suite that i made, which is available here:
>   http://snowy.arsc.alaska.edu/bowerbird/test-suite/test-suite.zml


>   I assume the pdf there is generated
>   from the zml ? via what mechanism?
>   a single conversion step
>   or via somthing like latex ?

inside of the z.m.l. viewer-program, in which you have
already set your preferences according to your desires
(on things like font, textsize, leading, and many others),
just print to a .pdf driver, and the .pdf will be created...


>   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.

none of them were targeted directly enough for books.

z.m.l. was derived from actual hands-on experience with
the conventions present in the project gutenberg e-library.
this gave me a sharp focus at exactly the right perspective;
i was able to implement every thing i needed, and no others.

however...

given my experience now, i think i could advise any of those
other methodologies on how they might do what z.m.l. does.


>   Is there a format description for z.m.l ?

well, yes, but i see it's not online.  so i'll put a copy up.

if you're in a hurry, you can join the viewer beta-test
-- send an e-mail to zml_talk@yahoogroups.com --
and download the most recent viewer, which will have
a copy of "the 11 rules of z.m.l." contained within it...

you could also check the archives of this listserve,
as i've sent it here on a couple different occasions.

but if you can wait a couple days, i'll put it up online.


>   Do you have existing tools/parsers for z.m.l with
>   freely available code? Or is that another 6 figures ?  :)

roll your own.  the rules are very simple.


>   and how is this different from what gutenmark does ?
>   Apart from hopefully fewer errors in the html or latex output ?

gutenmark gave up because of the inconsistencies i point out.
thus, it's an excellent example of what _could_ have been, if only
a simple concession to attain a minimal amount of consistency
had been made, and acted upon.

you can judge the quality of my .html versions by
looking at the "alice" example that i cited earlier...

(i won't pretend my .html converter is finished yet,
but i also won't pretend to care all that much about
getting it done, since a web-browser is a bad viewer.
but it's important to support the internet in general,
and equally important to support the p.d.a. option.)


>   Surely this is competely orthogonal to the choice of markup language.

the point is that you don't need heavy markup to get
a kick-ass high-performance e-book experience, so
it is a mistake to pay the price of doing heavy markup.


>   uh - just because you use whitespace
>   instead of <h> to indicate headings
>   doesn't mean its not markup.

well, it means that it's _zen_ markup.

because you can't see it.  it's invisible.
and as such, it doesn't muck up the
reading experience, so it's easy to edit.

clean, simple, graceful, all the good stuff.

compared to this elegance, markup is cruft.


>   oh and the fact that you've named it
>   Zen *markup* language :)

oh, so i see you _did_ get the joke.
that's good, i was a bit worried there.        :+)

-bowerbird

p.s.  "z.m.l. -- it's two steps better than x.m.l."