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

Re: gnuplot and DISPLAY

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

Allin Cottrell wrote:
> On Fri, 9 Mar 2007, Daniel J Sebald wrote:
> 
>> Allin Cottrell wrote:
>>
>>>
>>> (2) After applying Daniel's patch and recompiling, my "set term
>>> png" echoed to gnuplot produced a failure (as before), but in
>>> addition
>>>
>>>    echo "show version long" | gnuplot
>>>
>>> now produced the same X11 failure!
>>
>>
>> Strange.  What is the strace this time?
> 
> 
> I didn't check that; I can, if it's of interest.  But here's one more 
> piece of information.  I now suspect that this may be a bug in 
> gnome-terminal.  I was running the test in gnome-terminal and it 
> occurred to me to try doing the same thing in an xterm: lo and behold, 
> no problem!  That is, my original test
> 
>  echo "set term png" | gnuplot && echo "OK"
> 
> works fine, over the same 2-stage ssh connection from home to campus, 
> when executed in an xterm.
> 
> All the same, it's bizarre that the problem doesn't occur with older 
> gnuplot versions.

Yes, it is strange.  Apparently xterm is more forgiving, but I think there may still be an issue.  I say that because if I comment out all locations where X11_ipc is assigned inside X11_init(), which should be the equivalent of:

RETURN VALUE
       The popen function returns NULL if the fork(2) or pipe(2)  calls  fail,
       or if it cannot allocate memory.

gnuplot is exiting with a segfault.

In any case, I think that patch I put on SourceForge should be moved into CVS to make the endianess function consistent with other functions.

Dan

Re: gnuplot and DISPLAY

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

On Fri, 9 Mar 2007, Daniel J Sebald wrote:

> Allin Cottrell wrote:
>>
>> (2) After applying Daniel's patch and recompiling, my "set term
>> png" echoed to gnuplot produced a failure (as before), but in
>> addition
>>
>>    echo "show version long" | gnuplot
>>
>> now produced the same X11 failure!
>
> Strange.  What is the strace this time?

I didn't check that; I can, if it's of interest.  But here's one 
more piece of information.  I now suspect that this may be a bug 
in gnome-terminal.  I was running the test in gnome-terminal and 
it occurred to me to try doing the same thing in an xterm: lo and 
behold, no problem!  That is, my original test

  echo "set term png" | gnuplot && echo "OK"

works fine, over the same 2-stage ssh connection from home to 
campus, when executed in an xterm.

All the same, it's bizarre that the problem doesn't occur with 
older gnuplot versions.

Allin Cottrell

Re: gnuplot and DISPLAY

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

Allin Cottrell wrote:
> On Fri, 9 Mar 2007, Daniel J Sebald wrote:
> 
>   a patch designed to fix the sort of problem that I reported.
> 
> I'm now in the same position vis-a-vis the various computers as 
> when I first reported the issue.  I'm afraid things get weirder.
> 
> (1) Before applying Daniel's patch, the situation is as I 
> described yesterday.  But, taking Ethan's idea, I also tried
> 
>    echo "show version long" | gnuplot
> 
> and this worked OK.
> 
> (2) After applying Daniel's patch and recompiling, my "set term 
> png" echoed to gnuplot produced a failure (as before), but in 
> addition
> 
>    echo "show version long" | gnuplot
> 
> now produced the same X11 failure!
> 
> waverley:~$ echo "show version long" | gnuplot
> 
> gnuplot: unable to open display ''
> gnuplot: X11 aborted.

Strange.  What is the strace this time?


> I then reverted the patch, recompiled, and tried again.  At least 
> the results seem stable: "show version long" piped to gnuplot 
> worked, "set term png" failed.

And the strace for this as well?

I just want to confirm that the system is exiting at the same location and it isn't moved somewhere else after the patch.

Dan

Re: gnuplot and DISPLAY

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

On Fri, 9 Mar 2007, Daniel J Sebald wrote:

  a patch designed to fix the sort of problem that I reported.

I'm now in the same position vis-a-vis the various computers as 
when I first reported the issue.  I'm afraid things get weirder.

(1) Before applying Daniel's patch, the situation is as I 
described yesterday.  But, taking Ethan's idea, I also tried

   echo "show version long" | gnuplot

and this worked OK.

