fried fish, available, for free
Bowerbird at aol.com
Bowerbird at aol.com
Thu Jun 9 20:29:59 EDT 2011
> is this a "Discussion related to Markdown" anymore?
let me deal with this last comment first.
if people think this is out-of-place, i can back off.
i've been a long-time supporter of light-markup,
and as markdown has been the leading exemplar
for a while now, i have done a lot to promote it...
at the same time, i've been developing _my_ flavor.
(and my efforts in that regard _predate_ markdown.)
i'm obviously interested in markdown, or i wouldn't
be here, but i'm thinking that people here might be
interested in other forms of light-markup as well,
including things like pandoc and restructured text.
there are certainly a lot of issues that are related to
the ongoing development of light-markup that can
be discussed productively, if people want to do that.
but if y'all do not, it's not my role to push that here.
so let me know. either way.
> 1. Congrats! It validates as XHTML 1.0 Strict .
most of the e-book compiler-tools will refuse to work
if the .html which they are being fed doesn't validate...
> 2. What's with all the horizontal rules at the end?
it's a way to say "the end". plus it makes that final
"chapter" fat enough that the "<c>" stays in place.
> 3. What's with the "<c>" that keeps showing up?
so, you didn't try it? that's probably understandable.
it's a bed of links, but i strip decoration off the links.
the "<" is a link to the previous chapter, the "c" links to
the table of contents, and ">" goes to the next chapter.
this makes it easy to step through the chapters, and is
one of the best navigational functionalities i am using.
i will probably end up making it smaller, and gray, but
my experience after many years is that it is fantastic...
and there's simply no way i would ever dispense with it.
not that you were asking for that -- just to let you know.
one of the things is that the project is directed at e-books.
so the assumption is the readers are in it for the long haul,
and will quickly learn the interface, so that big instructions
aren't really needed.
> 4. At the start you have an <h1> that is split by a <br />
> and formatted with multiple <big> tags. I don't know
> off-hand if header tags _shouldn't_ be split by <br />,
> but it sure doesn't _feel_ right.
i most definitely feel that headings should be "copy-fit" to
the available space, which often means linebreaking them,
and usually not in the places where they just got "too long".
> And "<big>"-style formatting doesn't
> seem like it should be mixed in with CSS.
well, that was something that i added by hand afterward.
(the other was tightened leading on the table of contents.)
i wish i could write a routine that would be clever enough
to know when a part of a title should be made bigger and
when not, but i don't feel that i'm smart enough to do so.
(i'll try, when i have time, but i am not optimistic about it.)
> 5. Why does every image have a "caption"
> that indicates the filename?
> This seems like more markup that is
> supposed to be handled, but is
> also being passed through to the HTML.
a big part of the design philosophy of my project is that
everything in the input has to be present in the output...
related to this is a focus on the importance of _remixing_,
with an important component the goal of "round-tripping".
that is, a person should be able to _regenerate_ the input
with little more than a few global-changes to the _output_.
in other words, if i copy the text out of the web-browser,
or the .pdf, i'll get something very close to the input-file.
with which i could generate the _identical_ .html and .pdf.
in order to wrap your head around just how radical this is,
imagine that you could copy the text from a .pdf and have
the indesign file which created the .pdf. pretty insane, eh?
it's not quite so impossible with light-markup, but still...
the equivalent with the markdown dingus would be that
you could copy the results from the ".html output" part
and paste 'em back in the "markdown input" section and
create the same .html output, and do that over and over.
maybe you feel there's "no need" for that type of thing.
and maybe there isn't. but i think there is. either way,
it'd be pretty darn cool -- and i aim to make it happen.
and what that means is that things like the image-name
must be present in the output, and not obfuscated away.
now, they certainly can be smaller, and rendered in gray,
so as to be less conspicuous. but a big part of the design
is to "resurface" those things that are often "tucked away".
i'm seeking transparency that hasn't been present before.
> 6. Is there a single capital letter on the page?
i certainly hope not. but every once in a while one slips in.
> 7. The text could use some more "interesting" formatting,
> but that could just be the styling that you've chosen.
i am certainly open to any feedback that you might have...
i fully recognize that i have absolutely zero designer skills.
and .css is more "frustrating" to me than illuminating, and
i have been doing stylesheets ever since ventura publisher.
so i welcome feedback, and working .css, from anyone...
at the same time, this is a tool for making e-books, and
i don't know if you've seen the kindle viewer-program, or
even ibooks, but they're incapable of anything except the
simplest of the basics, and often even that is a big stretch.
so i'm bound at the other end with impoverished environs.
> The weirdest part is the seeming mix of markup
> in the formatted document. I'm not sure if it's
> supposed to be an example of the HTML output
> of your converter or an HTML representation
> of the input to your converter. It seems like both.
i should have shown you the input file as well. it's here:
comparing the .zml and .html, side-by-side, is instructive.
it might also show you why i believe that i have developed
the lightest light-markup around. that's why i call it "zen".
so arno, thank you for your valuable feedback.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Markdown-Discuss