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

pdf libraries

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

A fast search for a free PDF writing library has shown this one (except for 
the PDFlib Lite):

	http://sourceforge.net/projects/libharu/

Haru is a free, cross platform, open-sourced software library for generating 
PDF written in ANSI-C. It can work as both a static-library (.a, .lib) and a 
shared-library (.so, .dll).

A fast comparison shows that the C syntax is close to the PDFlib one. Maybe 
gnuplot could support both libraries?

---
PM

Re: PS terminal fillbetween crosshatch not appearing

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

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

Re: PS terminal fillbetween crosshatch not appearing

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

There may still be a problem with pattern fill.  I ran fillbetween.dem to the second plot, then hit Cntrl-C, then

set term postscript color
set output 'fb2.ps'
replot
set output

to generate the attached file.  When I look at this with gv (antialiasing off) things are fine.  But when I send it to an HP2200D printer (lpr -P simplex fb2.ps) it prints the fill between line except the very first column (left most... which actually may be the last strip if things are drawn as they are popped off the stack).  The left most column comes out white and there is no annotation on the plot.

I do the same process for the first plot in fillbetween.dem and everything prints fine.

Dan

Re: PS terminal fillbetween crosshatch not appearing

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

Ethan A Merritt wrote:

> Well then no, I don't see much worth in breaking the part that's working :-)

Suppose not.

Re: PS terminal fillbetween crosshatch not appearing

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

On Thursday 25 January 2007 22:35, Daniel J Sebald wrote:
> Ethan A Merritt wrote:
> > which makes the fill behave and appear similar.
> > Is it worth changing this?
> 
> > Similar as in "both work" or similar as in "neither works"?
> 
> Similar as in neither works, until antialiasing is turned off.
 
Well then no, I don't see much worth in breaking the part that's working :-)

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

Re: PS terminal fillbetween crosshatch not appearing

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

Ethan A Merritt wrote:

> Similar as in "both work" or similar as in "neither works"?

Similar as in neither works, until antialiasing is turned off.

Re: PS terminal fillbetween crosshatch not appearing

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

On Thursday 25 January 2007 21:59, Daniel J Sebald wrote:
> Here's one thing to consider.  I noticed that in this fill between example where the antialiasing filter filters out the pattern leaving the area between curves blank there is the key sample which appears even though the fill between curves doesn't.
> The sample and the fill are done two different ways.  The sample looks like:
> 
> 6479 4452 399 70 40 45 2 PatternFill
> 
> I replaced that with something looking more like what is used for the fill:
> 
> gsave 6479 4452 N 0 70 V 399 0 V 0 -70 V Pattern2 fill grestore
> 
> which makes the fill behave and appear similar.

Similar as in "both work" or similar as in "neither works"?


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

Re: PS terminal fillbetween crosshatch not appearing

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

Here's one thing to consider.  I noticed that in this fill between example where the antialiasing filter filters out the pattern leaving the area between curves blank there is the key sample which appears even though the fill between curves doesn't.

The sample and the fill are done two different ways.  The sample looks like:

6479 4452 399 70 40 45 2 PatternFill

I replaced that with something looking more like what is used for the fill:

gsave 6479 4452 N 0 70 V 399 0 V 0 -70 V Pattern2 fill grestore

which makes the fill behave and appear similar.

Is it worth changing this?

Dan

Re: PS terminal fillbetween crosshatch not appearing

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

Ethan Merritt wrote:
> On Thursday 25 January 2007 17:04, Daniel J Sebald wrote:
> 
>>In the latest CVS the "fillbetween.dem" demo for
>>
>>set term postscript color
>>does not fill in the cross hatch pattern of the second example.
> 
> 
> Yes, it does.
> 
> You have rediscovered the longstanding bug in ghostview/gv that fails to
> display pattern fill if anti-aliasing is enabled.
> 
> If you toggle the antialiasing setting in your viewer, you will see the pattern.

Oh...  OK thanks.

I just built the latest version of ghostscript.  Rather than not show fill, 8.54 issues error messages.  (Turning off antialiasing works correctly.)  So still unresolved, unless it is in their SVN repository somewhere.

Dan

Re: PS terminal fillbetween crosshatch not appearing

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

On Thursday 25 January 2007 17:04, Daniel J Sebald wrote:
> In the latest CVS the "fillbetween.dem" demo for
> 
> set term postscript color
> does not fill in the cross hatch pattern of the second example.

