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

Re: gnuplot projects, terminal modules

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

On Thursday 15 March 2007 04:02, Timoth=E9e Lecomte wrote:
> It affects the current terminal only, so it won't do anything if the
> current terminal is postscript for example. When I say 'current terminal',
> it includes all windows for an interactive terminal.

It is slightly more complicated for x11.  The "raise" command can only
affect x11 windows opened by the current instance of gnuplot_X11.
It is possible, although unusual, to have multiple active instances of
gnuplot_x11, each managing a separate set of display windows.

If we wanted to make this truly general, we would have to keep a=20
table mapping previous x11 plot commands to the x11 window ID that=20
they were assigned.  That could be done, but it would be a big
headache and I don't recommend it.

	Ethan=20


> I think it's clear=20
> when you look at the function primitive:
>=20
> term->raise_termwindow(int w /* windows number */,
>                        TBOOLEAN raise /* raise or lower*/,
>                        TBOOLEAN all /* all windows or only the given
> number */)
>=20
> As an example:
>=20
> set term x11 0
> plot x
> set term x11 1
> plot x
> set term wxt 0
> plot x
> set term wxt 1
> plot x
> set term plot; raise # nothing happens
> set term wxt; raise # all wxt windows is raised.
> set term wxt; raise 1 # wxt window n=B01 is raised
> set term wxt; raise 0 # wxt window n=B00 is raised
> set term wxt 0; raise 1 # wxt window n=B01 is raised
> set term x11; raise 0 # x11 window n=B00 is raised
> set term x11; raise 1 # x11 window n=B01 is raised
> set term x11 0; raise 1 # x11 window n=B01 is raised
>=20
> Does that sound right to you ?

=2D-=20
Ethan A Merritt

Re: gnuplot projects, terminal modules

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

On Thursday 15 March 2007 02:44, Petr Mikulik wrote:
> 
> > > The difficult part would be to do something like zooming a subplot;
> > > as currently implemented, that would require going back to the
> 
> Yes, that's impossible .. unless the whole output of "save ..." just after 
> the plot is stored internally.

It is not impossible.  In fact SVG can already do it, because the
SVG viewer is responsible for the zooming.  It does not recalculate 
the axis positions and relabel them, of course, but it does give you
an zoomed-in view of the original plot. The same thing could be done
in x11 if we decide it's worth it.

Furthermore, it would be possible to do a more efficient job
of "replot" in the core code that would benefit all terminals.
Perhaps I am overlooking something, but I don't see any hard
requirement to re-read the original data from a file on each
replot command.  Yes, this is sometimes exactly what you want
because you know the data has changed.  But more often you
just want to redraw the plot with a different plot option,
or zoom or view angle.  In these cases there should be enough,
or almost enough, information already stored in the data structures
from the previous plot.  Why re-read the data file when it is
just storing the same information all over again?  This would in
particular be of  plot '-', where it is very annoying to type in
the same data all over again.  

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

Re: gnuplot projects, terminal modules

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

>> >> > 4) Mousing support for multiplot mode
>> >>
>> >> This one is probably more difficult than it seems.
>> >
>> > The difficult part would be to do something like zooming a subplot;
>> > as currently implemented, that would require going back to the
>
> Yes, that's impossible .. unless the whole output of "save ..." just after
> the plot is stored internally.

Not only 'save', but also the input data, which is not available anymore
in case of a pipe for example. We would need some cache layer in between
the parser and the terminals. Doesn't it exist for pm3d quadrangles
already ?

>
>
>> Well, everything is already there, see 'help raise' (you can do 'raise
>> 5'
>> to raise the 5th window).
>>
>> Currently, if you do:
>>
>> set term x11
>> plot x
>> set term wxt
>> plot x
>> raise # then both wxt and x11 windows are raised.
>>
>> With my patch (whose first goal is to eradicate that ugly code from
>> command.c):
>>
>>
>> set term x11
>> plot x
>> set term wxt
>> plot x
>> raise # only wxt windows is raised.
>> set term x11
>> raise # only x11 windows is raised.
>
> Will the "raise" command keep raising all windows of wxt and/or of x11?
> And which one will it choose when currently there is e.g. "set term post"?

It affects the current terminal only, so it won't do anything if the
current terminal is postscript for example. When I say 'current terminal',
it includes all windows for an interactive terminal. I think it's clear
when you look at the function primitive:

