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

Re: color loop for gd.trm

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

>>   set term png xffffff x000000 x404040 \
>>   xff0000 x00ff00 x0000ff xff00ff x00ffff xa0522d xffa500 xff7f50 \
>>   xff0000 x00ff00 x0000ff xff00ff x00ffff xa0522d xffa500 xff7f50 \
>
> I see.  That is different from what I understood at first.
>
> So your goal is not to reduce the total number of colors, instead
> it is to have the same default colors on all terminals?

What about

set style linetype colorsequence red,green,blue,"FFEE00", ...

which would redefine the color sequence for the linetype series, and then it 
would become the same for all terminals?

---
PM

Re: color loop for gd.trm

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

On Monday 10 October 2005 10:42 pm, Shigeharu TAKENO wrote:
> 
> | From: Ethan Merritt <merritt@u.washington.edu>
> | Could you please explain why or when this is needed?
> 
> This patch is for user who want the same color behavior in png 
> term as in x11 term (or win term) without setting
> 
>   set term png xffffff x000000 x404040 \
>   xff0000 x00ff00 x0000ff xff00ff x00ffff xa0522d xffa500 xff7f50 \
>   xff0000 x00ff00 x0000ff xff00ff x00ffff xa0522d xffa500 xff7f50 \

I see.  That is different from what I understood at first.

So your goal is not to reduce the total number of colors, instead
it is to have the same default colors on all terminals?
Bastian Maerkisch <bma...@we...> has recently raised this
same issue on the mailing list.

My feeling is that the default colors on different terminal types
should *not* be the same, because each terminal has its own set
of visual properties.  For instance, yellow lines on white paper are
not easy to see - so why should PostScript or pen-plotter drivers
include yellow as one of the first 6 colors?

But I agree that the user should be able to request a particular set
of colors even if they are not the default. That is one reason I
wanted to introduce rgb colors to the core gnuplot code.
    plot <foo> with lines lc rgb 'yellow'
now plots a yellow line on any terminal that supports rgb
colors, regardless of whether it is one of the default colors.

Please look again at the 2nd plot in the demo script "rainbow.dem",
which shows how to define a spectrum of line styles that will be
the same on all terminals.

The piece that is still missing is a command that tells gnuplot to
cycle through line *styles* rather than line *types* by default.
There should be a new command so that
	set style line 1 lc rgb "purple"
	set style line 2 lc rgb "yellow"
	set <some_command_that_does_not_exist_yet>
	plot sin(x), cos(x)
uses linestyle 1 for sin(x) and linestyle 2 for cos(x) so
that the plot is purple and yellow, instead of red and green. 

Would this provide what you want?


> We found some requests on "Gnuplot Q&A board"
> http://ayapin.film.s.dendai.ac.jp/cgi-bin/trees.cgi  
> (in Japanese)

Thank you for relaying requests from that group.
I will try to look there if you point out specific requests,
but I can't read Japanese well enough or fast enough to monitor
it regularly. 



-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

PBM documentation patch

[Don T. <dt...@to...>]

I saw that Ethan added 'size' to the pbm terminal options and
provided documentation.  Thanks.  I also noted that the information
about PBMPLUS is way out of date.  A patch to fix this is 
appended.

Don Taber

--- pbm.trm.orig	2005-10-11 10:24:16.000000000 -0700
+++ pbm.trm	2005-10-11 11:01:31.000000000 -0700
@@ -482,15 +482,15 @@
 " portable bitmap (one bit per pixel), `gray` a portable graymap (three bits",
 " per pixel) and `color` a portable pixmap (color, four bits per pixel).",
 "",
