Re: extending pstricks terminal driver

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

On Thursday 11 December 2008 14:49:55 Petr Mikulik wrote:
> > > > > >>     plot '<convert table.png avs:-' binary filetype=avs with rgbimage
> > > > > >>
> > > > > >> Nowadays gnuplot is typically compiled with the gd library. Therefore it
> > > > > >> should be pretty easy to use the gd-library to load png/gif/jpg images
> > > > > >> directly. I think it may not be too much code in breaders.c. Could somebody
> > > > > >> contribute this feature?
> > > > > >
> > > > > > I honestly don't see quite how that would work.
> > > > > > Using libgd, or libpng for that matter, will result in an in-memory copy
> > > > > > of the bitmap image.  But that's not exactly what the binary file input code
> > > > > > wants; it expects to read a stream of binary data on the input fd, so that it
> > > > > > can filter, re-map, combine fields, etc.  It seems to me that one would
> > > > > > have to write a new input layer that dummies up access to an in-memory
> > > > > > bitmap as successive reads to a fake pipe.
> > > 
> > > The abstraction layer ... cannot be this done in some easy way? Currently 
> > > there are fread(f, ..., bytes) ... so instead of fread() there would be 
> > > memcpy().
> > > 
> > > The gain would be portability and speed. We could put lena.png and lena.jpg 
> > > into demos/ and be sure that these demos can be run by Windows executables 
> > > as well.
> > 
> > I don't see how requiring ImageMagick limits the portability, and it is
> > a much more general solution than one that accommodates only png images.
> > I am dubious that the speed is enough different to notice.
> >
> > As to Windows, it would be of far more value to get the popen() filter
> > mechanism working under Windows than it would be to add large chunks of
> > code to make up for various individual things you can't do because of this
> > shared fundamental flaw.
> 
> ImageMagick is no problem for Linux users. It is problem for Windows people. 
> We cannot expect them to install any other tool. Gnuplot should not depend 
> on outside filters, if we can organize it within gnuplot.

That's nonsense.  If they can install gnuplot, they can also install
ImageMagick.  Probably more easily, since we don't have a one-click 
Windows installer :-)

Gnuplot already makes good use of external filters and tools including
ghostscript, LaTeX, Fig, and lots of locally tailored scripts requiring
perl, python, tcl, etc.  Gnuplot's strength is the extent to which it
complements and extends existing tools.  The ability to pipe data in and
out through filters is a key part of this. We should not re-invent the
wheel, badly, rather than playing to our strength.
 
> popen() works on Windows, but wgnuplot_pipes.exe binary has to be run 
> instead of wgnuplot.exe

I understand that stdin/stdout are problematic if the program is run
without a console window, but that is a different issue than reading
data via a call to popen().  Why would you ever want to run a version
that deliberately omits support for popen()?

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