term->raise_termwindow(int w /* windows number */,
                       TBOOLEAN raise /* raise or lower*/,
                       TBOOLEAN all /* all windows or only the given
number */)

As an example:

set term x11 0
plot x
set term x11 1
plot x
set term wxt 0
plot x
set term wxt 1
plot x
set term plot; raise # nothing happens
set term wxt; raise # all wxt windows is raised.
set term wxt; raise 1 # wxt window n°1 is raised
set term wxt; raise 0 # wxt window n°0 is raised
set term wxt 0; raise 1 # wxt window n°1 is raised
set term x11; raise 0 # x11 window n°0 is raised
set term x11; raise 1 # x11 window n°1 is raised
set term x11 0; raise 1 # x11 window n°1 is raised

Does that sound right to you ?

Timothée

Re: gnuplot projects, terminal modules

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

> >> > 4) Mousing support for multiplot mode
> >>
> >> This one is probably more difficult than it seems.
> >
> > At least in x11 it should not be fairly easy. Gnuplot_x11 already
> > stores plot bounds and axis scaling information, used to echo back
> > the mouse coordinates based on the current cursor coordinates in
> > the window.  To make mouse coordinates work for multiplot, one just
> > needs a  pre-test on the cursor coordinates to see which scaling
> > table should be used.  So I think echoing the appropriate mouse
> > coordinates for various subplots on the screen would be easy.

I think so. And it does not depend on x11 at all.

> > The difficult part would be to do something like zooming a subplot;
> > as currently implemented, that would require going back to the

Yes, that's impossible .. unless the whole output of "save ..." just after 
the plot is stored internally.


> Well, everything is already there, see 'help raise' (you can do 'raise 5'
> to raise the 5th window).
> 
> Currently, if you do:
> 
> set term x11
> plot x
> set term wxt
> plot x
> raise # then both wxt and x11 windows are raised.
> 
> With my patch (whose first goal is to eradicate that ugly code from
> command.c):
> 
> 
> set term x11
> plot x
> set term wxt
> plot x
> raise # only wxt windows is raised.
> set term x11
> raise # only x11 windows is raised.

Will the "raise" command keep raising all windows of wxt and/or of x11?
And which one will it choose when currently there is e.g. "set term post"?

---
PM

Re: Possible more TODO features

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

Ethan Merritt wrote:
> On Wednesday 14 March 2007 16:05, Daniel J Sebald wrote:
> 
>>set arrow 1 from -2,0 to -10,0 nohead lc rgb "black"
>>set arrow 2 from -2,0 to -2+10*cos(pi/3),0+10*sin(pi/3) nohead lc rgb "black"
>>set arrow 3 from -2,0 to -2+10*cos(-pi/3),0+10*sin(-pi/3) nohead lc rgb "black"
>>
>>1) I'd like the asymptotes to be dashed lines.  Is it possible to do so, 
>>I mean generally speaking for all terminals? 
> 
> 
> No. Not all terminals can draw dotted lines.  Them's the breaks.
>  
> 
>>2) Note how the lines are not clipped at the boundaries.  
> 
> 
> Correct. Only the plots themselves are clipped to the plot boundaries.
> That is a feature.
> Otherwise you obviously couldn't place arrows and labels in the borders.

Yes, I thought of that after I sent the original message.  But still, if one of the end points of the arrow is "plotboundary" or something then the arrow should no to clip there.


>>4) As Ethan mentioned, do this with lines so that clipping behaves as desired.  
>>But I then have to set up the sampling so that a sample point lands on (-2,0), 
>>and do this as parametric so that I can get portions of lines.  
> 
> 
> ???
> No idea what you are talking about with points, sampling, parametric.
> All garbage. If you want a line through (-2,0) with a defined slope S
> 
>   line1(x) = S*(x+2)
>   plot line1(x)
> 
> If you want only a portion of that line, you set bounds:
>   line1(x) = x < lower ? NaN : x > upper ? NaN : S*(x+2)

Right, that is what I meant.  But recall that gnuplot does an internal sampling when plotting so that you aren't sure that the point will start at (-2,0).  There could be a little bit of discrepancy that makes the lines not exactly right.

Dan

Re: Possible more TODO features

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

Daniel J Sebald wrote:

[snip]

Ultimately, maybe the easiest is:

set term x11 dashed
set xrange [-5:5]
set yrange [-5:5]
plot '-' title '' with lines lt 1 lc rgb "black", \
     '-' title '' with lines lt 1 lc rgb "black", \
     '-' title '' with lines lt 1 lc rgb "black", \
     '-' with points
-2 0
488 866.03
e
-2 0
488 -866.03
e
-2 0
-1002 0
e
0 0
e

I.e., just make sure one has chosen the line end points outside the boundaries in question.

Dan

Re: Possible more TODO features

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

On Wednesday 14 March 2007 16:05, Daniel J Sebald wrote:
> 
> set arrow 1 from -2,0 to -10,0 nohead lc rgb "black"
> set arrow 2 from -2,0 to -2+10*cos(pi/3),0+10*sin(pi/3) nohead lc rgb "black"
> set arrow 3 from -2,0 to -2+10*cos(-pi/3),0+10*sin(-pi/3) nohead lc rgb "black"
> 
> 1) I'd like the asymptotes to be dashed lines.  Is it possible to do so, 
> I mean generally speaking for all terminals? 

No. Not all terminals can draw dotted lines.  Them's the breaks.
 
> 2) Note how the lines are not clipped at the boundaries.  

Correct. Only the plots themselves are clipped to the plot boundaries.
That is a feature.
Otherwise you obviously couldn't place arrows and labels in the borders.

 
> 4) As Ethan mentioned, do this with lines so that clipping behaves as desired.  
> But I then have to set up the sampling so that a sample point lands on (-2,0), 
> and do this as parametric so that I can get portions of lines.  

???
No idea what you are talking about with points, sampling, parametric.
All garbage. If you want a line through (-2,0) with a defined slope S

  line1(x) = S*(x+2)
  plot line1(x)

If you want only a portion of that line, you set bounds:
  line1(x) = x < lower ? NaN : x > upper ? NaN : S*(x+2)

But if that's what you want then you could have used arrows as you
originally showed.  And you don't need clipping if you're setting
the bounds yourself.

-- 
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742

Re: Possible more TODO features

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

Ethan Merritt wrote:
> On Wednesday 14 March 2007 14:15, Daniel J Sebald wrote:
> 
>>* Many times people want to plot a line representing some boundary or plane which basically means they'd like to have the line extend from one boundary of the plot to another.  In other words, they'd like an infinite length line that should be clipped at the boundary.  (Or a line that is infinite in one direction and not the other... a bit imprecised, math wise, but I think you get the idea.)  To do this now, I believe the user has to resort to computing the points of intersection of the line and the four possible boundaries.  (If they have a bit more knowledge about the slope of the line, guessing which boundaries intersect is easy.)  This isn't a difficult problem for the user, but it is a bit of a pain.  So, if the term->clip_region() function is implemented, it might be nice to have gnuplot do this work for the user.  So, for arrow, rather than just a "to"/"from", it might be nice to augment that with "thru"/"slope", or more generally w'x + b where w is a two dimensiona
l 
>>or three dimensional vector perpendicular to the line or plane and b is a constant (commonly referred to as a hyperplane).  I'm not exactly sure what syntax one would use:
> 
> 
> Maybe I haven't had enough coffee yet, but I have no idea
> what you are trying to describe here.
> How is this different from just specifying the equation of a line,

Well, that is a good point.  Giving the equation of a line just about does it.  Maybe this isn't as difficult as I thought.  Let me illustrate.  Consider drawing some asymptotes at (-2,0) (I'll leave out the actual curves.)  I want something like

set arrow 1 from -2,0 to -10,0 nohead lc rgb "black"
set arrow 2 from -2,0 to -2+10*cos(pi/3),0+10*sin(pi/3) nohead lc rgb "black"
set arrow 3 from -2,0 to -2+10*cos(-pi/3),0+10*sin(-pi/3) nohead lc rgb "black"
set xrange [-5:5]
set yrange [-5:5]
plot '-' with points
0 0
e

OK, some comments:

1) I'd like the asymptotes to be dashed lines.  Is it possible to do so, I mean generally speaking for all terminals?


2) Note how the lines are not clipped at the boundaries.  Let's say that clipping region is possible and I change from

set xrange [-5:5]

to

set xrange [-20:20]

I'd have to go back and make sure my lines extend past the boundaries.  Anyway...


3) OK, not too much work to compute those additional requirements by noting the boundary is y=+-5 and figure

0+Y*sin(pi/3) = +5

or

