Adding additional output formats for Markdown?
Fletcher T. Penney
fletcher at alumni.duke.edu
Thu Jul 28 10:14:11 EDT 2005
On Jul 28, 2005, at 9:01 AM, Michel Fortin wrote:
> Le 27 juil. 2005, à 21:53, Fletcher T. Penney a écrit :
>
>
>> For me, my dream for Markdown would be to use it as the default
>> syntax for most of my text-ish documents - weblogs, wiki pages,
>> academic papers, readme's for my software, etc. A single Markdown
>> document would likely end up becoming a variety of different kinds
>> of documents, each of which would have a different means of
>> specifying the title, author, etc.
>>
>
> And what exactly is a *Markdown document*?
Not to sound "circular" but it is really whatever the user wants it
to be. For some it is only useful as a weblog format. For me, it is
more than that - a Markdown document is simply a text document,
written using the Markdown syntax, that can be easily converted into
other file formats (pdf, XHTML, RTF, etc).
> As you may have noticed, Markdown does not output HTML documents;
> this is not what it is meant to. It convert snippets of text that
> you can put in the middle of a template HTML page.
>
> The same thing could apply to a Markdown-to-Latex converter: you
> convert Markdown headers to Latex headers and so on, then another
> program put it in inside a template Latex document. This way,
> people can choose the template they like, and give the metadata (if
> any) into that other program that build the final result.
The problem is that some formats are meaningless as "snippets." To
my knowledge, there is no way to view a snippet of LaTeX. You either
have a (mostly) valid complete document, or you don't. Therefore, it
doesn't make much sense to me to try and separate the two parts of
the process. Any individual user, however, is not required to use a
template, or to use metadata. My goal was to have a "fire and
forget" process for converting Markdown text to a pdf without any
need for human interaction. And I succeeded.
That said, others are certainly welcome to create separate programs
that perform parts of the process if that would be more useful to
them. The end result is the same, and perhaps that would offer more
flexibility in a way that I can't see right now.
> Your metadata format is interesting, but I see no reason why you
> should merge the template program with the Markdown conversion
> program. They could both exist as separate entities. For example,
> your template program could read the metadata, then read the
> Markdown formatted content, call the Markdown-to-something-else
> converter over the content and output the document using the
> template, the converted content, and the metadata.
But that's what I have done. To me, it seems to be a matter of
semantics whether you type:
commanda --optiona --optionb | output
or:
commanda --optiona | commandb --optionb | output
In either case, the logical process is the same - you convert
Markdown formatted content to some other content (HTML, LaTeX), and
then wrap it in the additional information required to make the
document complete. Two separate, independent, (but in the case of
producing complete documents from Markdown text), mutually required
steps.
The main problem is a matter of compatibility. Without a standard
format for metadata, you can't simply take a Markdown+metadata
document/snippet/whatever and drop it from MultiMarkdown to Blosxom
to MovableType.
If there was a standardized format for including metadata within
Markdown, there would be a blosxom plugin for it within hours to
days, and I can only assume one for Movable Type as well (In fact,
with the format I am currently using for Metadata, it would not take
much of a tweak of the current blosxom meta plugin to be
compatible). I am not trying to convince everyone else (i.e. John ;)
that my way is the right way to do metadata, or that it must be
included within the official Markdown syntax. But I simply wanted to
propose it for discussion. After trying this out, I will continue to
use metadata within my markdown documents - it's incredibly useful.
> This way you have a separate Markdown converter usable in other
> environments where the metadata isn't stored the same way, like,
> say, Movable Type or Bloxsom. More than that: you have a separate
> metadata/template tool that could work with other syntaxes than
> Markdown provided there is a converter.
And anyone is certainly free to create such a tool. I prefer to have
one program that takes Markdown text and outputs a complete document
- I don't see the need for multiple tools in this case, but others
may. What would be nice, however, is a standardized way of including
the metadata so that all of these tools would be compatible. And
again, my tool reads the actual conversion process from a
configuration file - it is not tied to just LaTeX or XHTML or whatever.
I don't require that metadata be added to the official Markdown
syntax. I don't require that anyone else use MultiMarkdown. It
works for me, which was my reason for writing it. But it seems so
useful to me that I can only assume it is useful to at least one
other person out there. It would be nice if there was a consistent
way of doing things so that the data can be as cross-compatible as
possible. But if there is not sufficient interest, then it is a moot
point.
One direction I personally am trying to go with this is to create a
different version of a wiki program for my website. I would like to
enter the text using the Markdown Syntax. The wiki program takes
this data, and creates the html version of the content for the web
site, in the "usual" way. Additionally, however, the user could
click on a link to download the same content as a nicely formatted
pdf file. Or the raw LaTeX. Or a .pdb for a Palm pilot. Or,
**shudder**, even a word .doc if someone desired, though I might have
to ban that person from my website... ;) As we are seeing from the
whole music/drm/mp3/aac process, people want to be able to use the
same data in different ways. A tool such as this would assist in
making that possible for text-based information.
Again, my thanks to everyone who is giving me feedback for this!
Fletcher
--
Fletcher T. Penney, M.D.
fletcher at alumni.duke.edu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3949 bytes
Desc: not available
Url : http://six.pairlist.net/pipermail/markdown-discuss/attachments/20050728/e176fa4a/smime.bin
More information about the Markdown-Discuss
mailing list