Quote:
Originally Posted by bowerbird
kovidgoyal said:
> To summarize your response,
> zml cannot support setting presentational aspects.
ok, _you_ don't get it. i'm sorry about that.
the _philosophy_ of z.m.l. puts the _locus_of_control_
for _presentational_matters_ into the hands of the reader.
|
Surely you can make the leap to the next logical step. If a file defines only structural elements, the only elements that the viewer app has control over are those structural elements. Not all elements in an ebook are structural. Occassionally, there is a need for special formatting for isolated instances. zml + viewer will NOT handle this.
Quote:
Originally Posted by bowerbird
this is part of a much bigger _philosophy_ that it is far more
efficient -- in the long-run -- and a much better _strategy_
to put intelligence into our _applications_, not our _formats_.
the problem with putting smarts in the _format_ is that you
have to then mold the content to the format, whereas if we
put the smarts in the _apps_, they'll parse the raw content...
as before, this is far too big a concept for us to _discuss_,
so i'm only just laying it out, because we cannot "decide"
the issue here, that's for the real-world to do, but i thought
some lurkers might be interested in the "big picture" of that.
|
Umm so you're stating a philosophy as a motivation for the use of lightweight markup and then refusing to discuss its merits?
Quote:
Originally Posted by bowerbird
> Indeed your whole attitude is that authors dont know
> whats good for them and you're going to tell them that.
no, my attitude is that some authors don't want to do markup,
so i'm gonna give them a simple format so they don't have to,
but can nonetheless provide their readers with e-books that are
both powerful and beautiful.
|
Again a better way to give authors this power is to create an authoring tool, not a file format.