set arrow 1 from -2,0 to -5,0 nohead lc rgb "black"
set arrow 2 from -2,0 to -2+5/sin(pi/3),0+5 nohead lc rgb "black"
set arrow 3 from -2,0 to -2+5/sin(pi/3),0-5 nohead lc rgb "black"
set xrange [-5:5]
set yrange [-5:5]
plot '-' with points
0 0
e

But let's say I change my range now from

set xrange [-5:5]

to

set xrange [-5:1]

in which case I'd have to focus now on the intersection along the right boundary rather than the top and bottom.


4) As Ethan mentioned, do this with lines so that clipping behaves as desired.  But I then have to set up the sampling so that a sample point lands on (-2,0), and do this as parametric so that I can get portions of lines.


Ultimately, I think it isn't convenient for the user to enter lines like I have.  (And what I've done doesn't seem too unusual of a request.)

Dan

Re: Possible more TODO features

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

Daniel J Sebald wrote:

> * Many times people want to plot a line representing some boundary or
> plane which basically means they'd like to have the line extend from
> one boundary of the plot to another.  

  	set arrow from graph 0, first <y1> to graph 1, first <y2> nohead

does that quite nicely.

> now, I believe the user has to resort to computing the points of
> intersection of the line and the four possible boundaries.

Not at all.  Express the line as a function and plot it.  Done.

> So, if the term->clip_region()
> function is implemented, it might be nice to have gnuplot do this
> work for the user.  

Not unless you also want to add a term->draw_infinite_line() entry to it 
while at it.  term->clip_region is for clipping primitives.  Infinite 
lines aren't terminal primitives, and as long as they aren't, it's none 
of term->clip_region()'s job to clip them.

Re: Possible more TODO features

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

On Wednesday 14 March 2007 14:15, Daniel J Sebald wrote:
>=20
> * Many times people want to plot a line representing some boundary or pla=
ne which basically means they'd like to have the line extend from one bound=
ary of the plot to another.  In other words, they'd like an infinite length=
 line that should be clipped at the boundary.  (Or a line that is infinite =
in one direction and not the other... a bit imprecised, math wise, but I th=
ink you get the idea.)  To do this now, I believe the user has to resort to=
 computing the points of intersection of the line and the four possible bou=
ndaries.  (If they have a bit more knowledge about the slope of the line, g=
uessing which boundaries intersect is easy.)  This isn't a difficult proble=
m for the user, but it is a bit of a pain.  So, if the term->clip_region() =
function is implemented, it might be nice to have gnuplot do this work for =
the user.  So, for arrow, rather than just a "to"/"from", it might be nice =
to augment that with "thru"/"slope", or more generally w'x + b where w is a=
 two dimensional=20
> or three dimensional vector perpendicular to the line or plane and b is a=
 constant (commonly referred to as a hyperplane).  I'm not exactly sure wha=
t syntax one would use:

Maybe I haven't had enough coffee yet, but I have no idea
what you are trying to describe here.
How is this different from just specifying the equation of a line,
and letting gnuplot clip it at the plot boundaries?


=2D-=20
Ethan A Merritt

Possible more TODO features

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

Here are a few other things that might be nice to have:

* Many times people want to plot a line representing some boundary or plane which basically means they'd like to have the line extend from one boundary of the plot to another.  In other words, they'd like an infinite length line that should be clipped at the boundary.  (Or a line that is infinite in one direction and not the other... a bit imprecised, math wise, but I think you get the idea.)  To do this now, I believe the user has to resort to computing the points of intersection of the line and the four possible boundaries.  (If they have a bit more knowledge about the slope of the line, guessing which boundaries intersect is easy.)  This isn't a difficult problem for the user, but it is a bit of a pain.  So, if the term->clip_region() function is implemented, it might be nice to have gnuplot do this work for the user.  So, for arrow, rather than just a "to"/"from", it might be nice to augment that with "thru"/"slope", or more generally w'x + b where w is a two dimensional 
or three dimensional vector perpendicular to the line or plane and b is a constant (commonly referred to as a hyperplane).  I'm not exactly sure what syntax one would use:

set arrow from 0,0 to border thru 1,1
set arrow from border to border thru 0,0 perp (1,1)

Requires some thought, but the idea of saving the user a bit of work seems worthwhile.


* How about a line format that puts a periodic arrowhead along its path?  Sort of this kind of thing:

----->----->----->----->----->----->----->----->----->----->

?  This sort of line is often useful for indicating flow or direction of travel.