Yes, it does.

You have rediscovered the longstanding bug in ghostview/gv that fails to
display pattern fill if anti-aliasing is enabled.

If you toggle the antialiasing setting in your viewer, you will see the pattern.

PS terminal fillbetween crosshatch not appearing

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

In the latest CVS the "fillbetween.dem" demo for

set term postscript color

does not fill in the cross hatch pattern of the second example.  (I think this worked at one time.)

The PDF terminal produces the desired output.

If this sounds like a familiar bug, let me know.  Otherwise I will put it on SourceForge.

Dan

Re: Segmentation fault when using hidden option

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

Petr Mikulik wrote:
>>Using the attached input result in a segmentation
>>fault using:
>>        Version 4.2 patchlevel rc3
>>        last modified January 2007
>>        System: Linux 2.6.11.4-21.15-smp
> 
> 
> It works for me:
> 
>         Version 4.2 patchlevel rc3
>         last modified January 2007
>         System: Linux 2.6.13-15.13-default
> 
> (gnuplot just recompiled from 4.2-cvs).

Works for me as well.  However, I'd say this is a good example to illustrate a possible bug in the hidden line removal.  Again there are little specks that appear to be vertices that should clearly be hidden in this example but aren't.

Dan

Re: Universal binaries for Mac

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

On Jan 25, 2007, at 19:30, Mojca Miklavec wrote:

> But there are more serious problems, like libraries. If I build
> gnuplot with fink, the user who wants to use it need the same fink's
> libraries installed to be able to use it.

Isn't that expected? Fink's job is to track dependencies and handle  
them for _you_.

> Simply adding "-static"
> doesn't help since all the libraries on the system should be build
> static and for both architectures I assume.

Well, -static won't help but of course you can statically link any  
required library which can be built as a static library.
As an example, in a binary release, static linking of readline (or  
using builtin) is a must.

For libs provided as part of OS X, always shared libs or  
"frameworks", we should use them.
Any other functionality which relies on non-standard libs[1] (from an  
OS X point of view) should be statically linked.

In fixing up the release script, we might as well do our homework  
properly and decide what should come from the system and what should  
be linked in statically (and what must be left out).

[1] D'oh! I just realized that the one and only non-standard  
*framework* required is AquaTerm.framework. Can't link statically  
from frameworks AFAIK. Maybe we should supply the AquaTerm package as  
a sub-package[2] of gnuplot to be automagically installed if necessary?

[2] Come to think of it, we could do that for other libs as well, but  
then again, we don't want to mess up people's computers do we? ;-)

Best,
Per

Re: readline problems on OSX

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

>>
>> However, using ./configure  --with-readline=/path/to/your/gnu/
>> libreadline should work if libreadline is installed somewhere.

This is strange, using --with-readline=/path/to/your/gnu/libreadline  
doesn't seem to affect the linking.
I still get the missing symbols error caused by libedit.

Ah, now I see! (checking configure.in):
It is supposed to be --with-readline=/usr/local for a libreadline in / 
usr/local/lib. Maybe its just me, but from ./configure --help I  
expected the option to be either:
--with-readline=/usr/local/lib
or
--with-readline=/usr/local/lib/libreadline.dylib

Maybe we should rephrase the help text a little?

/Per

Re: readline problems on OSX

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

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

> Aha.  So gnuplot's configure script is correct, but OSX is lying to  
> it.
> Wonderful.  I don't think we can fix this on the gnuplot end, except
> maybe by making a special case of OSX (which of course the
> autoconf tools do not want you to do).

Not a special case, but (in my understanding) a test to determine if  
we are actually dealing with libedit should be OK, right?
I'm not saying we should, I'm just trying to figure out every  
possible strategy...

/Per

Re: Universal binaries for Mac

[Jeremy C. <jer...@gm...>]