-" The output of this driver can be used with Jef Poskanzer's excellent PBMPLUS",
-" package, which provides programs to convert the above PBMPLUS formats to GIF,",
-" TIFF, MacPaint, Macintosh PICT, PCX, X11 bitmap and many others.  PBMPLUS may",
-" be obtained from ftp.x.org.  The relevant files have names that begin with",
-" \"netpbm-1mar1994.p1\"; they reside in /contrib/utilities.  The package can",
-" probably also be obtained from one of the many sites that mirrors ftp.x.org.",
+" The output of this driver can be used with various image conversion and",
+" manipulation utilities provided by NETPBM.  Based on Jef Poskanzer's",
+" PBMPLUS package, NETPBM provides programs to convert the above PBM formats",
+" to GIF, TIFF, MacPaint, Macintosh PICT, PCX, X11 bitmap and many others.",
+" Complete information is available at http://netpbm.sourceforge.net/.",
 "",
 " Examples:",
-"       set terminal pbm small monochrome             # defaults",
-"       set terminal pbm color medium size 800,600"
+"       set terminal pbm small monochrome                # defaults",
+"       set terminal pbm color medium size 800,600",
+"       set output '| pnmrotate 45 | pnmtopng > tilted.png'  # uses NETPBM"
 END_HELP(pbm)
 #endif /* TERM_HELP */

Re: Again: canvas size

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

On Monday 10 October 2005 02:37 pm, Harald Harders wrote:
> At the moment, there are two different possibilities to change
> the canvas size (partly depending on the terminal):
> 
> - Use 'set size xcan,ycan' before using 'set terminal'.
>   This leads to screen coordinates 0,0 in the lower left corner and
>   xcan,ycan in the upper right corner.

That does seem to be true currently.
I really dislike this as being totally counter-intuitive.   
See for example, today's bug report #1324011


> - Use 'set terminal <term> size xterm,yterm'.
>   This leads to screen coordinates 0,0 in the lower left corner and
>   1,1 in the upper right corner.

This is not true currently.
What it does is to define range screen 0 -> screen 1 as spanning
xterm pixels.  That may or may not be the same as the upper right
corner of the screen, as you pointed out yourself just above.
 
> Say, you want to have many plots in one document with identical size. If
> one of these plots is a multiplot, it is useful to have a canvas with
> maximal screen coordinates 1,2.

I am totally lost here.  Can you post a web page that contains an 
example of such a document?  Won't you get exactly what you describe
without specifying "set size" at all?  Each plot, multi- or single-
will be of identical size.

 
> I propose following structure:
> 
> - The canvas size is defined exclusively by the 'set terminal' commands,
>   e.g., 'set terminal png size 640,480' or 'set term post size 6in,4in'.

I agree with this part.

> And for a multiplot, you can use
> 
> set screen-coordinate max 1,2
> set terminal postscript size 5in,6in
> 
> This would lead to identical absolute screen coordinate lengths in both
> cases.

I do not understand this at all. 
What is "screen coordinate length"?
Consider the two following command sequences:

A)
set term png size 200,200
set output 'A.png'
set screen-coord max 1,1
set multiplot layout 2,1
plot <foo>
plot <baz>

B)
set term png size 200,200
set output 'B.png'
set screen-coord max 1,2
set multiplot layout 2,1
plot <foo>
plot <baz>

Both png images are 200x200 pixels, right?
Will B.png contain both plots, or will it only contain one of them?
If it contains both, in what way does it differ from A.png?
 
> What do you think of this structure?

So far I don't understand it :-)


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

[ gnuplot-Patches-1323515 ] Sort points in 3D before plotting

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

[moving this to the mailing list for discussion]

I wrote>
> This patchset adds a qsort() of the points in a 3D
> plot, so that you get proper occlusion of distant
> points by close points. The improvement is particularly
> noticible for large solid points. See for example the
> plots in rgb_variable.dem


Petr Mikulik replied>
> The series of points can be  a time sequence, and there it
> would be useful to draw them (into a map) as they appear in
> the data file, without ordering.

I do not understand this example. Could you explain what the
x, y, and z coordinates would be in this case?