Dan

Re: 4.2 Release plans - Last chance for comments

[Shigeharu T. <sh...@ie...>]

shige 03/14 2007
----------------

Ethan Merritt <merritt@u.washington.edu> wrote:
> Both gp420win32x11.zip and gp420win32.zip have now been copied 
> to the download area.

Thanks.

Petr Mikulik <mi...@ph...> wrote:
> contains wgnuplot-ja.mnu, but not wgnuplot-ja.{hlp, pdf}. Could you generate 
> them? That .hlp file could go to the above zip file. And the wgnuplot-ja.pdf 

These are already opened in my www page:
 http://takeno.iee.niit.ac.jp/%7Efoo/gp-jman/gp-jman.html

MS-Windows help file is included in 
 http://takeno.iee.niit.ac.jp/%7Efoo/gp-jman/data/wgp-jp/wgp420-ja-20070304.zip

PDF file is available at
 http://takeno.iee.niit.ac.jp/%7Efoo/gp-jman/data/20070304/gnuplot-ja.pdf.gz

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: gp420win32{x11}.zip and Re: www.gnuplot.info

[<bma...@we...>]

> 
> Bastian, could you please contribute
> 	gp420os2.zip
> 

I will, as soon as I have access to my OS/2 machine again.
Sadly, this will have to wait until may as I am currently staying
abroad. 

Bastian

Re: 4.2 Release plans - Last chance for comments

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

On Tuesday 13 March 2007 10:53, Petr Mikulik wrote:
> 
> Could you remove the "gnuplot-current  4.2.rc4" from there?

I'm not sure.  I don't think so.  The instructions say that
once a package is uploaded, it cannot be deleted or removed.
It may be possible to "hide", however.   I'll try.

-- 
Ethan A Merritt

Re: 4.2 Release plans - Last chance for comments

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

> > >  http://sourceforge.net/project/showfiles.php?group_id=2055
> 
> Both gp420win32x11.zip and gp420win32.zip have now been copied 
> to the download area.

Fine.

Could you remove the "gnuplot-current  4.2.rc4" from there?
  
> > The file
> > 	gp420win32.zip  
> > contains wgnuplot-ja.mnu, but not wgnuplot-ja.{hlp, pdf}. Could you generate 
> > them? That .hlp file could go to the above zip file. And the wgnuplot-ja.pdf 
> > could go to the Download. 
> 
> I do not understand.  How would wgnuplot-ja.pdf differ from gnuplot-ja.pdf?

Sorry, I ment gnuplot-ja.pdf and wgnuplot-ja.hlp.

---
PM

Re: 4.2 Release plans - Last chance for comments

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

On Tuesday 13 March 2007 08:36, Petr Mikulik wrote:
> > By the way, there are many users of MS-Windows version in Japan, 
> > so I think they now want the MS-Windows version on the official 
> > site
> > 
> >  http://sourceforge.net/project/showfiles.php?group_id=2055
> 
> Win32 version is currently at
>   http://gnuplot.sourceforge.net/ftp_testing/ftp_gnuplot_info/4.2/
> waiting for somebody to put it on the SF Download.

Both gp420win32x11.zip and gp420win32.zip have now been copied 
to the download area.
 
> The file
> 	gp420win32.zip  
> contains wgnuplot-ja.mnu, but not wgnuplot-ja.{hlp, pdf}. Could you generate 
> them? That .hlp file could go to the above zip file. And the wgnuplot-ja.pdf 
> could go to the Download. 

I do not understand.  How would wgnuplot-ja.pdf differ from gnuplot-ja.pdf?


-- 
Ethan A Merritt

Re: 4.2 Release plans - Last chance for comments

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

> By the way, there are many users of MS-Windows version in Japan, 
> so I think they now want the MS-Windows version on the official 
> site
> 
>  http://sourceforge.net/project/showfiles.php?group_id=2055

Win32 version is currently at
  http://gnuplot.sourceforge.net/ftp_testing/ftp_gnuplot_info/4.2/
waiting for somebody to put it on the SF Download.

The file
	gp420win32.zip  
contains wgnuplot-ja.mnu, but not wgnuplot-ja.{hlp, pdf}. Could you generate 
them? That .hlp file could go to the above zip file. And the wgnuplot-ja.pdf 
could go to the Download. 

---
PM

Re: 4.2 Release plans - Last chance for comments

[Shigeharu T. <sh...@ie...>]