On 1/25/07, Per Persson <per...@ma...> wrote:
>
> On Jan 25, 2007, at 17:40, Ethan A Merritt wrote:
>
> > We had similar report on OSX problems with -rc3.
> > But in that case building with ./configure --with-readline=builtin
> > apparently worked.  See bug report
> >
> > http://sourceforge.net/tracker/index.php?
> > func=detail&aid=1642845&group_id=2055&atid=102055
> >
> > Please help us figure out whether this is 1 bug, or 2 bugs, or a
> > general problem with gnu libreadline on OSX, or what.
> >
>
> Hi all,
> sorry for being late to the party, trying to catch up after we
> finally got back phone line last week and DSL-connection yesterday,
> after almost 8 weeks (long story involving moving and switching
> service providers... :-P ).
>
> 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)
>
> However, using ./configure  --with-readline=/path/to/your/gnu/
> libreadline should work if libreadline is installed somewhere.
>
> 2) The snapshot script: It is really crude, and currently only works
> on my machine. However, it was intended as a staring point for a tool
> to build properly packaged binary OS X releases from CVS or tarballs
> with a single command.
> Besides TeX, you'll need Iceberg ( http://s.sudre.free.fr/Software/
> Iceberg.html ) for it to work.
> We should fix it to build Universal Binaries too, but it'll require
> someone with an Intel Mac for testing.
>

I have an Intel Mac and am willing to test.  What should I do?

Jeremy

readline problems on OSX

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

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)
> 
> However, using ./configure  --with-readline=/path/to/your/gnu/ 
> libreadline should work if libreadline is installed somewhere.

Aha.  So gnuplot's configure script is correct, but OSX is lying to it.
Wonderful.  I don't think we can fix this on the gnuplot end, except
maybe by making a special case of OSX (which of course the 
autoconf tools do not want you to do).

On the bright side, does this mean that OSX contains a usable
version of libedit?  We were already experimenting with adding
that as a ./configure option, but couldn't find a copy of libedit that
actually worked :-(      

If OSX really does have a working version, then I suppose we could
test first for libedit, and only test for gnu readline after that.
That might work, and would not be specific to OSX.   
But only if libedit actually works, of course.

> I'll update my gnuplot sources now, and have a look at (1).

Great.  While you're at it, maybe you could have a look at  patchset 
#1504831 which attempts to use libedit as an alternative to readline.
Note the warning about a name conflict with routine term_init().

	thanks for the insight!

Re: Universal binaries for Mac

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

On Jan 25, 2007, at 17:40, Ethan A Merritt wrote:

> We had similar report on OSX problems with -rc3.
> But in that case building with ./configure --with-readline=builtin
> apparently worked.  See bug report
>
> http://sourceforge.net/tracker/index.php? 
> func=detail&aid=1642845&group_id=2055&atid=102055
>
> Please help us figure out whether this is 1 bug, or 2 bugs, or a
> general problem with gnu libreadline on OSX, or what.
>

Hi all,
sorry for being late to the party, trying to catch up after we  
finally got back phone line last week and DSL-connection yesterday,  
after almost 8 weeks (long story involving moving and switching  
service providers... :-P ).

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)

However, using ./configure  --with-readline=/path/to/your/gnu/ 
libreadline should work if libreadline is installed somewhere.

2) The snapshot script: It is really crude, and currently only works  
on my machine. However, it was intended as a staring point for a tool  
to build properly packaged binary OS X releases from CVS or tarballs  
with a single command.
Besides TeX, you'll need Iceberg ( http://s.sudre.free.fr/Software/ 
Iceberg.html ) for it to work.
We should fix it to build Universal Binaries too, but it'll require  
someone with an Intel Mac for testing.

I'll update my gnuplot sources now, and have a look at (1).

/Per

Re: Universal binaries for Mac

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

On 1/25/07, Jeremy Conlin wrote:
> Please excuse me for jumping in to this list.  I just downloaded
> gnuplot 4.2 rc4 this morning and tried to compile using the
> suggestions from Mojca, but it didn't work.  Since this project is
> about to release a stable version I thought I would chime in.

Please note that I'm a complete newbie on mac and in compiling/making
issues. I managed to create a new terminal, but I don't manage to deal
with compilation/installation issues.

Las tweek I've found the script which does "kind-of-bundling", but
there are quite some problems with it and I have no idea how to do
things properly (I know what I should do, but not how to do that).

