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

Re: User specified location of GD not carried into Makefiles

[m s. <mw...@us...>]

> ----- Original Message -----
> From: "Ethan A Merritt" <merritt@u.washington.edu>
> To: gnu...@li...
> Subject: Re: User specified location of GD not carried into Makefiles
> Date: Sun, 28 Jan 2007 21:18:17 -0800
>=20
>=20
> I am not clear on what problem you are trying to fix exactly.
> The version of libgd found during configuration does not have to be
> the same one used at runtime. For instance, I have been working with seve=
ral
> libgd versions since I'be been trying to push fixes upstream to libgd.org.
> I have seen no version-compatibility problems when running against any
> libgd version from 2.0.29 to 2.0.34-cvs, all with the same=20
> gnuplot executable.
>=20
> [pokes around a bit] OK, Mandrake 10.1 came with 2.0.27 so it didn't have
> GIF support. Is that the issue?
>=20
> Anyhow, even if you force ./configure to use some particular version
> when building gnuplot, at runtime it will still pick the libgd.so.2
> provided by the system setup or by LD_LIBRARY_PATH.  Wouldn't it be
> easier just to upgrade the system's libgd?
>=20

Let me try to explain this some more.  I work on some systems that=20
are locked down.  I cannot add packages as root.  So this means I=20
have to build and install in my local home directory.  Furthermore,=20
I often build only the static libraries for things like GD.  This=20
removes the LD_LIBRARY_PATH issues and it is now easier to move the=20
executable to another host on our network.

My reasoning is the configure script should examine a --with-gd=20
specified path before checking the $PATH.  After all I just=20
explicitly told configure where to look.  If the --with-gd path is=20
not respected then the wrong gd.h file will be included.

As for the link time options to remember the path (-R, -rpath),=20=20
implementing this gets trickier because there is not a standard=20
option across all compilers.  For now I would fore go trying to=20
implement this in the configure script.

I hope that makes my rationale clearer.

Mike Sutton


=3D
Low Cost Auto Insurance
Paying Too Much for Auto Insurance? Get Lower Ohio Quotes Today.
http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=3D2c928adba226c84e2bc09=
e9f322e81b3

Re: User specified location of GD not carried into Makefiles

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

On Monday 29 January 2007 11:24, Hans-Bernhard Br=F6ker wrote:
> Ethan A Merritt wrote:
> > Anyhow, even if you force ./configure to use some particular version=20
> > when building gnuplot, at runtime it will still pick the libgd.so.2=20
> > provided by the system setup or by LD_LIBRARY_PATH. =20
>=20
> Not necessarily.  Shared libraries can be registered with an absolute=20
> path.  The don't have to be searched via LD_LIBRARY_PATH or related=20
> means, and the executable can influence its own effective search path to=
=20
> some extend.  Viz. 'ld' options -R, -rpath etc.

That is true, at least on some systems.  But so far as I know gnuplot's
configure script doesn't do any such thing.  =20

It may be that you can force this in the gdlib-config file; I don't know mu=
ch=20
about that mechanism. But if I understand Lars' comment correctly,=20
the needed fix is not a change to the ./configure script but rather a change
to the environmental variable PATH at the time ./configure is run. =20

Re: User specified location of GD not carried into Makefiles

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

Ethan A Merritt wrote:
> Anyhow, even if you force ./configure to use some particular version 
> when building gnuplot, at runtime it will still pick the libgd.so.2 
> provided by the system setup or by LD_LIBRARY_PATH.  

Not necessarily.  Shared libraries can be registered with an absolute 
path.  The don't have to be searched via LD_LIBRARY_PATH or related 
means, and the executable can influence its own effective search path to 
some extend.  Viz. 'ld' options -R, -rpath etc.

Re: User specified location of GD not carried into Makefiles

[Lars H. <lhe...@us...>]

 
> Anyhow, even if you force ./configure to use some particular version 
> when building gnuplot, at runtime it will still pick the libgd.so.2 
> provided by the system setup or by LD_LIBRARY_PATH.  Wouldn't it be
> easier just to upgrade the system's libgd?
 
 All Mike needs to do is prepend the directory that contains his local
 gdlib-config to PATH (assuming the local location is the resulty of a
 make install, not just the compile dir). No patch necessary.

Re: User specified location of GD not carried into Makefiles

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