(2) After applying Daniel's patch and recompiling, my "set term 
png" echoed to gnuplot produced a failure (as before), but in 
addition

   echo "show version long" | gnuplot

now produced the same X11 failure!

waverley:~$ echo "show version long" | gnuplot

gnuplot: unable to open display ''
gnuplot: X11 aborted.

I then reverted the patch, recompiled, and tried again.  At least 
the results seem stable: "show version long" piped to gnuplot 
worked, "set term png" failed.

Allin Cottrell

Re: gnuplot and DISPLAY

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

On Fri, 9 Mar 2007, Ethan A Merritt wrote:

> On Friday 09 March 2007 05:39, Allin Cottrell wrote:
>>
>> I may have misdescribed the outcome, but in the context of a
>> configure check this is what I had in mind:
>>
>> echo "set term png" | gnuplot 2>/dev/null && echo "OK"
>> echo "set term foo" | gnuplot 2>/dev/null && echo "OK"
>>
>> The first command echoes "OK", the second doesn't.
>
> Can you point to any place in the documentation that supports
> this idea?  I have been looking, and can't find anything that
> would give the impession that such a test would work.

No, I haven't looked for this in the docs, I just noticed that it 
worked.  Thanks for your further suggestions.

Allin Cottrell

Re: gnuplot projects, terminal modules

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

Timothée Lecomte wrote:
>>  On Thursday 08 March 2007 04:53, Timothée Lecomte wrote:
>>     
>
>   
>>>> What I implement in the plugin1.diff and plugin2.diff is the an
>>>> in-between
>>>> interactive structure:
>>>> term->inter->waitforinput
>>>> term->inter->put_tmptext
>>>> term->inter->set_ruler
>>>> term->inter->set_cursor
>>>> term->inter->set_clipboard
>>>>
>>>> so that non-interactive terminals just have term->inter = 0, making it
>>>> easier to extend the terminal API for interactive commands.
>>>>         
>>> Yes, that's a bit cleaner.
>>> But it's not like we extend the terminal API every week.
>>>       
>> So you would suggest that I add term->raise_term_window directly in
>> struct termentry ?
>>
>> In that case, my point is that:
>> - if I add it to the bottom, then it's one more #ifdef USE_MOUSE
>> - if I add it inside the current #ifdef USE_MOUSE, I have to add one '0'
>> manually to all drivers
>>     
>
> Well, let's forget this idea of term->inter->...
> I can actually add term->raise_term_window just inside the existing #ifdef
> USE_MOUSE ... #endif, and I can introduce the following:
>
> #define EMPTY_MOUSE_ENTRIES \
> #ifdef USE_MOUSE \
> 0, 0, 0, 0, 0, 0, \
> #endif
>
>
> So that non-mouseable terminals will just use NO_MOUSE_ENTRIES, and it
> will be much easier to add new mousing commands in the future.
>
> Does that sound right ?
>
> Best regards,
>
> Timothée
>   

Ok, that's done:
http://sourceforge.net/tracker/index.php?func=detail&aid=1677582&group_id=2055&atid=302055
Comments ?

Best regards,

Timothée

Re: Cairo-PNG

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

On Friday 09 March 2007 10:48, Mojca Miklavec wrote:
>=20
> I just wanted to point out that it might be useful to implement such a
> functionality for wxt (Timoth=E9e was a bit sceptic).
>=20
> > > For many users this is the most natural way indeed. Some people prefer
> > > scripting, some prefer clicking.
> >
> > I don't understand what that has to do with aqua.
> > In any interactive gnuplot terminal, you can bind a hotkey/click to a
> > print command of your choice.  This is not limited to aquaterm.
>=20
> "bind a hotkey" is not equivalent to "have it in menu". I never came
> to an idea of binding a hotkey.

Well, I'll repeat a suggestion that I have made before.
There is a nice button-panel at the top of the wxt terminal,=20
but no mechanism for a user to add buttons to it.  We could
do this via the existing "bind" command, or use some other
mechanism altogether, perhaps a configuration file.

Either way, the idea would be to specify an icon=20
(e.g. "~/icons/printer.png") and an action script
("set term push; set term pdf; set output '| lpr'; replot; set term pop").
Clicking the button triggers the script, just as it would for a hotkey bind=
ing.=20

