nekokami said:
> is z.m.l. designed to produce the kind of output style you use in your posts?
no. it's designed to produce the kind of output you find in paper-books,
i.e., the high-quality typography that has evolved over hundreds of years
and as far as the web goes, it's designed to produce normal e-book .html,
of the type that just about everyone would agree is a decent representation.
(but the web-browser is always going to be an inferior book environment.)
> I'm an html fan, because I can see the tags in a regular text editor
> and I know what they mean. There's very little I need from a book
> or any other document that can't be done with quite plain html.
there is a one-to-one correspondence between the "rules" of z.m.l.
and the tags you see in .html, which is why z.m.l. can generate .html.
did you even look at the .zml example books that i pointed you to?
z.m.l. _headers_ are indicated by a sequence of at least _4_ blank-lines
preceding the header, with a two-blank-line sequence after the header.
(headers can be of the 2-part type that is extremely common in books,
where the first part is "chapter 10", the second "the lobster quadrille",
where these two parts are simply separated by a single blank line...)
the number of blank lines that precede the header indicate its _level_.
(more blank lines indicate a higher-priority header, which means that
you could conceivably have an outline with an infinite number of levels.
realistically, six is workable. but most books will only have one or two.)
even without much experience, it's easy to get used to seeing the headers:
>
http://snowy.arsc.alaska.edu/bowerbi...01/alice01.zml
to see the .html that was generated by this .zml file, look here:
>
http://snowy.arsc.alaska.edu/bowerbi...1/alice01.html
again, if you have any negative feedback on that file, please share it here.
there's a .pdf version as well, for people who would prefer that format:
>
http://snowy.arsc.alaska.edu/bowerbi...1/alice01b.pdf
as with the .html, this was generated by the .zml file. the beauty is that
an individual user can generate a .pdf to their own custom specifications.
once you get used to clean .zml, obtrusive <h2>html tags</h2> get
extremely claustrophobic, especially when further cluttered with the
<a href="#tableofcontents"> and <h2 id="chapter10thelobsterquadrille">
tags</h2> that are needed for <strong>powerful</strong> navigation...
it will be even easier for people to "visualize" how z.m.l. works when
i release my .zml authoring-tool, with its side-by-side interface where
you do .zml on one side of the screen, and it's formatted on the other.
(the format is fairly similar to the "showdown" webpage i pointed to...)
and although you might dislike my _italics_underscores_ when i post here,
they seem -- to my eyes anyway -- more clear than the <i>html kind</i>
if you're editing the raw tags in a text-editor.
likewise, i think you'll find the footnote rule-set rather easy to grasp.[1]
but clarity to the end-user is just half of the bargain.
another benefit of light markup is that it's extremely easy for programmers
to build applications which leverage the simplicity of plain-text input files,
since it's unnecessary to program around the obstruction of heavy markup.
every bit of my format has been stress-tested in the harsh environment
of actual real-world programming, where you have to be quite specific...
there's no room for wiggling when you get down to the actual app coding.
and this is something that the format wonks significantly fail to appreciate.
they seem to believe that by creating a format, all the work has been done.
but until you have applications that bring about the desired functionalities,
you haven't got squat. and if you _do_ have an application to do the work,
odds are the programmers already invented their own format, thank you...
it's not like we programmers are sitting around waiting for the right format.
we can mix one up quite easily all by ourselves, one that we know will work.
i mean, truly, i'm just _amazed_ that some people seem to think that they
can just lay out a format -- with little or no input from programmers about
whether it can be implemented correctly or not -- and then seemingly just
_expect_ that the programmers will come be led by the nose to implement
the format. i cannot tell you how many times i've made a decision about a
file-format that i later had to change once i tried to implement it in an app.
yet we went through a period of _years_ of "browser incompatibilities" and
"non-standards-compliant" nightmares -- heck, we are still living them! --
all because file-formats were created without clear implementation plans...
and does anyone think .epub will be any different? if you do, you're crazy.[2]
and what good does it do to have "one format" if different viewer-programs
implement it differently?
will there be a "best if viewed with digital editions" logo that people will use?
as far as i'm concerned, if you don't have _three_ open-source viewer-apps
for a particular format -- each with a dedicated programmer community --
all of which display an e-book exactly the same way, across many e-books,
you shouldn't even be _proposing_ that format as an industry-wide standard.
scratch that. make it three open-source viewers
_and_ three open-source _authoring_tools_ too...
-bowerbird
[1] footnote references are surrounded by brackets. if a bracketed reference
is preceded by two end-line markers, then it is the actual footnote itself.
(that is, it must be at the beginning of a line, with an empty line above it.)
otherwise, the brackets are the place that _called_ the footnote.[special]
[special] there we have a case of a footnote that's _inside_ another footnote,
and which is referenced[magic] with the word "special", rather than a number.
these bracketed references inside the text are not preceded by two end-lines,
so the program knows that they are _pointers_ to a footnote, not the footnote.
[magic] this footnote just shows a footnote reference can be placed anywhere,
such as the middle of a sentence, without confusing the viewer-program at all.
you might be wondering about ordinary bracketed text [were you?}, but do not
fear, since if there is no matching bracket-reference preceded by two end-lines,
the viewer-program knows that it shouldn't treat _that_ bracket as a footnote.
(this means the "were you?" text above is treated as ordinary bracketed text.)
why force a human being to do markup on all those footnotes, when a basic
viewer-program can employ an elementary rule-set to sort things out by itself?
note that this paragraph is a continuation of the "magic" footnote above it;
if it were the next footnote, it would have begun with its bracketed name...
[2] i mean the _generic_ "you", of course, not you personally, whoever you are.
two blank lines after the last footnote indicates that the footnotes are done,
and the regular text, if any, is continuing. of course, since you will ordinarily
put the footnotes in their own section (so they're actually more like endnotes),
the last footnote should be followed by a stream of at least _4_ blank lines and
a header, thereby indicating the beginning of the next section, if there is one...