From graphics-request at octave dot org Thu Feb 16 12:15:39 2006
Subject: Re: Minimal requirements from a handle graphics package
From: Shai Ayal <shaiay at gmail dot com>
To: Marcus Vinicius Eiffle Duarte <eiffleduarte at gmail dot com>
Cc: octave-help at octave dot org, octave-graphics <graphics@octave.org>
Date: Thu, 16 Feb 2006 20:13:56 +0200

I think I understand now. My confusion was in part because I though
you meant the fig format from xfig.

The simplest way to make this, and this would also be compatible with
all handle graphics applications (including the leading brand) would
be for application to output a m-file containing all commands needed
to recreate the figure. This file would be ugly and hard to read, but
it would do the job.

Shai

p.s. The way I deal with it right now in my work is ensure each graph
has an m-file which creates it, stamped with CVS version both in the
file and on the graph, but this does not address the problem of the
data which might come from a different file.

On 2/16/06, Marcus Vinicius Eiffle Duarte <eiffleduarte at gmail dot com> wrote:
> Shai,
>
> let me explain: I find it very useful to have graphs saved in a file that
> contains both data and formatting. After I handcraft the formatting of a
> graph for a given purpose (let's say, printing fullcolor in brilliant glossy
> paper), I can just reload it and change the formatting for another purpose
> (a b&w printing, for example).
>
> Of course I can do it from data files, just changing the code that
> originated the first figure. However, I really like to "backup" my figures
> as FIG files, as I can later have the exact formatting I used, even after I
> change code (and fail to keep track of changes - I suppose I am not the only
> one who forgets to keep track of different versions of code/formatting).
>
> If there is no saving/loading FIG files, there is no lack of functionality,
> I just find it would be really useful. If the difficulty is the exact format
> of the FIG file, I guess there could be an alternate file format to store
> data and formatting, but it would be not a required feature, just a possible
> (and later) add-on.
>
> Marcus Vinicius
>
>