Let me clarify that the sort operation only applies to the
order in which the points are drawn on the screen. It does
not change their connectivity or ordering within the plot.
So if you draw in style "with linespoints" the lines will still
run from point 1 to point 2 to point 3 and so on, regardless of
their relative Z values in the current view.  However, if
point 2 is closer to the viewer than points 1 and 3, it will
occlude them.

Of course in that case the line segments will not be sorted,
even though their endpoints are.  The result is imperfect,
but is better than what we have now.

However, I am having second thoughts about whether it is
worth adding this sort operation outside of the hidden3d code.
It does not handle the general case of mixing points from
multiple sources into one plot. Suppose you are inspecting
two sets of 3D data points, hoping to find that one set
clusters in a different region of 3-space than the other.

gnuplot>  splot "class1" with points, "class2" with points

The patch I posted would sort the "class1" points relative
to each other, and the "class2" points relative to each
other, but all the points from class2 will occlude all of
the points from class1 because they are drawn afterwards.
Not good.

So even though the simple sort patchset was useful to me for
the specific plots I was trying to make last week, I think that
the longer term plan should be to extend the category of
plots handled by "set hidden3d".  In particular the hidden3d code
could sort points and line segments even if there is no surface
present, and it could track the full set of properties associated
with each point or line segment.  

I am not clear on how this would fit in with Johannes Zellner's
patch #1077726 "true depth ordering for pm3d plots".
Have you looked at that patchset?



-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: gnuplot+octave+cygwin-X11

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

> The current octave-cygwin package depends on gnuplot which depends on X11=
=2E  I=20
> know there is a Windows native terminal for gnuplot so the X11 package is=
n't=20
> strictly required, but I believe the Windows terminal only allows one fig=
ure.

It is advantageous to use the X11-gnuplot under windows so that the complet=
e=20
set of multi-window features (and more) is allowed.

> Any idea how difficult it would be to extend octave/gnuplot to support=20
> multiple figures natively?

Cross-platform wxWidgets terminal for gnuplot is under development by=20
Timoth=E9e Lecomte, see

http://tipote.free.fr/wxt3.png
http://tipote.free.fr/wxt4.png

http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1267434&group_=
id=3D2055&atid=3D302055

It will have (has...) all the goodies of X11 plus menu's like OS/2 PM=20
terminal.

---
PM

Re: color loop for gd.trm

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

shige 10/11 2005
----------------

| From: Ethan Merritt <merritt@u.washington.edu>
| Reply-To: merritt@u.washington.edu
| To: gnu...@li...
| Subject: Re: color loop for gd.trm
| Date: Mon, 10 Oct 2005 11:58:39 -0700
| Cc: Shigeharu TAKENO <sh...@ie...>
=====
| Could you please explain why or when this is needed?
| 
| The current png driver (really libgd itself) only
| stores the colors actually used by the plot.

This patch is for user who want the same color behavior in png 
term as in x11 term (or win term) without setting

  set term png xffffff x000000 x404040 \
  xff0000 x00ff00 x0000ff xff00ff x00ffff xa0522d xffa500 xff7f50 \
  xff0000 x00ff00 x0000ff xff00ff x00ffff xa0522d xffa500 xff7f50 \
  ...

On current png term, line type 9 is not red under the simple 
setting:

  set term png xffffff x000000 x404040 \
  xff0000 x00ff00 x0000ff xff00ff x00ffff xa0522d xffa500 xff7f50

and the result of test command differs from the one on the x11 
term.

We found some requests on "Gnuplot Q&A board"

 http://ayapin.film.s.dendai.ac.jp/cgi-bin/trees.cgi  
 (in Japanese)

to set the same colors in png term as in win term. My patch may 
help them.

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

gnuplot+octave+cygwin-X11

[Paul K. <pki...@us...>]

Hi,

The current octave-cygwin package depends on gnuplot which depends on 
X11.  I know there is a Windows native terminal for gnuplot so the X11 
package isn't strictly required, but I believe the Windows terminal 
only allows one figure.

