← Back to team overview

zim-wiki team mailing list archive

Re: Metadata; Pandoc <=> Zim (Was: Link friendly Markdown editor?)

 

On Wednesday, January 25, 2012 3:40:30 AM UTC+7, Joseph Reagle wrote: 

I'll also note that Zim uses a meta-data header (see below) and, as John 
> knows all too well, the markup community can't really come to consensus on 
> how to support this widely.
>
>  

> ~~~
> Content-Type: text/x-zim-wiki
> Wiki-Format: zim 0.4
> Creation-Date: 2011-03-16T16:08:32-04:00
>
Where would Jaap go to see how this data could be usefully transformed, for 
example if reST is the target output?

1. Zim will continue using it's format, but perhaps come up with a plugin 
> to export to markdown and ...
> 2. then execute pandoc  (as an external utility) for other format 
> conversions.
>
Something like this is Jaap's current intention as I understand it.
 

  In my perfect world:
>
> 1. Zim would use a subset of pandoc markdown as it's native format. (With 
> the subset being as large as possible :) .)
> 2. Pandoc and Zim could agree on a a meta-data format.
> 3. Pandoc and Zim import/export nicely amongst each other.
>

Here are my tweaks to the above "ideal" scenario, with the proviso that I 
have a very limited understanding of all this, just thinking out loud

  - Zim has user-config options to switch over to reST support rather than
    its current proprietary syntax

    - probably just globally
    - but perhaps per-database
    - probably not on a per "page" basis

  - starting out by limiting to the subset of reST supported by Pandoc
    - a canonical listing would be useful here

  - eventually that could possibly evolve to broader (as full as possible)
    support for the Sphinx extensions
    - so that Zim could alternatively develop a direct "full" site-/book-
      level export/generate facility

Ideally, to the extent possible/appropriate Pandoc will be able to continue 
to accept this as input, in order to facilitate output to targets not 
supported by Sphinx directly.

To the extent this is not the case, then the export/conversion tool would 
in the meantime need to accept an option to select either full-reST/Sphinx 
syntax export or the Pandoc-specific reST subset.


Follow ups