Menu
▾
▴
gnuplot-beta
|
From: Peter D. <pc...@wi...> - 2007-03-09 09:13:26
|
The wxt terminal looks great, by the way; 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
|
|
From: <tim...@en...> - 2007-03-09 09:46:06
|
> 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 |
|
From: Peter D. <pc...@wi...> - 2007-03-09 13:37:45
|
> 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
|
|
From: <tim...@en...> - 2007-03-09 18:32:04
|
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 |
|
From: Pierre <pie...@gm...> - 2007-03-09 14:22:33
|
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 |
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-03-09 16:07:21
|
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 |
|
From: Pierre <pie...@gm...> - 2007-03-09 16:58:58
|
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 |
|
From: Mojca M. <moj...@gm...> - 2007-03-09 16:57:35
|
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.
|
|
From: Ethan M. <merritt@u.washington.edu> - 2007-03-09 17:36:28
|
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
|
|
From: Ethan M. <merritt@u.washington.edu> - 2007-03-09 17:51:03
|
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 |
|
From: Brendan B. <bb...@cs...> - 2007-03-09 18:02:15
|
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. |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-03-09 18:16:20
|
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
|
|
From: Brendan B. <bb...@cs...> - 2007-03-09 18:37:03
|
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 |
|
From: Mojca M. <moj...@gm...> - 2007-03-09 18:48:49
|
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
|
|
From: Ethan M. <merritt@u.washington.edu> - 2007-03-09 19:26:17
|
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
|