Any idea how difficult it would be to extend octave/gnuplot to support 
multiple figures natively?

Thanks,

	- Paul

Again: canvas size

[Harald H. <h.h...@tu...>]

In the last days, I have thought about the canvas size discussion we had
in this mailing list.

At the moment, there are two different possibilities to change
the canvas size (partly depending on the terminal):

- Use 'set size xcan,ycan' before using 'set terminal'.
  This leads to screen coordinates 0,0 in the lower left corner and
  xcan,ycan in the upper right corner.

- Use 'set terminal <term> size xterm,yterm'.
  This leads to screen coordinates 0,0 in the lower left corner and
  1,1 in the upper right corner.

In my opinion, both possibilities are necessary.

Of course, it is a good thing to specify the canvas size in
terminal-dependent, absolute values, using 'set terminal <term> size'. And
in many cases, it is good to reach a canvas that has the screen
coordinates 0,0 and 1,1 for the lower left and upper right corner,
respectively.

But there are also cases, where a screen coordinate unequal to 1,1 for the
upper right corner is useful:
Say, you want to have many plots in one document with identical size. If
one of these plots is a multiplot, it is useful to have a canvas with
maximal screen coordinates 1,2.

I propose following structure:

- The canvas size is defined exclusively by the 'set terminal' commands,
  e.g., 'set terminal png size 640,480' or 'set term post size 6in,4in'.
- Inside the bounds of the canvas, the screen coordinate system can be set
  by another command, e.g.,
  'set screen-coordinate min <xmin>,<ymin> max <xmax>,<ymax>'
  where defaults are xmin=0, ymin=0, xmax=1, ymax=1.
  This command does not change the canvas size, e.g., Bounding Box (in
  contrast to the current 'set size' command before 'set terminal').

In the case mentioned above, you could use for a single plot:

set screen-coordinate max 1,1
set terminal postscript size 5in,3in

And for a multiplot, you can use

set screen-coordinate max 1,2
set terminal postscript size 5in,6in

This would lead to identical absolute screen coordinate lengths in both
cases.

What do you think of this structure?

Best regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Win32: change pointstyle

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

>> Would it be too much to devise some kind of color table lookup
>> for each terminal?
>
> You have not been paying attention.
> As of several months ago, all terminals that support color at
> all support named colors:
>
> plot <foo> with lines lt rgb "yellow",
>      <baz> with lines lt rgb "purple"

Then there could be
   set style linetype 6 "brown"
=> so that you can redefine the linetype (not linestyle) definitions, and
that will be portable among all rgb-supporting platforms.

---
PM

Re: color loop for gd.trm

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

On Friday 07 October 2005 05:07 am, Shigeharu TAKENO wrote:
> shige 10/07 2005
> ----------------
> 
> The following patch do use small number of colors in gd.trm. 

Could you please explain why or when this is needed?

The current png driver (really libgd itself) only
stores the colors actually used by the plot.
For example:

gnuplot> set term png lw 2
gnuplot> set output 'colors.png'
gnuplot> plot sin(x),cos(x),x,x**2
gnuplot> quit


# identify -verbose colors.png
Image: colors.png
  Format: PNG (Portable Network Graphics)
  Geometry: 640x480
  Class: DirectClass
  Type: palette with transparency
  Depth: 8 bits-per-pixel component
  Colors: 13

      2489: (  0,  0,  0,  0)    black
       228: ( 31, 31, 31,  0)    grey12
       265: ( 63, 63, 63,  0)    #3F3F3F00
       161: ( 95, 95, 95,  0)    #5F5F5F00
       244: (127,127,127,  0)    grey50
       581: (  0,192,  0,  0)    #00C00000
       554: (  0,128,255,  0)    #0080FF00
       527: (255,  0,  0,  0)    red
       846: (192,  0,255,  0)    #C000FF00
       150: (159,159,159,  0)    #9F9F9F00
       147: (191,191,191,  0)    grey75
       234: (223,223,223,  0)    #DFDFDF00
    300774: (255,255,255,  0)    grey100
  Resolution: 72x72 pixels