I may well get around to trying to implement this myself,
but I was hoping Timoth=E9e would again speak up to say
"that's a one-line change if you know where to look".


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

Re: Cairo-PNG

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

On 3/9/07, Ethan Merritt wrote:
> On Friday 09 March 2007 08:57, Mojca Miklavec wrote:
> >
> > Just to let you know - after a long discussion on the de.comp.text.tex
> > mailing list ("gnplot als PDF ausgeben") and a long list of proposals
> > how to create PDF with gnuplot, the user preffered to choose the
> > "aqua->save as pdf" way.
>
> So, a Mac-only solution?

Regretably yes.

> Fine for Mac users, although I guess this puts pressure on Per to
> finishing implementing the full set of features in aquaterm.  Right now
> aqua lags the other interactive terminal types in terms of what it can do=
.

I just wanted to point out that it might be useful to implement such a
functionality for wxt (Timoth=E9e was a bit sceptic).

> > For many users this is the most natural way indeed. Some people prefer
> > scripting, some prefer clicking.
>
> I don't understand what that has to do with aqua.
> In any interactive gnuplot terminal, you can bind a hotkey/click to a
> print command of your choice.  This is not limited to aquaterm.

"bind a hotkey" is not equivalent to "have it in menu". I never came
to an idea of binding a hotkey.

> > A well-written application supports both.
>
> We already support both, or actually 3 choices.  You can have
> 1) command line scripted replot on a different terminal type
> 2) hotkey or click to trigger replot to a printer
> 3) select and export to clipboard for further action of your choice

I need to try that out on a windows machine ...
I have never tried any of the last two options.

> In addition, the window manager may offer other choices. For example,
> the KDE desktop uses the "print screen" key to trigger a utility program
> that can save all or part of your plot window to a PNG file.

But this is a longer procedure and only creates suboptimal (bitmap) results=
.

> > It's realy nice that the PDF documents that come out are vector-based,
> > not pixel-based, as would be the most natural way to save a graphic
> > from windows.
>
> That's just Windows idiocy.  Except that it's not even true, I think.
> Doesn't saving via the Windows clipboard give you a vector-based metafile=
?

This might be true, but usually printscreen is the only choice (unless
a specific program supports some kind of vector graphics). I doubt
that one can export any kind of vector graphic out of the windows
terminal, but I may be wrong.

Mojca

Re: Cairo-PNG

[Brendan B. <bb...@cs...>]

And that indeed appears to still be the case ;-)  Although I'm not  
100% certain what it should look like...  (and I don't have Konqueror  
on OS X)

--brendan

On Mar 9, 2007, at 1:16 PM, Ethan Merritt wrote:

> On Friday 09 March 2007 10:02, Brendan Burns wrote:
>> Actually, I just looked at the graphs on the link you sent, and it
>> seems like Firefox (2.0.2 on Mac OS X) supports transparency.  In the
>> first graph on that page, I see the bleed through from the green into
>> the yellow, etc.
>
> Development is rapid. Isn't it great? :-)
>
> But to be more precise, I should have said "Firefox did not support
> transparent pattern-fill last time I checked (version 1.5 under  
> linux)".
>
> See plots 3 and 4 of
>     http://gnuplot.sourceforge.net/demo_svg/transparent.html
>
> -- 
> Ethan A Merritt
>
> ---------------------------------------------------------------------- 
> ---
> 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

Re: Cairo-PNG

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

Peter Danenberg wrote:
>> My second concern is that we already have gd that does the work
>> quite well to export in jpeg/gif/png apart from not doing
>> antialiasing.
>>     
>
>
>      Aye,  that's  the rub, Timothée; I'm setting up gnuplot
> as a webservice, and having antialiased PNGs would be a sig‐
> nificant quality-improvement.
>
>      Where  does  the pdf code live; and would it be a suit‐
> able template for making a Cairo-PNG patch?
>
> Best, Peter

The cairopdf terminal is here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1651015&group_id=2055&atid=302055

Making a cairopng terminal is actually almost a one-liner from the above 
patch: you just have to change 'cairo_pdf_surface_create' to its png 
counterpart. Sweet, isn't it ?

Best regards,

Timothée

Re: Cairo-PNG

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