I am not clear on what problem you are trying to fix exactly.
The version of libgd found during configuration does not have to be
the same one used at runtime. For instance, I have been working with several
libgd versions since I'be been trying to push fixes upstream to libgd.org.
I have seen no version-compatibility problems when running against any
libgd version from 2.0.29 to 2.0.34-cvs, all with the same gnuplot executable.

[pokes around a bit] OK, Mandrake 10.1 came with 2.0.27 so it didn't have
GIF support. Is that the issue?

Anyhow, even if you force ./configure to use some particular version 
when building gnuplot, at runtime it will still pick the libgd.so.2 
provided by the system setup or by LD_LIBRARY_PATH.  Wouldn't it be
easier just to upgrade the system's libgd?

	Ethan



On Sunday 28 January 2007 20:37, m sutton wrote:
> OK.  I think I have a working patch to configure.in to resolve the 
> --with-gd= issues.  The same problem was also present in the 
> --with-pdf section.  I was able to test the --with-gd stuff but not 
> the --with-pdf parts.  However, the same basic logic is used in 
> both.
> 
> Mike Sutton


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

Re: User specified location of GD not carried into Makefiles

[m s. <mw...@us...>]

OK.  I think I have a working patch to configure.in to resolve the=20
--with-gd=3D issues.  The same problem was also present in the=20
--with-pdf section.  I was able to test the --with-gd stuff but not=20
the --with-pdf parts.  However, the same basic logic is used in=20
both.

Mike Sutton


=3D
Ruth's Chris Steak House
Serious steak and fine wines. Easy online reservations. Book your table now.
http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=3Df68766c3b16c72099ff7c=
0eb075c04fd

Re: Oddities when plotting "with labels"

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

On Sunday 28 January 2007 14:00, m sutton wrote:
> > > So I started playing around with the text color.      plot 
> > > 'mike3.dat' w labels left  tc rgb "blue"
> > >
> > > This works for RC4 but not for the CVS HEAD (4.3).  I have not 
> > > investigated why "tc rgb 'color'" does not work for 4.3.  It 
> > > always comes up black.
> > 
> > Huh. You are right. That's a strange one.
> > I have absolutely no idea what has gone wrong.
> 
> If I stumble on a solution I will post it.

Found it.  When I added the possibility of "rgb variable" for
label plots I should have been more restrictive in storing 
per-label color information *only* in the "rgb variable" case.
I got it right for points/impulses/dots/etc...

Fixed in CVS.

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

Re: User specified location of GD not carried into Makefiles

[m s. <mw...@us...>]

> ----- Original Message -----
> From: "Timoth=E9e Lecomte" <tim...@en...>
> To: "Mike Sutton" <mw...@us...>
> Subject: Re: User specified location of GD not carried into Makefiles
> Date: Sun, 28 Jan 2007 22:58:40 +0100
> Hi Mike,
>=20
> The offending code in configure.in is:
>=20
> if test "$with_gd" !=3D no; then
>   AC_PATH_PROG([GDLIB_CONFIG], [gdlib-config])
>   if test -n "$GDLIB_CONFIG"; then
>     libgd_CPPFLAGS=3D`gdlib-config --cflags`
>     libgd_LDFLAGS=3D`gdlib-config --ldflags`
>   elif test -d "$with_gd"; then
>     libgd_CPPFLAGS=3D"-I$with_gd/include"
>     libgd_LDFLAGS=3D"-L$with_gd/lib"
>   fi
> (...)
> fi
>=20
> So what you gave to --with-gd is only used if gdlib-config cannot=20
> be found in your $PATH. And then it doesn't even try to use the=20
> gdlib-config in the custom path that you provided, but just appends=20
> 'include' and 'libs' to it. This could indeed be improved.

OK.  However, the expectation is that my --with specification would override
the default behavior.  Perhaps, the test should be for $with_gd/bin/gdlib-c=
onfig
first, if fails then try in $PATH.  I quickly tested the following and it
seems to work.  (I'm not well versed in this configure script stuff but
I gave it a try).

  if test -d "$with_gd"; then
    if test -n "$with_gd/bin/gdlib-config"; then
      libgd_CPPFLAGS=3D`$with_gd/bin/gdlib-config --cflags`
      libgd_LDFLAGS=3D"-L$with_gd/lib "`$with_gd/bin/gdlib-config --ldflags`
    else
      libgd_CPPFLAGS=3D"-I$with_gd/include"
      libgd_LDFLAGS=3D"-L$with_gd/lib"
    fi
  else
    AC_PATH_PROG([GDLIB_CONFIG], [gdlib-config])
    if test -n "$GDLIB_CONFIG"; then
      libgd_CPPFLAGS=3D`gdlib-config --cflags`
      libgd_LDFLAGS=3D`gdlib-config --ldflags`
    fi
  fi