You may ask why are there 13 colors rather than 6?
We requested white background, black text,
  red, green, blue, magenta plot lines.

It is because antialiasing of the text to make it look smoother
introduces some grey pixels.
If I had not specified "lw 2" in the "set term png" command
there would also have been anti-aliasing of the colored lines,
which  would have introduced additional colors.


> Although png term use 256 colors even if the number of colors was 
> given explicitly, the colorloop option tells gnuplot to use only 
> specified colors.

The png output only stores 256 colors if you create a plot that
uses 256 colors.  That is primarily true for plots using the
pm3d palette.  But any number of colors up to 256 still uses a
1-byte color index for each pixel ("Depth" in the output shown above).
So even in the case of pm3d images, reducing the colors to fewer than
256 will degrade the image while saving almost no space in the output
file.

It is true that if you generate 24-bit color images by explicitly
requesting "set term png truecolor", then it requires more storage
space.  In this case there are 24 bits of color information per pixel
rather than 8 bits, so the output file will be roughly 3 times as large.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Win32: change pointstyle

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

On Saturday 08 October 2005 11:26 am, ds...@ch... wrote:
> 
> Would it be too much to devise some kind of color table lookup
> for each terminal?

You have not been paying attention.
As of several months ago, all terminals that support color at
all support named colors:

plot <foo> with lines lt rgb "yellow",
     <baz> with lines lt rgb "purple"



-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Re: set term x11 -1

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

>>> However, "set term x11 -1" titles the window "Gnuplot -1". Is this bug
>>> in gnuplot_x11, or in the docs?
>
> It is an arbitrary tag.
>
> Restricting the sign shouldn't pose any problems and might be less 
> confusing.  Or change the docs to be "n not equal 0".  It's up to list 
> consensus.

I vote for

  If n is not 0, the terminal number will be appended to the window title
  (unless a title has been supplied manually) ...

---
PM

Re: Re: set term x11 -1

[<ds...@ch...>]

> 
> From: Ethan A Merritt <merritt@u.washington.edu>
> Date: 2005/10/09 Sun PM 04:09:21 EDT
> To: gnu...@li...
> CC: Petr Mikulik <mi...@ph...>
> Subject: Re: set term x11 -1
> 
> On Sunday 09 October 2005 02:48 am, Petr Mikulik wrote:
> > "help x11" says:
> >
> >   Multiple plot windows are supported: `set terminal x11 <n>` directs
> > the output to plot window number n.  If n>0, the terminal number will be
> > appended to the window title (unless a title has been supplied manually)
> > and the icon will be labeled `Gnuplot <n>`.
> >
> > However, "set term x11 -1" titles the window "Gnuplot -1". Is this bug
> > in gnuplot_x11, or in the docs?
> 
> Is there any reason to allow negative terminal numbers in the first place?
> 
> Neither x11.trm nor gplt_x11.c appears to use the number for anything
> other than an arbitrary ID tag.

It is an arbitrary tag.  I know I specifically thought at one point "oh, leave the negative value possible" for some reason.  Can't remember why now, naturally.  I was probably asking at the time "should there be a window #0 or should it start at #1".  I didn't want to put more thought into that because people hadn't seen the new number scheme yet, so why get into a hypothetical discussion back then?

Restricting the sign shouldn't pose any problems and might be less confusing.  Or change the docs to be "n not equal 0".  It's up to list consensus.

Dan

Re: set term x11 -1

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

On Sunday 09 October 2005 02:48 am, Petr Mikulik wrote:
> "help x11" says:
>
>   Multiple plot windows are supported: `set terminal x11 <n>` directs
> the output to plot window number n.  If n>0, the terminal number will be
> appended to the window title (unless a title has been supplied manually)
> and the icon will be labeled `Gnuplot <n>`.
>
> However, "set term x11 -1" titles the window "Gnuplot -1". Is this bug
> in gnuplot_x11, or in the docs?

