Re: [guppi-list] Re: Radical suggestion/question

[Conrad Steenberg <conrad srl caltech edu>]

Hi Jon

I'm quoting a lot here and cc to the guppi-list, this may be of interest
to others as well.

On Thu, 27 Jan 2000, Jon Trowbridge wrote:

> On Thu, Jan 27, 2000 at 02:52:45PM -0800, Conrad Steenberg wrote:
> > I meant that you could create documents with it, i.e. with multiple pages
> > per document, multiple objects (which may be plots, or whatever) per page.
> > That way you could make multipage plots from the same data/instruction
> > file.
> 
> OK, I see where you are going with this now.
> 
> > When guppi plots are printed, I think you deal with plot positioning on a
> > page anyway, so putting multiple plots on a page, and adding multiple
> > pages to a document are not great conceptual leaps.
> 
> Well, I don't really deal with positioning yet, but I eventually will.
> 
> This is an important idea, actually, and it is good to raise it now.
> The question really (IMHO) boils down to how much "desktop publishing"
> to put into a program like Guppi.  Obviously Guppi should be able to
> produce nice looking individual plots --- how do you go about creating
> a way for the user to deal with multiple plots or (more generally) to
> create a complex document with N visualizations based on M common
> datasets.
> 
> Off the top of my head, I'd say that Guppi doesn't need to worry about
> this so much, and should be optimized for producing one
> visualization/plot at a time.  Why?  Well, I see two ways that Guppi
> might be used:
> 
> * Traditional Publishing of Scientific Papers.  As long as Guppi can
>   emit nice postscript, this front is covered -- people will just
>   stick stuff into their TeXed paper in \epsfbox-es.
> 
> * Fancier compound documents.  I assert (perhaps incorrectly) that it
>   is sufficient, and in fact is the most Gnomeifically correct
>   solution, to Bonoboify and componentize Guppi.  Then complex
>   documents could be made by embedding N Guppi windows inside of a
>   Gnumeric spreadsheet, an AbiWord document (assuming that AbiWord
>   eventually supports components), an Achtung! presentation (assuming
>   that anybody ever gets around to writing Achtung!), etc.
> 
>   (I don't really know much about how this whole components business
>   works, but I'm assuming that Miguel & Co. have ways to correctly
>   handle high quality printing, etc. of compound documents.)
> 
> Now I do want to support a high level of complexity in each individual
> Guppi visualization.  For example, NxN scatterplot grids showing each
> possible 2-dim scatterplot of N different variables.  Or multiple
> superimposed plots with custom hand-placed annotations and markings.
> 
> But overall, I think that even small amounts of "desktop publishing"
> can increase the complexity of the whole enterprise by an order of
> magnitude.  Of course, I could be totally wrong --- maybe it really
> isn't that hard of a problem.  Maybe, if things are designed properly
> from the beginning, it could be added later w/o much trouble.  And
> maybe it really is necessary and the two cases I mentioned above
> aren't exhaustive --- and if it is necessary, there is no choice but
> to put it in there, no matter the complexity.
> 
> This is definitely a subject for future rumination; I'd appreciate
> hearing any thoughts you might have about it.  I've found that it is
> important to identify these kinds of issues as early as possible, so
> that they can be rattling around in the back of your head during the
> early coding.
> 
> -JT
> 

Well personally I always get requests to alter plots in some way that just
cries out for some dtp solution. Eg. "draw an arrow pointing out this data
point" or "label this part of the line with an X". 

The nice thing about doing everything with components is that you can
embed your plot in, say sketch or sodipodi, and do those manual drawing
things, and eventually embed the result in abiword or latex. Oh, and then
you will need an equation editor component too.

On the other hand, I figured that once you start doing the little things,
like axes and label, you might as well establish an object framework. Once
that is done you just work on the object editors. From that perspective,
guppi is a plot object editor at the moment. It will need an axis label
editor, an axis tick mark editor and label placement editor. The problem
is that this becomes a huge undertaking.

So, to sum up:
    for: generalization is nice and eventually needs to be done
against: it will set back guppi _another_ chunk of time and we all would
         rather have something working soon

There, my brain is fried, and I need to get home and get rid of this cold
:-)

Conrad