On Friday 09 March 2007 10:02, Brendan Burns wrote:
> Actually, I just looked at the graphs on the link you sent, and it  
> seems like Firefox (2.0.2 on Mac OS X) supports transparency.  In the  
> first graph on that page, I see the bleed through from the green into  
> the yellow, etc.

Development is rapid. Isn't it great? :-)

But to be more precise, I should have said "Firefox did not support
transparent pattern-fill last time I checked (version 1.5 under linux)".

See plots 3 and 4 of
    http://gnuplot.sourceforge.net/demo_svg/transparent.html

-- 
Ethan A Merritt

Re: Cairo-PNG

[Brendan B. <bb...@cs...>]

Actually, I just looked at the graphs on the link you sent, and it  
seems like Firefox (2.0.2 on Mac OS X) supports transparency.  In the  
first graph on that page, I see the bleed through from the green into  
the yellow, etc.

--brendan

On Mar 9, 2007, at 12:50 PM, Ethan Merritt wrote:

> Firefox is not bad either, although it doesn't handle transparency.

Re: Cairo-PNG

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

On Friday 09 March 2007 06:39, Peter Danenberg wrote:
>      Aye,  that's  the rub, Timoth=C3=A9e; I'm setting up gnuplot
> as a webservice, and having antialiased PNGs would be a sig=E2=80=90
> nificant quality-improvement.

There is also the choice of creating embedded SVG images for
web display.  I think this will be the wave of the future,
particularly if we add scripted mousing support to the SVG
output.  That way you'd have mousable plots on a web page.

Even aside from mousing, SVG has an advantage over PNG
in that it is vector-based and can be zoomed in the browser.

The current state of gnuplot SVG output is pretty good:

	http://gnuplot.sourceforge.net/demo_svg/

In fact, gnuplot's support of SVG is better than the
web browsers', which is where the biggest current problem lies.
By far the best browser support I've seen is in Konqueror,
which uses the ksvg module from KDE.  Firefox is not bad either,
although it doesn't handle transparency.
The Adobe browser plugin used to be pretty solid, but recently I
haven't been able to make it work at all under linux.

=2D-=20
Ethan A Merritt

Re: Cairo-PNG

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

On Friday 09 March 2007 08:57, Mojca Miklavec wrote:
> 
> Just to let you know - after a long discussion on the de.comp.text.tex
> mailing list ("gnplot als PDF ausgeben") and a long list of proposals
> how to create PDF with gnuplot, the user preffered to choose the
> "aqua->save as pdf" way.

So, a Mac-only solution?
Fine for Mac users, although I guess this puts pressure on Per to 
finishing implementing the full set of features in aquaterm.  Right now
aqua lags the other interactive terminal types in terms of what it can do.
 
> For many users this is the most natural way indeed. Some people prefer
> scripting, some prefer clicking.

I don't understand what that has to do with aqua.
In any interactive gnuplot terminal, you can bind a hotkey/click to a
print command of your choice.  This is not limited to aquaterm.

> A well-written application supports both.

We already support both, or actually 3 choices.  You can have
1) command line scripted replot on a different terminal type
2) hotkey or click to trigger replot to a printer
3) select and export to clipboard for further action of your choice

In addition, the window manager may offer other choices. For example,
the KDE desktop uses the "print screen" key to trigger a utility program 
that can save all or part of your plot window to a PNG file.

> It's realy nice that the PDF documents that come out are vector-based,
> not pixel-based, as would be the most natural way to save a graphic
> from windows.

That's just Windows idiocy.  Except that it's not even true, I think.
Doesn't saving via the Windows clipboard give you a vector-based metafile?

-- 
Ethan A Merritt

Re: Cairo-PNG

[Pierre <pie...@gm...>]

On 3/9/07, Ethan A Merritt <merritt@u.washington.edu> wrote:
> On Friday 09 March 2007 06:22, Pierre wrote:
> > Hello,
> >
> > On 3/9/07, Peter Danenberg <pc...@wi...> wrote:
> > > > My second concern is that we already have gd that does the work
> > > > quite well to export in jpeg/gif/png apart from not doing
> > > > antialiasing.
> >
> > As a side note, GD supports antialiased lines and polygon (without
> > transparency).
>
> Sorry to disagree,

Nothing to disagree, the AA support is limited, nothing new here :) Or
to be short, it works well only with simple (and single) lines.

