gnuplot-beta — Developers and beta testers of new gnuplot code

Re: gnuplot algorithm to find axis spacing - linking axes

[<HBB...@t-...>]

Daniel Farrell wrote:
> I have notices that 'linking' axes is on the 'todo' list, how can I  
> get involved?

Do it, post the patch on the tracker, and watch the show.

> I guess the command could be:
> link {<known axis><linked axes>} {<equation string>}

No new top-level command please.  Make it a new option to 'set xtics' 
instead.

As to the evaluation engine: look up the function "evaluate_at", and its 
supporting machinery in eval.c, internal.c, specfun.c and some others.

Re: gnuplot algorithm to find axis spacing - linking axes

[Petr M. <mi...@ph...>]

> I guess the command could be:
> link {<known axis><linked axes>} {<equation string>}

I think it should be
 	set x2range mapping 10*x+1

Have a look to the archive of this conference, I think it was discussed some 
time in the past.

---
PM

RC2 on Suse 9.3

[Jacques Le B. <Jac...@ob...>]

Bonjour,

I just compiled and installed RC2 on a Linux Laptop with SuSE 9.3 (+ all
latest upgrades I could find). I had very few issues. Thank you for the
nice job! Here are the pbs:

* libgd:
   I had to manually create a link from libgd.so.2 to libgd.so in
/usr/lib. It was not found by configure. Also gd was installed, but not
gd-devel so that "make" crashed when looking for gd.h (which was not
there). probably configure should look for both libgd and gd.h

* Pango:
   SuSE comes with pango 1.10.2 and I could not find newer packages. I
compiled 1.10.4 and had no further problems at
configuration/compilation time. But...

* Wxt:
   The terminal works (i.e. I get all the nice plots in the window).
However all texts are ridiculously small (size 1 point?) and useless. I
could not figure out why.

* UTF8:
  Results of "utf8.dem" are unreliable. May come from my fonts
installation (which I never really understood). More specifically, I can
not set encoding to "utf8" (I know it is not in the list...), and could
not find how to get such characters as "=E9", "=E0", etc... which are
mandatory in french. Note: I use the standard SuSE setting : LANG =3D
fr_FR.UTF-8, so neither "default" nor "iso_8859_15" work.

The colors are incredibly nice!

Thank you.

Jacques Le Bourlot

PS: The "x2 =3D f(x1)" ticks is something I have prayed for for years. I
hate computing and setting the x2tics by hand each time. Please include i=
t
ASAP. Tanks.

Re: gnuplot algorithm to find axis spacing - linking axes

[Daniel F. <boy...@gm...>]

Hi Daniel,

The algorithm is external to all gnuplot source code at the moment.

I don't really know where to start in term of integrating it to the  
project?

I have notices that 'linking' axes is on the 'todo' list, how can I  
get involved?

I guess the command could be:
link {<known axis><linked axes>} {<equation string>}

e.g.
plot 'data.txt' using 1:2 with lines link x1x2 '$1*10'

i.e. if x1 = 0,1,2,3,4,5
x2 = 0,10,20,30,40,50

Regards,

Dan








On 27 Nov 2006, at 11:25, Daniel J Sebald wrote:

>  sourceforge web site to maintain your algorithm.

Re: Re: Building wxt terminal for OS X

[Mojca M. <moj...@gm...>]

On 11/24/06, Joe Koski wrote:
> on 11/23/06 10:09 PM, Mojca Miklavec wrote:
>
> > Just as a warning. This is how the last Mac version of gnuplot 4.0 fails here.
> >
> >> /usr/local/bin/gnuplot
> > dyld: Library not loaded: /usr/local/lib/libaquaterm.1.0.0.dylib
> >   Referenced from: /usr/local/bin/gnuplot
> >   Reason: image not found
> > Trace/BPT trap
> >> locate libaquaterm
> > /sw/lib/libaquaterm.1.0.0.dylib
> > /sw/lib/libaquaterm.dylib
> > /usr/local/lib/libaquaterm.1.0.1.dylib
> > /usr/local/lib/libaquaterm.dylib
> >
> > Mojca
> >
> Mojca,
>
> If you run the AquaTerm installer found via the AquaTerm website, it puts
> things into /Library/Frameworks/AquaTerm.framework and /usr/local/lib. You
> might try running the "official" AquaTerm-1.0.1 installer, rather than using
> the older Fink version of AquaTerm.

