emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Eric Schulte" <schulte.eric@gmail.com>
To: Carsten Dominik <carsten.dominik@gmail.com>
Cc: Russell Adams <RLAdams@AdamsInfoServ.Com>,
	Org Mode List <emacs-orgmode@gnu.org>
Subject: Re: org-exp-block patch and Graphviz Demo
Date: Thu, 28 May 2009 06:44:14 -0700	[thread overview]
Message-ID: <m2hbz5ibpt.fsf@gmail.com> (raw)
In-Reply-To: <240CD10F-57E8-4AEB-B2D1-E03A9851DB41@gmail.com> (Carsten Dominik's message of "Thu, 28 May 2009 09:48:51 +0200")

Carsten Dominik <carsten.dominik@gmail.com> writes:

> On May 27, 2009, at 9:09 PM, Russell Adams wrote:
>
>> I updated org-exp-block.el to support other Graphviz output types (ie:
>> neato, fdp, twopi, and circo.), and created a test document to
>> demonstrate each type.
>>
>> Attached is a tar file containing the demo, diff, and updated
>> org-exp-block.el. It could use some tuning before being permanently
>> applied, see the comments within.
>>
>> I considered posting this to Worg, but was concerned that it would
>> bomb without the updated block support. After its added to core, I'd
>> be happy to post this into Worg.
>>

Hi Russel,

Thanks for the update, and for the clear exposition in the org demo
file.  I think that rather than changing the specification of the dot
block (which will break existing org files) we should create new block
files.  Either create a single graphviz file, which will accept an
argument indicating which command to use, or create a new block type for
each command.  I'm not sure which of these approaches would be
preferred...  They should both require only small changes to your
existing code.  If we were starting from scratch my preference would be
a single graphviz block type, however in order to maintain functionality
for existing org-mode documents, in this case I would lean towards
generating a block type for each command.  I suppose we could support
both options.

any suggestions?

I certainly agree that a change along these lines should be added to the
version of org-exp-block.el distributed with org mode.

Also, sorry about the delayed reply, I was waiting until I found the
time to actually look over your attached files.

>>
>>
>> My next question relates to using Graphviz between HTML and Latex
>> export. When I do HTML I don't mind using PNG, however with Latex it
>> is better to export to EPS. That way you export to a vector format
>> that looks superb in the final PDF. This requires a postprocessing
>> step that I'm not sure how to integrate.
>>
>> From one of my Makefiles, I use this line to fix the EPS so that Latex
>> can import it:
>>
>> sed -i -e 's/PS-Adobe-2.0/PS-Adobe-2.0 EPSF-1.2/1' $@
>
> Maybe this needs a bug report to the Graphviz people???
>

+1

>
> I guess the best solution would actually be to allow a lisp
> function to do the formatting, and it should return the
> link to be used.  then you can implement whatever is needed.
>
> Eric, would that make sense?
>

Yes,

Although I'm not sure how best to automatically associate a lisp (or
shell) function as a post processing step, and to then pass the file
path used in this block to said function... Possibly a something along
the lines of a #+postprocessing: line immediately preceding the block.

However that would be a general solution.  If our goal is just to allow
post processing in this instance, I believe that using defadvice would
be the easiest hack.  Make sure that the last statement in
`org-export-blocks-format-dot' returns the file path, and then try
something like the following...

--8<---------------cut here---------------start------------->8---
(defadvice org-export-blocks-format-dot (around fix-eps-org-export-blocks-format-dot activate)
  "Fix graphviz eps output."
  (let ((file ad-do-it))
    (shell-command (format "sed -i -e 's/PS-Adobe-2.0/PS-Adobe-2.0 EPSF-1.2/1' %s" file))))
--8<---------------cut here---------------end--------------->8---

Cheers -- Eric

>
> - Carsten

  reply	other threads:[~2009-05-28 13:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-27 19:09 org-exp-block patch and Graphviz Demo Russell Adams
2009-05-28  7:48 ` Carsten Dominik
2009-05-28 13:44   ` Eric Schulte [this message]
2009-05-28 14:23     ` Eric Schulte
2009-05-28 18:03 ` Org Mode List
2009-05-28 22:47   ` Russell Adams
2009-05-28 22:57     ` Eric Schulte
2009-06-09 15:50       ` Russell Adams
2009-06-10 14:51         ` Eric Schulte
2009-06-10 15:29           ` Russell Adams
2009-06-10 16:06             ` Eric Schulte
2009-06-10 16:22               ` Russell Adams
2009-06-10 17:12                 ` Eric Schulte
2009-06-10 17:54             ` Mark Elston

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2hbz5ibpt.fsf@gmail.com \
    --to=schulte.eric@gmail.com \
    --cc=RLAdams@AdamsInfoServ.Com \
    --cc=carsten.dominik@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).