shige 03/13 2007
----------------

Ethan A Merritt <merritt@u.washington.edu> wrote:

| Also Shigeharu Takeno, who may want to post the release announcement to
| a Japanese forum.[*]

I announced on some Japanese forums (BBS and ML).

| [*] You may be interested to learn that Google Trends reports that the=20
| highest concentration of search queries about gnuplot is from Japan:
|    http://www.google.com/trends?q=3Dgnuplot

:-)

By the way, there are many users of MS-Windows version in Japan, 
so I think they now want the MS-Windows version on the official 
site

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

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: Fwd: [Gnuplot-developers] [ gnuplot-Patches-1651015 ] Cairo-based PDF terminal

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

> %% Boolean flag Color (user-editable) used to toggle palette;
> %% Switch between rgb color and grayscale using ntsc conversion
> \C  {Color {setrgbcolor} {ntsc setgray} ifelse} def

ntsc =3D Never The Same Color? ... here Gray ...

Given an RGB, you can never get the original gray value, because the mappin=
g=20
depends on the colormap: gray =3D> (R(gray), G(gray), B(gray))

> >   - possibility to change the color palette
>=20
> By editing the PostScript file?  That sounds like a very unusual
> thing to do.  Can you give an example?

Yes, unusual, but feasible.=20

> > > I'm cc'ing this to Petr, who may want to comment on whether
> > > there are cases where weak optimization (factor of 2 at best)
> > > is still useful.=20
> >=20
> > It is of factor 3:
> > =09.123
> > =09.123 .123 .123
> > thus a lot of KB's more to add into the file or (LaTeX) paper.
>=20
> I think it's a factor of slightly less than 2:

So it is great, isn't it? It saves a lot of disk space for large maps.
(Please don't claim that *nowadays* the disk space is cheap.)

> > No, pdf is not intended to be edited.
>=20
> PDF is mostly just marked-up PostScript which is then compressed.
> Any feature which is useful in PostScript should also be available
> in PDF.

Unless some postscript programming, like ifelse ... ?

> Even aside from Timoth=C3=A9e's new pdf driver, wouldn't it be a good
> idea to offer the same user-editable flags at the start of gnuplot's
> PDF output that we offer for the PostScript output?  That would give
> the user the same ability to tweak the *.pdf file that they already
> have for the *.ps files.

How would he tweak them? A javascript?
Have you seen any example of such a pdf gray/color file with a switch?

---
PM

gp420win32{x11}.zip and Re: www.gnuplot.info

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

Recently I proposed a new structure for "ftp.gnuplot.info", and put it
here:
   http://gnuplot.sourceforge.net/ftp_testing/ftp_gnuplot_info/

Now, you find there also gnuplot 4.2 windows binaries:
   http://gnuplot.sourceforge.net/ftp_testing/ftp_gnuplot_info/4.2/

Could someone put
	 gp420win32.zip
	 gp420win32x11.zip 
into the Download section on sf?

Timothee, could you please contribute
	gp420win32wx.zip
i.e., win32 binary compiled with the wx terminal.

Bastian, could you please contribute
	gp420os2.zip

***

Other comments about the new ftp.gnuplot.info:

There are also other dirs on ftp.gnuplot.info:
- gnuplot-historical: could be moved inside the above
- gnuplot-misc could be removed
- gnuplot-recent ???
- winsock can be removed

I think ftp.gnuplot.info should be kept, as it is mirrored by CTAN and maybe 
some other repositories.

---
PM

Re: Fwd: [Gnuplot-developers] [ gnuplot-Patches-1651015 ] Cairo-based PDF terminal

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

On 3/13/07, Ethan Merritt <merritt@u.washington.edu> wrote:
> On Monday 12 March 2007 16:14, Mojca Miklavec wrote:
> > On 3/12/07, Ethan Merritt wrote:
> > > PDF is mostly just marked-up PostScript which is then compressed.
> >
> > And indexed.
>
> Could be. What does that mean, exactly?

Than means that I never managed to create a useful PDF file by hand (I
never took time to study the specifications in such a detail), I
didn't even managed to reproduce the minimal PDF file example as
written in the specification. The last few numbers in the document
tell you where to look for objects. I don't know much about it, so I
really don't want to go in details (because I'll would sooner or later
give wrong statements), but one thing that I know is that editing by
hand is of no practical use for PDF files.

