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

Re: x11: slow drawing after set xtics font

[Ben A. <bpa...@ma...>]

On Friday, June 19, 2009, at 12:47PM, "Ethan Merritt" <merritt@u.washington.edu> wrote:
>
>> > Cannot it get the list via xlsfont, GDFONTPATH, etc. and then use
>> > arial/verdana/helvetica/ (i.e. the usual ttf and postscript fonts)?
>> >
>> 
>> I like that idea (provided xlsfonts always accompanies x11).
>
>It does not.  In particular it does seem to be provided by default in xorg
>distributions.
>
>> If we wanted to match a scalable font whose metrics are as close to  
>> Helvetica as possible, how would that be done with xlsfonts?
>
>I think you are attacking this from the wrong end.
>If Octave wants to use a "standard" font but are worried that the user's font 
>server may not provide it, you should include a FAQ or trouble-shooting guide
>explaining how to add that font to the font server.  
>
>    Ethan

That is a reasonable thing to include in the manual, but we'd also like to ensure that the graphics work with the user tries his/her first plot command.

Re: x11: slow drawing after set xtics font

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

On Friday 19 June 2009, Ethan Merritt wrote:
> > > Cannot it get the list via xlsfont, GDFONTPATH, etc. and then use
> > > arial/verdana/helvetica/ (i.e. the usual ttf and postscript fonts)?
> > >
> > 
> > I like that idea (provided xlsfonts always accompanies x11).
> 
> It does not.  In particular it does     seem to be provided by default in xorg
                                      not
                                      ^^^    
> distributions.

Re: x11: slow drawing after set xtics font

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

> > Cannot it get the list via xlsfont, GDFONTPATH, etc. and then use
> > arial/verdana/helvetica/ (i.e. the usual ttf and postscript fonts)?
> >
> 
> I like that idea (provided xlsfonts always accompanies x11).

It does not.  In particular it does seem to be provided by default in xorg
distributions.

> If we wanted to match a scalable font whose metrics are as close to  
> Helvetica as possible, how would that be done with xlsfonts?

I think you are attacking this from the wrong end.
If Octave wants to use a "standard" font but are worried that the user's font 
server may not provide it, you should include a FAQ or trouble-shooting guide
explaining how to add that font to the font server.  

    Ethan

Re: x11: slow drawing after set xtics font

[Ben A. <bpa...@ma...>]

On Jun 19, 2009, at 2:50 AM, Petr Mikulik wrote:

>>>> If the drawing gets so slow, it seems that the server searches  
>>>> the font list
>>>> for each tic for font "*", right? Cannot this be eliminated?
>>>>
>>>> I think that Octave should produce gnuplot code like:
>>>>
>>>> set terminal x11 font "arial"
>>>> set title "Hello world" font ",12"
>>>>
>>>> instead of
>>>>
>>>> set terminal x11
>>>> set title "Hello world" font "*,12"
>>
>> But I am puzzled why Octave would ever want to pass "*" as a font  
>> name.
>
> What I can see on my Linux is that
> gnuplot> set title "Hello world" font ",20"; p x
> gnuplot> set title "Hello world" font "*,20"; p x
>
> show the same drawing, while in
>
> gnuplot> set title "Hello world" font ",22"; p x
> gnuplot> set title "Hello world" font "*,22"; p x
> the case ",22" shows an ugly text.
>
>
>>> The problem the octave developers have is that identifying a font
>>> that reliably works for x11, aqua and windows ...
>>> and hopefully works for the other terminals as well.
>>
>> I am afraid that is impossible.  Neither Octave nor gnuplot has any
>> control over what fonts are available on a user's system, and  
>> different
>> terminal types intrinsically use different types of fonts.
>
> Cannot it get the list via xlsfont, GDFONTPATH, etc. and then use
> arial/verdana/helvetica/ (i.e. the usual ttf and postscript fonts)?
>

I like that idea (provided xlsfonts always accompanies x11).

If we wanted to match a scalable font whose metrics are as close to  
Helvetica as possible, how would that be done with xlsfonts?

Ben

Re: x11: slow drawing after set xtics font

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

> > > If the drawing gets so slow, it seems that the server searches the font list 
> > > for each tic for font "*", right? Cannot this be eliminated?
> > > 
> > > I think that Octave should produce gnuplot code like:
> > > 
> > > set terminal x11 font "arial"
> > > set title "Hello world" font ",12"
> > > 
> > > instead of
> > > 
> > > set terminal x11
> > > set title "Hello world" font "*,12"
> 
> But I am puzzled why Octave would ever want to pass "*" as a font name.

What I can see on my Linux is that
gnuplot> set title "Hello world" font ",20"; p x
gnuplot> set title "Hello world" font "*,20"; p x

show the same drawing, while in

gnuplot> set title "Hello world" font ",22"; p x
gnuplot> set title "Hello world" font "*,22"; p x
the case ",22" shows an ugly text.


