Different Rendering Backends

[Mandarancio]

It could be interesting give the possibilities to use external rendering back-ends to Marker. Some interesting back-ends are:

• pweave: let execute and embed python code in markdown
• pandoc: support multiple formats such as LaTeX and is already a dependency of Marker.

[fabiocolacio]

It could be an interesting idea to add support for backends like pweave and r-markdown, but we would lose compatibility with the hoedown extensions we added.

I think the best way to go about something like this is to let the user define a command to run when the refresh function is called, so they can use any backend. , similar to what we briefly discussed for the book mode

[Mandarancio]

My idea was to have the internal engine with our extension plus the possibilities to use external one in form of external command. However I think we will need some sort of plugin or configuration file for each renderer as some return the html directly in the stdout other save as file etc and marker as to know where to find the html.

[fabiocolacio]

A plugin system could work, and our custom hoedown engine would be the default. This would also make it very easy to add support for #46

[fabiocolacio]

I will look into this and see if libpeas can provide what we are looking for.

[fabiocolacio]

After looking into it, I don't think libpeas can provide what we are looking for.

I would like to create some kind of header declaring the prototype for the rendering function, and then provide some kind of way to dynamically load plugin files that contain the rendering function. This seems to be possible with dlopen() and dlclose(), as defined in dlfcn.h.

That way we can have a header that looks something like this:

#ifndef __MARKER_RENDERER_H__
#define __MARKER_RENDERER_H__

/**
 * marker_renderer_render:
 * @input_text: The plain-text, utf-8 encoded contents of the editor in Marker
 *
 * Returns: A newly allocate array containing the HTML data.
 */
char *marker_renderer_render (const char *input_text);

#endif

Then people who write plugins can create a function matching the above prototype, compile the code into a .so file, and store it in our plugin directory.

From there, our program can check the contents of the plugin directory, and selectively load and unload the renderers using dlopen() and dlclose().

We can have a gui combobox to select a rendering backend from that list, and load it.

[fabiocolacio]

I have done some testing with the above method, and I am convinced that this is the best way to go about making custom backends. We can also expand the header file to better integrate with marker's features.

/**
 * Return a the name of the language used in the editor pane.
 * This can be used so that the highlighting in the editor pane will work
 * automatically when changing backends.
 */
char *marker_backend_get_lang ();

/**
 * We can add support for non-html formats like pdf that backends can use. This function
 * would return an enum value describing whether to render as HTML or PDF
 */
MarkerPreviewFormat marker_backend_get_preview_format ();

// other functions can be added so that shortcuts such as bold, italic, etc still work with other non-markdown formats

It is also probably best to implement the backend system as a part of the MarkerEditor class. Rather than having an application wide option for the backend, his would allow the user to simultaneously work on multiple documents which do not necessarily have the same format.

[nick87720z]

Just to note, pandoc can use markdown input directly. Moreover, for now that's only way to get correct odt with formulas, converted to lomath formulas (I added them as latex formulas, surrounging with $$...$$).