emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [O] Babel support for Processing-language


From: Jarmo Hurri
Subject: Re: [O] Babel support for Processing-language
Date: Tue, 16 Sep 2014 13:19:49 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Nick Dokos <address@hidden> writes:

> Jarmo Hurri <address@hidden> writes:
>
>> ...
>> However, I have _no idea_ what kind of work supporting output capture of
>> both static mode (image) and active mode (animation) would
>> require. Ideally, Babel support for Processing output would mean that in
>> the case of
>> 1. an animation 
>>    - HTML export it would export the entire animation
>>    - PDF export it would export, e.g., the first frame from the
>>      animation
>> 2. a static picture, the picture would be exported.
>
> Here's a possible starting point in your research:
>
>   http://orgmode.org/worg/org-contrib/babel/languages.html#develop
>
> My next step would be to find an ob-<lang>.el that is as similar
> as possible to what Processing does and what I'd want to achieve
> and go from there.

Yep, I am going to start doing this if no-one is working on it yet.

I woke up in the middle of the night to realize how amazingly easily
this can be done if I drop out the support for PDF export, that is, only
leave the option to export as HTML. There is no need to even execute the
code at export time to draw the image or the animation, because in HTML
you can just wrap the original Processing code in a canvas element and
the Processing.js code will draw it in the browser.

http://en.wikipedia.org/wiki/Processing.js

Let me repeat: by just exporting the code suitably embedded in the HTML
document, the _browser_ will draw the image or the animation. I just
tested it and it works perfectly.

So I will implement this in Org/Babel so that
- executing Processing code will result in the image / animation being
  shown in an external window via processing-java
- exporting the results of Processing code is only sensible in HTML
  export, which will produce a web page with the code embedded as
  described above; the browser does the drawing.

These operations will require the availability of processing-java and
processing.js in the system where the code is executed/exported.
  
Any objections?

Jarmo




reply via email to

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