> > The problem the octave developers have is that identifying a font 
> > that reliably works for x11, aqua and windows ... 
> > and hopefully works for the other terminals as well.  
> 
> I am afraid that is impossible.  Neither Octave nor gnuplot has any
> control over what fonts are available on a user's system, and different
> terminal types intrinsically use different types of fonts.

Cannot it get the list via xlsfont, GDFONTPATH, etc. and then use 
arial/verdana/helvetica/ (i.e. the usual ttf and postscript fonts)?

> The right thing to pass is either no font option at all (which on all
> terminals should yield a usable default), or   ",12"   which will 
> yield that same default font in a particular size. 


---
PM

Re: x11: slow drawing after set xtics font

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

On Thursday 18 June 2009 06:55:45 Daniel J Sebald wrote:
> Petr Mikulik wrote:
> >>'*' as a font name is a disadvantageous choice: the font selection
> >>mechanism of the x-server searches through all the fonts to find
> >>one which matches the name (there is a speed difference between
> >>specifying '*' and the name of a non existent font) and has the
> >>selected font size - in the normal x-server installation first the
> >>bitmapped fonts are searched then the scalable.
> > 
> > 
> > If the drawing gets so slow, it seems that the server searches the font list 
> > for each tic for font "*", right? Cannot this be eliminated?
> > 
> > I think that Octave should produce gnuplot code like:
> > 
> > set terminal x11 font "arial"
> > set title "Hello world" font ",12"
> > 
> > instead of
> > 
> > set terminal x11
> > set title "Hello world" font "*,12"
> 
> I suggest gnuplot be modified slightly to deal with this. 
> Rather than continually searching for the font when '*' is the font name, 

It's not gnuplot that's doing the search, it's the x11 font server.

> x11 terminal should search for the font the first time, 
> record the default font file name to memory, 
> and from there forward use the saved file name, not searching.  

There is no file name.  The font is provided by the x11 font server.


But I am puzzled why Octave would ever want to pass "*" as a font name.
It is true that x11 will eventually resolve this to something, but I
don't think many/any other terminal type will handle it usefully.


Ben Abbott wrote>
> The problem the octave developers have is that identifying a font 
> that reliably works for x11, aqua and windows ... 
> and hopefully works for the other terminals as well.  

I am afraid that is impossible.  Neither Octave nor gnuplot has any
control over what fonts are available on a user's system, and different
terminal types intrinsically use different types of fonts.

The right thing to pass is either no font option at all (which on all
terminals should yield a usable default), or   ",12"   which will 
yield that same default font in a particular size. 




	Ethan

Re: x11: slow drawing after set xtics font

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

Petr Mikulik wrote:
>>'*' as a font name is a disadvantageous choice: the font selection
>>mechanism of the x-server searches through all the fonts to find
>>one which matches the name (there is a speed difference between
>>specifying '*' and the name of a non existent font) and has the
>>selected font size - in the normal x-server installation first the
>>bitmapped fonts are searched then the scalable.
> 
> 
> If the drawing gets so slow, it seems that the server searches the font list 
> for each tic for font "*", right? Cannot this be eliminated?
> 
> I think that Octave should produce gnuplot code like:
> 
> set terminal x11 font "arial"
> set title "Hello world" font ",12"
> 
> instead of
> 
> set terminal x11
> set title "Hello world" font "*,12"

I suggest gnuplot be modified slightly to deal with this.  Rather than continually searching for the font when '*' is the font name, x11 terminal should search for the font the first time, record the default font file name to memory, and from there forward use the saved file name, not searching.  The drawback is that the x11 terminal default font would be changeable on the fly, but that isn't an uncommon expectation with these sorts of things.

Dan

Re: unified dashes

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

On Wednesday 17 June 2009, Petr Mikulik wrote:
> > > It seems x11 supports the "dash" option, but ignores this.
> > > Is the dash line functionality not implemented?
> > 
> > It is implemented and fully functional.
> > It just happens to look terrible on the screen, so the default
> > settings don't use it :-)
> > 
> > The definition of dash types is controlled by Xresources.
> > See the file Gnuplot.app-defaults for full information.
> 
> In my $HOME/.Xdefaults, I have no dash option (compared to 
> Gnuplot.app-defaults). Therefore I expect that running
> 
> 	gnuplot -dashed
> 
> would use the default dashed pattern sequence, it does not seem so.
> 
> It works after
> 	xrdb -merge Gnuplot.app-defaults 
> 	gnuplot -dashed
> 
> Could these defaults work also without putting the new stuff into xrdb?

You don't like configuration files?

> > > Could wxt add also this option?

Added to CVS a few days ago.

> Comparing the dashed output of x11, wxt, postscript, pdfcairo and pngcairo 
> for "dashcolor.dem", the pattern is not consistent -- dash length are 
> different, in some terminals there is "-." and in some "-..". It would be 
> great if the sequence is consistent, for example:
> 
> - (solid), -- (dashed), .. (dotted?), -. (dashdot), --. (dashdashdot),
> -.. (dashdotdot) etc.
> 
> I propose that the dash stuff to be removed from config's (of x11, for 
> example) and replace it by user-defined values?
> 
> plot sin(x) with line dashtype "-.." {dl NNN | dd NNN}