Yes, you can change a number or two, but sometimes a single character
can confuse indexes (which tell you at which location (in bytes?) an
object is saved). And besides that: PDF is not a programming language.
I'm not sure if defining a palette in such a way as it's done in PS is
even possible in PDF. I might be wrong, but in general I don't think
that investing any time into configurability of PDF makes sense
(making the LaTeX terminal better/configurable would be much more
useful).

If one really needs to edit that file, it means that something might
be wrong with gnuplot interface ... as if one would need to edit the
assebler code after compiling the program with C. I agree, it's
sometime handy to change a line or two, but in the case of PDF I would
even vote for compressed format anyway (if cairo enables that). I
imagine that the number of people who prefer small files is
significantly bigger that the number of those who case about editing
PDF files.

Mojca


> I don't have a PDF spec here to refer to.
>
> > No, because PDF files are indexed. It might be possible to change
> > minor things (index of a palette for example), but you can break the
> > whole file if you add a single character. Generally it's not a good
> > idea to edit PDF files manually, just as it's not a good idea to edit
> > PNG files with a text editor.
>
> I think that must depend on the program that creates your pdf file.
> Some of them are just as editable as PostScript file.  Others are
> in-line encoded/compressed right from the first line, and thus not
> human readable.  I append the first few lines from a pdf file
> produced by Timoth=E9e's cairopdf terminal.  It's a bit cryptic, but
> does not seem to suffer when I edit/add/subtract lines using vi.
> To me it looks very similar to the Adobe Illustrator shorthand form
> of PostScript.
>
>
> %PDF-1.4
> %=B5=ED(r)=FB
> 2 0 obj
> << /Length 3 0 R
>    /Type /XObject
>    /Subtype /Form
>    /BBox [ 0 0 720 504 ]
> >>
> stream
> 1 0 0 -1 0 504 cm
> 1 1 1 RG 1 1 1 rg /a0 gs
> 0 0 720 504 re f
> 0 0 0 RG 0 0 0 rg /a0 gs
> 20 w
> 2 J
> 0 j
> [] 0.0 d
> 10 M 1482.999878 9460 m 1607.000122 9460 l q 0.05 0 0 0.05 0.5 0.5 cm
> S Q
> 0 0 0 RG 0 0 0 rg /a0 gs
> 20 w
> 2 J
> 0 j
> [] 0.0 d
> 10 M 14078.999939 9460 m 13955 9460 l q 0.05 0 0 0.05 0.5 0.5 cm
> S Q
> 0 0 0 RG 0 0 0 rg /a0 gs
> BT
> /CairoFont-0-0 1 Tf
> 13.33335 0 -0 -13.33335 40.981247 478.123389 Tm <00> Tj
>
> ... [and so on]
>
> --
> Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
> Dept of Biochemistry
> Health Sciences Building
> University of Washington - Seattle WA 98195-7742
>

PS/PDF (was cairo-based PDF terminal)

[Allin C. <cot...@wf...>]

On Mon, 12 Mar 2007, Ethan Merritt wrote:

> 2) If it is worth it for PostScript, does that mean it is also
>   worth doing for pdf?

Talking about PS/PDF compatibility issues, it seems to me that the 
PDF term options should be, so far as is reasonably practical, 
compatible with the PS options.  I've noticed one departure.  If 
you choose the "monochrome" option to PS, you get lines 
distinguished by dash patterns.  If you select the mono option to 
PDF, you get a bunch of identical lines, unless you specifically 
select the "dashed" option.  The latter result seems to me a case 
of "broken by design".

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: Fwd: [Gnuplot-developers] [ gnuplot-Patches-1651015 ] Cairo-based PDF terminal

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

On Monday 12 March 2007 11:03, Petr Mikulik wrote:
> > where the operator "g" is defined in the page header based on
> > the current palette.  In other words, the color mapping is done
> > by the postscript interpreter, not by gnuplot.  I believe the
> > reason for this was simply to make the output file shorter.
>=20
> Plus two more reasons:
>   - replace the color - gray by a simple switch in the header

%% Boolean flag Color (user-editable) used to toggle palette;
%% Switch between rgb color and grayscale using ntsc conversion
\C  {Color {setrgbcolor} {ntsc setgray} ifelse} def

>   - possibility to change the color palette

By editing the PostScript file?  That sounds like a very unusual
thing to do.  Can you give an example?

