|
greg said:
> I would propose that the Gutenberg problem
> does not lie in marking up for ebooks, but
> rather a markup that allows easy translation
> to things like epub (a very good move).
well, gee, that would be _nice_.
but the problem is that, in order to get .epub,
you _do_ have to do markup. quite a lot of it.
epub is xhtml/css underneath. (and not far...)
so yeah, it would certainly be lovely if we could
jump directly to epub without any markup, but
it's not really possible.
(you could also do what hadrien does at feedbooks,
which is to put the book into a structured database,
and _then_ churn out the .epub. he's doing markup,
he's just doing it another kind of way, via database.)
> It is matter of finding a light markup that can be
> transformed coherently and consistently into
> heavy markup, they may include voice markup,
> reference markup, and complete structural markup,
> that is potentially well beyond what
> any present reader can handle.
so now you want light-markup as a middleman.
at first glance, that's an appealing position too...
you avoid the high costs of doing much markup,
but get the benefits that heavy markup "promises".
and once again, it would be nice if you could get it.
but you can't...
well -- to be completely frank -- you kind of can...
my routines can turn a light-markup file _into_
a heavy-markup file, and do a fairly good job...
but let me tell you why i think that's a dead-end.
consider the whole set of routines that will successfully
convert the light-markup file into a heavy-markup file,
which is then input to another app (call it "program p")
for "purposes of presentation" (whatever form it takes).
_instead_, put that set of routines right in "program p",
so it inputs the light-markup file, does the conversion
_itself_, and then goes on to act on the converted data.
that's better, isn't it? you didn't have to convert it yourself,
because "program p" did it for you. you avoided the mess
of the intermediate file. (because, really, were you going to
keep both the light-markup _and_ the heavy-markup files?
because that's just a bunch of unnecessary file-overhead.)
> I would suggest, that TEI (text Encoding Initiative)
> is the only candidate.
oh sheesh! you want to jump _directly_
to the heaviest of the heavy, don't you? :+)
good luck with that. that's been the plan of
the technoid faction over at p.g. for... well,
going on 6 years now... going _nowhere_...
-bowerbird
|