There still is the issue of testing for the fontconfig library.=20=20
There is not a unique function that can be tested for.  I see
that gdlib-config can list the libraries it requires.

Mike Sutton


=3D
Mica Heli Guides, Canada
Private Canadian helicopter skiing. Powder skiing from our remote lodge nea=
r Jasper. Great prices, availability for this season. Guaranteed fresh deep=
 powder every run. All tours private.
http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=3D1666da2f83f9115bd2aa1=
90b8f0b0899

Re: Oddities when plotting "with labels"

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

Ethan A Merritt wrote:
> On Sunday 28 January 2007 12:58, Mike Sutton wrote:
> 
>>The comma in the offset specification confuses the command line parser.
>>  plot 'mike3.dat'  with labels left offset 3,3 , 'mike4.dat' with points
>>        duplicated or contradicting arguments in plot options
> 
> 
> Yes, I had totally forgotten about that. Thanks for the reminder.
> It is a known problem, but is probably fixable.
> 
> 
>>A work around is to make sure the "with labels" is the last thing plotted.
> 
> 
> Other work-arounds:
> - Give a dummy z coordinate in the offset
> 	plot 'mike3' with labels left offset 3,3,0, 'mike4' with points
> - put an attribute keyword after the offset
> 	plot 'mike3' with labels offset 3,3 left, 'mike4' with points
> - even if it's a useless attribute
> 	plot 'mike3' with labels offset 3,3 nopoint, 'mike4' with points
> 

I wasn't aware this issue came up elsewhere.  I think this is the same problem as we skirted with a change in syntax to something else that used commas in the binary format string.  That is, we changed a comma to a colon, but in that case the comma wasn't used as a delimiter for something like coordinates.

Not sure this is fixable.  The problem is that one has to sort of advance the parse pointer a little too far and move on before making a final decision about how to treat the numbers.  For example, note the slight difference between these two lines, both of them valid:

	plot 'mike3' with labels left offset 3,3,0, 'mike4' with points

	plot 'mike3' with labels left offset 3,3,0 with points

Yes, it is clear that their is a second plot and it is zero as one looks at it, but that doesn't become clear until the "with" is interpreted which from a programming perspective is too far down the line.

