From mboxrd@z Thu Jan 1 00:00:00 1970 From: sand@blarg.net Subject: Re: PIC embedding to XHTML Date: Mon, 22 Jun 2009 19:00:14 -0700 Message-ID: <19008.14126.229480.924010@priss.frightenedpiglet.com> References: <19004.38714.502593.818239@priss.frightenedpiglet.com> <8FA50A43-511E-4A4E-BFBD-B919440BE70E@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MIvKg-0003Ak-Sn for emacs-orgmode@gnu.org; Mon, 22 Jun 2009 22:01:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MIvKc-00039W-Gr for emacs-orgmode@gnu.org; Mon, 22 Jun 2009 22:01:58 -0400 Received: from [199.232.76.173] (port=50233 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MIvKc-00039T-7q for emacs-orgmode@gnu.org; Mon, 22 Jun 2009 22:01:54 -0400 Received: from v-static-143-234.avvanta.com ([206.124.143.234]:46608 helo=priss.frightenedpiglet.com) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MIvKb-0006CD-9S for emacs-orgmode@gnu.org; Mon, 22 Jun 2009 22:01:53 -0400 In-Reply-To: <8FA50A43-511E-4A4E-BFBD-B919440BE70E@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Carsten Dominik Cc: emacs-orgmode@gnu.org 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