There have been past discussions about this.
I think the best approach suggested so far is to add "dashtype" as a
property in struct lp_style_type, and track it as a regular line 
property along with line width, line color, point type, point style, and so on.

> I'm not sure how "dashlength|dl" works ... maybe "dashdensity|dd" option 
> could be used to increase/decrese dash density?

Most terminals specify dash pattern by an array of lengths; successive
array elements control the length of the first line segment, the length of
the first gap, the length of the second line segment, the length of the
second gap, and so on.  "dashlength" is applied as a multiplier for these
lengths.   

Re: x11: slow drawing after set xtics font

[Thomas S. <t.s...@fz...>]

it would be best to specify the font once:

set terminal x11 font "arial,12"

and then give a font for title and labels only if it must be
different from "arial,12"

if a font isn't found by the x-server then another font is
taken instead without error message.

specifying a font and/or size for tics makes the plotting
extremely slow and is needless, because the tics
should be written in the default (the one given when
setting the terminal) font and size.


Ben Abbott wrote:
> 
>  On Thursday, June 18, 2009, at 08:32AM, "Petr Mikulik"
> <mi...@ph...> wrote:
>>> '*' as a font name is a disadvantageous choice: the font selection
>>> mechanism of the x-server searches through all the fonts to find
>>> one which matches the name (there is a speed difference between
>>> specifying '*' and the name of a non existent font) and has the
>>> selected font size - in the normal x-server installation first the
>>> bitmapped fonts are searched then the scalable.
>>
>>If the drawing gets so slow, it seems that the server searches the font
list 
>>for each tic for font "*", right? Cannot this be eliminated?
>>
>>I think that Octave should produce gnuplot code like:
>>
>>set terminal x11 font "arial"
>>set title "Hello world" font ",12"
>>
>>instead of
>>
>>set terminal x11
>>set title "Hello world" font "*,12"
>>
> 
> The problem the octave developers have is that identifying a font that
> reliably works for x11, aqua and windows ... and hopefully works for the
> other terminals as well.
> 
> If a font name is used (such as Arial) that is not present for a
> particular terminal gnuplot prints errors which results in user complaints
> and bug reports.
> 
> I've tested octave's graphics using the font spec ",12" and see no problem
> (i.e. the fontname is left blank). Would this work? ... Would x11 default
> to an existing font?
> 
> Ben
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing 
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 

-- 
View this message in context: http://www.nabble.com/x11%3A-slow-drawing-after-set-xtics-font-tp24088151p24093308.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: x11: slow drawing after set xtics font

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

> '*' as a font name is a disadvantageous choice: the font selection
> mechanism of the x-server searches through all the fonts to find
> one which matches the name (there is a speed difference between
> specifying '*' and the name of a non existent font) and has the
> selected font size - in the normal x-server installation first the
> bitmapped fonts are searched then the scalable.

If the drawing gets so slow, it seems that the server searches the font list 
for each tic for font "*", right? Cannot this be eliminated?

I think that Octave should produce gnuplot code like:

set terminal x11 font "arial"
set title "Hello world" font ",12"

instead of

set terminal x11
set title "Hello world" font "*,12"


