Adding additional output formats for Markdown?

[Fletcher T. Penney]

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