Is there any reason to allow negative terminal numbers in the first place?

Neither x11.trm nor gplt_x11.c appears to use the number for anything
other than an arbitrary ID tag.

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

Re: Win32: change pointstyle

[Juergen W. <wie...@fr...>]

On Friday 07 October 2005 19:02 Ethan Merritt wrote:
> The default colors (at least the first 10 or so) for each terminal
> type are supposed to be chosen for maximal contrast on that
> particular medium. In general this leads to darker colors for
> print and brighter colors for screen display.  I dare say that
> more research and effort could be put into the optimal choice
> for each terminal, but that's the general idea.

Is it possible that the colors are at least somewhat similar to each
other.  So that linetype 1 is always some kind of red, linetype 2
green, ...?  I think it is no problem if they differ in brightness.

Juergen

set term x11 -1

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

"help x11" says:

  Multiple plot windows are supported: `set terminal x11 <n>` directs the
  output to plot window number n.  If n>0, the terminal number will be
  appended to the window title (unless a title has been supplied manually)
  and the icon will be labeled `Gnuplot <n>`.


However, "set term x11 -1" titles the window "Gnuplot -1". Is this bug in 
gnuplot_x11, or in the docs?

---
PM

Re: Re: Win32: change pointstyle

[<ds...@ch...>]

> 
> From: Petr Mikulik <mi...@ph...>
> Date: 2005/10/07 Fri PM 06:03:11 EDT
> To: Bastian Maerkisch <bma...@we...>
> CC: gnu...@li...
> Subject: Re: Win32: change pointstyle
> 
> > This patch aims to increase consistency between the windows
> > terminal and other terminals:
> > The order of the pointstyles is changed. It is now the same
> > as in gd.trm, pdf.trm, post.trm and possibly others.
> > And default colors are now taken from web_color_rgbs[], as
> > do gd.trm and pdf.trm. Btw. terminals are not very consistent
> > here: gd.trm uses all web colors, pdf only the first 12
> > and postscript uses 9 or so. win.trm uses 15 different colors ...
> 
> There was an effort before 4.0 to unify colors and pointtypes "as much as 
> possible". It would be great if this effort continues. Colors are still not 
> well unified as you've found.

I agree with this.  It doesn't bother me too much because I think the most popular colors of the few terminals I use are about the same.  But it can be annoying to find that a line is yellow when working in a window terminal and brown when when making a hard copy.

Would it be too much to devise some kind of color table lookup for each terminal?  Then have some kind of "get_color(term,..., char *color)"?  E.g.,

lookup_table {
  {"r$ed", 1},
  {"y$ellow", 2},
  {"m$agenta", 3}
...
};

Then, when a user issues a command requiring a color s/he can say "yellow", "green", etc.  Gnuplot then does a

