Re: [O] org-mode, tikz and beamer

[Suvayu Ali]

Hello Cédric,

First, apologies for the delay.  I am swamped with a lot of things for a
while now, makes my responses rather irregular.

On Thu, May 21, 2015 at 10:33:13PM +0200, cédric ody wrote:
> Thank you for your answer.
> 
> Here is the shell script (many comments are in english except the
> beginning) and the org file I use. To see how I call it, you can have
> a look at the enclosed Makefile. Note that it uses specific
> configurations files as well tex macros so it won't work without these
> files. I can prepare a short example which generates the tex and pdf
> files if needed. The script probably gives for now a good idea. You
> can also look at the enclosed generated tex file to see how the tikz
> language.

I think you forgot the Makefile.  Aside from that, I looked at the
script, and the Org file, albeit not very thoroughly.  My impression is,
it is a really nice effort but I think it's unsustainable.  You have to
duplicate a lot of work, and since you do it in a shell script, you are
limited.  Here are a few particular points:

- You reimplement the Org parser.  This of course means you do not
  support a large part of the standard syntax[1].  It's not future proof
  either.  For the same reasons, it is very brittle.  Org-element does a
  great job of parsing, you should use it.

- You seem to rely on specific cookies, like `%%%' (and maybe "abusing"
  tags like noexport?).  This is introducing _new_ syntax.  Again, since
  this is outside of org-element, there is no way to ensure robustness
  and reproducibility.

> Basically, the shell script looks recursively into the org file and
> creates nodes for the tikz headline mindmaps. Thus, there are parent
> nodes and children nodes.
> 
> During that excursion, two kinds of files are created: the "tree"
> files and the "contents" files.
> 
> The first ones are tex files with tikz mindmaps that must be inserted
> at specific locations at the final latex compilation step. One tree
> file contains the parent node with all the children files.

This part sounds good.

> The "contents" files are org files and are converted into tex files
> via the org-mode export command in a batch way. In the shell script,
> hyperlinks are added to these newly converted tex files.

This, I'm not completely certain.  If I got this right, you export one
file per beamer frame?  Is that right?  I also see you do a bit of
editing with sed.  Again, I think this makes it too brittle, too many
assumptions about what is present and what is not.

> At the end, the assembly of all these files is done before compiling.
> 
> Numbering of sections through the recursive call is important so that
> links work properly as you notice. Links allow one to go back and
> forth the document. To go back, the idea is to click on the headline.
> If a node exists without content, the links sends you the beginning of
> the file or something like that.

This part I'm not sure I quite understand.  Shouldn't normal LaTeX
referencing mechanisms (à la \label and \ref) be able to handle this?  

Anyway, after looking at the script I'm convinced this endeavour is
better pursued in lisp.  I think it would help if you draft a document
outlining the Org elements you want to map to which specific tikz
features/commands.  You will then have a list of leftover info that tikz
still needs to achieve the end goal.  At this point others can suggest
how you could communicate these missing info to tikz.  E.g. you already
have one suggestion from Bernhard, but I think it is probably too
generic.  If you manage to pursue this, I think the outcome will be a
new Org backend, possibly derived from ox-latex or ox-beamer.

Please don't be afraid to learn lisp, although it is hard to master,
it's easy to pick up.  I think the list will be more than willing to
help you with that.  Also, I think this is not a easy project.  It will
take some iterations to get to a version that can be test widely (by say
putting in an experimental branch or something).

While proof reading my email, I just realised ox-koma-letter might be a
really nice place for you to get familiar with how to repurpose Org
syntax to translate info to the backend in different ways.  Have a look.

Hope this helps,


Footnotes:

[1] Do not underestimate this aspect, Org users have a way to come up
    with interesting ways to use features that were not envisioned
    during development!

-- 
Suvayu

Open source is the future. It sets us free.