I have that one as well. The problem is that gnuplot has been compiled
with the older version and now it doesn't work any more. I have a
working version of gnuplot at the moment, but such situations should
be avoided in future if possible.

On 11/24/06, Per Persson wrote:
> >Just as a warning. This is how the last Mac version of gnuplot 4.0 fails here.
> >
> >/usr/local/bin/gnuplot
> >dyld: Library not loaded: /usr/local/lib/libaquaterm.1.0.0.dylib
>
> Mojca,
> this is an installer bug in AquaTerm 1.0.1
>
> Unless you are on an Intel Mac, simply use the AquaTerm 1.0.0 installer to downgrade (only difference is that 1.0.1 is a "fat" binary containing both Intel and PPC code).
>
> If you have an Intel Mac, just create a symlink:
> ln -s /Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm /usr/local/lib/libaquaterm.1.0.0.dylib

I don't think that it makes any sense to downgrade for me since I
managed to create my own binary anyway, but I'm afraid of problems
that other users might have (now or in future) if gnnuplot will remain
highly dependant on versions of libraries used on a certain computer.

I hope that the one in charge for preparing the latest binaries will
also take care about such issues.

Thanks,
Mojca

Re: gnuplot algorithm to find axis spacing

[Daniel F. <boy...@gm...>]

Hi,

Thanks for the pointers. I have it all working now.

I have made an algorithm that 'links' x1 and x2 axis via a equation =20
(it actually just automate the set x2tics(...) function once the x1 =20
and a transformation equation are known.). It would be nice to =20
integrate my work with the gnuplot source when. However, I will now =20
have to learn about how gnuplot interprets equation; so that the user =20=

can link the axes, my code needs to be more general.

I'll post again about this subject after I've had a chance to read =20
some more source.

Cheers,

Daniel.

On 26 Nov 2006, at 21:36, Hans-Bernhard Br=F6ker wrote:

> Daniel Farrell wrote:
>
>> Where is this calculated in the code?
>
> src/axis.c: gen_tics and make_tics()
>
>> How does gnuplot calculate the step size between tic marks?
>
> Compute the length of the axis, find a tic size from the usual =20
> 1/2/5 times power-of-ten series that will create a "useful" number =20
> of tics (between 5 and 10) on that range.  Variations of this =20
> scheme are needed for logarithmic and time/date scales.
>
>

Re: gnuplot algorithm to find axis spacing

[<HBB...@t-...>]

Daniel Farrell wrote:

> Where is this calculated in the code?

src/axis.c: gen_tics and make_tics()

> How does gnuplot calculate the step size between tic marks?

Compute the length of the axis, find a tic size from the usual 1/2/5 
times power-of-ten series that will create a "useful" number of tics 
(between 5 and 10) on that range.  Variations of this scheme are needed 
for logarithmic and time/date scales.

gnuplot algorithm to find axis spacing

[Daniel F. <boy...@gm...>]

Hello,

I want to understanding how gnuplot calculates xtic for a given range  
e.g.
plot x
set xrange [0:100]
replot

will place tic marks at 0, 20, 40, 60, 80 and 100.

Where is this calculated in the code?

How does gnuplot calculate the step size between tic marks?

I have worked on my own algorithm for xtics position for a given  
range and it works well.  However it required the user to input the  
step size between tic marks. e.g. plotting x from 0 to 100 the user  
would have to specify the tic separation was 20.

Regards,

Daniel.

Re: Mac wxt build errors with gnuplot-4.2.rc2

[Joe K. <jko...@co...>]

on 11/25/06 2:00 PM, Timoth=E9e Lecomte at tim...@en... wrote:

> Joe Koski wrote:
>> Ethan, Timoth=E9e,
>>=20
>> I tried building gnuplot-4.2.rc2 on my G5 Mac with OS X 10.4.8, Xcode2.4
>> Developer tools, and same pango/cairo that I had built previously. There
>> have been no changes to my build routines since I successfully built
>> gnuplot-4.2.rc1.
>>=20
>> During the build, all goes well until:
>>=20
>> <snip> I seem to be missing some parts (a header file?) necessary to bui=
ld
>> the wxt
>> terminal.
>>  =20
> You still need to patch in src/wxterminal with wxmac.diff
> I have not committed it yet to the CVS, although I should have...
>=20
> Thank you again for your efforts in testing this.
>=20
> Best regards,
>=20
> Timoth=E9e

Timoth=E9e,

Yes, that fixed the problem. Thanks. Yes, I think that the patch can be
submitted, and then we can worry about bundling later.

Joe

Re: Mac wxt build errors with gnuplot-4.2.rc2

[<tim...@en...>]

Joe Koski wrote:
> Ethan, Timoth=E9e,
>
> I tried building gnuplot-4.2.rc2 on my G5 Mac with OS X 10.4.8, Xcode2.=
4
> Developer tools, and same pango/cairo that I had built previously. Ther=
e
> have been no changes to my build routines since I successfully built
> gnuplot-4.2.rc1.
>
> During the build, all goes well until:
>
> <snip> I seem to be missing some parts (a header file?) necessary to bu=
ild the wxt
> terminal.
>  =20
You still need to patch in src/wxterminal with wxmac.diff
I have not committed it yet to the CVS, although I should have...

Thank you again for your efforts in testing this.

Best regards,

Timoth=E9e

Mac wxt build errors with gnuplot-4.2.rc2

[Joe K. <jko...@co...>]

Ethan, Timoth=E9e,

I tried building gnuplot-4.2.rc2 on my G5 Mac with OS X 10.4.8, Xcode2.4
Developer tools, and same pango/cairo that I had built previously. There
have been no changes to my build routines since I successfully built
gnuplot-4.2.rc1.

During the build, all goes well until:

/Tools/gnuplot-4.2/share/gnuplot/4.2/PostScript\"
-DCONTACT=3D\"gnu...@li...\"
-DHELPFILE=3D\"/Tools/gnuplot-4.2/share/gnuplot/4.2/gnuplot.gih\"
-I/usr/local/include/cairo -I/usr/local/include/libpng12
-I/usr/local/include/pango-1.0 -I/usr/local/include/glib-2.0
-I/usr/local/lib/glib-2.0/include    -g -O2
-I/usr/local/lib/wx/include/mac-ansi-release-2.6 -I/usr/local/include/wx-2.=
6
-D__WXMAC__ -D_FILE_OFFSET_BITS=3D64 -D_LARGE_FILES -DNO_GCC_PRAGMA
-I/usr/local/include/cairo -I/usr/local/include/libpng12
-I/usr/local/include/pango-1.0 -I/usr/local/include/glib-2.0
-I/usr/local/lib/glib-2.0/include   -MT wxt_gui.o -MD -MP -MF
".deps/wxt_gui.Tpo" -c -o wxt_gui.o `test -f 'wxterminal/wxt_gui.cpp' ||
echo './'`wxterminal/wxt_gui.cpp; \
then mv -f ".deps/wxt_gui.Tpo" ".deps/wxt_gui.Po"; else rm -f
".deps/wxt_gui.Tpo"; exit 1; fi
In file included from wxterminal/wxt_gui.cpp:96:
wxterminal/wxt_gui.h:199:3: error: #error "Not implemented"
wxterminal/wxt_gui.cpp:197:3: error: #error "Not implemented."
wxterminal/wxt_gui.cpp:1365:3: error: #error "Not implemented."
wxterminal/wxt_gui.cpp:2892:2: error: #error "Not implemented"
wxterminal/wxt_gui.cpp:3087:3: error: #error "No implementation"
wxterminal/wxt_gui.cpp:3098:3: error: #error "No implementation"
wxterminal/wxt_gui.cpp:2640: error: no 'void
wxtPanel::wxt_cairo_create_bitmap()' member function declared in class
'wxtPanel'
wxterminal/wxt_gui.cpp: In function 'void wxt_atexit()':
wxterminal/wxt_gui.cpp:2981: error: 'thread' was not declared in this scope
wxterminal/wxt_gui.cpp:2982: error: type '<type error>' argument given to
'delete', expected pointer
wxterminal/wxt_gui.cpp:2991: error: expected type-specifier before
'wxtThread'
wxterminal/wxt_gui.cpp:2991: error: expected `;' before 'wxtThread'
wxterminal/wxt_gui.cpp: In function 'void wxt_cleanup()':
wxterminal/wxt_gui.cpp:3061: error: 'thread' was not declared in this scope
wxterminal/wxt_gui.cpp:3062: error: type '<type error>' argument given to
'delete', expected pointer
make[3]: *** [wxt_gui.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

I seem to be missing some parts (a header file?) necessary to build the wxt
terminal.

(Once we get past this, maybe I should post to either the Apple unix-portin=
g
list or the wxWidget list to get some help with bundling. I still need some
advice on how to deal with bundling so that a terminal is invoked when one
is needed.)

Let me know what to try next. Thanks.

Joe

Gnuplot version 4.2-rc2 (second release candidate)

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

	SECOND RELEASE CANDIDATE FOR GNUPLOT VERSION 4.2
	================================================

We are delighted to announce the availability of the second release
candidate for gnuplot version 4.2, in the form of a source file tarball.
4.2-rc2 is available initially as source only; pre-compiled binaries
for selected platforms will follow. Volunteers to produce such binaries
would be very welcome.

You may download 4.2-rc2 from the gnuplot development site on SourceForge.

  http://sourceforge.net/project/showfiles.php?group_id=2055


Installation
------------
Installation instructions are available in the source itself; the short
version for linux/unix-like systems is to unpack the tarball and then
build it:
		cd gnuplot-4.2.rc2 ; ./configure ; make
test it:
		make check
install it:
		make install


Short list of fixes since 4.2-rc1
---------------------------------
- various platform-specific fixes for configuration and compile problems
- clip arrows to boundary of 3D plots
- fixed gamma correction of image plots in postscript
- fix color-handling in fig terminal
- pass UTF-8 character sequences through to svg and png output
- fixed logic error in initializing rotation matrices for binary data
- do a better job of skipping gracefully over empty or missing data files
- do not segfault on entry if the x11 external driver is not found
- more consistent implementation of "-persist" option
- do not allow 'set view map' to affect placement of rectangles in 2D plots
- Fix off-by-one error in defining PNG line widths - thanks, Mike!
- Fix errors in size specification for pdf terminal
- Remove several spurious warning messages emitted at run-time

Remaining issues (may or may not be resolved before official 4.2 release)
-------------------------------------------------------------------------
- Installation of the new wxt terminal under OSX is problematic
- Ongoing discussion of last-minute changes to the syntax of new options 
  + array specifications for 'with image'
  + additional modifiers for the 'set term <foo> size XX,YY' command
- Known bugs (no fix yet) in handling reversed axes in some plot types
- Behaviour of 'set size <foo>; set term png size <baz>' is different
  for the png/jpeg/gif terminal compared to all other terminal types.
  + Change it?  (breaks backwards compatibility with old scripts)
  + Leave it, but issue a warning whenever it would make a difference?
  + Add new build option, run option, or keyword?



Version 4.2
-----------
This version has been under development since the release of version
4.0 in April 2004. You have probably seen frequent mention of it here
as "the development version" or "version 4.1" or "the cvs version". 

4.2 contains a ton of new features and several new terminal drivers.
For a complete list, see the NEWS file that comes with the program.
Some major additions include

	* new 2D plot styles 'histogram' 'labels' 'image' 'rgbimage'
	* new 3D plot styles 'labels' 'vectors'
	* user control over color definitions and color choices
	* improved font handling and text formatting
	* text strings can be read and manipulated as normal data
	* new syntax to handle string variables and string functions
	* creation of animated gif sequences

Demo plots illustrating these and other features are online at

	http://gnuplot.sourceforge.net/demo_4.2/


We encourage everybody with a vested interest in gnuplot to get this new
version and give it a test ride.  In other words, we're calling for a
beta-test by the broader public.  That means you.

In order to assure that the quality of the upcoming full release is as
high as practical, it is important that as many of you as possible test
this release candidate in your own ways, and check that it doesn't break
spectacularly.  If there's a bug in it that makes this version unusable,
we'd like to hear about it _now_, rather than 3 hours after we release
an official version 4.2 to the general public.

Please report all bugs and installation problems to the bug tracker
on SourceForge:

	http://sourceforge.net/tracker/?group_id=2055&atid=102055

Thanks in advance, and have fun with it!

	- the gnuplot development team

-- 
Ethan A Merritt
sf...@us...

Re: help: how to set font in postscript files

[<HBB...@t-...>]

renjith padmanabha pillai wrote:

> but now i have to generate ps script file for the generated graph. the 
> labels and tics are getting overlaped if i used multiplot.
>  
> how i can set font in the case of post script.

Various ways, depending on which elements you need to do it for:

1) as an option on the 'set terminal postscript' command, to change the 
overall font

2) as a 'font' option in various commands that control text outputs, to 
change the font for those texts

3) using enhanced syntax (see 'help enhanced').

Re: Re: Building wxt terminal for OS X (Mojca Miklavec)

[Per P. <per...@ma...>]

>Just as a warning. This is how the last Mac version of gnuplot 4.0 fails here.
>
>/usr/local/bin/gnuplot
>dyld: Library not loaded: /usr/local/lib/libaquaterm.1.0.0.dylib

Mojca,
this is an installer bug in AquaTerm 1.0.1 

Unless you are on an Intel Mac, simply use the AquaTerm 1.0.0 installer to downgrade (only difference is that 1.0.1 is a "fat" binary containing both Intel and PPC code).

If you have an Intel Mac, just create a symlink:
ln -s /Library/Frameworks/AquaTerm.framework/Versions/A/AquaTerm /usr/local/lib/libaquaterm.1.0.0.dylib

/Per (back on-line real soon now)

Re: Building wxt terminal for OS X

[Joe K. <jko...@co...>]

on 11/23/06 10:09 PM, Mojca Miklavec at moj...@gm...
wrote:

> Just as a warning. This is how the last Mac version of gnuplot 4.0 fails here.
> 
>> /usr/local/bin/gnuplot
> dyld: Library not loaded: /usr/local/lib/libaquaterm.1.0.0.dylib
>   Referenced from: /usr/local/bin/gnuplot
>   Reason: image not found
> Trace/BPT trap
>> locate libaquaterm
> /sw/lib/libaquaterm.1.0.0.dylib
> /sw/lib/libaquaterm.dylib
> /usr/local/lib/libaquaterm.1.0.1.dylib
> /usr/local/lib/libaquaterm.dylib
> 
> Mojca
> 
Mojca,

If you run the AquaTerm installer found via the AquaTerm website, it puts
things into /Library/Frameworks/AquaTerm.framework and /usr/local/lib. You
might try running the "official" AquaTerm-1.0.1 installer, rather than using
the older Fink version of AquaTerm.

Joe

help: how to set font in postscript files

[renjith p. p. <ren...@ya...>]

Sir,=0A=0Ai am using this software for last three months. it works perfectl=
y.=0A=0Abut now i have to generate ps script file for the generated graph. =
the labels and tics are getting overlaped if i used multiplot.=0A=0Ahow i c=
an set font in the case of post script.=0A=0AThank you.=0A=0ARenjith=0A=0A

Re: Re: Building wxt terminal for OS X

[Mojca M. <moj...@gm...>]

Just as a warning. This is how the last Mac version of gnuplot 4.0 fails here.

> /usr/local/bin/gnuplot
dyld: Library not loaded: /usr/local/lib/libaquaterm.1.0.0.dylib
  Referenced from: /usr/local/bin/gnuplot
  Reason: image not found
Trace/BPT trap
> locate libaquaterm
/sw/lib/libaquaterm.1.0.0.dylib
/sw/lib/libaquaterm.dylib
/usr/local/lib/libaquaterm.1.0.1.dylib
/usr/local/lib/libaquaterm.dylib

Mojca

Re: Broken link in FAQ

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

On Wednesday 22 November 2006 02:43 am, Kristian Waagan wrote:
> Hello,
>
> There's a broken link in the FAQ, under the entry
> "Does gnuplot support bar-charts/histograms/boxes?"
> (http://www.gnuplot.info/faq/faq.html#SECTION00064000000000000000).

Thanks.

In any case, histograms/bar-charts are now supported as a distinct
style type. So the link should be updated or supplemented with a
pointer to the current demo

   http://gnuplot.sourceforge.net/demo_4.2/histograms.html

> The broken link is this one:
> http://www.usf.uni-osnabrueck.de/~breiter/tools/gnuplot/barcharts.en.
>html The correct one (I think) can be obtained my removing the last
> 's' ('barcharts' -> 'barchart'):
> http://www.usf.uni-osnabrueck.de/~breiter/tools/gnuplot/barchart.en.h
>tml
>
>
>
> regards,

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

Broken link in FAQ

[Kristian W. <kri...@gm...>]

Hello,

There's a broken link in the FAQ, under the entry
"Does gnuplot support bar-charts/histograms/boxes?"
(http://www.gnuplot.info/faq/faq.html#SECTION00064000000000000000).

The broken link is this one:
http://www.usf.uni-osnabrueck.de/~breiter/tools/gnuplot/barcharts.en.html
The correct one (I think) can be obtained my removing the last 's'
('barcharts' -> 'barchart'):
http://www.usf.uni-osnabrueck.de/~breiter/tools/gnuplot/barchart.en.html



regards,
-- 
Kristian

SVG versions of the demos

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

I ran the entire set of demos through the svg terminal,
shaking out some bugs in the process.  
The bugfixes are in cvs, and the demos can be viewed at

   http://gnuplot.sourceforge.net/demo_svg/

I omitted the main image demo because it adds another 30 MByte
and tends to tie up your browser for several minutes while it
renders the images pixel by pixel.

All demos are properly handled by the KDE ksvg plugin except
for the justification of enhanced text.  This is a known bug in ksvg.

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

Re: Simplified processing of image and rgbimage plots

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

On Monday 20 November 2006 10:01 pm, Daniel J Sebald wrote:
> 
> Would it mean altering
> 
>     void (*image) __PROTO((unsigned, unsigned, coordval *, gpiPoint *, t_imagecolor));
> 
> to include a pointer to a set of values representing a translation matrix?
> 
> Or would a new terminal driver routine for a translation matrix 
> that applies more generally be in order? 

I think it wants to be a new terminal entry (the core code needs to be able
to test for it). But in some of the terminals (post, pdf) this will 
essentially replace the current routine, which in turn becomes a one line
wrapper:

PS_image_rotate(M, N, *image, *corner, color_mode, double *matrix) 
{ old code with a new twist }

PS_image(M, N, *image, *corner, color_mode)
{
static double identity[9] = {1,0,0, 0,1,0, 0,0,1};
    PS_image_rotate(M, N, *image, *corner, color_mode, identity);
}

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

Re: Simplified processing of image and rgbimage plots

[Daniel J S. <dan...@ie...>]

Timothée Lecomte wrote:

>>I believe that PDF and SVG also benefit from this approach, but
>>I have not investigated fully.
> 
> 
> For your information, cairo supports this, so the wxt terminal will profit
> from it too.

Already seems worth doing then.

Would it mean altering

    void (*image) __PROTO((unsigned, unsigned, coordval *, gpiPoint *, t_imagecolor));

to include a pointer to a set of values representing a translation matrix?

Or would a new terminal driver routine for a translation matrix that applies more generally be in order?

Dan

Re: Simplified processing of image and rgbimage plots

[<tim...@en...>]

> On Sunday 19 November 2006 05:47 am, Petr Mikulik wrote:
>>
>> However, your generic fall-back is OK.
>
> I want to clarify something.  This is not just a fall-back.
> It is currently the only way to place rgb data in 3D.
>
> So not only does it allow additional drivers (svg, fig, emf) to
> handle rgbimage in 2D, it also extends the capability of ALL drivers
> to work in 3D.
>
> However, as you noted it is rather expensive to describe an image
> this way, which causes slow data transfer in x11 and large file
> size in PostScript and PDF.
>
> We could do better.
>
> PostScript supports the specification of a general transformation
> matrix.  Rather than using individual filled_polygons
> to draw a rgbimage in 3D, we could simply include a projection of
> the 3x3 rotation matrix.  This would drastically reduce the
> PostScript file size for such plots.   We already calculate this
> same matrix in the core code in order to place the polygons; in
> the case of PostScript it would be sufficient to provide the matrix
> to the driver along with the original 2D array of rgb pixels.
>
> Anyone want to have a go a coding this?
>
> I believe that PDF and SVG also benefit from this approach, but
> I have not investigated fully.

For your information, cairo supports this, so the wxt terminal will profi=
t
from it too.

Best regards,

Timoth=E9e

Re: Re: Re: compiling gnuplot on Windows & mac/linux

[Mojca M. <moj...@gm...>]

On 11/19/06, Petr Mikulik wrote:
> >> I'd rather you remove the stupid compiler that emits them.
> > makefile.mgw
> > #DESTDIR = /c/Progra~1/Gnuplot4.1
> >
> > any many other places still contain old strings. Can anyone grep for
> > them and replace them?
>
> By what? Isn't there some way to know whether that dir should be called
> "Program Files", "Programy", "Programme", etc?

I meant the number. Some files still contain 4.1 as the version number
(or 4.2 in cvs, which should be 4.3 now).

> > Now a question: is anyone ready to help me to write a clean makefile
> > for MinGW for cross-compiling (which would be suitable to add to CVS)
> > or does that exist already?
>
> Do you really need it? I "crosscompile" gnuplot for Windows on Linux by
> means of MingW: I run the wine console (wcmd), and then do what is written
> for mingw: go to src/, type "make -f ../config/makefile.mgw", and it is
> done.
>
> Isn't there a Wine for MacOSX on Intel?

Yes, there is - thanks for the hint, it will probably go more smoothly
(easier) there. I was compiling without wine (crosscompiling using
mingw) - successfully, but I didn't manage to integrate external
libraries (gd, wxt) yet.

> >> Microsoft has made it clear that they don't care about providing a
> >> working compiler, why should we care about supporting their broken product?
> >
> > OK, I accept that.
>
> There could be a message in that makefile that the
> compilation/binary/pgnuplot/... may not work for which version of the
> compiler.

It conditionally works with the latest version (apart from gd & wxt -
I have no idea whose fault that is because I cannot check with older
compilers), but I understood the answer more like
   "We don't want to fix (minor things that would make compiling a bit easier)."
and I'm OK with it.

> > Do you really need it? I "crosscompile" gnuplot for Windows on Linux by
> > means of MingW: I run the wine console (wcmd), and then do what is written
> > for mingw: go to src/, type "make -f ../config/makefile.mgw", and it is
> > done.
>
> That's not really cross-compiling.  Cross-compiling would mean you build
> a version of GCC running directly on Linux that builds Win32 executables
> based on the MinGW libraries and headers.

I don't really mind if this is called cross-compiling or not - I only
care about the end effect which should be a working windows
application. (And if it's easier to do it using wine, there should be
no reason for not using it.)

Mojca

Re: Simplified processing of image and rgbimage plots

[Petr M. <mi...@ph...>]

>> Do you really mean to remove the term->image() routine??? Definitely no, the
>> processing is several orders of magnitude slower ... try to draw a 1024x1024
>> image with pm3d and with image. Terminal-specific term->image() is the
>> proper way.
>
> It may seem counter-intuitive, but in fact the RGB polygon processing is
> just as fast as the term->image() processing, at least for gd.trm.

Are not ther any "aliasing" or "Moire" problems?

> And rendering speed.  gv is very slow with the filled polygons.

For performance reasons, I guess term->image() is a must. It was implemented 
for exactly this reason, after all.

BTW, there are some other screen terminals (OS/2, Windows) which may or may 
not be double-buffered, and where many-polygon approach instead of image 
makes them very very slow -- and even for a window redraw by the window 
manager.

---
PM