Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]

[Ethan A M. <merritt@u.washington.edu>]

On Thursday 14 July 2005 10:47 pm, Lucas Hart wrote:
> > >In particular PM3D is now so integral to many new features that I
> > >think it would make no sense for anyone to upgrade past version 4.0
> > >and *not* include PM3D.  Why go out of our way to support a
> > >combination of options that doesn't make any sense?
>
> Has there been a consensus on such a change in the direction of
> gnuplot development?
>
> From the gnuplot home page "Gnuplot is a portable command-line driven
> interactive data and function plotting utility for ...many platforms
> ... has grown to support many non-interactive uses, including web
> scripting and integration as a plotting engine for third-party
> applications like Octave."

I see no change away from that policy statement.

> PM3D support adds image processing but that is an option in v4.0.

But there the description goes off the rails.  PM3D may have been
originally motivated by image processing, but most/all of the #ifdef PM3D
code segments in gnuplot have absolutely zero to do with image 
processing.

> Users who have no need for the image processing features, who do
> not have graphics hardware to support PM3D graphics, or to whose
> OS PM3D is not ported can build a v4.0 executable without PM3D
> support.

This makes no sense to me (does it really say this on our home page?).
There is no graphics hardware required for PM3D, nor is there an OS
requirement. Zero. None. Nada.  This statement is just utterly confused.

> You seem to be taking the position that portability and local
> configurability of gnuplot are no longer goals, rather that newer
> versions of gnuplot are intended solely for systems capable of being
> used for image processing

Forget this business about image processing. That is a red herring.
That phrase appears nowhere in the gnuplot documentation, and should
not appear on the web site either. 

In fact the portability and generality of gnuplot scripting is very
much improved by the PM3D code. I have never used gnuplot for image
processing, but my web scripts use the PM3D code daily for generating
plots with portable color assignments, filled curves, color-coded
scatter plots, and so on.

> While it is an additional burden on developers to code and test
> w/ and w/o PM3D support, and building w/o PM3D support on Linux
> platforms may have little impact on resources, I believe requiring
> gnuplot users to include PM3D support is a major change that may
> affect portability.

I would be more impressed by that argument if someone could point
to a single platform for which inclusion of PM3D  support is problematic.  
Are you agreeing with HBB that a 10% size difference is a make-or-break
issue?  Is there reason to believe that the size difference on non-unix
platforms will be greater that 10%?  I encourage someone to run the
same test builds I did on, say, MSWindows.

If I recall correctly, PM3D per se is not a problem even for 16-bit
DOS. It's the PostScript driver that is the killer, because its text
section contains huge blocks of PostScript prolog string data.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742