if (!(color_number = get_color(term, user_char_string)) {
  printf("sorry user, don't know that color");
  errorout();
}

That way, all the headache of color matching is left to the person creating the terminal driver.

Of course, we'd have a "show term colors", etc.  There'd be variations on this naturally.  The one down side would be a user utilizing colors for one terminal that are not in another terminal.  Switching to the new terminal would cause faults.

Dan

Re: bug in terminals affected by 'set size'

[Harald H. <h.h...@tu...>]

On Fri, 7 Oct 2005, Petr Mikulik wrote:

> > One difficult thing is a0 posters: it is not possible to make big enough
> > eps images with Gnuplot to be included into an a0 poster.  Of course,
> > there is a workaround; one just plots everything in smaller scale in
> > Gunplot (a4 vs a0), and scales the result back into a0.  However, the
> > calculations with font sizes and linewidths are something that a user
> > shouldn't need to do.
>
> Using scalable fonts, it is feasible using "set termoptions font ..." <=
> it's only here you give the font scale. Now, we miss "set termoptions
> linewidth x" to scale in the same way.
>
> > Origin (a windows GUI driven plotting program), because it seems not to
> > have such limitation.
>
> I would combine several eps plots together using Xfig, or LaTeX.
>
> > set term post eps canvas 8cm, 5cm
> > set term post canvas a0
>
> Actually there are two possibilities what this "8cm" can mean:
>    - scalable size
>    - non-scalable size

In my opinion, with canvas 8cm,5cm, a BoundingBox with a width of
8cm=227pt and height of 5cm=142pt has to be ment, e.g.

%%BoundingBox: 50 50 277 192

Thus, the measure has to be non-scalable.

Best regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: bug in terminals affected by 'set size'

[Harald H. <h.h...@tu...>]

On Fri, 7 Oct 2005, Petr Mikulik wrote:

> Question: how to organize different linewidths on different pages, or rather
> in different subplots?
>
> > We could, I think, do exactly the same with font sizes by introducing
> > a global multiplier in the header
> > /gnufontsize 1.000 def
>
> This would be useful.

I don't think it is too useful since the layout changes depending on the
font size. Thus, a subsequent change in the Postscript output leads to bad
results.

Best regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Win32: change pointstyle

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

> This patch aims to increase consistency between the windows
> terminal and other terminals:
> The order of the pointstyles is changed. It is now the same
> as in gd.trm, pdf.trm, post.trm and possibly others.
> And default colors are now taken from web_color_rgbs[], as
> do gd.trm and pdf.trm. Btw. terminals are not very consistent
> here: gd.trm uses all web colors, pdf only the first 12
> and postscript uses 9 or so. win.trm uses 15 different colors ...

There was an effort before 4.0 to unify colors and pointtypes "as much as 
possible". It would be great if this effort continues. Colors are still not 
well unified as you've found.

---
PM

Re: Win32: change pointstyle

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

On Friday 07 October 2005 09:44 am, Bastian Maerkisch wrote:

> And default colors are now taken from web_color_rgbs[], as
> do gd.trm and pdf.trm. Btw. terminals are not very consistent
> here: gd.trm uses all web colors, pdf only the first 12
> and postscript uses 9 or so. win.trm uses 15 different colors ...

Yes, but some terminals types are used almost entirely for
screen display (x11, jpeg, usually png) while other
terminal types are used to generate plots for printing with ink
on paper (PostScript, LaTeX, sometimes png).  The visual
contrast between colors A and B can be very different on the
screen and on the printed page.

The default colors (at least the first 10 or so) for each terminal
type are supposed to be chosen for maximal contrast on that
particular medium. In general this leads to darker colors for
print and brighter colors for screen display.  I dare say that
more research and effort could be put into the optimal choice
for each terminal, but that's the general idea. 

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Win32: change pointstyle

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

This patch aims to increase consistency between the windows
terminal and other terminals:
The order of the pointstyles is changed. It is now the same
as in gd.trm, pdf.trm, post.trm and possibly others.
And default colors are now taken from web_color_rgbs[], as
do gd.trm and pdf.trm. Btw. terminals are not very consistent
here: gd.trm uses all web colors, pdf only the first 12
and postscript uses 9 or so. win.trm uses 15 different colors ...

Bastian

--=20
Bastian M=E4rkisch
Physikalisches Institut, Universit=E4t Heidelberg

Re: fit in parametric mode

[Hans-Bernhard B. <br...@ph...>]

Giuseppe Angilella wrote:
> would it be possible to fit data using a parametric function?

Not without knowing the input parameter for each point on the curve --- 
and even then it'll be tricky.  You'll probably end up with a 
multi-branch fit of x(t) and y(t), each to their own function defining 
the parametric curve.

fit in parametric mode

[Giuseppe A. <Giu...@ct...>]

Hi,

would it be possible to fit data using a parametric function?

I mean, I have "experimental" (x,y) pairs, and "theoretical" functions 
(x(t),y(t)), say.

Thank you in advance.

Giuseppe.