emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Best way to include METAPOST in ConTeXt exporter


From: Jason Ross
Subject: Re: Best way to include METAPOST in ConTeXt exporter
Date: Tue, 5 Oct 2021 07:40:12 -0700

(Apologies to Ihor who I already replied to without cc'ing the list)
=======================================================
> If you are in control of the export backend, you can directly process
> the metapost source blocks during export and ignore/filter their output
> as needed.

This is definitely possible, but I don't want to commit to bypassing the
entire Org Babel system right now. I will explore this a bit.

> Or you can use "raw" results by default and format everything as you
> wish in your Org Babel module programatically.

I'm not sure I understand this yet. Would this emit METAPOST code to the
Org buffer? Ideally, I'd like to emit METAPOST code if the backend is
`context`, otherwise, emit a file.

> If above is not sufficient, you can install global export filters that
> can transform the metapost blocks/source blocks/their results as you
> need in other export backends.

This sounds like it might be a good solution. Is it possible to have an
export filter that changes the header arguments of a source block before
Org Babel sees them? If so, ox-context could change all METAPOST source
block header arguments to give raw results wrapped in appropriate tags.

Also, I'm still curious if there's a better way to add #+CAPTION and
#+NAME tags to images generated by source blocks (in any context). It
would be extremely handy to reference figures generated with
matplotlib throughout the document, not just METAPOST drawings.

Thanks,
Jason

On Mon, Oct 4, 2021 at 9:44 AM Ihor Radchenko <yantar92@gmail.com> wrote:
>
> Jason Ross <jasonross1024@gmail.com> writes:
>
> > I had considered using special blocks; they match my mental model the best.
> > However, they don't provide any support for syntax highlighting or opening
> > the block in a new major mode buffer. I'm not sure if it's worth giving up
> > language features in order to use the block that's most intuitive to users.
> >
> > I'm also considering writing an Org Babel module for METAPOST. This could
> > allow METAPOST figures to be included with any export backend. However,
> > if I go this route, there are still some challenges:
>
> If you are in control of the export backend, you can directly process
> the metapost source blocks during export and ignore/filter their output
> as needed.
>
> >    #+MACRO: conditional-header (eval (when (not (eq
> > org-export-current-backend 'context)) (concat  "#+HEADER: :results
> > file :file " $1)))
>
> >    #+BEGIN_SRC metapost :results drawer :post
> > wrap_metapost(name="my-name", caption="my-caption", data=*this*)
>
> Or you can use "raw" results by default and format everything as you
> wish in your Org Babel module programatically.
>
> If above is not sufficient, you can install global export filters that
> can transform the metapost blocks/source blocks/their results as you
> need in other export backends.
>
> Best,
> Ihor



reply via email to

[Prev in Thread] Current Thread [Next in Thread]