zim-wiki team mailing list archive

[Jaap Karssenberg <jaap.karssenberg@xxxxxxxxx>]

Resending because mailing list bounced first message

On Wed, Jan 25, 2012 at 7:46 AM, HansBKK <hansbkk@xxxxxxxxx> wrote:
> 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

Consider this a zim specific wrapper around the actual content of the
page. Just using email headers (rfc 822) with a few custom fields.
Other media could use different wrapper to communicate the same
meta-data.

> Where would Jaap go to see how this data could be usefully transformed, for
> example if reST is the target output?

Quick question - I was told before that markdown+extensions is the
preferred format for pandoc. But now it sounds like you consider reST
the default format. Which of the two should we focus on?

>> 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.

Yes, adding an export format is easy, because I only need to transform
my data to a specific output.

>>  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.

My long term goal is for zim to support multiple syntaxes to store
it's data. Markdown is on my list for that feature, looks like I'll
need extensions like the ones in pandoc to make all zim features work.

However this is more work then just export, because I need both export
and import, and make sure all data from import is preserved in the
internal model such that export reconstructs the import.

> 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
 ... 8< ...

Let me worry about preferences etc. later - first need to sort out
syntax requirements.

>   - 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.

Back to my question why we are no talking about reST/Spinx, and not
Markdow with pandoc extensions.

My understanding is that I can generate markdown with extension and
call pandoc to convert it to any of the formats supported by pandoc.
This means some coding for me, but does not require any change in
pandoc, correct ?

Regards,

Jaap