> but in the context of drawing arbitrary curves
> with arbitrary line-widths (which is to say practically every line
> drawn by gnuplot) libgd through version 2.0.34 does not support
> antialiasing.

Yes, it is one of the case where the anti alias does not work well (I
should say does not work at all)..  Ellipse or circle (filled, arcs or
with thickness) will be in cvs in the next days. Filled polygon and
general ellipses will follow later. It will hopefully help to render
nicer shapes.

A temporary solution for the thick lines is to use the filled polygon
function, as long as you don't need transparency. I'm not sure it will
work well with polylines (it may draw twice the area between two
segments).

> > I'm working on the other drawing functions like the
> > filled ellipses or arcs as well as a an improved polygon function
> > (full transparency support as well).
>
> IMHO the most dramatic improvement would come from implementing
> an anti-aliased brushstroke.  That one change would by itself fix
> most of the aliasing artifacts seen in gnuplot png output.

Yes, but it is what cairo does and I don't think it is worth the
effort to re implement something like that in GD (it is not that
simple). However, if someone likes to implement something like that,
he will be more than welcome. I'll be happy to help (that's true for
any desired features or change).

--Pierre

Re: Cairo-PNG

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

On 3/9/07, Timoth=E9e Lecomte wrote:

> At first, I had the idea to provide an 'export' feature from the wxt
> terminal, using cairo code directly. However, now I feel that it's
> dangerous to have two different paths to do the same thing (gnuplot as it
> is now is a scripting language after all, not a GUI).

Just to let you know - after a long discussion on the de.comp.text.tex
mailing list ("gnplot als PDF ausgeben") and a long list of proposals
how to create PDF with gnuplot, the user preffered to choose the
"aqua->save as pdf" way.

For many users this is the most natural way indeed. Some people prefer
scripting, some prefer clicking. A well-written application supports
both. (Did you already figure out how to do vector-based pm3d?)

Mojca

(I can translate if needed, but the whole thread was about different
proposals how to make PDF, and the user has chosen the "save as" way.
It's realy nice that the PDF documents that come out are vector-based,
not pixel-based, as would be the most natural way to save a graphic
from windows.)

----------------------------

Martin P=F6pping schrieb:
> ich verwende pdflatex f=FCr meine Latex Dokumente und bevorzuge daher
> Bilder/ Diagramme als PDF Datei anstelle von EPS.
> Gibt es eine M=F6glichkeit von gnuplot heraus direkt ein PDF zu erzeugen?
> Oder wie verwendet ihr gnuplots f=FCr pdflatex?

> Oder ist epstopdf der sauberste Weg?
> Mit epstopdf hatte ich jedenfalls, zumindest bei Datenfluss- und
> UML-Diagrammen, nicht die besten Erfahrungen gemacht.


Hallo,
wen es interessiert... ich habe jetzt einen sch=F6nen simplen Weg gefunden.
Da ich unter MacOS arbeite, habe ich AquaTerm gefunden:
http://aquaterm.sourceforge.net/

Einfach unter gnuplot:
set terminal aqua

Und dann wird es unter Aqua geplottet.
Dort kann man dann einfach mit Datei =3D> Speichern unter den Plot als EPS
oder PDF Datei speichern.

Klappt sehr gut und man hat den Vorteil, dass man nicht den Umweg =FCber
X11 gehen muss.

Re: gnuplot and DISPLAY

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

On Friday 09 March 2007 05:39, Allin Cottrell wrote:
> 
> I may have misdescribed the outcome, but in the context of a 
> configure check this is what I had in mind:
> 
> echo "set term png" | gnuplot 2>/dev/null && echo "OK"
> echo "set term foo" | gnuplot 2>/dev/null && echo "OK"
> 
> The first command echoes "OK", the second doesn't.

Can you point to any place in the documentation that supports
this idea?  I have been looking, and can't find anything that
would give the impession that such a test would work.  

It is true there is at least one code path that would
result in gnuplot exiting with an error status set, but the
path looks rather fragile to me.  It depends on the current
input stream and on whether the "interactive" flag is set,
and anyhow it isn't initialized until the initial terminal
setup is already complete.  So I guess I am surprised to
learn that such a test ever worked!

My recommendation for a configuration test is to use the
output of "show version long":

