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

Re: 4.4 - Nearing the finish line

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

On Monday 08 March 2010 11:04:08 Petr Mikulik wrote:
> I wonder about the pdf documentations. If I compile it by "make pdfimages", 
> I get a gnuplot.pdf of size 2.8 MB. Tatsuro obtained 2.1. The only 
> difference I have found is this almost-empty session in Tatsuro's pdf:

It probably just depends on your latex version.
As built here:

2.2M -rw-rw-r-- 1 merritt merritt 2206047 2010-03-08 12:04 gnuplot.pdf

But the make target is "make pdffigures". I guess that is just a typo?

Re: 4.4 - Nearing the finish line

[Tait <gnu...@t4...>]

> All of them are temporarily here:
>	physics.muni.cz/~mikulik/tmp/gp440.zip
> Ethan, please upload the inner zip files to SourceForge.

I ran wgnuplot.exe on my computer (Windows XP) and it looks like this:
	http://imagebin.ca/img/Z6vled.png

The terminal text is unreadable. Is this unique to me somehow, or do
others see it too?

Tait

Re: 4.4 - Nearing the finish line

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

	Hi all,

I have compiled OS/2 binary package and synchronized it with Tatsuro's
build of Windows and dj2 packages.

All of them are temporarily here:
	physics.muni.cz/~mikulik/tmp/gp440.zip
Ethan, please upload the inner zip files to SourceForge.

