octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

gnuplot backend (was Re: Patch to add axis position property)


From: Daniel J Sebald
Subject: gnuplot backend (was Re: Patch to add axis position property)
Date: Mon, 13 Aug 2007 21:19:15 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020

Peter Gustafson wrote:
Daniel J Sebald wrote:

It's a fixable problem, I suspect.  If you want, you can force the
margins and hence the borders to the same.

[snip]

Thanks for the info.  This will certainly help if somebody tries to
implement a plotyy feature.  I may try and code it but it is not
imminent... several other priorities are in the way.

People can force that themselves for now.

[snip]

PPS jwe has stated that he believes gnuplot is a temporary fix for a
backend, and has encouraged people to contribute in ways that will help
implement the long term solution... may I ask what people believe that
is?  Perhaps that should be a different thread.

Yes, you may; valid question.  John has stated this now and then.  However, I'm 
a little more comfortable with gnuplot than most, I suppose, for several 
reasons.  Yes, gnuplot has its limitations and has been feature-barren in the 
past.  However, there are a few developers that have added features at a faster 
pace lately.  The advantages are the wealth of output formats, especially 
latex/ps.  To someone with a command line, linux and nice final plot (with some 
work) computer philosophy, that is preferred over the more GUI-like plotting.  
Also, gnuplot is an interpreter, as opposed to being compiled into Octave.  
Some see that as a disadvantage, perhaps speed wise, but my guess is that 
compiling an output-format-rich plotting library into Octave would be more work 
than one thinks.  One would have to program the margins, font size, color etc. 
inside Octave, probably no less work than __go_draw_axes__.m.  Then, one step 
further, I think the goal is GUI interactive fine-tuning, w
hich makes the programming task even greater.

Which brings up the main issue, i.e., someone or a group of individuals with 
time to dedicate to an Octave graphics engine.  Paying someone to do that might 
get the ball rolling, but I'm not suggesting that.

On the other hand, the handle graphics transition went more smoothly than I expected 
(relatively speaking), so maybe I'm over-estimating the amount of work.  Also, I think 
that what John has set up now is nice.  All the engine-dependent code is in 
__go_draw_axes__.m, __go_close_all__.m, etc.  (i.e., "graphics output") and 
there is little if any core graphics code in these files.  If these were bundled under 
one subdirectory, they could be considered a package, of which gnuplot support is just 
another option that could be selected when Octave is installed.  Whether eventually that 
means internal compiled functions (for a little extra speed), external functions, don't 
know.  This ability to select graphics engine would be a feature in itself.

Dan


reply via email to

[Prev in Thread] Current Thread [Next in Thread]