> > I'm cc'ing this to Petr, who may want to comment on whether
> > there are cases where weak optimization (factor of 2 at best)
> > is still useful.=20
>=20
> It is of factor 3:
> 	.123
> 	.123 .123 .123
> thus a lot of KB's more to add into the file or (LaTeX) paper.

I think it's a factor of slightly less than 2:

Currintly routine save_space(gray) returns a 4-digit float
to be printed as "%.4g g"
       .1234 g 	  % 7 characters for 4-digit gray scale

We work internally with 24bit RGB colors in most places, so
if we were to switch to an RGB-based postscript output it could
logically be
	/C {255 div 3 1 roll 255 div 3 1 roll 255 div 3 1 roll
            setrgbcolor} def
yielding
	RRR GGG BBB C   % 13 characters for 24-bit color=20


> > So there are two questions:
> >=20
> > 1) Is this really worth doing in PostScript?
>=20
> Definitely.
>=20
> > 2) If it is worth it for PostScript, does that mean it is also
> >    worth doing for pdf?
>=20
> No, pdf is not intended to be edited.

PDF is mostly just marked-up PostScript which is then compressed.
Any feature which is useful in PostScript should also be available
in PDF.  Which brings up a good point...

Even aside from Timoth=E9e's new pdf driver, wouldn't it be a good
idea to offer the same user-editable flags at the start of gnuplot's
PDF output that we offer for the PostScript output?  That would give
the user the same ability to tweak the *.pdf file that they already
have for the *.ps files.


=2D-=20
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742

Re: Fwd: [Gnuplot-developers] [ gnuplot-Patches-1651015 ] Cairo-based PDF terminal

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

> where the operator "g" is defined in the page header based on
> the current palette.  In other words, the color mapping is done
> by the postscript interpreter, not by gnuplot.  I believe the
> reason for this was simply to make the output file shorter.

Plus two more reasons:
  - replace the color - gray by a simple switch in the header
  - possibility to change the color palette
... and both are useful when the original data are no longer available.
Both these features are used AFAIK.

> Given defintions in the prolog
>   \g {complicated color mapping code} def
>   \C {setrgbcolor} def
> 
> then
>   ".123 g"
> is shorter than
>   "rrr ggg bbb C"
> 
> But not very much shorter. So it is a weakly justified optimization.
> 
> I'm cc'ing this to Petr, who may want to comment on whether
> there are cases where weak optimization (factor of 2 at best)
> is still useful. 

It is of factor 3:
	.123
	.123 .123 .123
thus a lot of KB's more to add into the file or (LaTeX) paper.

> So there are two questions:
> 
> 1) Is this really worth doing in PostScript?

Definitely.

> 2) If it is worth it for PostScript, does that mean it is also
>    worth doing for pdf?

No, pdf is not intended to be edited.

---
PM

Re: Fwd: [Gnuplot-developers] [ gnuplot-Patches-1651015 ] Cairo-based PDF terminal

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

On Monday 12 March 2007 00:19, you wrote:
> >> > In particular, what happens to palette settings (for example)
> >> > when you jump from one page of the document to another?
> 
> Anyway, we really don't allocate palettes for cairopdf:
> So if gnuplot asks for the right colors in term->set_color, it will get
> them for sure.
Code quoted from cairopdf driver:
[snip]
> 	} else if (colorspec->type == TC_FRAC)
> 		rgb1_from_gray( colorspec->value, &rgb1 );
[snip]
> 	gp_cairo_set_color(&plot, rgb1);


Got it.  So you rely on the gnuplot utility routine rgb1_from_gray
to  do the color mapping.   That is different from post.trm, which
does essentially this:

   /* map [0;1] to gray/colors */
     fprintf(gppsfile, "%.4g g ", colorspec->value);

where the operator "g" is defined in the page header based on
the current palette.  In other words, the color mapping is done
by the postscript interpreter, not by gnuplot.  I believe the
reason for this was simply to make the output file shorter.
Given defintions in the prolog
  \g {complicated color mapping code} def
  \C {setrgbcolor} def

then
  ".123 g"
is shorter than
  "rrr ggg bbb C"

But not very much shorter. So it is a weakly justified optimization.

I'm cc'ing this to Petr, who may want to comment on whether
there are cases where weak optimization (factor of 2 at best)
is still useful. 

So there are two questions:

1) Is this really worth doing in PostScript?
2) If it is worth it for PostScript, does that mean it is also
   worth doing for pdf?

-- 
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742