The problem is that an "isolated" or "stand alone" comma has multiple meanings.  The only ways around this, it seems to me, is to change the syntax of end of line (difficult to deprecate something like that, but could allow new syntax that hasn't ambiguity) or restrict the use of comma somewhat (again, difficult to change at this point).

Unfortunately semicolon and backslash are already used.  There is a straight line "|"

	plot 'mike3' with labels left offset 3,3 | 'mike4' with points

also, ~ < > - & (actually "and" would be a not-so-illogical choice) and then possible double character use .. ;; \\.

The other approach would be to restrict coordinates to include parentheses, e.g.,

	plot 'mike3' with labels left offset (3,3), 'mike4' with points

Dan

Re: User specified location of GD not carried into Makefiles

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

Mike Sutton wrote:
> I was testing 4.2RC4 and noticed that my specified location for GD was =
not=20
> passed down through to the Makefile.  This is on Mandrake 10.1 and I us=
e a=20
> newer version of GD that is intalled in my user area.  I swear this has=
=20
> worked properly in the past.
>
> My configure line was:
>   ./configure --with-gd=3D/home/mike/tmp/gnu
>
> The GD directory does not make it to the compile step:
> if gcc -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term=20
> -DBINDIR=3D\"/usr/local/bin\"=20
> -DX11_DRIVER_DIR=3D\"/usr/local/libexec/gnuplot/4.2\"=20
> -DGNUPLOT_PS_DIR=3D\"/usr/local/share/gnuplot/4.2/PostScript\"=20
> -DCONTACT=3D\"gnu...@li...\"=20
> -DHELPFILE=3D\"/usr/local/share/gnuplot/4.2/gnuplot.gih\" -I/usr/X11R6/=
include=20
> -I/usr/include  -g -O2 -MT term.o -MD -MP -MF ".deps/term.Tpo" -c -o te=
rm.o=20
> term.c; \
> then mv -f ".deps/term.Tpo" ".deps/term.Po"; else rm -f ".deps/term.Tpo=
"; exit=20
> 1; fi
>
>
> And the link step for gnuplot was:
> g++  -g -O2  -L/usr/X11R6/lib -o gnuplot  alloc.o axis.o breaders.o bit=
map.o=20
> color.o command.o contour.o datafile.o dynarray.o eval.o fit.o gadgets.=
o=20
> getcolor.o graph3d.o graphics.o help.o hidden3d.o history.o internal.o=20
> interpol.o matrix.o misc.o mouse.o parse.o plot.o plot2d.o plot3d.o pm3=
d.o=20
> readline.o save.o scanner.o set.o show.o specfun.o standard.o stdfn.o=20
> tables.o term.o time.o unset.o util.o util3d.o variable.o version.o   -=
lz=20
> -lgd -lXpm -lX11 -ljpeg -lfreetype -lpng12 -lz -lm   -lm
>
>
> As you can see my specification to GD was lost.  I'm guessing this is s=
ome=20
> kind of problem with the=20
>
> I also noticed that GD 2.0.33 links in the fontconfig library if availa=
ble. =20
> Gnuplot does not check for fontconfig.  Is this picked up when the prop=
er=20
> gdlib-config script is found?
>
> Mike Sutton
>  =20

Hi Mike,

The offending code in configure.in is:

if test "$with_gd" !=3D no; then
  AC_PATH_PROG([GDLIB_CONFIG], [gdlib-config])
  if test -n "$GDLIB_CONFIG"; then
    libgd_CPPFLAGS=3D`gdlib-config --cflags`
    libgd_LDFLAGS=3D`gdlib-config --ldflags`
  elif test -d "$with_gd"; then
    libgd_CPPFLAGS=3D"-I$with_gd/include"
    libgd_LDFLAGS=3D"-L$with_gd/lib"
  fi
(...)
fi

So what you gave to --with-gd is only used if gdlib-config cannot be=20
found in your $PATH. And then it doesn't even try to use the=20
gdlib-config in the custom path that you provided, but just appends=20
'include' and 'libs' to it. This could indeed be improved.

Best regards,

Timoth=E9e

User specified location of GD not carried into Makefiles

[Mike S. <mw...@us...>]

I was testing 4.2RC4 and noticed that my specified location for GD was not 
passed down through to the Makefile.  This is on Mandrake 10.1 and I use a 
newer version of GD that is intalled in my user area.  I swear this has 
worked properly in the past.

My configure line was:
  ./configure --with-gd=/home/mike/tmp/gnu

The GD directory does not make it to the compile step:
if gcc -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term 
-DBINDIR=\"/usr/local/bin\" 
-DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.2\" 
-DGNUPLOT_PS_DIR=\"/usr/local/share/gnuplot/4.2/PostScript\" 
-DCONTACT=\"gnu...@li...\" 
-DHELPFILE=\"/usr/local/share/gnuplot/4.2/gnuplot.gih\" -I/usr/X11R6/include 
-I/usr/include  -g -O2 -MT term.o -MD -MP -MF ".deps/term.Tpo" -c -o term.o 
term.c; \
then mv -f ".deps/term.Tpo" ".deps/term.Po"; else rm -f ".deps/term.Tpo"; exit 
1; fi


And the link step for gnuplot was:
g++  -g -O2  -L/usr/X11R6/lib -o gnuplot  alloc.o axis.o breaders.o bitmap.o 
color.o command.o contour.o datafile.o dynarray.o eval.o fit.o gadgets.o 
getcolor.o graph3d.o graphics.o help.o hidden3d.o history.o internal.o 
interpol.o matrix.o misc.o mouse.o parse.o plot.o plot2d.o plot3d.o pm3d.o 
readline.o save.o scanner.o set.o show.o specfun.o standard.o stdfn.o 
tables.o term.o time.o unset.o util.o util3d.o variable.o version.o   -lz 
-lgd -lXpm -lX11 -ljpeg -lfreetype -lpng12 -lz -lm   -lm


As you can see my specification to GD was lost.  I'm guessing this is some 
kind of problem with the 

I also noticed that GD 2.0.33 links in the fontconfig library if available.  
Gnuplot does not check for fontconfig.  Is this picked up when the proper 
gdlib-config script is found?

Mike Sutton

Re: Oddities when plotting "with labels"

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

On Sunday 28 January 2007 12:58, Mike Sutton wrote:
> The comma in the offset specification confuses the command line parser.
>   plot 'mike3.dat'  with labels left offset 3,3 , 'mike4.dat' with points
>         duplicated or contradicting arguments in plot options

Yes, I had totally forgotten about that. Thanks for the reminder.
It is a known problem, but is probably fixable.

> A work around is to make sure the "with labels" is the last thing plotted.

Other work-arounds:
- Give a dummy z coordinate in the offset
	plot 'mike3' with labels left offset 3,3,0, 'mike4' with points
- put an attribute keyword after the offset
	plot 'mike3' with labels offset 3,3 left, 'mike4' with points
- even if it's a useless attribute
	plot 'mike3' with labels offset 3,3 nopoint, 'mike4' with points

> I think a note should be added to the 4.2 documentation about this limitation.

Yes, if no trivial fix is found.
The trick will be to put the note in a place that users will actually find.

 
> So I started playing around with the text color.  
>     plot 'mike3.dat' w labels left  tc rgb "blue"
> 
> This works for RC4 but not for the CVS HEAD (4.3).  I have not investigated 
> why "tc rgb 'color'" does not work for 4.3.  It always comes up black. 

Huh. You are right. That's a strange one.
I have absolutely no idea what has gone wrong.

> I have also thought that the addition of a label style, analogous to 
> linestyle,  would be useful.

I have a slightly different approach already on my TODO list.
Rather than using linestyle as a model, I was thinking that there should
be the equivalent of
	set style histogram
	set style fill
	set style object rectangle
Each of these defines a set of default properties for all instances of
the respective plot elements.  

In the case of labels, my idea was that if a specific label
command does not set a font, say, then its font field is set to DEFAULT
and inherits the current value in the generic label style. Thus if you
were to set 100 labels in advance, perhaps plotting to judge visual effect,
you could change all of them at once to use a smaller font by saying
	set style label font "Times,9"

I take it your idea is similar, except that there would be multiple
predefined label styles rather than a single default style. Right?

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

Oddities when plotting "with labels"

[Mike S. <mw...@us...>]

I was trying to plot some data with labels and points from a data file and =
got=20
the following error when the "offset" option was used.  It seems that the=20
comma in the offset specification confuses the command line parser.  A work=
=20
around is to make sure the "with labels" is the last thing plotted.  I thin=
k=20
a note should be added to the 4.2 documentation about this limitation.

plot 'mike3.dat'  with labels left offset 3,3 , 'mike4.dat' with points
        duplicated or contradicting arguments in plot options

=46rom the documentation for "with labels"
> The font, color, rotation angle and other properties of the printed text =
may
> be specified as additional command options .=20

So I started playing around with the text color. =20
    plot 'mike3.dat' w labels left  tc rgb "blue"

This works for RC4 but not for the CVS HEAD (4.3).  I have not investigated=
=20
why "tc rgb 'color'" does not work for 4.3.  It always comes up black.=20
However, using "tc lt #" does work as expected.

I have also thought that the addition of a label style, analogous to=20
linestyle,  would be useful.

Mike Sutton

Re: readline problems on OSX

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

On Sunday 28 January 2007 11:36, Per Persson wrote:
> 
> On Jan 25, 2007, at 22:09, Ethan Merritt wrote:
> 
> > On Thursday 25 January 2007 12:52, Per Persson wrote:
> 
> I've put a patch (#1646558) which makes configure look for  
> _remove_history rather than _readline.
> This works on OS X 10.4.x, but newer versions of libedit seems to  
> have that symbol, so this is likely not a future-proof test.
 
I have no way to test your fix, other than to confirm that ./configure
under linux can still successfully find gnu libreadline after
applying the patch.  

> Let me know if you think I should commit it to CVS.

You'll have to make that call yourself, or ask other  OSX users for
opinions.  It sounds better than the current ./configure behaviour
on OSX.  But remember that gnuplot releases seem to stick around for
several years, so looking ahead to likely compatibility with future
OS versions is a good idea.  

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

Re: readline problems on OSX

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

On Jan 25, 2007, at 22:09, Ethan Merritt wrote:

> On Thursday 25 January 2007 12:52, Per Persson wrote:
>>
>> 1) The readline issue is caused by someone at Apple having the
>> "bright" idea to symlink /usr/lib/libreadline.dylib to /usr/lib/
>> libedit.dylib
>> (The reason for not including readline are license terms, only BSD/
>> LGPL/etc. in OS X not GPL)
>>

