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

Re: [Gnuplot-bugs] cgm terminal font size for gnuplot 4.3

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

tma...@ya... wrote:

> I changed 'set term cgm mono font 'times' 16'.

Looks like the change to the new syntax for font/size specification 
meant to be common to all terminals:

	set term cgm mono font 'times,16'

has broken parsing of the old-style

	"<font>" <size>

syntax in the CGM driver.  I suspect the 'break;' statement in the 
default case.

[CCed to the developers' mailing list...]

Re: Consistent naming scheme for cairo-based terminals

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

On Tue, 2 Oct 2007, Allin Cottrell wrote:

> On Sun, 30 Sep 2007, Petr Mikulik wrote:
> 
> > > So I propose that we rename the two cairo based terminals, and any future 
> > > ones, to use instead the names
> > > 	set term pdfcairo
> > > 	set term pngcairo
> > 
> > I like this naming as well.
> 
> Hmm.  Given the pace of gnuplot development at present (in itself, 
> very good) it seems that quite a few people are using CVS gnuplot.
> So backward-incompatible changes (even just backward-incompatible 
> with prior CVS) seems to me better avoided, if possible.

Being in CVS only, there is no problem to rename a feature. Once released in 
a tar ball, then it would become a problem. CVS is mainly for testing.

The cairo terminal is very new.

> Is it the case that having multiple drivers for a given target 
> format (PDF, PNG) is a temporary, transitional phenomenon?  I 
> would rather hope so.  But in that case, do we really want to do 
> what Ethan is suggesting?  In other words, it seems a bad 
> precedent to have "terminals" named "<format><altdriver>".

I think people want "command" compatibility. So whatever library is compiled 
in, "set term pdf" should work. If there are multiple possibilities then it 
is better to say explicitly "set term pdfcairo | pdflib | pdflibharu" ... 
but the user must know what he is doing. Having to know which library was 
built for setting pdf terminal makes scripts difficult or non-portable.

What needs to be ensured is that both pdflib and pdfcairo terminals take the 
same options (but they can (silently? warning?) ignore some of them).

---
PM

Re: Consistent naming scheme for cairo-based terminals

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

On Tuesday 02 October 2007 17:08, Allin Cottrell wrote:
> On Sun, 30 Sep 2007, Petr Mikulik wrote:
> 
> > > So I propose that we rename the two cairo based terminals, and any future 
> > > ones, to use instead the names
> > > 	set term pdfcairo
> > > 	set term pngcairo
> > 
> > I like this naming as well.
> 
> Hmm.  Given the pace of gnuplot development at present (in itself, 
> very good) it seems that quite a few people are using CVS gnuplot.
> So backward-incompatible changes (even just backward-incompatible 
> with prior CVS) seems to me better avoided, if possible.

The cairo+png terminal isn't even in CVS yet.
The cairo+pdf terminal just went in a month or so back, and is
not yet production-ready.  It's easy enough to make "cairopdf"
recognized as a synonym if necessary.

> Is it the case that having multiple drivers for a given target 
> format (PDF, PNG) is a temporary, transitional phenomenon?  

I don't know.  

You are correct that it is a nuisance. For the last 4 years there
have been two PNG drivers, mostly because for unknown reasons various
linux distributions didn't switch over to the libgd-based driver even
though the distro itself ships libgd.  I hope we've quashed that for
4.2 by deleting the older driver from the tree.


But the choice of pdf drivers is a somewhat different story.
At the moment the pdflib-based terminal is more capable, but it isn't
all that widespread because the licensing restrictions prevent its
being bundled into pre-built binaries.
For now I think people who build their own may want to stick with
pdflib, while the bundlers would happily include the cairo version
in order to provide pdf output even if it is imperfect.
And then there are the developers, who may want both drivers 
available in the same build in order to compare their output.

> I would rather hope so.  But in that case, do we really want to do 
> what Ethan is suggesting?  In other words, it seems a bad 
> precedent to have "terminals" named "<format><altdriver>".

I'm open to other suggestions. But this one has the virtue that
you would only have to type "set term pdf" even if the full name
is "set term pdfcairo".  So your scripts would work no matter 
which of the pdf terminals was present, subject of course to any
limitations in what features are supported.

-- 
Ethan A Merritt  

Re: Consistent naming scheme for cairo-based terminals

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

On Sun, 30 Sep 2007, Petr Mikulik wrote:

> > So I propose that we rename the two cairo based terminals, and any future 
> > ones, to use instead the names
> > 	set term pdfcairo
> > 	set term pngcairo
> 
> I like this naming as well.

Hmm.  Given the pace of gnuplot development at present (in itself, 
very good) it seems that quite a few people are using CVS gnuplot.
So backward-incompatible changes (even just backward-incompatible 
with prior CVS) seems to me better avoided, if possible.

Is it the case that having multiple drivers for a given target 
format (PDF, PNG) is a temporary, transitional phenomenon?  I 
would rather hope so.  But in that case, do we really want to do 
what Ethan is suggesting?  In other words, it seems a bad 
precedent to have "terminals" named "<format><altdriver>".

Allin Cottrell

Re: Consistent naming scheme for cairo-based terminals

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

> So I propose that we rename the two cairo based terminals, and any future 
> ones, to use instead the names
> 	set term pdfcairo
> 	set term pngcairo

I like this naming as well.

---
PM

Re: Consistent naming scheme for cairo-based terminals

[Peter D. <pc...@wi...>]

> If would also be nice to merge the file .../term/cairopng.trm into
> cairo.trm so that the code can be shared.

My thoughts exactly; I was even thinking of creating a cairo
super-terminal with a driver parameter: `set term cairo
{png|pdf|...}'.

That way, `pngcairo' would be an alias for `cairo png'; and the
abstract `cairo' terminal could fall back on some documented default,
like pdf.

Consistent naming scheme for cairo-based terminals

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

I have been playing with the cairopng terminal (see 
<http://skuld.bmsc.washington.edu/people/merritt/gnuplot/demo_cairopng/> 
and of course we have the cairopdf terminal already in cvs.

Both work OK whether or not the corresponding alternative libgd and pdflib 
terminals are also present.  If all four are present then it doesn't seem 
so bad to have to type "pdf", "png", "cairopdf", and "cairopng", although 
it is somewhat annoying to have to type 7 characters to distinguish 
cairopdf from cairopng.

But if you build *only* the cairo-based terminals, then the naming scheme 
seems counterproductive.  People will expect "set term png" to work, but 
instead they must type "set term cairopng".

So I propose that we rename the two cairo based terminals, and any future 
ones, to use instead the names
	set term pdfcairo
	set term pngcairo
and so on.  This has the advantage that if no separate "png" driver is 
present, then "set term png" is unambiguous and will select the pngcairo 
driver instead.  If the libgd-based png driver *is* present, then you must 
type at "set term pngc" to select the cairo-based alternative, but that's 
still shorter than having to type 7 or more characters as you must do now.

This requires changing:
 - the name of the terminal in the corresponding TERM_TABLE entry  
 - the name of the terminal in the docs
 - the test in term.c (change_term) so that it is legal to have one
   terminal name be a leading substring of another.

Proposed patch uploaded to SourceForge.

If would also be nice to merge the file .../term/cairopng.trm into 
cairo.trm so that the code can be shared.  If for some reason that is not 
possible, then it would be logical to rename cairo.trm to cairopdf.trm.
But the patch does neither of these things.

Any objections or better suggestions?

	Ethan

Re: [Gnuplot-info] pm3d problem

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

On Thursday 27 September 2007 12:17, Hans-Bernhard Br=F6ker wrote:
> Henry S. Alken wrote:
>=20
> set term postscript enhanced
> set out "test.ps"
> set pm3d map
> set samples 100
> set isosamples 100
> set palette gray
> set palette gamma 0.5
> splot sin(sqrt(x**2 + y**2))/sqrt(x**2 + y**2)
>
> > -- and I look at the file test.ps, the plot looks worse than the x11
> > version -- there are white grid lines throughout the image making it lo=
ok
> > pretty bad. Does anyone know how to get rid of these ugly grid lines?
>=20
> Turn off antialiasing in ghostscript, and they'll be gone.
>=20
> [CC to -beta]
>=20
> Gents, hadn't we fixed this a *long* time ago?

=46or what it's worth, the postscript plot output from 4.2.2 using those
commands produces no white grid line artifacts when viewed here
via ghostscript version 8.15.3 and gv version 3.6.1.
Toggling the anti-aliasing does not visibly change the rendered image.

The current ghostscript viewing glitches that I know about are:

1) Pattern fill areas are invisible unless you turn off antialiasing.

2) solid-fill areas made up of many adjacent rectangles, e.g. the
   colorbar in a pm3d plot, sometimes suffer from spurious grid lines.
   I do not know the cause of the "sometimes", but suspect it is due
   to different ghostscript versions.  These lines are rendering
   artifacts, not coordinate errors in the file.  They shift in position
   as you change the viewer magnification setting.

Both are known ghostscript bugs, and I don't know of any easy way to
fix things on our end.  We have speculated that using a scaled matrix
operation (as used in the "with image" code) to draw the colorbar all
in one go might work around the problem, but nobody has coded it up to
confirm this.

=2D-=20
Ethan A Merritt

Re: [Gnuplot-info] pm3d problem

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

Henry S. Alken wrote:

> -- and I look at the file test.ps, the plot looks worse than the x11
> version -- there are white grid lines throughout the image making it look
> pretty bad. Does anyone know how to get rid of these ugly grid lines?

Turn off antialiasing in ghostscript, and they'll be gone.

[CC to -beta]

Gents, hadn't we fixed this a *long* time ago?

patch for ISO8859-9 support

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

I've just submitted a patch that adds support for ISO8859-9.  This 
should be useful for people producing PostScript output with 
Turkish titles.

set encoding iso_8859_9
set term post eps
set title "<Turkish text>" ...

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

Re: sprintf bug 4.2.2

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

On Friday 07 September 2007 04:22, Richard Henwood wrote:
> Hi folks,
> 
> Gnuplot 4.2.2 crashes when I do the following:
> 
> test = sprintf("%d %d %d %d %d %d %d %d %d %d", 1, 1, 1, 1, 1, 1, 1, 1, 1, 1)
> 
> it works fine on 4.3 from CVS

Sure.  
Only a selected few fixes or improvements to 4.3 (CVS) were simultaneously
back-ported to 4.2.  That particular fix wasn't flagged as being critical,
so it was only applied to CVS.  I can back-port it to the 4.2 tree,
where it would eventually appear in 4.2.3 if there ever is such a release.
But there may well not be.

	Ethan

-- 
Ethan A Merritt

Re: cairopng terminal [submitted]

[Peter D. <pc...@wi...>]

> [W]e should make our best to share the code between the various cairo*
> terminals . . .

That occured to me, too; it should be possible to abstract a set of
utilities that accept, say, a cairo_surface_t and a render-function
(like cairo_surface_write_to_png).

> Does this mean that cairopng could be made the default 'png'
> terminal?

Ideally, it will act as a drop-in replacement.

> [M]aybe it's time to talk with gd people, who have been
> talking about interfacing gd and cairo . . .

Do you have a link, by any chance?

Re: cairopng terminal [submitted]

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

Peter Danenberg wrote:
>> [I]t still piggybacks, however, on the cairopdf terminal.
>>     
>
> I broke down and created a bona fide cairopng terminal based on
> Timothee's cairopdf with trivial enhancements; it can be used with:
>
>     set terminal cairopng
>
> I also submitted it to sourceforge.*
>
>   
Hi Peter !

I'm happy to see you working on this, and having success in adapting 
cairopdf to write png. It's a good proof that the cairopdf terminal is 
to some extent understandable ;) and that cairo itself is well designed 
since few modifications were required.

Here are a few remarks:
- first, if it is agreed to included this cairopng terminal, we should 
make our best to share the code between the various cairo* terminals 
(pdf and png currently, but it could be svg and ps too). At least the 
help text, which is also shared with wxt, and maybe more of the code.
- second, the most obvious advantage of this terminal is its 
antialiasing, which gd doesn't have at the same level. Does this mean 
that cairopng could be made the default 'png' terminal ?
- third, maybe it's time to talk with gd people, who have been talking 
about interfacing gd and cairo, so that we could draw with cairo and 
export to as many format as gd supports.

Best regards,

Timothée

Re: cairopng terminal [submitted]

[Peter D. <pc...@wi...>]

> [I]t still piggybacks, however, on the cairopdf terminal.

I broke down and created a bona fide cairopng terminal based on
Timothee's cairopdf with trivial enhancements; it can be used with:

    set terminal cairopng

I also submitted it to sourceforge.*

-----------
  * http://sourceforge.net/tracker/index.php?func=detail&aid=1795644&group_id=2055&atid=302055

Re: cairopng terminal

[Peter D. <pc...@wi...>]

> It turns out that hack was insufficient, among other things, for
> multiplots[.]

The attached patch works for multiplots without requiring
post-processing; it still piggybacks, however, on the cairopdf
terminal.

Re: cairopng terminal

[Peter D. <pc...@wi...>]

> I finally got around to implementing a quick and dirty cairopng hack
> that Timothée intimated in March[.]

It turns out that hack was insufficient, among other things, for
multiplots; the attached patch implements multiplots as a successive
sequence of PNGs in the form <filename>-#.png.

The resultant PNGs can be composed with something like:

    convert plot-0.png plot-1.png -composite plot-2.png -composite plot.png

Is there any advantage over the simple `convert plot.pdf plot.png'?
The image quality, above all, seems to be superior to the naive
conversion.

cairopng terminal

[Peter D. <pc...@wi...>]

I finally got around to implementing a quick and dirty cairopng hack
that Timothée intimated in March:*

diff -ru gnuplot-orig/term/cairo.trm gnuplot/term/cairo.trm
--- gnuplot-orig/term/cairo.trm 2007-09-13 23:12:53.000000000 -0700
+++ gnuplot/term/cairo.trm      2007-09-13 23:15:01.000000000 -0700
@@ -374,6 +374,7 @@

        /* finish the page - cairo_destroy still has to be called for the whole documentation
         * to be written */
+        cairo_surface_write_to_png(cairo_get_target(plot.cr), outstr);
        cairo_show_page(plot.cr);

        FPRINTF((stderr,"status =
        %s\n",cairo_status_to_string(cairo_status(plot.cr))));


Problem is, it still produces a redundant PDF which gets truncated by
the PNG; how to go about suppressing the PDF output?

-----------
  * http://sourceforge.net/mailarchive/message.php?msg_name=45F1A71F.6010506%40ens.fr

Re: embedding gnuplot x window into gtk app

[Egil A. <egi...@ya...>]

> Hello,
>  I have been developing a GTK application and I am now using GnuPlot to
> create some graphical output.
>
>  I was hoping to embed the gnuplot x window results into my GTK
> application.
> So far I have been unable to do that can anyone give me any tips on how I
> would go about this?
>
> Thanks,
>
> Kiran

Hi!

There is actually an easier way to achieve this. First create an Gtk::Socket
and add it to your widget. Then pass the socket ID (as hex) to gnuplot 'set
terminal x11 window "ID"'. And that's it!

Cheers!
Egil Andersson


-- 
View this message in context: http://www.nabble.com/embedding-gnuplot-x-window-into-gtk-app-tf4103801.html#a12582225
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

sprintf bug 4.2.2

[Richard H. <r.h...@rl...>]

Hi folks,

Gnuplot 4.2.2 crashes when I do the following:

test = sprintf("%d %d %d %d %d %d %d %d %d %d", 1, 1, 1, 1, 1, 1, 1, 1, 1, 1)

test = sprintf("%d %d %d %d %d %d %d %d %d", 1, 1, 1, 1, 1, 1, 1, 1, 1)
works, however.
and it works fine on 4.3 from CVS

my install:
      G N U P L O T
        Version 4.2 patchlevel 2
        last modified 31 Aug 2007
        System: Linux 2.6.18.8-0.5-default

I think I posted this problem before. If so, apologies. 
r,

Re: mirroring for www.gnuplot.info

[Clark G. <cga...@vt...>]

Petr Mikulik wrote:
> Changes to gnuplot.sourceforge.net have not propagated to www.gnuplot.info 
> after more than 24 hours. Could somebody check the mirroring?
>
> The gnuplot 4.2.2 announcement should be available there.
>   

I think this was a just a matter of the timing of the synchronization. I
have had problems with too-frequent synchronizations from sourceforge,
so the sync was set up to be performed every few days. The mirroring was
working fine; it just hadn't happened yet.

In the past, SF was friendlier to more frequent syncs when using rsync.
As a result of your inquiry, I've implemented that (rather than the wget
approach we have been using) and increased the frequency to twice/day.
Please don't hesitate to contact me if you observe any issues in the future.

--ckg

mirroring for www.gnuplot.info

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

Changes to gnuplot.sourceforge.net have not propagated to www.gnuplot.info 
after more than 24 hours. Could somebody check the mirroring?

The gnuplot 4.2.2 announcement should be available there.

---
PM

Re: zooming of inline data

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

> > I propose to commit your patch into cvs for both 4.2 and 4.3. This will 
> > allow us to use the mousing functionality immediately. (I thought his has 
> > already happen.) 
> 
> I can apply the patch to CVS over the weekend. But I will be travelling
> for the next 3 weeks, and will not be able to deal with any fallout or breakage.

I see you have applied it already. I confirm it work with Octave 2.9.x.

> Unfortunately, neither my patch nor Daniel's will apply directly against 4.2.
> Both are large enough changes that I would worry about seriously breaking
> something in 4.2 if there is a rush to back-port the new code.
> 
> To replace the old zooming code and then back-port the "refresh" 
> implementation is way more than I could do quickly.  Let's get it into CVS 
> so that it sees some testing over the next few months.  At that point we 
> can decide whether it's solid enough and worth another 4.2.x release. At 
> least a few of the Octave users should be willing to build gnuplot from 
> cvs, and that will hopefully provide more immediate testing than new 
> features often get.
> 
> Or if you take the lead in backporting to 4.2 and thorough testing,
> maybe it could be done more quickly?

Sorry, I cannot do anything till the end of September.

So let us propose 4.3 (cvs) for Octave users. Then, you would either make 
the patch ready for 4.2.n, or it would force an early release of 4.4.

---
PM

Re: zooming of inline data

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

On Friday 31 August 2007 01:44, Petr Mikulik wrote:
> I propose to commit your patch into cvs for both 4.2 and 4.3. This will 
> allow us to use the mousing functionality immediately. (I thought his has 
> already happen.) 

I can apply the patch to CVS over the weekend. But I will be travelling
for the next 3 weeks, and will not be able to deal with any fallout or breakage.

Unfortunately, neither my patch nor Daniel's will apply directly against 4.2.
Both are large enough changes that I would worry about seriously breaking
something in 4.2 if there is a rush to back-port the new code.

> It would be a good reason for releasing gnuplot 4.2.2 (also 
> with a bugfix to xylabels as reported today).

I think I will have to release a quick 4.2.2 anyhow, because the lack of 
axis labels is indeed serious.  But that is a two-line fix.  To replace
the old zooming code and then back-port the "refresh" implementation
is way more than I could do quickly.  Let's get it into CVS so that it
sees some testing over the next few months.  At that point we can decide
whether it's solid enough and worth another 4.2.x release.
At least a few of the Octave users should be willing to build gnuplot
from cvs, and that will hopefully provide more immediate testing than
new features often get.

Or if you take the lead in backporting to 4.2 and thorough testing,
maybe it could be done more quickly?

	Ethan


> > > I thought that Ethan has already committed his patch
> > >     [ 1723715 ] Refresh plot or zoom without re-reading data
> > > and that it was released in 4.2.1, but it is not the case.
> > > What was the reason of not putting it into cvs (see 2007-07-01 04:36)?
> > > 
> > > 
> > > There is also this patch
> > >     [ 1745865 ] store raw data to refresh plot without rereading files
> > > which is somehow similar in results (but caches all datafiles).
> > > 
> > > 
> > > So, how to continue? Zooming of inline data is really important (and not 
> > > only for Octave users).
> > 
> > Good question.  I don't know the correct answer.
> > 
> > My patch 1723715 is imperfect, as Daniel Sebald pointed out.
> > One imperfection is that is does not allow toggling log scale axes.
> > One positive feature is that it requires no additional internal
> > storage or data structures.
> 
> I propose to commit your patch into cvs for both 4.2 and 4.3. This will 
> allow us to use the mousing functionality immediately. (I thought his has 
> already happen.) It would be a good reason for releasing gnuplot 4.2.2 (also 
> with a bugfix to xylabels as reported today).
> 
> > Daniel's alternative patch  174865 creates a new set of internal storage
> > buffers and saves all the input data for later re-use.
> > 
> > We also discussed the option of re-writing the log scale code so that
> > the original data is stored rather than rescaled data.
> 
> Both are more serious changes, so they can be developed for a later 
> inclusion into 4.3.
> 
> ---
> PM
> 

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

Re: zooming of inline data

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

> > I thought that Ethan has already committed his patch
> >     [ 1723715 ] Refresh plot or zoom without re-reading data
> > and that it was released in 4.2.1, but it is not the case.
> > What was the reason of not putting it into cvs (see 2007-07-01 04:36)?
> > 
> > 
> > There is also this patch
> >     [ 1745865 ] store raw data to refresh plot without rereading files
> > which is somehow similar in results (but caches all datafiles).
> > 
> > 
> > So, how to continue? Zooming of inline data is really important (and not 
> > only for Octave users).
> 
> Good question.  I don't know the correct answer.
> 
> My patch 1723715 is imperfect, as Daniel Sebald pointed out.
> One imperfection is that is does not allow toggling log scale axes.
> One positive feature is that it requires no additional internal
> storage or data structures.

I propose to commit your patch into cvs for both 4.2 and 4.3. This will 
allow us to use the mousing functionality immediately. (I thought his has 
already happen.) It would be a good reason for releasing gnuplot 4.2.2 (also 
with a bugfix to xylabels as reported today).

> Daniel's alternative patch  174865 creates a new set of internal storage
> buffers and saves all the input data for later re-use.
> 
> We also discussed the option of re-writing the log scale code so that
> the original data is stored rather than rescaled data.

Both are more serious changes, so they can be developed for a later 
inclusion into 4.3.

---
PM

Re: zooming of inline data

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

On Thursday 30 August 2007 14:23, Petr Mikulik wrote:
> I thought that Ethan has already committed his patch
>     [ 1723715 ] Refresh plot or zoom without re-reading data
> and that it was released in 4.2.1, but it is not the case.
> What was the reason of not putting it into cvs (see 2007-07-01 04:36)?
> 
> 
> There is also this patch
>     [ 1745865 ] store raw data to refresh plot without rereading files
> which is somehow similar in results (but caches all datafiles).
> 
> 
> So, how to continue? Zooming of inline data is really important (and not 
> only for Octave users).

Good question.  I don't know the correct answer.

My patch 1723715 is imperfect, as Daniel Sebald pointed out.
One imperfection is that is does not allow toggling log scale axes.
One positive feature is that it requires no additional internal
storage or data structures.

Daniel's alternative patch  174865 creates a new set of internal storage
buffers and saves all the input data for later re-use.  I do not
like the overhead, but I concede the point that it provides 
identical parsing and plotting behaviour for fresh or stored data.
I have not had time to look at the code quality, nor have I tested
it on real data.

We also discussed the option of re-writing the log scale code so that
the original data is stored rather than rescaled data.
That is, the log scaling would be applied at the time of plotting
rather than at the time the data is read in. This would remove the major
limitation of patch 1723715, but at the cost of rewriting all the
code that references log scaling.  I.e., high risk of breakage.
I think this is an attractive long-term alternative, but it doesn't
address the immediate needs of Octave users.


-- 
Ethan A Merritt