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

Re: launch help in pdf or on web

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

Hello

--- Petr Mikulik wrote:

> HTML Help Workshop says it can convert rtf (such as gnuplot.rtf) into CHM. 
> However, it does not work for me -- on WXP or Wine it says that some DLLs 
> are incorrect.
> 
> Has somebody succeeded?
I have met the same errors.  I googled again and found the page.

http://www.helpfulsolutions.com/

HTML Help DLL Registrar - ...........This little program asks you where you installed HTML Help
Workshop and then registers all of the DLLs it requires..................

HLP to HTML Help Convertor Fixer - ..... "The DLLs necessary to convert RTF to HTML have not been
installed correctly. Reinstall HTML Help Workshop and try again." is somewhat bogus............


I will try them
> 
> > Now html documents in 'make' are produced by latex2html.
> > I have tried the above. However, my limited ability and time prevents me to go ahead :-( .
> >
> > http://www.geocities.jp/tmgpltwin/Files/Files.html
> > 0022 gnuplot.chm.zip, 376,810 bytes, 2009-09-07, zipped gnuplot.chm file 
> > generated by HTML Help Complier
> >
> > The above file was made by mere translattion of htmldocs of the recent cvs 
> > sources. That is a mere test of HTML Help Complier.
> 
> How have you managed to include Contents and Index?
> 
> 
> I wonder whether MS HTML Help Workshop is the only tool. Isn't there some 
> other tool, e.g. such that can be operated from a command line as the HCW 
> currently used?

That was a mere test so that contents and index were not treated.  To get complete help, of course, we
have to treat the contents an index.  I have not try them yet.

>Isn't there some 
> other tool, e.g. such that can be operated from a command line as the HCW 
> currently used?

I have looking about the help. I cannot find the description of  command line.
Script writing by WSH (Windows script host) might be possible to treat it from command line.

Regards

Tatsuro
 


 

--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/

Re: launch help in pdf or on web

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

> > Or shell we ship the CHM help file (is there an appropriate convertor 
> > for gnuplot formats? I've googled one shareware hlp2chm.exe.)?
> 
> I have tried to convert the html-style gnuplot documents to a chm file by HTML Help Workshop.
> However customization of html files to chm help for index or so will be recommended.
>
> I think that it is better to convert doc2rtf for Help Workshop to program 
> like doc2html for HTML Help Workshop.

HTML Help Workshop says it can convert rtf (such as gnuplot.rtf) into CHM. 
However, it does not work for me -- on WXP or Wine it says that some DLLs 
are incorrect.

Has somebody succeeded?


> Now html documents in 'make' are produced by latex2html.
> I have tried the above. However, my limited ability and time prevents me to go ahead :-( .
>
> http://www.geocities.jp/tmgpltwin/Files/Files.html
> 0022 gnuplot.chm.zip, 376,810 bytes, 2009-09-07, zipped gnuplot.chm file 
> generated by HTML Help Complier
>
> The above file was made by mere translattion of htmldocs of the recent cvs 
> sources. That is a mere test of HTML Help Complier.

How have you managed to include Contents and Index?


I wonder whether MS HTML Help Workshop is the only tool. Isn't there some 
other tool, e.g. such that can be operated from a command line as the HCW 
currently used?

---
PM

Re: {png,pdf}cairo terminals and font size

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

> My inclination is to add a "fontscale" option for all terminal drivers,
> analogous to the "linewidth" and "dashlength" terminal options.
> Like these, it would be interpreted as "whatever font size was requested,
> multiply it by this scale factor before using it".  
> 
> Then the font sizes mentioned explicitly in a script could be used
> without change, so long as you added an appropriate scaling factor 
> in the 'set term' command.

That would be great especially for inset figures in multiplot, where smaller 
font is  a must. A simple command such as "set termoption fontscale 0.5"
would make the job much easier.

---
PM

Re: exposing cairo context from gnuplot

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

On Thu, 10 Sep 2009, Ethan Merritt wrote:

> On Thursday 10 September 2009, Allin Cottrell wrote:
> >
> > "Back to basics".  The only sort of thing you can literally "pass
> > to" gnuplot (as an executable program) is a string, as in the argv
> > array or as part of a "set foo ..." statement.
>
> That's not really true.  It is certainly the most portable thing,
> but far from the only thing.  You can pass shared memory objects,
> or loadable shared libraries/plugins, for example...

OK, then I'm missing something.  Could you give an example of how
you can pass such things at run time other than via strings in
argv or "set..."?  I understand that you can ask gnuplot to read
binary data, but I thought the only way to do that was by passing
the program a string, namely the name of a file to open.

Allin Cottrell

Re: exposing cairo context from gnuplot

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

On Thursday 10 September 2009, Allin Cottrell wrote:
> 
> "Back to basics".  The only sort of thing you can literally "pass
> to" gnuplot (as an executable program) is a string, as in the argv
> array or as part of a "set foo ..." statement.

That's not really true.  It is certainly the most portable thing,
but far from the only thing.  You can pass shared memory objects,
or loadable shared libraries/plugins, for example.  There is even an
existing patchset on the SourceForge tracker that implements
loadable shared objects so that you can have pluggable math functions.

> However, strings can be interpreted in various ways.  If we're
> really talking about passing a pre-allocated cairo context to
> gnuplot, the only way I can envisage of doing this would be saying
> something like
> 
> set cairo_t "0x818a400"
> 
> (to a hypothetical gnuplot "raw_cairo" terminal).
> 
> It seems this would offer (depending on one's black-hat skill
> level) a good way of crashing gnuplot or turning it into a
> rootkit; 

It's no different than plugins in Firefox or Gimp or xmms or
MSWord or name your favorite application.  If the plugin is malicious
then, yeah, it can cause problems.  But only at the level gnuplot itself
can already cause problems.  It doesn't magically gain additional 
capabilities or privilege levels.

> but I suppose that in the right hands it could do what
> Richard is (I think) talking about -- i.e. get gnuplot to write
> into an area of memory rather than a file.

Maybe I mis-understand the intended use. I thought the proposed application
was to draw into an existing widget that was being displayed on the screen,
much like the x11 terminal can draw into an existing x-window.  If it's on
the screen, then it has a publically visible identifier already that the 
display/window manager can use.  You would in principle only have to pass that
identifier, just like passing the ID of an X window (and in fact it might even
_be_ the identifier of an X window; I don't know how gtk widgets work exactly).

Be that as it may, at least on linux "writing into an area of memory rather
than a file" is a false dichotomy.  You can map a file into memory and 
access it by either mechanism.  Or at least that is my understanding.
I admit that I've never programmed using memory-mapped files. See, e.g.
http://www.ecst.csuchico.edu/~beej/guide/ipc/mmap.html
So that might indeed be one way to implement this.


	Ethan

Re: exposing cairo context from gnuplot

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

On Thu, 10 Sep 2009, Ethan Merritt wrote:

> On Thursday 10 September 2009 02:34:07 Richard Henwood wrote:
> > there is a useful post provided by the author of the extcairo driver:
> > http://www.mail-archive.com/plp...@li.../msg01273.html
> > and example usage:
> > http://plplot.sourcearchive.com/documentation/5.9.2/ext-cairo-test_8c-source.html
>
> Hmm.
> Their use of the word "external" doesn't match mine, if that's
> an example of it. In the URL you point to, it's just that a
> routine in plplot itself initializes cairo and then passes it to
> the driver.  What we would be looking for is an example of one
> process initializing a cairo context and then passing a handle
> to another process entirely.  Which may or may not be possible -
> I just dont know.

"Back to basics".  The only sort of thing you can literally "pass
to" gnuplot (as an executable program) is a string, as in the argv
array or as part of a "set foo ..." statement.

However, strings can be interpreted in various ways.  If we're
really talking about passing a pre-allocated cairo context to
gnuplot, the only way I can envisage of doing this would be saying
something like

set cairo_t "0x818a400"

(to a hypothetical gnuplot "raw_cairo" terminal).

It seems this would offer (depending on one's black-hat skill
level) a good way of crashing gnuplot or turning it into a
rootkit; but I suppose that in the right hands it could do what
Richard is (I think) talking about -- i.e. get gnuplot to write
into an area of memory rather than a file.

Allin Cottrell

Re: exposing cairo context from gnuplot

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

On Thursday 10 September 2009 02:34:07 Richard Henwood wrote:
> On Wed, 2009-09-09 at 08:42 -0700, Ethan Merritt wrote:
> <snip>
> > 
> > I'm not a gtk programmer, but there's always Google...
> > which leads me to the plplot project on SourceForge. It seems that
> > plplot is somewhat similar to gnuplot in intent, but the relevant point
> > is that they recently added an external cairo terminal driver "extcairo"
> > that so far as I can tell from the description does exactly what you want.
> > If it works for them, I don't see why it wouldn't work for us.
> > Anyonw have time to check out the code and report back on how the
> > information to open the context is passed?
> 
> I've had a quick look at what I think the relevant bits of PLplot are.
> 
> 1. The extcairo driver within PLplot requires an existing cairo context
> to be provided to it.
> 2. PLplot then draws over the context and returns.
> 
> there is a useful post provided by the author of the extcairo driver:
> http://www.mail-archive.com/plp...@li.../msg01273.html
> and example usage:
> http://plplot.sourcearchive.com/documentation/5.9.2/ext-cairo-test_8c-source.html

Hmm.
Their use of the word "external" doesn't match mine, if that's an example of it.
In the URL you point to, it's just that a routine in plplot itself initializes
cairo and then passes it to the driver.  What we would be looking for is an
example of one process initializing a cairo context and then passing a handle
to another process entirely.  Which may or may not be possible - I just dont know.


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

Re: {png,pdf}cairo terminals and font size

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

On Thursday 10 September 2009 11:38:09 Allin Cottrell wrote:
> On Wed, 9 Sep 2009, Ethan Merritt wrote:
> > I don't see anything immediately in looking at the code.
> > It really is initialized to 6, but after that it seems to just pass
> > through any request to the cairo library.
> 
> Ah, in cairo.trm we have two alternative default initializations,
> CAIROPDF_PARAMS_DEFAULT and CAIROPNG_PARAMS_DEFAULT; the former
> specifies a 6-point font and the latter specifies 12-point.

Guess I missed that in my quick look.
  
> What's to be done?  One option would be to multiply the user's
> font size specification by 2 in the case of pngcairo, to make it
> consistent with the "6 point" default. That is, if I say
> 
> set term pngcairo font "foo,8"
> 
> the actual size sent to the driver is 16.
> 
> The alternative would be to amend the doc for pngcairo to say that
> the default is 12 points.  This has the advantage that it doesn't
> change the output of existing gnuplot scripts, but the
> disadvantage that it ratifies the situation where you have to
> apply a factor of 2 to the font size if you want comparable output
> from pdfcairo and pngcairo (in the case where you're not just
> accepting the default size).

The issue is more general that just comparing pdfcairo and pngcairo.
For instance, 'set term post' defaults to 7x10" output, but
'set term post eps' defaults to half of that: 3.5"x5".  Yet they
both claim to have the same default font size.

My inclination is to add a "fontscale" option for all terminal drivers,
analogous to the "linewidth" and "dashlength" terminal options.
Like these, it would be interpreted as "whatever font size was requested,
multiply it by this scale factor before using it".  

Then the font sizes mentioned explicitly in a script could be used
without change, so long as you added an appropriate scaling factor 
in the 'set term' command.

	Ethan



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

Re: {png,pdf}cairo terminals and font size

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

On Wed, 9 Sep 2009, Ethan Merritt wrote:

> On Wednesday 09 September 2009, Allin Cottrell wrote:
> >
> > I like the *cairo terminals a lot: PNG looks good on screen and
> > PDF is good for publication-quality output; and these two
> > terminals share a common command-set with high fidelity, since
> > they use a common back-end.  Except for one thing...
> >
> > The help for both pngcairo and pdfcairo says that the default size
> > for fonts is 6 points.  That's fine, and if you go with the
> > default you get quite consistent-looking output from the two
> > terminals.
> >
> > But if you alter the size, an inconsistency emerges.  Suppose I'd
> > prefer 8 points.  I do my PNG plot using
> >
> > set term pngcairo font ",8"
> >
> > then do my PDF plot using
> >
> > set term pdfcairo font ",8"
> >
> > Relative to the "6-point" baseline, the PNG file shows a smaller
> > font (8 < 6, hmm) while the PDF plot shows a larger font (8 > 6).
> >
> > I'm happy to take a look at the code and see if I can come up with
> > a patch for this.  But I'd rather hear any comments first.
>
> I don't see anything immediately in looking at the code.
> It really is initialized to 6, but after that it seems to just pass
> through any request to the cairo library.

Ah, in cairo.trm we have two alternative default initializations,
CAIROPDF_PARAMS_DEFAULT and CAIROPNG_PARAMS_DEFAULT; the former
specifies a 6-point font and the latter specifies 12-point.

> The whole idea of "font size" in a png image is kind of arbitrary anyhow,
> since it depends entirely on the pixel size of the device it is viewed on.

Yes, agreed, there is a degree of freedom here, and I think the
following may be the implicit logic of how that degree of
freedom is used at present:

* In pdfcairo a 6-point font looks appropriate.

* We want the default appearance of PNG to be similar to PDF.

* You get similar-looking output by setting a fontsize of 12 for
pngcairo.

* So we'll call that (fontsize = 12) "6 points" in the doc for
pngcairo.

This seems alright until the user changes the font size in
pngcairo, and sees that "8 point" comes out smaller than "6
point".

What's to be done?  One option would be to multiply the user's
font size specification by 2 in the case of pngcairo, to make it
consistent with the "6 point" default. That is, if I say

set term pngcairo font "foo,8"

the actual size sent to the driver is 16.

The alternative would be to amend the doc for pngcairo to say that
the default is 12 points.  This has the advantage that it doesn't
change the output of existing gnuplot scripts, but the
disadvantage that it ratifies the situation where you have to
apply a factor of 2 to the font size if you want comparable output
from pdfcairo and pngcairo (in the case where you're not just
accepting the default size).

Allin Cottrell

Re: exposing cairo context from gnuplot

[Richard H. <ric...@st...>]

On Wed, 2009-09-09 at 08:42 -0700, Ethan Merritt wrote:
<snip>
> 
> I'm not a gtk programmer, but there's always Google...
> which leads me to the plplot project on SourceForge. It seems that
> plplot is somewhat similar to gnuplot in intent, but the relevant point
> is that they recently added an external cairo terminal driver "extcairo"
> that so far as I can tell from the description does exactly what you want.
> If it works for them, I don't see why it wouldn't work for us.
> Anyonw have time to check out the code and report back on how the
> information to open the context is passed?

I've had a quick look at what I think the relevant bits of PLplot are.

1. The extcairo driver within PLplot requires an existing cairo context
to be provided to it.
2. PLplot then draws over the context and returns.

there is a useful post provided by the author of the extcairo driver:
http://www.mail-archive.com/plp...@li.../msg01273.html
and example usage:
http://plplot.sourcearchive.com/documentation/5.9.2/ext-cairo-test_8c-source.html

r,

-- 
Scanned by iCritical.

Re: {png,pdf}cairo terminals and font size

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

On Wednesday 09 September 2009, Allin Cottrell wrote:
> 
> I like the *cairo terminals a lot: PNG looks good on screen and
> PDF is good for publication-quality output; and these two
> terminals share a common command-set with high fidelity, since
> they use a common back-end.  Except for one thing...
> 
> The help for both pngcairo and pdfcairo says that the default size
> for fonts is 6 points.  That's fine, and if you go with the
> default you get quite consistent-looking output from the two
> terminals.
> 
> But if you alter the size, an inconsistency emerges.  Suppose I'd
> prefer 8 points.  I do my PNG plot using
> 
> set term pngcairo font ",8"
> 
> then do my PDF plot using
> 
> set term pdfcairo font ",8"
> 
> Relative to the "6-point" baseline, the PNG file shows a smaller
> font (8 < 6, hmm) while the PDF plot shows a larger font (8 > 6).
> 
> I'm happy to take a look at the code and see if I can come up with
> a patch for this.  But I'd rather hear any comments first.

I don't see anything immediately in looking at the code.
It really is initialized to 6, but after that it seems to just pass
through any request to the cairo library.

The whole idea of "font size" in a png image is kind of arbitrary anyhow,
since it depends entirely on the pixel size of the device it is viewed on.
Perhaps there is some "pixels per inch" setting in the cairo context that
can be tweaked? 

	Ethan

{png,pdf}cairo terminals and font size

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

I like the *cairo terminals a lot: PNG looks good on screen and
PDF is good for publication-quality output; and these two
terminals share a common command-set with high fidelity, since
they use a common back-end.  Except for one thing...

The help for both pngcairo and pdfcairo says that the default size
for fonts is 6 points.  That's fine, and if you go with the
default you get quite consistent-looking output from the two
terminals.

But if you alter the size, an inconsistency emerges.  Suppose I'd
prefer 8 points.  I do my PNG plot using

set term pngcairo font ",8"

then do my PDF plot using

set term pdfcairo font ",8"

Relative to the "6-point" baseline, the PNG file shows a smaller
font (8 < 6, hmm) while the PDF plot shows a larger font (8 > 6).

I'm happy to take a look at the code and see if I can come up with
a patch for this.  But I'd rather hear any comments first.

Allin Cottrell

Re: typo in docs

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

On Wednesday 09 September 2009 14:48:28 Allin Cottrell wrote:
> 
> help pdfcairo gives, inter alia:
> 
> <quote>
> The width of all lines in the plot can be modified by the factor
> <lw> specified in `linewidth`. The default linewidth is 0.25
> points. (1 "PostScript" point = 1/72 inch = 0.353 cm)
> </quote>
> 
> Er, that should be 0.0353 cm.

True.

typo in docs

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

help pdfcairo gives, inter alia:

<quote>
The width of all lines in the plot can be modified by the factor
<lw> specified in `linewidth`. The default linewidth is 0.25
points. (1 "PostScript" point = 1/72 inch = 0.353 cm)
</quote>

Er, that should be 0.0353 cm.

-- 
Allin Cottrell
Department of Economics
Wake Forest University

Re: exposing cairo context from gnuplot

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

On Wednesday 09 September 2009, Allin Cottrell wrote:
> 
> On Wed, 9 Sep 2009, Richard Henwood wrote:
> 
> > On Tue, 2009-09-08 at 09:27 -0700, Ethan Merritt wrote:
> > > On Tuesday 08 September 2009 01:44:25 Richard Henwood wrote:
> > > > On Mon, 2009-09-07 at 17:49 -0400, Allin Cottrell wrote:
> > > > >
> > > > > I think what Richard was asking is whether the "cairo drawing
> > > > > context" struct, or "cairo_t", that is used internally by gnuplot
> > > > > could somehow be exposed programmatically...
> > > >
> > > > This is indeed what I am curious about...
> 
> > > [...] This mode of operation is already supported by the qt,
> > > tkcanvas, and x11 terminal drivers.  You initialize the
> > > context, invoke gnuplot, and tell it to draw into your
> > > existing context rather than creating a new one.  Of course
> > > the details are different in each case.
> >
> > Ah! This is good news. So presumably if a 'cairo' terminal driver
> > existed, this would provide me a way to get nice gnuplot plots into my
> > GTK/cairo application?
> 
> In the meantime a good option, I find, is to get gnuplot to create
> a PNG file (e.g. using the pngcairo terminal), then load that file
> into your GTK window using gdk_pixbuf_new_from_file() or perhaps
> cairo_image_surface_create_from_png().  Of course, you don't
> get a vector graphic that way.
> 
> I'm not quite sure how a "cairo term" would work.  You couldn't
> actually pass a cairo drawing context to gnuplot, could you?

I'm not a gtk programmer, but there's always Google...
which leads me to the plplot project on SourceForge. It seems that
plplot is somewhat similar to gnuplot in intent, but the relevant point
is that they recently added an external cairo terminal driver "extcairo"
that so far as I can tell from the description does exactly what you want.
If it works for them, I don't see why it wouldn't work for us.
Anyonw have time to check out the code and report back on how the
information to open the context is passed?

	Ethan

> With the x11 term, for example, you can say "window <XID>", passing the
> X11 ID of the window you want to draw into, in string form. I
> don't offhand see what a cairo counterpart would look like.
 
> Here's something I haven't tried, but that might be nice. Since
> gnuplot already does SVG, one could get gnuplot to write an SVG
> file, create a cairo context using gdk, then call librsvg to read
> the SVG file into your cairo context.  This would not require any
> modifications to gnuplot.
> 
> Allin Cottrell
> 

Re: exposing cairo context from gnuplot

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

On Wed, 9 Sep 2009, Richard Henwood wrote:

> On Tue, 2009-09-08 at 09:27 -0700, Ethan Merritt wrote:
> > On Tuesday 08 September 2009 01:44:25 Richard Henwood wrote:
> > > On Mon, 2009-09-07 at 17:49 -0400, Allin Cottrell wrote:
> > > >
> > > > I think what Richard was asking is whether the "cairo drawing
> > > > context" struct, or "cairo_t", that is used internally by gnuplot
> > > > could somehow be exposed programmatically...
> > >
> > > This is indeed what I am curious about...

> > [...] This mode of operation is already supported by the qt,
> > tkcanvas, and x11 terminal drivers.  You initialize the
> > context, invoke gnuplot, and tell it to draw into your
> > existing context rather than creating a new one.  Of course
> > the details are different in each case.
>
> Ah! This is good news. So presumably if a 'cairo' terminal driver
> existed, this would provide me a way to get nice gnuplot plots into my
> GTK/cairo application?

In the meantime a good option, I find, is to get gnuplot to create
a PNG file (e.g. using the pngcairo terminal), then load that file
into your GTK window using gdk_pixbuf_new_from_file() or perhaps
cairo_image_surface_create_from_png().  Of course, you don't
get a vector graphic that way.

I'm not quite sure how a "cairo term" would work.  You couldn't
actually pass a cairo drawing context to gnuplot, could you? With
the x11 term, for example, you can say "window <XID>", passing the
X11 ID of the window you want to draw into, in string form. I
don't offhand see what a cairo counterpart would look like.

Here's something I haven't tried, but that might be nice. Since
gnuplot already does SVG, one could get gnuplot to write an SVG
file, create a cairo context using gdk, then call librsvg to read
the SVG file into your cairo context.  This would not require any
modifications to gnuplot.

Allin Cottrell

Re: exposing cairo context from gnuplot

[Richard H. <ric...@st...>]

On Tue, 2009-09-08 at 09:27 -0700, Ethan Merritt wrote:
> On Tuesday 08 September 2009 01:44:25 Richard Henwood wrote:
> > On Mon, 2009-09-07 at 17:49 -0400, Allin Cottrell wrote:
> > > 
> > > I think what Richard was asking is whether the "cairo drawing
> > > context" struct, or "cairo_t", that is used internally by gnuplot
> > > could somehow be exposed programmatically.  But I don't see how
> > > this could be done -- seems to me it would require building
> > > gnuplot as a library, not a stand-alone executable.
> > > 
> > 
> > This is indeed what I am curious about. As you comment: if the 'cairo
> > drawing context' was exposed, it would then allow gnuplot to behave as a
> > library. i.e. if one was writing a cairo widget for a (typically GTK)
> > application, one may create a context (cairo_t), pass it to gnuplot
> > (along with some commands to plot a graph on it), and then return it to
> > the application for display.
> 
> The two halves of your statement do not quite match up.
> While I understand wanting to pass gnuplot a context, e.g. a widget in
> an external application, I don't see what that has to do with making
> gnuplot into a library.  This mode of operation is already supported by the
> qt, tkcanvas, and x11 terminal drivers.  You initialize the context,
> invoke gnuplot, and tell it to draw into your existing context rather 
> than creating a new one.  Of course the details are different in each case.
> 

Ah! This is good news. So presumably if a 'cairo' terminal driver
existed, this would provide me a way to get nice gnuplot plots into my
GTK/cairo application?

> > In the first instance I thought I would raise this idea for discussion.
> > If it is technically feasible - and within the gnuplot mission - I think
> > there is an excellent opportunity to both have a extensive, publication
> > quality plotting library available to gtk/cairo application developers -
> > and increase usage of gnuplot.
> 
> I personally think that plotting libraries, as opposed to plotting programs,
> are not the way to go.  That's just my personal opinion, but it is based
> on years of programming experience using both approaches.
>  

I don't think I have sufficient experience to comment - and defer to
your judgement on this. I will have a poke around with the existing
qt/tkcanvas/x11 terminals and see how I get on with them.

cheers,
Richard
-- 
Scanned by iCritical.

Re: Will "Volatile Data" in gnuplot 4.3 (CVS) be planned to be implemented in the next major release : Ver 4.4.x ?

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

Hello Ethan Merritt 

Thank you for your reply.  Supporting "Volatile Data" in gnuplot 4.4 is very nice for octave users!!

Regards

Tatsuro 

(Sorry the previous mail forget to cc. to "gnuplot-beta" <gnu...@li...>. Please
ignore that.)

--- Ethan Merritt  wrote:

> On Tuesday 08 September 2009 16:13:19 Tatsuro MATSUOKA wrote:
> > Hello
> > 
> > Some discussion had been done the mouse zooming in 2D plot in octave, by which all plotting
> command
> > and data are sent to gnuplot via pipe.
> > 
> > I explained that the above is only realized in gnuplot 4.3 (cvs) source trees of which are
> later than
> > 2007-08-31.
> > 
> > To my knowldge, this will be realized the supports of Volatile Data in terms of the gnuplot.
> > 
> > Is my knowledge right
> 
> Yes. Version 4.4 will include everything that was in CVS up to 1 June 2009,
> plus all bugfixes applied since then,
> plus many but not all of the changes applied to CVS since then.
> 
> The major things that it does not include from current CVS:
> mouse-wheel interaction
> qt terminal driver
> dashed line support in cairo
> 
> 	Ethan
> 
> 
> > 
> > ***********
> > Volatile Data
> > 
> > The new command refreshis similar to replotexcept that it uses the previously-stored input
> data values
> > rather than rereading the input data file.Mouse operations (zoom,rotate)will automatically use
> > refreshrather than replotif the input data stream is marked volatile.Piped or in-line data is
> > automatically treated as volatile.See refresh,plot datafile volatile.
> > ***********
> > 
> > Will "Volatile Data" in gnuplot 4.3 (CVS) be planned to be implemented in the next major
> release : Ver
> > 4.4.x ?
> > 
> > Regards
> > 
> > Tatsuro
> > 
> > 	
> > 
> > --------------------------------------
> > Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
> > http://pr.mail.yahoo.co.jp/ec10years/
> > 
> 
> 
> 
> -- 
> Ethan A Merritt
> Biomolecular Structure Center
> University of Washington, Seattle 98195-7742
> 


--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/

Re: Will "Volatile Data" in gnuplot 4.3 (CVS) be planned to be implemented in the next major release : Ver 4.4.x ?

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

On Tuesday 08 September 2009 16:13:19 Tatsuro MATSUOKA wrote:
> Hello
> 
> Some discussion had been done the mouse zooming in 2D plot in octave, by which all plotting command
> and data are sent to gnuplot via pipe.
> 
> I explained that the above is only realized in gnuplot 4.3 (cvs) source trees of which are later than
> 2007-08-31.
> 
> To my knowldge, this will be realized the supports of Volatile Data in terms of the gnuplot.
> 
> Is my knowledge right

Yes. Version 4.4 will include everything that was in CVS up to 1 June 2009,
plus all bugfixes applied since then,
plus many but not all of the changes applied to CVS since then.

The major things that it does not include from current CVS:
mouse-wheel interaction
qt terminal driver
dashed line support in cairo

	Ethan


> 
> ***********
> Volatile Data
> 
> The new command refreshis similar to replotexcept that it uses the previously-stored input data values
> rather than rereading the input data file.Mouse operations (zoom,rotate)will automatically use
> refreshrather than replotif the input data stream is marked volatile.Piped or in-line data is
> automatically treated as volatile.See refresh,plot datafile volatile.
> ***********
> 
> Will "Volatile Data" in gnuplot 4.3 (CVS) be planned to be implemented in the next major release : Ver
> 4.4.x ?
> 
> Regards
> 
> Tatsuro
> 
> 	
> 
> --------------------------------------
> Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
> http://pr.mail.yahoo.co.jp/ec10years/
> 



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

Will "Volatile Data" in gnuplot 4.3 (CVS) be planned to be implemented in the next major release : Ver 4.4.x ?

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

Hello

Some discussion had been done the mouse zooming in 2D plot in octave, by which all plotting command
and data are sent to gnuplot via pipe.

I explained that the above is only realized in gnuplot 4.3 (cvs) source trees of which are later than
2007-08-31.

To my knowldge, this will be realized the supports of Volatile Data in terms of the gnuplot.

Is my knowledge right

***********
Volatile Data

The new command refreshis similar to replotexcept that it uses the previously-stored input data values
rather than rereading the input data file.Mouse operations (zoom,rotate)will automatically use
refreshrather than replotif the input data stream is marked volatile.Piped or in-line data is
automatically treated as volatile.See refresh,plot datafile volatile.
***********

Will "Volatile Data" in gnuplot 4.3 (CVS) be planned to be implemented in the next major release : Ver
4.4.x ?

Regards

Tatsuro

	

--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/

Re: exposing cairo context from gnuplot

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

On Tuesday 08 September 2009 01:44:25 Richard Henwood wrote:
> On Mon, 2009-09-07 at 17:49 -0400, Allin Cottrell wrote:
> > 
> > I think what Richard was asking is whether the "cairo drawing
> > context" struct, or "cairo_t", that is used internally by gnuplot
> > could somehow be exposed programmatically.  But I don't see how
> > this could be done -- seems to me it would require building
> > gnuplot as a library, not a stand-alone executable.
> > 
> 
> This is indeed what I am curious about. As you comment: if the 'cairo
> drawing context' was exposed, it would then allow gnuplot to behave as a
> library. i.e. if one was writing a cairo widget for a (typically GTK)
> application, one may create a context (cairo_t), pass it to gnuplot
> (along with some commands to plot a graph on it), and then return it to
> the application for display.

The two halves of your statement do not quite match up.
While I understand wanting to pass gnuplot a context, e.g. a widget in
an external application, I don't see what that has to do with making
gnuplot into a library.  This mode of operation is already supported by the
qt, tkcanvas, and x11 terminal drivers.  You initialize the context,
invoke gnuplot, and tell it to draw into your existing context rather 
than creating a new one.  Of course the details are different in each case.

> In the first instance I thought I would raise this idea for discussion.
> If it is technically feasible - and within the gnuplot mission - I think
> there is an excellent opportunity to both have a extensive, publication
> quality plotting library available to gtk/cairo application developers -
> and increase usage of gnuplot.

I personally think that plotting libraries, as opposed to plotting programs,
are not the way to go.  That's just my personal opinion, but it is based
on years of programming experience using both approaches.
 
> Any thoughts greatly appreciated.
> Richard

	Ethan

Re: exposing cairo context from gnuplot

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

On Tue, 8 Sep 2009, Richard Henwood wrote:

> On Mon, 2009-09-07 at 17:49 -0400, Allin Cottrell wrote:
> > On Mon, 7 Sep 2009, Ethan Merritt wrote:
> >
> > > On Monday 07 September 2009, Richard Henwood wrote:
> > > > Hi All,
> > > >
> > > > I've been using Cairo (cairographics.org) a fair bit recently. I have
> > > > not found a plotting library which is as mature as gnuplot.
> > > >
> > > > I understand that the wxWidgets terminal uses cairo.
> > > >
> > > > Has anyone considered the possibility of exposing the cairo context from
> > > > within gnuplot/wxWidgets to the outside world?
> > >
> > > The development version has two new drivers - pngcairo and pdfcairo,
> > > the use the cairo library.  Not sure if that's what you meant.
> > > Both drivers will be in the version 4.4 release candidate, which I
> > > hope we can put out soonish.
> >
> > I think what Richard was asking is whether the "cairo drawing
> > context" struct, or "cairo_t", that is used internally by gnuplot
> > could somehow be exposed programmatically.  But I don't see how
> > this could be done -- seems to me it would require building
> > gnuplot as a library, not a stand-alone executable.
> >
>
> This is indeed what I am curious about. As you comment: if the
> 'cairo drawing context' was exposed, it would then allow gnuplot
> to behave as a library. i.e. if one was writing a cairo widget
> for a (typically GTK) application, one may create a context
> (cairo_t), pass it to gnuplot (along with some commands to plot
> a graph on it), and then return it to the application for
> display.

I agree this would be very nice, but I'd put the conditionality
the other way round: if it were possible to build gnuplot as a
library, then it would be feasible to expose the relevant cairo_t
via a suitable API.

There are many programs that use gnuplot in "slave" mode and
having a "libgnuplot" would be very useful in that context.  But
so far as I know (Ethan can correct me if I'm wrong) this is not
on an active TODO list.

However, gnuplot's GPVAL* variables, which provide a means of
accessing internal data in text form, can be quite helpful if your
program functions as a "driver" of gnuplot.

Allin Cottrell

gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x is updated

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

Hello

gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x is updated.

Topic
pdfcairo and png cairo terminals are supported only on cygwin-1.7.0. (The required libraries are only
prepared for the cygwin-1.7)

http://www.tatsuromatsuoka.com/gnuplot/Eng/cygbin/

Enjoy!!

Tatsuro

--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/

Re: exposing cairo context from gnuplot

[Richard H. <ric...@st...>]

On Mon, 2009-09-07 at 17:49 -0400, Allin Cottrell wrote:
> On Mon, 7 Sep 2009, Ethan Merritt wrote:
> 
> > On Monday 07 September 2009, Richard Henwood wrote:
> > > Hi All,
> > >
> > > I've been using Cairo (cairographics.org) a fair bit recently. I have
> > > not found a plotting library which is as mature as gnuplot.
> > >
> > > I understand that the wxWidgets terminal uses cairo.
> > >
> > > Has anyone considered the possibility of exposing the cairo context from
> > > within gnuplot/wxWidgets to the outside world?
> >
> > The development version has two new drivers - pngcairo and pdfcairo,
> > the use the cairo library.  Not sure if that's what you meant.
> > Both drivers will be in the version 4.4 release candidate, which I
> > hope we can put out soonish.
> 
> I think what Richard was asking is whether the "cairo drawing
> context" struct, or "cairo_t", that is used internally by gnuplot
> could somehow be exposed programmatically.  But I don't see how
> this could be done -- seems to me it would require building
> gnuplot as a library, not a stand-alone executable.
> 

This is indeed what I am curious about. As you comment: if the 'cairo
drawing context' was exposed, it would then allow gnuplot to behave as a
library. i.e. if one was writing a cairo widget for a (typically GTK)
application, one may create a context (cairo_t), pass it to gnuplot
(along with some commands to plot a graph on it), and then return it to
the application for display.

In the first instance I thought I would raise this idea for discussion.
If it is technically feasible - and within the gnuplot mission - I think
there is an excellent opportunity to both have a extensive, publication
quality plotting library available to gtk/cairo application developers -
and increase usage of gnuplot.

>From a technical standpoint - I would imagine starting with the
wxWidgets terminal code would be a 'hacky' way to get something
working. 

Any thoughts greatly appreciated.
Richard

-- 
Scanned by iCritical.

Re: exposing cairo context from gnuplot

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

On Mon, 7 Sep 2009, Ethan Merritt wrote:

> On Monday 07 September 2009, Richard Henwood wrote:
> > Hi All,
> >
> > I've been using Cairo (cairographics.org) a fair bit recently. I have
> > not found a plotting library which is as mature as gnuplot.
> >
> > I understand that the wxWidgets terminal uses cairo.
> >
> > Has anyone considered the possibility of exposing the cairo context from
> > within gnuplot/wxWidgets to the outside world?
>
> The development version has two new drivers - pngcairo and pdfcairo,
> the use the cairo library.  Not sure if that's what you meant.
> Both drivers will be in the version 4.4 release candidate, which I
> hope we can put out soonish.

I think what Richard was asking is whether the "cairo drawing
context" struct, or "cairo_t", that is used internally by gnuplot
could somehow be exposed programmatically.  But I don't see how
this could be done -- seems to me it would require building
gnuplot as a library, not a stand-alone executable.

Allin Cottrell