PIC embedding to XHTML

PIC embedding to XHTML

[sand]

When Firefox knows that your exported HTML file is really XHTML
(thanks to you changing `org-export-html-extension' to "xhtml"), you
can embed SVG into it.  For example, here are PIC diagrams:

http://home.avvanta.com/~sand/org-mode/embedded-pic.xhtml

Those are the first two diagrams in "Making Pictures With GNU PIC"
(http://www.kohala.com/start/troff/gpic.raymond.ps).

It should be possible to do something similar for the "dot" exporter.

Derek

-- 
Derek Upham
sand@blarg.net

Re: PIC embedding to XHTML

[Carsten Dominik]

On Jun 20, 2009, at 10:00 AM, sand@blarg.net wrote:

> When Firefox knows that your exported HTML file is really XHTML
> (thanks to you changing `org-export-html-extension' to "xhtml"), you
> can embed SVG into it.  For example, here are PIC diagrams:
>
> http://home.avvanta.com/~sand/org-mode/embedded-pic.xhtml
>
> Those are the first two diagrams in "Making Pictures With GNU PIC"
> (http://www.kohala.com/start/troff/gpic.raymond.ps).
>
> It should be possible to do something similar for the "dot" exporter.

So ...  are you going to implement this, asking for an implementation,  
or what...?

:-)

- Carsten

>
> Derek
>
> -- 
> Derek Upham
> sand@blarg.net
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: PIC embedding to XHTML

[sand]

Carsten Dominik writes:
> > When Firefox knows that your exported HTML file is really XHTML
> > (thanks to you changing `org-export-html-extension' to "xhtml"), you
> > can embed SVG into it.  For example, here are PIC diagrams:
> >
> > http://home.avvanta.com/~sand/org-mode/embedded-pic.xhtml
> >
> > Those are the first two diagrams in "Making Pictures With GNU PIC"
> > (http://www.kohala.com/start/troff/gpic.raymond.ps).
> >
> > It should be possible to do something similar for the "dot" exporter.
> 
> So ...  are you going to implement this, asking for an implementation,  
> or what...?

Still experimenting.  I got Dot working last night.  The problem is
we're missing some layers of abstraction:

  * If I submit code that lets "pic" blocks generate SVG for HTML,
    then things won't work properly for people without SVG-capable
    browsers.  We need some way for a user to say "When exporting
    HTML, render PIC using SVG".

  * The current "dot" and "ditaa" control mechanisms work by exposing
    command-line arguments, which get sent to the underlying program.
    Bernt Hansen's document example uses

        #+begin_dot gv01.png -Kdot -Tpng

    The "-Tpng" directive and the ".png" suffix should be implied by
    an "I want PNG" configuration, and the "-Kdot" should be implicit
    in the directive name.  There's definitely a need to allow
    command-line args on a block-by-block basis, but they need to be
    qualified by the rendering mechanism at least.

  * There are other arguments that you want to send to Emacs to do
    post-processing on the external program's output.  I use those to
    shrink the PIC SVG output down to something more manageable.
    In my examples, they are the "7in 1in" arguments; they are only
    meaningful for PIC-in-SVG, as the "pic2graph" tool always uses an
    8in x 8in canvas.

Taking all of this into account, we might come up with something like
the following:

#+begin_export pic html:svg latex:eps docbook:svg ascii:nroff
#+render_args eps :filename "figure_3_1.ps"
#+render_args svg :width "7in" :height "1in" :command "-F Times"
ellipse "document";
arrow;
box "\fIgpic\fP(1)";
arrow;
box width 1.2 "\fIgtbl\fP(1) or \fIgeqn\fP(1)" "(optional)" dashed;
arrow;
box "\fIgtroff\fP(1)";
arrow;
ellipse "PostScript"
#+end_export

The new directive is "#+begin_export".  First argument "pic" defines
how to interpret the contents.  The remaining arguments are supported
publishing types and what renderer to use.  Those are all optional;
users can set up their own defaults.

The "#+render_args" directive indicates a renderer, with a
property-list following.  My inclination is to have something that
Emacs can suck into a plist.  By convention, the ":command" tag
contains the arguments to pass down to the child process.

Comments?

Derek