I've put a patch (#1646558) which makes configure look for  
_remove_history rather than _readline.
This works on OS X 10.4.x, but newer versions of libedit seems to  
have that symbol, so this is likely not a future-proof test.

Let me know if you think I should commit it to CVS.

/Per

Re: image bounds when "set size .5"

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

On 1/27/07, Ethan A Merritt wrote:
> On Saturday 27 January 2007 07:29, Mojca Miklavec wrote:
> > just a short question: how should a terminal properly set the bounding
> > box of an image?
>
> I don't think that question is well-defined.  You may have to explain
> in more detail what you are asking.

I'm sorry for not being clear enough, these are just different naming
conventions. What I mean with "bounding box" (term used in eps figures
for examples) is what you mean with canvas. You guessed it properly.

> > I used to set it to (0,0) and (5in,3in), or whatever
> > the graphic size was, but then I figured out that the image is now too
> > big if one sets a smaller size ("set size .5" for example).
>
> Please define "graphic size" and "image size".  These are not the
> terms that we have been using with regard to gnuplot, so I am not
> sure what you mean.

Both refer to "canvas size". (I wasn't use to that term either.)

> > I would
> > like to set the image boundary only to the relevant part (in that case
> > it would be (0,0) and (2.5in,1.5in)).
>
> Please don't do that.  We are trying to make the scale of the plot,
> controlled by "set size", and the size of the 'canvas' (which I think
> is what you mean by 'image' but I'm not sure), independent of each other.
>
> This section of the current docs tries to explain, but maybe you can
> suggest how to make the description more clear:

(The description seems clear, but I didn't pay enough attention to it.
I also didn't know that it's called canvas.)

> gnuplot> help canvas
>
>  In earlier versions of gnuplot, some terminal types used the values from
>  `set size` to control also the size of the output canvas; others did not.
>  The use of 'set size' for this purpose was deprecated in version 4.2.
>  In version 4.3 almost all terminals now behave as follows:
>
>  `set term <terminal_type> size <XX>, <YY>` controls the size of the output
>  file, or "canvas". Please see individual terminal documentation for allowed
>  values of the size parameters.  By default, the plot will fill this canvas.
>
>  `set size <XX>, <YY>` scales the plot itself relative to the size of the
>  canvas.  Scale values less than 1 will cause the plot to not fill the entire
>  canvas.  Scale values larger than 1 will cause only a portion of the plot to
>  fit on the canvas.  Please be aware that setting scale values larger than 1
>  may cause problems on some terminal types.
>
>  The major exception to this convention is the PostScript driver, which
>  by default continues to act as it has in earlier versions. Be warned that
>  the next version of gnuplot may change the default behaviour of the
>  PostScript driver as well.
>  Example:
>        set size 0.5, 0.5
>        set term png size 600, 400
>        set output "figure.png"
>        plot "data" using lines
>
>  These commands will produce an output file "figure.png" that is 600 pixels
>  wide and 400 pixels tall. The plot will fill the lower left quarter of this
>  canvas.  This is consistent with the way multiplot mode has always worked,
>  however it is a change in the way the png driver worked for single plots in
>  version 4.0.

I'm sorry, I have to read the documentation more carefully next time
before asking something.

This is how my terminal already works, but I thought that it needs to
be fixed. So, I thought that for the example above I should create an
image of 300x200 pixels (leaving so much blank space in the border
seemed somehow nonsense to me).

The terminal also supports "set size" syntax, but I cannot use it in
the middle of the document, because if I want to change the size with
"set context size 0.5,0.5", then the terminal is reset (which could be
expressed as \end{document}\begin{document}" in LaTeX dialect), so
it's useless.

But that's OK - in most cases one creates single plots anyway.

> The individual terminal drivers are not supposed to know or care about
> this.  It is the responsibility of the core routines to decide how to
> place things onto the canvas size reported by the current driver in
> term->xmax and term->ymax.

OK. So there's nothing more to care about.

Thanks a lot,
     Mojca

Re: image bounds when "set size .5"

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

On Saturday 27 January 2007 07:29, Mojca Miklavec wrote:
> just a short question: how should a terminal properly set the bounding
> box of an image? 

I don't think that question is well-defined.  You may have to explain
in more detail what you are asking.

> I used to set it to (0,0) and (5in,3in), or whatever 
> the graphic size was, but then I figured out that the image is now too
> big if one sets a smaller size ("set size .5" for example).

Please define "graphic size" and "image size".  These are not the
terms that we have been using with regard to gnuplot, so I am not
sure what you mean.

> I would 
> like to set the image boundary only to the relevant part (in that case
> it would be (0,0) and (2.5in,1.5in)).

Please don't do that.  We are trying to make the scale of the plot, 
controlled by "set size", and the size of the 'canvas' (which I think
is what you mean by 'image' but I'm not sure), independent of each other.

This section of the current docs tries to explain, but maybe you can
suggest how to make the description more clear:

gnuplot> help canvas

 In earlier versions of gnuplot, some terminal types used the values from
 `set size` to control also the size of the output canvas; others did not.
 The use of 'set size' for this purpose was deprecated in version 4.2.
 In version 4.3 almost all terminals now behave as follows:

 `set term <terminal_type> size <XX>, <YY>` controls the size of the output
 file, or "canvas". Please see individual terminal documentation for allowed
 values of the size parameters.  By default, the plot will fill this canvas.

 `set size <XX>, <YY>` scales the plot itself relative to the size of the
 canvas.  Scale values less than 1 will cause the plot to not fill the entire
 canvas.  Scale values larger than 1 will cause only a portion of the plot to
 fit on the canvas.  Please be aware that setting scale values larger than 1
 may cause problems on some terminal types.

 The major exception to this convention is the PostScript driver, which
 by default continues to act as it has in earlier versions. Be warned that
 the next version of gnuplot may change the default behaviour of the
 PostScript driver as well.
 Example:
       set size 0.5, 0.5
       set term png size 600, 400
       set output "figure.png"
       plot "data" using lines

 These commands will produce an output file "figure.png" that is 600 pixels
 wide and 400 pixels tall. The plot will fill the lower left quarter of this
 canvas.  This is consistent with the way multiplot mode has always worked,
 however it is a change in the way the png driver worked for single plots in
 version 4.0.

 > How can I determine the bounds? I saw that "set size" sets "xsize" and
> "ysize" global variables,

Those are the scaling factors set by "set size".

> but then I also noticed the following: 
>     plot_bounds.xright = (xsize + xoffset) * t->xmax

plot_bounds was not intended for export to terminal drivers.
It is used by the generic drawing routines like draw_clip_line()
to perform terminal-independent clipping.

> Should the graphic boundary obey "plot_bounds" or something else?
> (Once again, I'm not sure about multiplots and such.)

The individual terminal drivers are not supposed to know or care about
this.  It is the responsibility of the core routines to decide how to
place things onto the canvas size reported by the current driver in
term->xmax and term->ymax.




> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

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

image bounds when "set size .5"

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

Hello,

just a short question: how should a terminal properly set the bounding
box of an image? I used to set it to (0,0) and (5in,3in), or whatever
the graphic size was, but then I figured out that the image is now too
big if one sets a smaller size ("set size .5" for example). I would
like to set the image boundary only to the relevant part (in that case
it would be (0,0) and (2.5in,1.5in)).

How can I determine the bounds? I saw that "set size" sets "xsize" and
"ysize" global variables, but then I also noticed the following:
    plot_bounds.xright = (xsize + xoffset) * t->xmax

Should the graphic boundary obey "plot_bounds" or something else?
(Once again, I'm not sure about multiplots and such.)

Thanks a lot,
    Mojca Miklavec

Re: pdf libraries

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

Ethan Merritt wrote:
> On Friday 26 January 2007 11:41, Timothée Lecomte wrote:
>>As for pattern-fill, what are you afraid of ?
> 
> 
> When I originally implemented pattern-fill in pdf.trm, I had to
> try about 6 different ways of constructing the patterns before I
> found a sequence of calls that worked.  The routines provided 
> by the PDF library did not parallel the PostScript routines as
> closely as I would have expected.  It worked in the end, but
> it was a bit tricky to find the right calls.

Would patterns composed of images rather than strokes be of any help?  I think there is now the necessary functions in PostScript to construct the ecodings.  PDFlib I don't know about.

Beats me what the issue is with sending patterns to the HP printer.  I don't see any complaints at the HP website about that.

Dan

Re: pdf libraries

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

On Friday 26 January 2007 11:41, Timoth=E9e Lecomte wrote:
> Ethan Merritt a =E9crit :
> >
> > What would be the state of UTF-8 support through such a path?
> > That is a big lack in PDFlib Lite.
> >  =20
> Well, I am not completely sure, but I would expect the text output to be=
=20
> the same as the one from the wxt terminal. Actually, fonts are more of a=
=20
> problem than encoding in my understanding of pdf.

I think the problem really is the encoding.  It's easy to specify
a font that contains a very large set of unicode glyphs, but PDFLib Lite
only allows you to select those glyphs that are indexed by a
single-byte coding table.  Full unicode table options, including UTF-8,
are only available in commercial versions of PDFLib.  Having the
glyphs in the font doesn't help if the encoding does not index them.

> > The other tricky bit is pattern-fill, but it's much less important.
> >
> As for pattern-fill, what are you afraid of ?

When I originally implemented pattern-fill in pdf.trm, I had to
try about 6 different ways of constructing the patterns before I
found a sequence of calls that worked.  The routines provided=20
by the PDF library did not parallel the PostScript routines as
closely as I would have expected.  It worked in the end, but
it was a bit tricky to find the right calls.

Re: pdf libraries

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

Ethan Merritt a =E9crit :
> On Friday 26 January 2007 11:30, Timoth=E9e Lecomte wrote:
>  =20
>> Petr Mikulik a =E9crit :
>>    =20
>>> 	http://sourceforge.net/projects/libharu/
>>> Haru is a free, cross platform, open-sourced software library for gen=
erating=20
>>> PDF written in ANSI-C.
>>>      =20
>
>  =20
>> Cairo can do it too, and we already have 90% of the code in gnuplot=20
>> right now thanks to the wxt terminal and gp_cairo.c.
>>    =20
>
> What would be the state of UTF-8 support through such a path?
> That is a big lack in PDFlib Lite.
>
> The other tricky bit is pattern-fill, but it's much less important.
>  =20
Well, I am not completely sure, but I would expect the text output to be=20
the same as the one from the wxt terminal. Actually, fonts are more of a=20
problem than encoding in my understanding of pdf.

As for pattern-fill, what are you afraid of ?

Timoth=E9e

Re: pdf libraries

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

On Friday 26 January 2007 11:30, Timoth=E9e Lecomte wrote:
> Petr Mikulik a =E9crit :
> > 	http://sourceforge.net/projects/libharu/
> > Haru is a free, cross platform, open-sourced software library for gener=
ating=20
> > PDF written in ANSI-C.

> Cairo can do it too, and we already have 90% of the code in gnuplot=20
> right now thanks to the wxt terminal and gp_cairo.c.

What would be the state of UTF-8 support through such a path?
That is a big lack in PDFlib Lite.

The other tricky bit is pattern-fill, but it's much less important.

Re: pdf libraries

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

Petr Mikulik a =E9crit :
> A fast search for a free PDF writing library has shown this one (except=
 for=20
> the PDFlib Lite):
>
> 	http://sourceforge.net/projects/libharu/
>
> Haru is a free, cross platform, open-sourced software library for gener=
ating=20
> PDF written in ANSI-C. It can work as both a static-library (.a, .lib) =
and a=20
> shared-library (.so, .dll).
>
> A fast comparison shows that the C syntax is close to the PDFlib one. M=
aybe=20
> gnuplot could support both libraries?
>
> ---
> PM
Cairo can do it too, and we already have 90% of the code in gnuplot=20
right now thanks to the wxt terminal and gp_cairo.c.

If enough interest is shown about that, I can concentrate on this in the=20
free time I'll have in next days/weeks (I even think I already started=20
to work on that some time ago, so I must be at 95% of the code ready).

Timoth=E9e

Re: PS terminal fillbetween crosshatch not appearing

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

On Friday 26 January 2007 10:15, Daniel J Sebald wrote:
> One small issue, for someone familiar with prologue.ps.  
> In this definition for Pat3 at the end of the paint process it says "fill" whereas 
> all the others say "stroke".  Selecting Pat3 results in a solid red fill. 

Correct. Pattern 3 is solid fill on most terminal types.

Re: PS terminal fillbetween crosshatch not appearing

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

One small issue, for someone familiar with prologue.ps.  In this definition for Pat3 at the end of the paint process it says "fill" whereas all the others say "stroke".  Selecting Pat3 results in a solid red fill.  Is that desired?  Or should that be "stroke"?

<< Tile8x8
 /PaintProc {0.5 setlinewidth pop 0 0 M 0 8 L
	8 8 L 8 0 L 0 0 L fill}
>> matrix makepattern
/Pat3 exch def


Daniel J Sebald wrote:
> Daniel J Sebald wrote:
> 
>>There may still be a problem with pattern fill.  I ran fillbetween.dem 
> 
> 
> ...but I don't think what I described in the last email has anything to do with that antialiasing issue in gv.  If I generate the pattern fill example using "set term pdf", gv behaves the same way on the resulting PDF.
> 
> Dan