-READLINE  +LIBREADLINE  +HISTORY  -BACKWARDS_COMPATIBILITY  +BINARY_DATA
+GD_PNG  +GD_JPEG  +GD_TTF  +GD_GIF  +ANIMATION
-NOCWDRC  +X11  +X11_POLYGON  +MULTIBYTE  +USE_MOUSE  +HIDDEN3D_QUADTREE
+DATASTRINGS  +HISTOGRAMS  +OBJECTS  +STRINGVARS  +MACROS  +IMAGE

You can even check these configuration option from inside a gnuplot
script.  The current demos do this. For example, image.dem begins with

if ((GPVAL_VERSION == 4.3 || GPVAL_VERSION == 4.2) \
&&  (!strstrt(GPVAL_COMPILE_OPTIONS,"+IMAGE"))) \
    print ">>> Skipping demo <<<\n" ; \
    print "This copy of gnuplot was built without support for plotting images" ; \
    exit ;

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

Re: Cairo-PNG

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

On Friday 09 March 2007 06:22, Pierre wrote:
> Hello,
> 
> On 3/9/07, Peter Danenberg <pc...@wi...> wrote:
> > > My second concern is that we already have gd that does the work
> > > quite well to export in jpeg/gif/png apart from not doing
> > > antialiasing.
> 
> As a side note, GD supports antialiased lines and polygon (without
> transparency).

Sorry to disagree, but in the context of drawing arbitrary curves
with arbitrary line-widths (which is to say practically every line
drawn by gnuplot) libgd through version 2.0.34 does not support
antialiasing.  

> I'm working on the other drawing functions like the 
> filled ellipses or arcs as well as a an improved polygon function
> (full transparency support as well).

IMHO the most dramatic improvement would come from implementing
an anti-aliased brushstroke.  That one change would by itself fix
most of the aliasing artifacts seen in gnuplot png output. 


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

Re: Cairo-PNG

[Pierre <pie...@gm...>]

Hello,

On 3/9/07, Peter Danenberg <pc...@wi...> wrote:
> > My second concern is that we already have gd that does the work
> > quite well to export in jpeg/gif/png apart from not doing
> > antialiasing.

As a side note, GD supports antialiased lines and polygon (without
transparency). I'm working on the other drawing functions like the
filled ellipses or arcs as well as a an improved polygon function
(full transparency support as well).  My goal is not to provide the
same quality as Cairo but to provide the best possible results
(compromises between speed and quality). The result of my work should
be in CVS in the next two weeks.

Another major addition for the 2.1.x serie is the support of Cairo
image surface (there is discussions about agg as well). It will let
one load, save or copy images from or to a Cairo image surface. That
means adding all image formats available in GD to Cairo (gif89(a), png
with the filters/compression options, jpeg or the new tga and tiff
formats).

--Pierre

Re: gnuplot and DISPLAY

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

On Fri, 9 Mar 2007, Daniel J Sebald wrote:

> Allin, please try the following patch and rebuild gnuplot to see if this 
> fixes matters.

Thanks, I'll try this tonight.  (I can't really test it right now, 
since I'm not seeing the problem from here.)

Allin Cottrell

Re: gnuplot and DISPLAY

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

On Thu, 8 Mar 2007, Ethan A Merritt wrote:

> On Thursday 08 March 2007 19:35, Allin Cottrell wrote:
>>>  bash-3.1$ echo "show term" | GNUTERM=dumb gnuplot_4.2
>>>
>>>     terminal type is dumb feed  79 24
>>
>> Yes, that works fine, only you have to parse the response; the
>> exit status seems to be OK regardless of the GNUTERM setting.
>
> Were you expecting an error exit status?  Why?
>
> I would not have expected an error exit from your original
> test run on gnuplot version 4.0 either.
> Failing to find a terminal is not a fatal error.
> It just returns you to the gnuplot command prompt.
> So when would you ever see an error exit?

I may have misdescribed the outcome, but in the context of a 
configure check this is what I had in mind:

echo "set term png" | gnuplot 2>/dev/null && echo "OK"
echo "set term foo" | gnuplot 2>/dev/null && echo "OK"

The first command echoes "OK", the second doesn't.  Thus I can get 
a reading on whether the term type is supported without having to 
parse any gnuplot output.

Allin Cottrell

Re: Cairo-PNG

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