> you can see this by specifying different font sizes: different
> fonts (sometimes even none) are selected.
> 
> to make the plot fast select the name of a font which exists.
> 
> 
> Petr Mikulik wrote:
> > 
> > Gnuplot x11 drawings in Octave 3.2 appear displayed much slower than it is 
> > usual. This slow-down can be reproduced in gnuplot by e.g.:
> > 
> > 
> > set terminal x11 close
> > test
> > 
> > set terminal x11 close
> > set title "Hello world" font "*,12" # no effect to speed
> > set xtics font "*,12"	# makes slow drawing
> > 
> > plot sin(x)/x
> > 
> > 
> > This slow-down is caused by
> > 	set xtics font "*,12" 
> > while the font specification in "set title" does not slow gnuplot down.
> > 
> > Note that using "set terminal wxt" does change its speed after the font 
> > command.
> > 
> > What can be the reason? Could the speed be improved?
> > The delay of replotting is rather boring when working with Octave on a 
> > laptop running on battery :-(
> > 
> > ---
> > PM

Re: x11: slow drawing after set xtics font

[Ben A. <bpa...@ma...>]

 On Thursday, June 18, 2009, at 08:32AM, "Petr Mikulik" <mi...@ph...> wrote:
>> '*' as a font name is a disadvantageous choice: the font selection
>> mechanism of the x-server searches through all the fonts to find
>> one which matches the name (there is a speed difference between
>> specifying '*' and the name of a non existent font) and has the
>> selected font size - in the normal x-server installation first the
>> bitmapped fonts are searched then the scalable.
>
>If the drawing gets so slow, it seems that the server searches the font list 
>for each tic for font "*", right? Cannot this be eliminated?
>
>I think that Octave should produce gnuplot code like:
>
>set terminal x11 font "arial"
>set title "Hello world" font ",12"
>
>instead of
>
>set terminal x11
>set title "Hello world" font "*,12"
>

The problem the octave developers have is that identifying a font that reliably works for x11, aqua and windows ... and hopefully works for the other terminals as well.

If a font name is used (such as Arial) that is not present for a particular terminal gnuplot prints errors which results in user complaints and bug reports.

I've tested octave's graphics using the font spec ",12" and see no problem (i.e. the fontname is left blank). Would this work? ... Would x11 default to an existing font?

Ben

Re: x11: slow drawing after set xtics font

[Thomas S. <t.s...@fz...>]

'*' as a font name is a disadvantageous choice: the font selection
mechanism of the x-server searches through all the fonts to find
one which matches the name (there is a speed difference between
specifying '*' and the name of a non existent font) and has the
selected font size - in the normal x-server installation first the
bitmapped fonts are searched then the scalable.

you can see this by specifying different font sizes: different
fonts (sometimes even none) are selected.

to make the plot fast select the name of a font which exists.


Petr Mikulik wrote:
> 
> Gnuplot x11 drawings in Octave 3.2 appear displayed much slower than it is 
> usual. This slow-down can be reproduced in gnuplot by e.g.:
> 
> 
> set terminal x11 close
> test
> 
> set terminal x11 close
> set title "Hello world" font "*,12" # no effect to speed
> set xtics font "*,12"	# makes slow drawing
> 
> plot sin(x)/x
> 
> 
> This slow-down is caused by
> 	set xtics font "*,12" 
> while the font specification in "set title" does not slow gnuplot down.
> 
> Note that using "set terminal wxt" does change its speed after the font 
> command.
> 
> What can be the reason? Could the speed be improved?
> The delay of replotting is rather boring when working with Octave on a 
> laptop running on battery :-(
> 
> ---
> PM
> 
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing 
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 

-- 
View this message in context: http://www.nabble.com/x11%3A-slow-drawing-after-set-xtics-font-tp24088151p24089641.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

x11: slow drawing after set xtics font

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

Gnuplot x11 drawings in Octave 3.2 appear displayed much slower than it is 
usual. This slow-down can be reproduced in gnuplot by e.g.:


set terminal x11 close
test

set terminal x11 close
set title "Hello world" font "*,12" # no effect to speed
set xtics font "*,12"	# makes slow drawing

plot sin(x)/x


This slow-down is caused by
	set xtics font "*,12" 
while the font specification in "set title" does not slow gnuplot down.

Note that using "set terminal wxt" does change its speed after the font 
command.

What can be the reason? Could the speed be improved?
The delay of replotting is rather boring when working with Octave on a 
laptop running on battery :-(

---
PM

unified dashes

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

> > It seems x11 supports the "dash" option, but ignores this.
> > Is the dash line functionality not implemented?
> 
> It is implemented and fully functional.
> It just happens to look terrible on the screen, so the default
> settings don't use it :-)
> 
> The definition of dash types is controlled by Xresources.
> See the file Gnuplot.app-defaults for full information.

In my $HOME/.Xdefaults, I have no dash option (compared to 
Gnuplot.app-defaults). Therefore I expect that running

	gnuplot -dashed

would use the default dashed pattern sequence, it does not seem so.

It works after
	xrdb -merge Gnuplot.app-defaults 
	gnuplot -dashed

Could these defaults work also without putting the new stuff into xrdb?

> > Could wxt add also this option?
> 
> Almost certainly.  The pdfcairo terminal support "dashed", so the
> support must be there in the underlying cairo library.

Comparing the dashed output of x11, wxt, postscript, pdfcairo and pngcairo 
for "dashcolor.dem", the pattern is not consistent -- dash length are 
different, in some terminals there is "-." and in some "-..". It would be 
great if the sequence is consistent, for example:

- (solid), -- (dashed), .. (dotted?), -. (dashdot), --. (dashdashdot),
-.. (dashdotdot) etc.

I propose that the dash stuff to be removed from config's (of x11, for 
example) and replace it by user-defined values?

plot sin(x) with line dashtype "-.." {dl NNN | dd NNN}

I'm not sure how "dashlength|dl" works ... maybe "dashdensity|dd" option 
could be used to increase/decrese dash density?

---
PM

[OT] Gnuplot Book: Galley Proofs Received!

[Philipp K. J. <ja...@ie...>]

After a long delay, due to technical difficulties during 
final layout, today I received the first set of galley 
proofs for review!

This means that the actual printed book should definitely 
be available for shipping within the next few weeks.

For more details on the book, see:
	www.manning.com/janert

Many thanks to everyone for your patience!

Best,

	Ph.

Re: plot issues -> favor pdfcairo [new changeset 2]

[Ben A. <bpa...@ma...>]

On Jun 15, 2009, at 3:35 AM, Benjamin Lindner wrote:

> Ethan Merritt wrote:
>> On Wednesday 10 June 2009 07:46:08 Benjamin Lindner wrote:
>>> Ben Abbott wrote:
>>>> On Wednesday, June 10, 2009, at 09:11AM, "Benjamin Lindner" <lin...@gm... 
>>>> > wrote:
>>>>> Ben Abbott wrote:
>>>>>> On Jun 10, 2009, at 5:02 AM, Benjamin Lindner wrote:
>>>>>>
>>>>>>> plot(0:0.1:10, sin(0:0.1:10), "@-;sin;", 0:0.1:10,  
>>>>>>> cos(0:0.1:10), "@-;cos;");
>>>>>>> print -depsc2 -debug:print.eps.log test.eps
>>>>>>> print -dpsc2 -debug:print.ps.log  test.ps
>>>>>>> print -dpng  -debug:print.png.log  test.png
>>>>>>> print -demf  -debug:print.emf.log  test.emf
>>>>>>> print -dpdf   -debug:print.pdf.log test.pdf
>>>>>>>
>>>>>>> I get now a pdfcairo and pngcairo output.
>>>>>>>
>>>>>>> However the pdfcairo output seems buggy, since it consists of  
>>>>>>> 3 pages: a blank first page, a second page with the expected  
>>>>>>> graph and a blank third page.
>>>>>>> Hmm, looks like a problem with gnuplot I guess.
>>>>>>>
>>>>>>> benjamin
>>>>>> What version of gnuplot are you running?
>>>>>>
>>>>>> I can run 4.2.2, 4.2.3, 4.2.4, 4.2,5 and 4.3.0 (current  
>>>>>> developers sources). If I can confirm the same behavior, I'll  
>>>>>> add "pdfcairo_is_broken" to __gnuplot_has_feature__ and switch  
>>>>>> to ghostrscript for that instance.
>>>>>>
>>>>> I have a 4.3.0 version, namely the CVS 2008-11-21 snapshot.
>>>>>
>>>>> benjamin
>>>> Ok. I'm running developers sources that are less than a week old.  
>>>> I don't see the problem you reported.
>>>>
>>> Probably it has been fixed in CVS.
>>> I hope there will be another gnuplot CVS snapshot, so I can  
>>> include it in a octave 3.2.1 release.
>> Yes. There was a cairo terminal bug fixed 10 May 2009.
>> If you generate a snapshot, please use the 4.4 pre-release sources  
>> rather than the 4.3 sources.
>> It is currently marked "alpha", but if you have a need for a more  
>> well-defined
>> version level we could bump that to "-rc1".
>> 	Ethan
>
> Ok, possibly dumb question: How do I get the 4.4 sources?
> I'm doing a "cvs update -d" from the sourceforge sources as  
> recommended on the gnuplot website. Correct?
>
> For inclusion in an octave binary a snapshot would be good, because  
> it makes support easier if there is a well-defined version bundled.
> I'm not a cvs expert, not even a mildly experienced user. I know  
> from svn and mercurial, that there is a unique version or revision  
> which characterizes the source tree, so if I check out today and  
> compile a binary, I can tell which version of the source tree was  
> used, even without a dedicated snapshot.
> Is there an equivalent in cvs?
>
> benjamin


I see the 4.4 branch does exist.

	http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/term/x11.trm?view=log&pathrev=branch-4-4-stable

However, I'm a novice when it comes to selecting cvs branches. Using  
the command line, how to I select a particular branch?

... and is MAIN or GNUPLOT_BETA the default branch for development?

Ben

p.s. I've cc'd the gnuplot mail-list. We should remove that once the  
cvs questions are answered.

Re: Adding some new transformations to gnuplot (arctan and power laws)

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

On Wednesday 10 June 2009, pl...@pi... wrote:
> Ethan Merritt wrote:
> > On Wednesday 03 June 2009 14:15:52 pl...@pi... wrote:
> >> Ethan Merritt wrote:
> > 
> >>>
> >>> I am arguing that it may be preferable to send terminal coordinates corresponding
> >>> to linear scale, plus some clue how they should be transformed by the viewer
> >>> upon request.  
> >>>
> >> I'm wondering about the rationality of this. "Toggling" log/transform 
> >> scaling is really a euphormism for a total replot it seems. You 
> >> fundementally change the x or y scale transformation and have to do a 
> >> full replot of the data, axes and all.
> 
> [snip] 
>
> Mouse coords are intrinsically low res and one way. As you already noted 
> yourself a one off inverse transformation is easy to do off the plot. 
> Making this repeatable when toggling on and off requires the original 
> data otherwise accumulated errors and over-sensitive parts of the 
> mapping will rapidly cause unacceptable error.

Yes, well, that was exactly what I was proposing: send the untransformed
coordinates, and do all the transforms on the fly from the original 
full-resolution coordinates.
 
> The most obvious log transform could quickly produce significant 
> distortions unless the original data was reused.

Exactly.  So I think we are in complete agreement.

As it may not be obvious, let me point out that the canvas terminal,
like the cairo terminals, works with much higher precision coordinates
than the actual pixel display. The nominal resolution of the scripted
plot commands is currently 10x that of the display, but that could be
further increased if desired. The only downside is that the output script
would increase in size by, say, one decimal character per coordinate.

	Ethan

Re: Adding some new transformations to gnuplot (arctan and power laws)

[<pl...@pi...>]

Ethan Merritt wrote:
> On Wednesday 03 June 2009 14:15:52 pl...@pi... wrote:
>> Ethan Merritt wrote:
> 
>>> The issue is clearest for the canvas terminal, where "both directions" does not
>>> apply.  I want to toggle between linear/logscale or linear/transform in the
>>> javascript code on the browser.  There is no back-connection to the original
>>> gnuplot run.  
>>>
>>> I am arguing that it may be preferable to send terminal coordinates corresponding
>>> to linear scale, plus some clue how they should be transformed by the viewer
>>> upon request.  
>> I'm wondering about the rationality of this. "Toggling" log/transform 
>> scaling is really a euphormism for a total replot it seems. You 
>> fundementally change the x or y scale transformation and have to do a 
>> full replot of the data, axes and all.
> 
> My goal is to come as close as feasible to replicating the capabilities of 
> the existing interactive terminals (win x11 wxt qt) in the browser-based
> terminals (canvas svg).    Except that I've kind of given up on svg :-(
>  
That seems like a great idea and much of that can be done relatively 
easily. Transforms is tricky.

>> This is feasible in a live terminal such as wxt since gnuplot is 
>> available to do the replotting. In the case of write-once interactive 
>> terminals I see two possibilities:
>>
>> 1/ export two renditions of the graph and a trivial js routine to toggle 
>> them. This could be similar to the line visibility toggle already 
>> working for svg but on a larger object. I suspect the coding would be 
>> trivial and fairly portable.
> 
> It's a little worse than that.  The axes, including the color palette,
> can all be individually toggled.  So at least in principle you might have
> to export 2^N  alternative plots.  I agree that it's unlikely in practice
> that you would want more than 4 = 2^2 (y or z, colorbar)
> 
> Also you are forgetting that in order to track mouse coordinates, the 
> browser-side code already has to know how to back-transform the
> displayed coordinates.  Since we have to provide that capability 
> anyhow to allow mousing, why not also use it to toggle the axis scaling?
Mouse coords are intrinsically low res and one way. As you already noted 
yourself a one off inverse transformation is easy to do off the plot. 
Making this repeatable when toggling on and off requires the original 
data otherwise accumulated errors and over-sensitive parts of the 
mapping will rapidly cause unacceptable error.

The most obvious log transform could quickly produce significant 
distortions unless the original data was reused.

> 
>> 2/ export enough information and js code for the interactive terminal to 
>> redraw new axes, tic labels , grid, plot lines, axes labels and 
>> possibily alter the legend. It seems that this close to the entire plot 
>> job except parsing the input data. It is reproducing most of what 
>> gnuplot would do. Gnuplot is no longer a plotter but a preprocessor. 
>> This seems rather off target in terms of what gnuplot should be doing.
> 
> That overstates the fraction of the total task that would be handed off
> to the viewer. To handle zoom/unzoom, the code in gnuplot_mouse.js already
> does most of what you list.  It's just not that much code.
> 
I agree stuff like toggling lines (already done for svg) zoom (browser 
std function) are very feasible. My comments were aimed at the subject 
of axis tranformations. That's a different kettle of fish which, like I 
said, seems to involve recoding most of what gnuplot does in javescript.

This raises another issue: it is no longer within the authors control to 
asses the mathematical accuracy of the platform doing the work and to 
verify the graphical output before publishing. He would have to publish 
without knowing what some arbitrary platform will do to his data whilst 
mashing it back and forth.


I see a lot of the interactive behaviour could be ported relatively 
easily and I'd love to see this but as far as axis transformation goes I 
still think you're stuck with the basic issues I outlined.


regards.

Re: Adding some new transformations to gnuplot (arctan and power laws)

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

On Wednesday 03 June 2009 14:15:52 pl...@pi... wrote:
> Ethan Merritt wrote:

> > The issue is clearest for the canvas terminal, where "both directions" does not
> > apply.  I want to toggle between linear/logscale or linear/transform in the
> > javascript code on the browser.  There is no back-connection to the original
> > gnuplot run.  
> > 
> > I am arguing that it may be preferable to send terminal coordinates corresponding
> > to linear scale, plus some clue how they should be transformed by the viewer
> > upon request.  
> 
> I'm wondering about the rationality of this. "Toggling" log/transform 
> scaling is really a euphormism for a total replot it seems. You 
> fundementally change the x or y scale transformation and have to do a 
> full replot of the data, axes and all.

My goal is to come as close as feasible to replicating the capabilities of 
the existing interactive terminals (win x11 wxt qt) in the browser-based
terminals (canvas svg).    Except that I've kind of given up on svg :-(
 
> This is feasible in a live terminal such as wxt since gnuplot is 
> available to do the replotting. In the case of write-once interactive 
> terminals I see two possibilities:
> 
> 1/ export two renditions of the graph and a trivial js routine to toggle 
> them. This could be similar to the line visibility toggle already 
> working for svg but on a larger object. I suspect the coding would be 
> trivial and fairly portable.

It's a little worse than that.  The axes, including the color palette,
can all be individually toggled.  So at least in principle you might have
to export 2^N  alternative plots.  I agree that it's unlikely in practice
that you would want more than 4 = 2^2 (y or z, colorbar)

Also you are forgetting that in order to track mouse coordinates, the 
browser-side code already has to know how to back-transform the
displayed coordinates.  Since we have to provide that capability 
anyhow to allow mousing, why not also use it to toggle the axis scaling?

> 2/ export enough information and js code for the interactive terminal to 
> redraw new axes, tic labels , grid, plot lines, axes labels and 
> possibily alter the legend. It seems that this close to the entire plot 
> job except parsing the input data. It is reproducing most of what 
> gnuplot would do. Gnuplot is no longer a plotter but a preprocessor. 
> This seems rather off target in terms of what gnuplot should be doing.

That overstates the fraction of the total task that would be handed off
to the viewer. To handle zoom/unzoom, the code in gnuplot_mouse.js already
does most of what you list.  It's just not that much code.

-- 
Ethan A Merritt

Re: Plotting exclusive values

[Thomas S. <t.s...@fz...>]

you could call your script inside the plot command and thus save the
intermediate file:
plot "< your_script datafilename" using .....

in principle the same as i suggested in my last email:
plot "< awk '{if (\$14 == 300) print NR \" \" \$0}' mem.log" using 1:7
linetype 1 title "foo" with filledcurves x1


Stepp wrote:
> 
> Hi Thomas
> 
> 
> Thomas Sefzick wrote:
>> 
>> if there is no curve, there is no filling, just white space.
>> 
>> to see that gnuplot behaves as expected plot 'with linespoints'
>> 
>> but if you want a connection between points over some undefined
>> points in between, then you need to filter your data outside gnuplot,
>> 
> 
> No, you misunderstood. I don't want that white space at all. Kind of
> plot     inp using ($14==300 ? $6 : "don't plot that value at all")
> linetype 1 title "foo" with filledcurves x1 
> 
> Well, I wrote a skript that extracts the values $6 from exclusive values,
> e.g. 300, and write them to a file. The rest is gnuplot trivial.
> 
> 
> Thx
> 

-- 
View this message in context: http://www.nabble.com/Plotting-exclusive-values-tp23907153p23944323.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: Plotting exclusive values

[Thomas S. <t.s...@fz...>]

you are plotting 'with filledcurves', that means that the space underneath
the
curve down to the x-axis is filled.
if there is no curve, there is no filling, just white space.

to see that gnuplot behaves as expected plot 'with linespoints'

but if you want a connection between points over some undefined
points in between, then you need to filter your data outside gnuplot,
e.g.:

plot "< awk '{if (\$14 == 300) print NR \" \" \$0}' mem.log" using 1:7
linetype 1 title "foo" with filledcurves x1


Stepp wrote:
> 
> Hi there
> 
> I have data logged from top-command like
> 
> 13013 name     20   0 16396  12m 1640 R   99  0.1   0:01.20 ./large 200
> 200 3  
> 13048 name     20   0 16396  10m 1640 R   99  0.1   0:01.20 ./large 300
> 300 3  
> 13052 name     20   0 16396  11m 1640 R   99  0.1   0:01.20 ./large 300
> 300 3  
> 13048 name     20   0 16396  15m 1644 R  100  0.1   0:07.20 ./large 300
> 300 3  
> 13013 name     20   0 16396  17m 1640 R   99  0.1   0:01.20 ./large 200
> 200 3  
> 13013 name     20   0 16396  10m 1640 R   99  0.1   0:01.20 ./large 200
> 200 3  
> 13052 name     20   0 16396  11m 1644 R  100  0.1   0:07.20 ./large 300
> 300 3  
> 13054 name     20   0 16396  11m 1644 R  100  0.1   0:07.20 ./large 300
> 300 3  
> 13048 name     20   0 16396  15m 1652 R  100  0.1   0:22.20 ./large 300
> 300 3  
> 13075 name     20   0  7208 4m 1576 R   97  0.0   0:02.90 ./large 500 500
> 0  
> 13081 name     20   0  9168 6m 1616 R   96  0.0   0:02.88 ./large 500 500
> 0  
> 
> and I want to plot the memory ($6) only for 200, 300 or 500 ($14) at a
> time.
> 
> I've tried starting with 300:
> 
> inp = "mem.log"
> set xrange [0:]
> plot     inp using ($14==300 ? $6 : 1/0) linetype 1 title "foo" with
> filledcurves x1
> 
> but this plots the not 300 values as 0. I want all not 300 values
> unplotted in the 300-plot so that there won't be empty places. How to?
> Need to say instead of '1/0' in using 'don't plot this value'.
> 
> 
> I hope you understand and can help me.
> 
> Regards
> Stepp
> 

-- 
View this message in context: http://www.nabble.com/Plotting-exclusive-values-tp23907153p23915405.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: new script and patch for Fink/Gnuplot

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

On Sunday 07 June 2009, Ben Abbott wrote:
> 
> On Jun 7, 2009, at 5:18 AM, Ingo Thies wrote:
> 
> > Hi Ben,
> >
> >> If you don't have a sourceforge account setup, you'll need to do  
> >> that first. You can setup an account at the link below.
> >
> > I have already sent sfeam an E-Mail (he is frequently posting in  
> > that newsgroup). However, I did not really know what to tell him  
> > since I only know what you just telled my about that lua-tikz issue.
> 
> The info below should e sufficient. Why you see it and I do not, I  
> don't understand.
> 
> make
> cd . && /bin/sh /sw/src/fink.build/gnuplot-4.3.0-99/gnuplot-4.3.0/ 
> missing --run autoheader
> rm -f stamp-h1
> touch config.hin
> cd . && /bin/sh ./config.status config.h
> config.status: creating config.h
> config.status: config.h is unchanged
> make  all-recursive
> Making all in config
> make[2]: Nothing to be done for `all'.
> Making all in m4
> make[2]: Nothing to be done for `all'.
> Making all in term
> make[2]: *** No rule to make target `lua/gnuplot-lua-tikz.sty', needed  

A week ago I moved this file into .../shared/LaTeX/ so that the various
latex-related files can be installed via the same Makefile.

The error message above suggests that your makefiles are still looking
for it in the old directory.  So I suspect that you need to re-run the
./prepare script.  To make sure you have the revised directory structure,
you should first run    cvs update -d

	Ethan  (sfeam)

Re: Alternative way to build gnuplot

[Ben A. <bpa...@ma...>]

Thanks for the info!

Ben



On Jun 8, 2009, at 12:14 AM, Ingo Thies <it...@as...>  
wrote:

> Hi Ben,
>
> I hope you had a nice and safe travel.
>
> Martin Costabel gave me another hint that at least seems to work  
> with me. In the Fink FAQ
>
> http://www.finkproject.org/faq/usage-general.php?#compile-myself
>
> is a list of path variables you must set before the installation of  
> gnuplot. Then erase the current gnuplot source folder and re-install  
> it from CVS the usual way. If you now run Gnuplot and type set term,  
> you will hopefully see that also PNG, GIF etc. are available.
>
> However, this way you have an independent working gnuplot build,  
> which is exactly what I desired, but may not what you would prefer.
>
> Best wishes,
>
> Ingo
> -- 
> ==========================================
> Ingo Thies
> Argelander-Institut fuer Astronomie (AIfA)
> Sternwarte, University of Bonn
> Auf dem Huegel 71, D-53121 Bonn, Germany
> Tel : +49 (0)228 73-3659
> Mail: it...@as...

Re: problem building developers sources

[Hans-Bernhard B. <HBB...@t-...>]

Ben Abbott wrote:

> To be save I've removed all files marked by "?" and "M" (uknown and  
> modified, I assume?)

Unknown files wouldn't pose a problem unless you did something really 
weird (like, say, copy modified *.trm files somewhere else than the 
*.trm directory).   You can usually leave them alone.

> $ cvs update -d | grep '^M ' | sed "s/^M /rm /g" | /bin/sh
> $ cvs update -d

     cvs update -d -C

would do that job more easily.

Re: new script and patch for Fink/Gnuplot

[Ben A. <bpa...@ma...>]

On Jun 7, 2009, at 5:18 AM, Ingo Thies wrote:

> Hi Ben,
>
>> If you don't have a sourceforge account setup, you'll need to do  
>> that first. You can setup an account at the link below.
>
> I have already sent sfeam an E-Mail (he is frequently posting in  
> that newsgroup). However, I did not really know what to tell him  
> since I only know what you just telled my about that lua-tikz issue.

The info below should e sufficient. Why you see it and I do not, I  
don't understand.

make
cd . && /bin/sh /sw/src/fink.build/gnuplot-4.3.0-99/gnuplot-4.3.0/ 
missing --run autoheader
rm -f stamp-h1
touch config.hin
cd . && /bin/sh ./config.status config.h
config.status: creating config.h
config.status: config.h is unchanged
make  all-recursive
Making all in config
make[2]: Nothing to be done for `all'.
Making all in m4
make[2]: Nothing to be done for `all'.
Making all in term
make[2]: *** No rule to make target `lua/gnuplot-lua-tikz.sty', needed  
by `all-am'.  Stop.
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
### execution of /var/tmp/tmp.1.BJ0k3W failed, exit code 2
Removing runtime build-lock...
Removing build-lock package...
/sw/bin/dpkg-lockwait -r fink-buildlock-gnuplot-4.3.0-99
(Lese Datenbank ... 57586 Dateien und Verzeichnisse sind derzeit  
installiert.)
Entferne fink-buildlock-gnuplot-4.3.0-99 ...
Failed: phase compiling: gnuplot-4.3.0-99 failed

Ben