Two tiny problems with that script:
- version is not fixed (config/MacOSX/createdist.sh)
- A file /usr/local/gwTeX/texmf.texlive/.../gnuplot.cfg (with the only
line which sets the font encoding to T1) gets included - the problem
is that if I gave that to someone, he might have TeX installed on
another location (for example: one month ago the default folder was
something else, but people might have fink's tetex or whatever else)

But there are more serious problems, like libraries. If I build
gnuplot with fink, the user who wants to use it need the same fink's
libraries installed to be able to use it. Simply adding "-static"
doesn't help since all the libraries on the system should be build
static and for both architectures I assume.


pdfTeX's svn repository also contain all the needed libraries, so
cross-compiling or building on a system without the needed libraries
is not an issue at all. With gnuplot it's like a nightmare to get all
the libraries properly. On linux distributions that's not a problem,
but on windows and mac it is. I only wish I had the knowledge how to
fix all that.

Without some mac developer who knows what he's doing, things will
never be sorted out properly for that platform. (I would also wish to
have the same kind of help as on windows, but I can't figure out what
flags to set for the compiler, so that gnuplot could launch "proper
help browser" instead of command-line version.)

I'll try to compile gnuplot without fink once I get home to see if I
get that problem. Just a thought: is it possible that "GNU readline"
would fail because the compiler/libraries are not exactly the same as
GNU?
(Sorry, I really don't know much about it, but when I got the computer
and tried to enable colors in "ls", I figured out that I needed the
GNU version of "ls"; the syntax/configuration didn't work with the
version that comes with mac by default - BSD.)

Mojca

Re: Universal binaries for Mac

[Jeremy C. <jer...@gm...>]

On 1/25/07, Ethan A Merritt <merritt@u.washington.edu> wrote:
> We had similar report on OSX problems with -rc3.
> But in that case building with ./configure --with-readline=builtin
> apparently worked.  See bug report
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=1642845&group_id=2055&atid=102055
>
>
I got it to work by doing the following

export CFLAGS='-arch i386'
export LDFLAGS='-arch i386'
./configure --with-readline=builtin

I also tried the gnu readline, but that didn't work.  Notice this is
not a universal binary!  It is only for intel macs.  I could not get
either builtin or gnu readline to work when compiling for both
architectures.

 Please help us figure out whether this is 1 bug, or 2 bugs, or a
> general problem with gnu libreadline on OSX, or what.
>
>         thanks
>
>                 Ethan
>
I'm not sure where the bug is.  I suspect this is only one bug noted
in the above bug report.  I wish I had more information to share

Thanks,
Jeremy

Re: Universal binaries for Mac

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

We had similar report on OSX problems with -rc3.
But in that case building with ./configure --with-readline=builtin
apparently worked.  See bug report 

http://sourceforge.net/tracker/index.php?func=detail&aid=1642845&group_id=2055&atid=102055

Please help us figure out whether this is 1 bug, or 2 bugs, or a 
general problem with gnu libreadline on OSX, or what.

	thanks

		Ethan

On Thursday 25 January 2007 08:08, Jeremy Conlin wrote:
> On 1/25/07, Lars Hecking <lhe...@us...> wrote:
> > [...]
> > > /usr/bin/ld: Undefined symbols:
> > > _remove_history
> > > _rl_forced_update_display
> > > _history_list
> > > _rl_ding
> > > _rl_complete_with_tilde_expansion
> > > collect2: ld returned 1 exit status
> > > make[3]: *** [gnuplot] Error 1
> > > make[2]: *** [all-recursive] Error 1
> > > make[1]: *** [all-recursive] Error 1
> > > make: *** [all] Error 2
> >
> >  This looks like you need to link with GNU readline. Probably a side effect
> >  of defaulting to GNU readline in the latest code (which I'm not convinced
> >  of for licensing reasons).
> >
> Well I wish it was that easy.  I tried linking to the builtin
> readline, that didn't work.  I downloaded and compiled/installed the
> GNU readline and tried linking to that (by letting configure pick the
> defauly and by explicitly selecting GNU readline) and that didn't work
> either.  I get the same errors.
> 
> I have tried this on my MacBook Pro (Intel) and on an older PowerMac
> G4.  Both running Tiger 10.4.8.  Any other suggestions?
> 
> Thanks,
> Jeremy
> 
> ps. Sorry Lars, meant to post this to the list
> 
> -------------------------------------------------------------------------
> 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

Re: Universal binaries for Mac

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

> ./configure --disable-dependency-tracking

What does that option mean? Try
	./configure

---
PM

Re: Universal binaries for Mac

[Jeremy C. <jer...@gm...>]

On 1/25/07, Lars Hecking <lhe...@us...> wrote:
> [...]
> > /usr/bin/ld: Undefined symbols:
> > _remove_history
> > _rl_forced_update_display
> > _history_list
> > _rl_ding
> > _rl_complete_with_tilde_expansion
> > collect2: ld returned 1 exit status
> > make[3]: *** [gnuplot] Error 1
> > make[2]: *** [all-recursive] Error 1
> > make[1]: *** [all-recursive] Error 1
> > make: *** [all] Error 2
>
>  This looks like you need to link with GNU readline. Probably a side effect
>  of defaulting to GNU readline in the latest code (which I'm not convinced
>  of for licensing reasons).
>
Well I wish it was that easy.  I tried linking to the builtin
readline, that didn't work.  I downloaded and compiled/installed the
GNU readline and tried linking to that (by letting configure pick the
defauly and by explicitly selecting GNU readline) and that didn't work
either.  I get the same errors.

I have tried this on my MacBook Pro (Intel) and on an older PowerMac
G4.  Both running Tiger 10.4.8.  Any other suggestions?

Thanks,
Jeremy

ps. Sorry Lars, meant to post this to the list

Re: Universal binaries for Mac

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

[...]
> /usr/bin/ld: Undefined symbols:
> _remove_history
> _rl_forced_update_display
> _history_list
> _rl_ding
> _rl_complete_with_tilde_expansion
> collect2: ld returned 1 exit status
> make[3]: *** [gnuplot] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2

 This looks like you need to link with GNU readline. Probably a side effect
 of defaulting to GNU readline in the latest code (which I'm not convinced
 of for licensing reasons).

Universal binaries for Mac

[Jeremy C. <jer...@gm...>]

Please excuse me for jumping in to this list.  I just downloaded
gnuplot 4.2 rc4 this morning and tried to compile using the
suggestions from Mojca, but it didn't work.  Since this project is
about to release a stable version I thought I would chime in.

I set the following before compiling:

export CFLAGS=3D'-arch i386 -arch ppc'
export LDFLAGS=3D'-arch i386 -arch ppc'
./configure --disable-dependency-tracking

Then when I did:

make

I got the following linking error:

$ make
make  all-recursive
Making all in config
make[2]: Nothing to be done for `all'.
Making all in m4
make[2]: Nothing to be done for `all'.
Making all in term
make[2]: Nothing to be done for `all'.
Making all in src
Making all in wxterminal
make[3]: Nothing to be done for `all'.
gcc -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term
-DBINDIR=3D\"/usr/local/bin\"
-DX11_DRIVER_DIR=3D\"/usr/local/libexec/gnuplot/4.2\"
-DGNUPLOT_PS_DIR=3D\"/usr/local/share/gnuplot/4.2/PostScript\"
-DCONTACT=3D\"gnu...@li...\"
-DHELPFILE=3D\"/usr/local/share/gnuplot/4.2/gnuplot.gih\"   -arch i386
-ObjC -c alloc.c

=85

gcc -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term
-DBINDIR=3D\"/usr/local/bin\"
-DX11_DRIVER_DIR=3D\"/usr/local/libexec/gnuplot/4.2\"
-DGNUPLOT_PS_DIR=3D\"/usr/local/share/gnuplot/4.2/PostScript\"
-DCONTACT=3D\"gnu...@li...\"
-DHELPFILE=3D\"/usr/local/share/gnuplot/4.2/gnuplot.gih\"   -arch i386
-ObjC -c version.c
g++  -g -O2  -arch i386 -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   -lreadline  -lncurses  -lz   -laquaterm
-framework Foundation
/usr/bin/ld: warning multiple definitions of symbol _init_color
color.o definition of _init_color in section (__TEXT,__text)
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libncurses.dylib(lib_color.o=
)
definition of _init_color
/usr/bin/ld: warning multiple definitions of symbol _set_term
term.o definition of _set_term in section (__TEXT,__text)
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libncurses.dylib(lib_set_ter=
m.o)
definition of _set_term
/usr/bin/ld: Undefined symbols:
_remove_history
_rl_forced_update_display
_history_list
_rl_ding
_rl_complete_with_tilde_expansion
collect2: ld returned 1 exit status
make[3]: *** [gnuplot] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

I have installed AquaTerm and everything else is left unchanged.  Can
someone help?  Has a Universal Binary been made available?
Thanks,
Jeremy