Considering Windows, I've put together the "native" Windows terminal with 
the wxt version. Therefore, the default is the wxt terminal on Windows as on 
Linux. I hope Copy-to-clipboard works; then only the Print dialog is missing 
(and maybe user's configurable position&size of the graph windows).

As a result, the Windows binary directory is full of dll's as compared to
single stand-alone executables up to now.


I wonder about the pdf documentations. If I compile it by "make pdfimages", 
I get a gnuplot.pdf of size 2.8 MB. Tatsuro obtained 2.1. The only 
difference I have found is this almost-empty session in Tatsuro's pdf:

3 cairo (pdfcairo, pngcairo, wxt terminals)
?fonts cairo
=fonts
=pdf
=png
=wxt
 Sorry, this section is under construction.
 These terminals find and access fonts using the external fontconfig tool 
 set. Please see the ...

I wonder what's the reason for the rest of 0.7 MB.
Currently, packages
    gp440os2.zip
    gp440win32.zip
contain Tatsuro's version, mine lying outside in gp440.zip is called 
petr_gnuplot.pdf. Ethan, what pdf do you get? If your's version is "more 
complete", please exchange it in the above two files.

Let's enjoy released 4.4,
  Petr

Re: Note for building gd wiwith libpng-1.4

[Tatsuro M. <tma...@ya...>]

Hello

--- Manfred Schwarb wrote:
> > It is already in libgd, see http://bitbucket.org/pierrejoye/gd-libgd-20/
> > 
> > You can get the most recent checkout under
> > http://bitbucket.org/pierrejoye/gd-libgd-20/get/tip.tar.gz
> > 
> > 
> 
> Although recent checkouts do not compile, as configure.ac additions have
> to be made for the latest added test cases:
> Around line 570 of configure.ac, you have to add
>    tests/gdimagefilledpolygon/Makefile
>    tests/gdimageopenpolygon/Makefile
>    tests/gdimagepolygon/Makefile
> 

Thank you for your helpful comments.
I will try the new gd libraries with a new libpng and IJG jpeg libraries.

I will use it on gnuplot 4.5 (CVS) on my web.

Regards

Tatsuro  

--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: 4.4 - Nearing the finish line

[Jonathan T. <jt...@as...>]

On Sunday 07 March 2010, Petr Mikulik wrote:
[[about the postscript prologue]]
# Well, now it seems that now it contains
# SDict begin [
#   /Author (mikulik)
# instead of the previous
#   /Author (Petr Mikulik)
# Is this intended? Shouldn't the /Author line be completely avoided?

On Sun, 7 Mar 2010, sfeam (Ethan Merritt) wrote:
> I don't know.
> There were two issues.
> 
> The static build issue was caused by a call to getpwnam(), which is now gone.
> 
> I suppose listing the user name is still an issue if you want complete
> anonymity, but it no longer includes GECOS information like phone number
> and address so I think it is not so much a privacy concern.

I would rather omit the /Author line entirely (or make it explicitly
configurable via a user option "set identification" (or suchlike)).

-- 
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
   Dept of Astronomy, Indiana University, Bloomington, Indiana, USA
   "C++ is to programming as sex is to reproduction. Better ways might
    technically exist but they're not nearly as much fun." -- Nikolai Irgens

Re: 4.4 - Nearing the finish line

[sfeam (E. Merritt) <eam...@gm...>]

On Sunday 07 March 2010, Petr Mikulik wrote:
> > > I have made those changes to INSTALL and the makefiles for mgw and cygwin.
> > > I will also disable the HAVE_PWD_H option because
> > > (1) Manfred Schwarb has reported here that it causes static build problems
> > > (2) Daniel Loeb has reported on the newsgroup that it introduces privacy issues
> > > (3) It seems like a totally unnecessary bell (or is it a whistle?) that in any case
> > >     is used only by the PostScript and PDF terminal output 
> 
> Well, now it seems that now it contains
> SDict begin [
>   /Author (mikulik)
> instead of the previous
>   /Author (Petr Mikulik)
> Is this intended? Shouldn't the /Author line be completely avoided?

I don't know.
There were two issues.

The static build issue was caused by a call to getpwnam(), which is now gone.

I suppose listing the user name is still an issue if you want complete
anonymity, but it no longer includes GECOS information like phone number
and address so I think it is not so much a privacy concern.

Re: 4.4 - Nearing the finish line

[sfeam (E. Merritt) <eam...@gm...>]

Petr Mikulik <mi...@ph...> wrote:

> There was a discussion about Mac issues recently. Is there any chance that 
> it/they can be also prepared for uploading into sourceforge at the same 
> time?

I don't think so, at least not without delaying 4.4.0 for another couple
of months at least.

The approach to making wxt work on OSX is to split it out into a separate
process, similar to how gnuplot_x11 is a separate process from gnuplot.
But doing that will affect all platforms, not just OSX, so I think it
should get considerable testing before it is placed in the stable version.

Re: 4.4 - Nearing the finish line

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

> > I have made those changes to INSTALL and the makefiles for mgw and cygwin.
> > I will also disable the HAVE_PWD_H option because
> > (1) Manfred Schwarb has reported here that it causes static build problems
> > (2) Daniel L[be][ad][a5][e2]b has reported on the newsgroup that it introduces privacy issues
> > (3) It seems like a totally unnecessary bell (or is it a whistle?) that in any case
> >     is used only by the PostScript and PDF terminal output 

Well, now it seems that now it contains
SDict begin [
  /Author (mikulik)
instead of the previous
  /Author (Petr Mikulik)
Is this intended? Shouldn't the /Author line be completely avoided?

> > I will generate the 4.4.0 source tarball tonight, and the wait for Tatsuro and/or
> > Petr to generate binary packages for windows so that the source and binaries 
> > can be uploaded to SourceForge on the same date.
> 
> Thank you for your taking my proposal account into account.
> I have confirmed the change on the cvs.
> 
> After you will made the source tarball the 4.4.0, I will make the windows, cygwin, djgpp binaries as
> soon as possible.  I will do it on the PC in the university. Because the Internet in my home is still
> narrow band :-( and I am now updating the dependency libraries in the PC in my home.
> (I want use it for gnuplot 4.5 release.)
> 
> For the building 4.4.0, it is better to use the no-updated dependencies, which have been used in a few
> months (probably) without problems, to avoid unexpected errors.
> 
> BTW, I do not have the authorization to upload files to the SourceForge.
> I can make my web page for uploading 4.4.0 binaries.
> Will someone download them and upload to SourceForge?

Please zip all those 3 distributions, put it into you web page and send the 
link to me and Ethan; I will proofread them and check against the previous 
packages provided by me. I will prepare also the OS/2 package.

There was a discussion about Mac issues recently. Is there any chance that 
it/they can be also prepared for uploading into sourceforge at the same 
time?

---
PM

Re: Note for building gd wiwith libpng-1.4

[Manfred S. <man...@gm...>]

Am Sonntag, den 07.03.2010, 12:39 +0100 schrieb Manfred Schwarb:
> Am Sonntag, den 07.03.2010, 11:54 +0900 schrieb Tatsuro MATSUOKA:
> > Hello
> > 
> > This is just a note for those who try to build the libgd with libpng-1.4.
> > 
> > I have update the libpng version of which is 1.4.
> > >>From the libpng-1.4, the function 'png_check_sig' is removed.
> > The change makes the libgd building in failure.
> > 
> > ./.libs/libgd.a(gd_png.o):gd_png.c:(.text+0xd20): undefined reference to `png_check_sig'
> > 
> >   The function png_check_sig can be replaced as 
> >       replace
> >         png_check_sig(buf, 8)
> >       with
> >         png_sig_cmp(buf, 0, 8) == 0
> > http://www.libpng.org/pub/png/src/libpng-1.2.x-to-1.4.x-summary.txt
> > 
> > A patch has been posted the below,
> > http://bugs.libgd.org/?do=details&task_id=218&histring=png_check_sig
> 
> 
> It is already in libgd, see http://bitbucket.org/pierrejoye/gd-libgd-20/
> 
> You can get the most recent checkout under
> http://bitbucket.org/pierrejoye/gd-libgd-20/get/tip.tar.gz
> 
> 

Although recent checkouts do not compile, as configure.ac additions have
to be made for the latest added test cases:
Around line 570 of configure.ac, you have to add
   tests/gdimagefilledpolygon/Makefile
   tests/gdimageopenpolygon/Makefile
   tests/gdimagepolygon/Makefile



> Cheers,
> Manfred
> 
> 
> > 
> > Regards
> > 
> > Tatsuro
> > 
> > --------------------------------------
> > Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
> > http://pr.mail.yahoo.co.jp/ie8/
> > 
> > ------------------------------------------------------------------------------
> > Download Intel® Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Note for building gd wiwith libpng-1.4

[Manfred S. <man...@gm...>]

Am Sonntag, den 07.03.2010, 11:54 +0900 schrieb Tatsuro MATSUOKA:
> Hello
> 
> This is just a note for those who try to build the libgd with libpng-1.4.
> 
> I have update the libpng version of which is 1.4.
> >>From the libpng-1.4, the function 'png_check_sig' is removed.
> The change makes the libgd building in failure.
> 
> ./.libs/libgd.a(gd_png.o):gd_png.c:(.text+0xd20): undefined reference to `png_check_sig'
> 
>   The function png_check_sig can be replaced as 
>       replace
>         png_check_sig(buf, 8)
>       with
>         png_sig_cmp(buf, 0, 8) == 0
> http://www.libpng.org/pub/png/src/libpng-1.2.x-to-1.4.x-summary.txt
> 
> A patch has been posted the below,
> http://bugs.libgd.org/?do=details&task_id=218&histring=png_check_sig


It is already in libgd, see http://bitbucket.org/pierrejoye/gd-libgd-20/

You can get the most recent checkout under
http://bitbucket.org/pierrejoye/gd-libgd-20/get/tip.tar.gz


Cheers,
Manfred


> 
> Regards
> 
> Tatsuro
> 
> --------------------------------------
> Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
> http://pr.mail.yahoo.co.jp/ie8/
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: 4.4 - Nearing the finish line

[Tatsuro M. <tma...@ya...>]

Hello

--- Tatsuro MATSUOKA  wrote:

I have forgotten to mention to the libedit for the cygwin binaries.

>From the statement by the Ethan, 

http://old.nabble.com/Re:-readline-to-gnuplot.exe-(console-mode)-for-windows-p27677233.html

I am now distributing the cygwin binaries linking with libedit and dll libraries that is
Berkeley-style licensed.
The cygwin currently does not support the libedit so that the dll file is attached.
Of course, the copyright documents of libedit is attached according to the notification of
"Redistributions in binary form".

****COPYING of libedit
2. Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the distribution.

Perhaps it is not a problem to make a package with the libedit, I think.
However, there is any complaint to do it, I will not to link with libedit.

Regards

Tatsuro 
 



--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: 4.4 - Nearing the finish line

[Tatsuro M. <tma...@ya...>]

Hello

--- Tatsuro MATSUOKA  wrote:

I have forgotten to mention to the libedit for the cygwin binaries.

>From the statement by the Ethan, 

http://old.nabble.com/Re:-readline-to-gnuplot.exe-(console-mode)-for-windows-p27677233.html

I am now distributing the cygwin binaries linking with libedit and dll libraries that is
Berkeley-style licensed.
The cygwin currently does not support the libedit so that the dll file is attached.
Of course, the copyright documents of libedit is attached according to the notification of
"Redistributions in binary form".

****COPYING of libedit
2. Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the distribution.

Perhaps it is not a problem to make a package with the libedit, I think.
However, there is any complaint to do it, I will not to link with libedit.

Regards

Tatsuro 
 



--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: 4.4 - Nearing the finish line

[sfeam (E. Merritt) <eam...@gm...>]

On Saturday 06 March 2010, Tatsuro MATSUOKA wrote:

> After you will made the source tarball the 4.4.0

I have tagged the CVS tree as Release_4_4_0 and created a tarball.
If you build from CVS as of that tag date it will be identical to my source package.

> I will make the windows, cygwin, djgpp binaries as
> soon as possible.  I will do it on the PC in the university. Because the Internet in my home is still
> narrow band :-( and I am now updating the dependency libraries in the PC in my home.
> (I want use it for gnuplot 4.5 release.)
> 
> For the building 4.4.0, it is better to use the no-updated dependencies, which have been used in a few
> months (probably) without problems, to avoid unexpected errors.
> 
> BTW, I do not have the authorization to upload files to the SourceForge.
> I can make my web page for uploading 4.4.0 binaries.
> Will someone download them and upload to SourceForge?

That would be fine.  Email me when they are ready, and I will place them
on SourceForge at the same time I put the source tarball there.

It seems that the SourceForge automatic indexing system only shows files
loaded on the same day as "Newest Files", so we want to upload everything
at the same time.

	Ethan

> 
> Regards
> 
> Tatsuro
> 
> --------------------------------------
> Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
> http://pr.mail.yahoo.co.jp/ie8/
> 

Re: 4.4 - Nearing the finish line

[Tatsuro M. <tma...@ya...>]

Hello

--- "sfeam (Ethan Merritt)" wrote:
>  
> I have made those changes to INSTALL and the makefiles for mgw and cygwin.
> I will also disable the HAVE_PWD_H option because
> (1) Manfred Schwarb has reported here that it causes static build problems
> (2) Daniel L将モb has reported on the newsgroup that it introduces privacy issues
> (3) It seems like a totally unnecessary bell (or is it a whistle?) that in any case
>     is used only by the PostScript and PDF terminal output 
> 
> I will generate the 4.4.0 source tarball tonight, and the wait for Tatsuro and/or
> Petr to generate binary packages for windows so that the source and binaries 
> can be uploaded to SourceForge on the same date.

Thank you for your taking my proposal account into account.
I have confirmed the change on the cvs.

After you will made the source tarball the 4.4.0, I will make the windows, cygwin, djgpp binaries as
soon as possible.  I will do it on the PC in the university. Because the Internet in my home is still
narrow band :-( and I am now updating the dependency libraries in the PC in my home.
(I want use it for gnuplot 4.5 release.)

For the building 4.4.0, it is better to use the no-updated dependencies, which have been used in a few
months (probably) without problems, to avoid unexpected errors.

BTW, I do not have the authorization to upload files to the SourceForge.
I can make my web page for uploading 4.4.0 binaries.
Will someone download them and upload to SourceForge?

Regards

Tatsuro

--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: 4.4 - Nearing the finish line

[sfeam (E. Merritt) <eam...@gm...>]

   Last call for changes to the 4.4.0 code or docs prior to release

On Friday 05 March 2010, Tatsuro MATSUOKA wrote:

> The Microsoft SDK is  not necessarily required. 
> Only the MS Help Workshop is required as the MS staff.
> 
> In makefile.mgw, and makefile.cyg, make processes are respectively written as,
> 
> # - compile the package: go to directory 'gnuplot' and therefrom run
> #	 make -C src -f ../config/makefile.mgw
> 
> and,
> 
> # - compile the package: go to directory 'gnuplot' and therefrom run
> #	 make -C src -f ../config/makefile.cyg
> **************************************
> 
> I propose that the part is simplified to
> ***************************
> Using the MinGW32 port of gcc, read instruction written in config/makefile.mgw.
> 
> Using the Cygwin port of gcc, read instruction written in config/makefile.cyg.
> ***************************
> 
> It might be better to add 'install' description in makefile.mgw and makefile.cyg,
> # - compile ans install the package: go to directory 'gnuplot' and therefrom run
> #	 make -C src -f ../config/makefile.mgw
> #	 make install -C src -f ../config/makefile.mgw
> 
> Any comments?

Fine by me.
 
I have made those changes to INSTALL and the makefiles for mgw and cygwin.
I will also disable the HAVE_PWD_H option because
(1) Manfred Schwarb has reported here that it causes static build problems
(2) Daniel Löb has reported on the newsgroup that it introduces privacy issues
(3) It seems like a totally unnecessary bell (or is it a whistle?) that in any case
    is used only by the PostScript and PDF terminal output 

I will generate the 4.4.0 source tarball tonight, and the wait for Tatsuro and/or
Petr to generate binary packages for windows so that the source and binaries 
can be uploaded to SourceForge on the same date.

	Ethan
 

Re: bug or feature?

[sfeam (E. Merritt) <eam...@gm...>]

On Saturday 06 March 2010, Allin Cottrell wrote:
> 
> On Sat, 6 Mar 2010, sfeam (Ethan Merritt) wrote:
> 
> > On Saturday 06 March 2010, Allin Cottrell wrote:
> > > > Anyhow, for postscript and for the libgd-based png terminal you should be
> > > > able to get what you want by saying, for example,
> > > >   set term png butt
> > >
> > > Thanks, and Yes, I get that with libgd-png. In fact I get no
> > > spillover with "set term post eps" (without adding "butt")
> >
> > "Butt" is the default for the PostScript terminals.
> 
> Ah, OK. But then shouldn't that be consistent across terminals?

That's one side of the argument.
The other side is that "butt" in libgd produces really ugly lines
unless they are parallel to x or y.  Better to default to the option
that isn't so ugly.   To be fair, I haven't checked to see if libgd
version 2.0.36 is better than earlier versions in this regard.
Perhaps they've fixed it.

IMHO "rounded" is almost always better visually.  The only exception
is when you really do need bars that terminate exactly at some given
coordinate.

Re: bug or feature?

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

On Sat, 6 Mar 2010, sfeam (Ethan Merritt) wrote:

> On Saturday 06 March 2010, Allin Cottrell wrote:
> > > Anyhow, for postscript and for the libgd-based png terminal you should be
> > > able to get what you want by saying, for example,
> > >   set term png butt
> >
> > Thanks, and Yes, I get that with libgd-png. In fact I get no
> > spillover with "set term post eps" (without adding "butt")
>
> "Butt" is the default for the PostScript terminals.

Ah, OK. But then shouldn't that be consistent across terminals?

> > but the
> > appearance of the gray bar is not good: it has horizontal stripes.
>
> That may be a defect in your viewer rather than in the postscript
> output.  If you are viewing in ghostview or gv, try turning off
> the anti-aliasing.

It may be the viewer (gv) but toggling anti-aliasing doesn't make
any difference, and it looks stripey at all magnifications.

Allin Cottrell

Re: bug or feature?

[sfeam (E. Merritt) <eam...@gm...>]

On Saturday 06 March 2010, Allin Cottrell wrote:
> > Anyhow, for postscript and for the libgd-based png terminal you should be
> > able to get what you want by saying, for example,
> >   set term png butt
> 
> Thanks, and Yes, I get that with libgd-png. In fact I get no
> spillover with "set term post eps" (without adding "butt") 

"Butt" is the default for the PostScript terminals. 

> but the
> appearance of the gray bar is not good: it has horizontal stripes.

That may be a defect in your viewer rather than in the postscript
output.  If you are viewing in ghostview or gv, try turning off
the anti-aliasing.

	Ethan

Re: bug or feature?

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

On Sat, 6 Mar 2010, Ethan Merritt wrote:

> On Saturday 06 March 2010, Allin Cottrell wrote:
>
> > But the problem is that
> > setting the linewidth to 30 (to represent the duration of the
> > recession) also causes the ends of the lines to be extended, top
> > and bottom, so they spill out of the graph area. (For terms = png,
> > pngcairo, pdfcairo, at least.)
> >
> > My first reaction is that setting a fat linewidth should not
> > affect the length of the line, but is there some reason why it
> > does so?
>
> This is the convention established by PostScript and followed by
> many other vector-drawing languages.  Lines are drawn as if by
> a pen with a flat, round, or square nib. In the latter two cases
> each line segment is extended by the radius of the nib.
> The corresponding PostScript commands are {0|1|2} setlinecap.
> The corresponding cairo properties are BUTT, ROUND, and SQUARE.
>
> Gnuplot's "set terminal" commands accept "rounded" and "butt" as options.
> Confusingly, the cairo terminal's "butt" option is translated into
> CAIRO_LINE_CAP_SQUARE rather than CAIRO_LINE_CAP_BUTT.
>
> This can be considered a bug :-)
>
> Anyhow, for postscript and for the libgd-based png terminal you should be
> able to get what you want by saying, for example,
>   set term png butt

Thanks, and Yes, I get that with libgd-png. In fact I get no
spillover with "set term post eps" (without adding "butt") but the
appearance of the gray bar is not good: it has horizontal stripes.

However, I've come to a better way to control the recession bars,
namely by adding the peaks and troughs as data and plotting them
using 1:2:3 with filledcurve.

Allin Cottrell

Note for building gd wiwith libpng-1.4

[Tatsuro M. <tma...@ya...>]

Hello

This is just a note for those who try to build the libgd with libpng-1.4.

I have update the libpng version of which is 1.4.
>From the libpng-1.4, the function 'png_check_sig' is removed.
The change makes the libgd building in failure.

./.libs/libgd.a(gd_png.o):gd_png.c:(.text+0xd20): undefined reference to `png_check_sig'

  The function png_check_sig can be replaced as 
      replace
        png_check_sig(buf, 8)
      with
        png_sig_cmp(buf, 0, 8) == 0
http://www.libpng.org/pub/png/src/libpng-1.2.x-to-1.4.x-summary.txt

A patch has been posted the below,
http://bugs.libgd.org/?do=details&task_id=218&histring=png_check_sig

Regards

Tatsuro

--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: bug or feature?

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

On Saturday 06 March 2010, Allin Cottrell wrote:

> But the problem is that
> setting the linewidth to 30 (to represent the duration of the
> recession) also causes the ends of the lines to be extended, top
> and bottom, so they spill out of the graph area. (For terms = png,
> pngcairo, pdfcairo, at least.)
> 
> My first reaction is that setting a fat linewidth should not
> affect the length of the line, but is there some reason why it
> does so?

This is the convention established by PostScript and followed by
many other vector-drawing languages.  Lines are drawn as if by
a pen with a flat, round, or square nib. In the latter two cases
each line segment is extended by the radius of the nib. 
The corresponding PostScript commands are {0|1|2} setlinecap.
The corresponding cairo properties are BUTT, ROUND, and SQUARE.

Gnuplot's "set terminal" commands accept "rounded" and "butt" as options. 
Confusingly, the cairo terminal's "butt" option is translated into 
CAIRO_LINE_CAP_SQUARE rather than CAIRO_LINE_CAP_BUTT.

This can be considered a bug :-)

Anyhow, for postscript and for the libgd-based png terminal you should be
able to get what you want by saying, for example,
  set term png butt

For the cairo terminals, it seems a bit late in the day to change
things for 4.4.0 but we can look at it after the release.  Probably
we should expose all three options to the user. We could do that
for post.trm also.

	Ethan

> (Or maybe a better question is, is there a better way of doing
> what I'm trying to do?)

bug or feature?

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

I'm trying to plot "recessions bars" (i.e. shaded vertical bars
indicating peak-to-trough of a recession) on an economic time
series graph.  I can get roughly the right effect by doing:

set style line 6 lc rgb "#dddddd" lw 30
set style increment user
set arrow from 1980.5,1600 to 1980.0,3400 nohead back lt 6
plot <data>

(where the y-range is 1600 to 3400). But the problem is that
setting the linewidth to 30 (to represent the duration of the
recession) also causes the ends of the lines to be extended, top
and bottom, so they spill out of the graph area. (For terms = png,
pngcairo, pdfcairo, at least.)

My first reaction is that setting a fat linewidth should not
affect the length of the line, but is there some reason why it
does so?

(Or maybe a better question is, is there a better way of doing
what I'm trying to do?)

Allin Cottrell

Re: 4.4 - Nearing the finish line [was Re: inconsistency between 4.4-cvs and 4.5 for default install]

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

On Saturday 06 March 2010, Manfred Schwarb wrote:
> > So I certainly believe you that your machine is trying to pull in
> > libexpat, but I don't know where/why this dependency creeps in.
> > One of life's little mysteries :-)
> > 
> 
> I did some digging, it seems you can build libfontconfig either with
> libexpat or with libxml2, at your will.
> My distribution (OpenSuse) decided to build libfontconfig with
> "configure --enable-libxml2=no", so that libexpat is used.
> No idea why they did like this.
>  
> What is your "gdlib-config --libs" output? Does it mention "-lxml2"?
> So then only the libexpat case would be broken.
> 
stonelion [386] gdlib-config --libs
-lXpm -lX11 -ljpeg -lfontconfig -lfreetype -lpng12 -lz -lm

Re: 4.4 - Nearing the finish line [was Re: inconsistency between 4.4-cvs and 4.5 for default install]

[Manfred S. <man...@gm...>]

Am Freitag, den 05.03.2010, 16:25 -0800 schrieb Ethan Merritt:
> On Friday 05 March 2010 15:50:48 Manfred Schwarb wrote:
> > 
> > > On Friday 05 March 2010 14:05:14 Manfred Schwarb wrote:
> > > > > > and had to apply
> > > > > > 
> > > > > > --- configure.in.orig   2010-03-01 13:44:59.000000000 +0100
> > > > > > +++ configure.in        2010-03-02 11:55:43.000000000 +0100
> > > > > > @@ -482,6 +482,7 @@
> > > > > >      libgd_CPPFLAGS=`gdlib-config --cflags`
> > > > > >      libgd_LDFLAGS=`gdlib-config --ldflags`
> > > > > >      libgd_LIBS=`gdlib-config --libs`
> > > > > > +    libgd_LIBS="$libgd_LIBS -lexpat -pthread"
> > > > > >    elif test -d "$with_gd"; then
> > > > > >      libgd_CPPFLAGS="-I$with_gd/include"
> > > > > >      libgd_LDFLAGS="-L$with_gd/lib"
> > > > > 
> > > > > That seems like a problem with the libgd package configuration tool.
> > > > > I'll forward a bug report in that direction if I can confirm it.
> > > > > 
> > > > > 	Ethan
> > > 
> > > I can't reproduce this problem. 
> > > 
> > > On my machines, neither libgd nor gnuplot as a whole requires libexpat,
> > > which seems to be an XML parsing tool.
> > > 
> > 
> > I think it comes from libfontconfig, newer libgd versions use it
> > (I use some cvs version of libgd 2.0.36 at the moment):
> > 
> > # ldd /usr/lib64/libfontconfig.so
> >         linux-vdso.so.1 =>  (0x00007fc1d544d000)
> >         libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fc1d4f90000)
> >         libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fc1d4d66000)
> >         libc.so.6 => /lib64/libc.so.6 (0x00007fc1d4a0b000)
> >         libz.so.1 => /lib64/libz.so.1 (0x00007fc1d47f5000)
> >         /lib64/ld-linux-x86-64.so.2 (0x00007fc1d544e000)
> > 
> > # ldd /usr/local/lib/libgd.so
> >         linux-vdso.so.1 =>  (0x00007fff9caea000)
> >         libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00007fa27ef78000)
> >         libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007fa27ed42000)
> >         libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fa27eabc000)
> >         libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00007fa27e894000)
> >         libz.so.1 => /lib64/libz.so.1 (0x00007fa27e67d000)
> >         libm.so.6 => /lib64/libm.so.6 (0x00007fa27e428000)
> >         libc.so.6 => /lib64/libc.so.6 (0x00007fa27e0cd000)
> >         libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fa27dea3000)
> >         /lib64/ld-linux-x86-64.so.2 (0x00007fa27f3e7000)
> 
> Huh.  I also am using libgd 2.0.36, built from source.
> It does link to libfreetype and to libfontconfig, but nowhere in the chain
> is there a dependence on libexpat:
> 
> stonelion [3] ldd /home/local/src/gd-2.0.36/.libs/libgd.so.2
>         linux-gate.so.1 =>  (0xffffe000)
>         libXpm.so.4 => /usr/lib/libXpm.so.4 (0xb7851000)
>         libX11.so.6 => /usr/lib/libX11.so.6 (0xb771f000)
>         libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb76fc000)
>         libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb76c8000)
>         libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7644000)
>         libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7619000)
>         libz.so.1 => /lib/libz.so.1 (0xb7606000)
>         libm.so.6 => /lib/i686/libm.so.6 (0xb75de000)
>         libc.so.6 => /lib/i686/libc.so.6 (0xb747d000)
>         libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb745f000)
>         libdl.so.2 => /lib/libdl.so.2 (0xb7459000)
>         libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb7318000)
>         /lib/ld-linux.so.2 (0xb78c0000)
>         libXau.so.6 => /usr/lib/libXau.so.6 (0xb7314000)
>         libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb730d000)
> stonelion [4] ldd /usr/lib/libfontconfig.so.1
>         linux-gate.so.1 =>  (0xffffe000)
>         libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb762e000)
>         libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb74ed000)
>         libc.so.6 => /lib/i686/libc.so.6 (0xb738c000)
>         libz.so.1 => /lib/libz.so.1 (0xb7379000)
>         libdl.so.2 => /lib/libdl.so.2 (0xb7373000)
>         libm.so.6 => /lib/i686/libm.so.6 (0xb734b000)
>         /lib/ld-linux.so.2 (0xb7700000)
> stonelion [5] ldd /usr/lib/libxml2.so.2
>         linux-gate.so.1 =>  (0xffffe000)
>         libdl.so.2 => /lib/libdl.so.2 (0xb7637000)
>         libz.so.1 => /lib/libz.so.1 (0xb7624000)
>         libm.so.6 => /lib/i686/libm.so.6 (0xb75fc000)
>         libc.so.6 => /lib/i686/libc.so.6 (0xb749b000)
>         /lib/ld-linux.so.2 (0xb7798000)
> stonelion [6] ldd /usr/lib/libfreetype.so.6
>         linux-gate.so.1 =>  (0xffffe000)
>         libz.so.1 => /lib/libz.so.1 (0xb7762000)
>         libc.so.6 => /lib/i686/libc.so.6 (0xb7601000)
>         /lib/ld-linux.so.2 (0xb7813000)
> 
> So I certainly believe you that your machine is trying to pull in
> libexpat, but I don't know where/why this dependency creeps in.
> One of life's little mysteries :-)
> 

I did some digging, it seems you can build libfontconfig either with
libexpat or with libxml2, at your will.
My distribution (OpenSuse) decided to build libfontconfig with
"configure --enable-libxml2=no", so that libexpat is used.
No idea why they did like this.
 
What is your "gdlib-config --libs" output? Does it mention "-lxml2"?
So then only the libexpat case would be broken.

For the pthreads thing, perhaps this is dependent on the glibc 
and/or gcc used, in my case it is glibc 2.10.1 and gcc 4.4.1.


Manfred


> 	cheers,
> 		Ethan
> 
> 
> 
> > 
> > But "gdlib-config --libs" gives:
> > -ljpeg -lfontconfig -lfreetype -lpng12 -lz -lm
> > 
> > So it seems libgd does not add all needed libraries to gdlib-config.
> > 
> > 
> > > And libpthread is pulled in by practically everything, so adding it
> > > specifically to libgd_LIBS is redundant.
> > > 
> > > What was the error message you got before adding this line to
> > > configure.in?
> > > 
> > 
> > 
> > from config.log:
> > configure:11686: checking for gdImageStringFT in -lgd
> > configure:11721: gcc  -o conftest -g -O2  -I/usr/local/include -static -s -L/usr/local/lib -L/usr/lib64 -L/lib conftest.c -lgd  -lm  -ljpeg -lfontconfig -lfreetype -lpng12 -lz -lm -ljpeg -lfreetype >&5
> > /usr/local/lib/libgd.a(gdft.o): In function `gdFontCacheSetup':
> > /tmp/libgd/gd-libgd-20/gdft.c:826: undefined reference to `pthread_mutex_init'
> > /tmp/libgd/gd-libgd-20/gdft.c:829: undefined reference to `pthread_mutex_destroy'
> > ...
> > /usr/lib64/libfontconfig.a(fcxml.o): In function `FcConfigMessage':
> > /tmp/fontconfig-2.7.0/fontconfig-2.7.0/src/fcxml.c:476: undefined reference to `XML_GetCurrentLineNumber'
> > /tmp/fontconfig-2.7.0/fontconfig-2.7.0/src/fcxml.c:479: undefined reference to `XML_GetCurrentLineNumber'
> > ...
> > 
> > 
> > Cheers, Manfred

Re: 4.4 - Nearing the finish line [was Re: inconsistency between 4.4-cvs and 4.5 for default install]

[Tatsuro M. <tma...@ya...>]

Hello

--- "sfeam (Ethan Merritt)"wrote:

> 
> Although I think a 4.4.0 release is nearly ready, I have encountered
> a couple of last-minute glitches.
> 
> 1) Sometime between the 4.4.0-rc1 tarball creation and the current 
>    4.4 cvs, the targets "make clean" and "make distclean" have broken.
> 
>    This is just really strange.  It doesn't stop you from building and
>    installing the program - but you can't clean up afterwards.
>    And it causes packaging errors from "make distcheck".
> 
> 2) The x11 app-defaults file
> On Saturday 20 February 2010, Hans-Bernhard Br将モker wrote:
> > Ethan Merritt wrote:
> > > It seems that no matter where the X11 resources file is installed,
> > > there are complaints.
> > > 
> > Or install it under ${pkgdatadir}, and let users decide what to about it.
> 
>   I've now changed it to install under ${pkgdatadir} and put notes in 
>   INSTALL and NEWS.

I would like to express strong appreciation of your efforts.

I have read the INSTALL. 
Installation from sources --> MS-Windows

**********************
Using the MinGW32 port of gcc: you need parts of the Micrsoft SDK for the
moment.
      copy ..\config\makefile.mgw makefile
  Look through the Makefile to see if you need to make any changes.
      make 
      make install

Using the Cygwin port of gcc, which includes MinGW32: you need parts of
the Microsoft SDK for the moment.
      copy ..\config\makefile.cyg makefile
  Look through the Makefile to see if you need to make any changes.
      make
******************************************

The Microsoft SDK is  not necessarily required. 
Only the MS Help Workshop is required as the MS staff.

In makefile.mgw, and makefile.cyg, make processes are respectively written as,

# - compile the package: go to directory 'gnuplot' and therefrom run
#	 make -C src -f ../config/makefile.mgw

and,

# - compile the package: go to directory 'gnuplot' and therefrom run
#	 make -C src -f ../config/makefile.cyg
**************************************

I propose that the part is simplified to
***************************
Using the MinGW32 port of gcc, read instruction written in config/makefile.mgw.

Using the Cygwin port of gcc, read instruction written in config/makefile.cyg.
***************************

It might be better to add 'install' description in makefile.mgw and makefile.cyg,
# - compile ans install the package: go to directory 'gnuplot' and therefrom run
#	 make -C src -f ../config/makefile.mgw
#	 make install -C src -f ../config/makefile.mgw


Any comments?

Regards

Tatsuro
 

--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/