> My second concern is that we already have gd that does the work
> quite well to export in jpeg/gif/png apart from not doing
> antialiasing.


     Aye,  that's  the rub, Timothée; I'm setting up gnuplot
as a webservice, and having antialiased PNGs would be a sig‐
nificant quality-improvement.

     Where  does  the pdf code live; and would it be a suit‐
able template for making a Cairo-PNG patch?

Best, Peter

Re: gnuplot and DISPLAY

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

On Thu, 8 Mar 2007, Ethan A Merritt wrote:

> The thing is, I still don't quite understand why Allin is
> seeing this problem.  The original bug report was due
> to incomplete installation;  gnuplot was built to default to
> X11, but the X11 driver (gnuplot_x11) had not actually been
> installed.  The problem arose because gnulot tried to open a
> pipe to gnuplot_x11, but gnuplot_x11 wasn't there. This
> is a different case entirely.

Yes, this is a bit mysterious.  This morning I'm at the machine 
that I was accessing remotely last night, and if I try the various 
experiments you mention (e.g. unsetting DISPLAY, or setting it to 
some invalid value) I get the same results that you report: the 
x11 terminal won't work (obviously) but gnuplot does not bomb out.

My connection last night was a 2-stage ssh session: from a home 
DSL connection, behind a firewall, to server B on campus, then 
from server B to machine A, inside the campus firewall.

Now I'm on campus, and I've tried ssh'ing from A to B, then back 
from B to A (with DISPLAY unset) and running my test command: it 
works OK!

Allin Cottrell

Re: Cairo-PNG

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

>      The  wxt  terminal  looks  great,  by the way;

Thanks !

> Timothée Lecomte mentioned, however, back in 2005* that:
>
>      [The  wxt  terminal]  could also be reused to give
>      ps/psf/png/... outputs easily.
>
> Is anyone working on antialiased PNG output via Cairo/Pango?
>
> Best, Peter
>
>   * http://lists.freedesktop.org/archives/cairo/2005-November/005647.html
>

Well, the pdf terminal is in the works, there's a patch on sourceforge
nearing completion.

As far as other formats are concerned:
- gnuplot already does svg and postscript very well, and I'm afraid using
cairo for this would generate more obfuscated code (however, if gradients
are ever used in gnuplot, it would prevent us from doing the work
ourselves).
- for bitmap formats, cairo only knows pixel buffers and PNG. So my first
concern is that we would need another library if we want to do anything
besides PNG. My second concern is that we already have gd that does the
work quite well to export in jpeg/gif/png apart from not doing
antialiasing.

At first, I had the idea to provide an 'export' feature from the wxt
terminal, using cairo code directly. However, now I feel that it's
dangerous to have two different paths to do the same thing (gnuplot as it
is now is a scripting language after all, not a GUI).

Best regards,

Timothée

Re: gnuplot projects, terminal modules

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

>  On Thursday 08 March 2007 04:53, Timothée Lecomte wrote:

>
>>
>>> What I implement in the plugin1.diff and plugin2.diff is the an
>>> in-between
>>> interactive structure:
>>> term->inter->waitforinput
>>> term->inter->put_tmptext
>>> term->inter->set_ruler
>>> term->inter->set_cursor
>>> term->inter->set_clipboard
>>>
>>> so that non-interactive terminals just have term->inter = 0, making it
>>> easier to extend the terminal API for interactive commands.
>>
>> Yes, that's a bit cleaner.
>> But it's not like we extend the terminal API every week.
>
> So you would suggest that I add term->raise_term_window directly in
> struct termentry ?
>
> In that case, my point is that:
> - if I add it to the bottom, then it's one more #ifdef USE_MOUSE
> - if I add it inside the current #ifdef USE_MOUSE, I have to add one '0'
> manually to all drivers

Well, let's forget this idea of term->inter->...
I can actually add term->raise_term_window just inside the existing #ifdef
USE_MOUSE ... #endif, and I can introduce the following:

#define EMPTY_MOUSE_ENTRIES \
#ifdef USE_MOUSE \
0, 0, 0, 0, 0, 0, \
#endif


So that non-mouseable terminals will just use NO_MOUSE_ENTRIES, and it
will be much easier to add new mousing commands in the future.

Does that sound right ?

Best regards,

Timothée