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

"Set label front" "set grid back" not working

[HorstSAut <hor...@tp...>]

Hello !

In Gnuplot 4.6.0 I did not succeed write labels over the grid,
even when I set label front, grid back:
simple exampreset
set xrange [-3.3]
set yrange[-3:3]
set xtics 1
set ytics 1
set grid xtics ytics
set grid back
set label 1 at -1,0 "This text should be in front"
set label 1 front
plot -1


The grid still not broken


thx,

HorstSaut



--
View this message in context: http://gnuplot.10905.n7.nabble.com/Set-label-front-set-grid-back-not-working-tp17404.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

"Set label front" "set grid back" not working

[HorstSAut <hor...@tp...>]

Hello ! 

In Gnuplot 4.6.0 I did not succeed write labels over the grid, 
even when I set label front, grid back: 
simple exampreset 
set xrange [-3.3] 
set yrange[-3:3] 
set xtics 1 
set ytics 1 
set grid xtics ytics 
set grid back 
set label 1 at -1,0 "This text should be in front" 
set label 1 front 
plot -1 


The grid still not broken 


thx, 

HorstSaut 



--
View this message in context: http://gnuplot.10905.n7.nabble.com/Set-label-front-set-grid-back-not-working-tp17405.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: boxed text

[Bastian M. <bma...@we...>]

Am 21.05.2013 17:49, schrieb Ethan Merritt:
>> The core code does not apply linetype before calling boxed_text.  I
>> guess in principle the color of the box should match the current line
>> color, but at least for wxt it always comes out black.  There actually
>> is a corresponding FIXME in the core code.
>
> Please offer suggestions.  Should the linetype be a property of
> "set style textbox"?  Should it be the same as the text color?
> Some new attribute?
> I think the line width is more likely to be an issue than the color.
>

Maybe, but I could image that one could use the colour e.g. to mark 
datasets instead of using a key box.  Anyway, I would at least expect 
that the "with labels" plot style would respect the linewidth/linecolor 
setting.  I guess it is reasonable to want to be able to set a different 
colour for the text, though.

>> It is also not clear to me how to handle rotated labels.  Currently,
>>     set label 1 "rotated text" rotate by 45 boxed
>> does produce rotated text, but the box is not rotated (wxt terminal).
>> Should that case be handled by enlarging the box or by rotating it?
>
> Rotated text is just too hard to deal with, with the obvious exception
> of 90 degree rotation.   I think that will remain a necessary limitation,
> since we have no control over the interpretation of a rotated
> "bounding box" by the various underlying graphics libraries.

In case we promise not to change the angle in between the boxed_text 
calls, implementing a rotated text box should be doable.  Otherwise that 
behaviour should be documented.


 >> For sake of clarity, I would also propose to provide an enum to define
 >> actions (instead of magic numbers).  Also most API sets provide a "draw
 >> a filled rectangle with border" function.  So instead of using two
 >> successive boxed_text calls, we could save one API call per filled box.
 >
 > Yeah, that would be a reasonable change.
 >

Depending on the investigations on the latex terminals, one extra call 
to boxed_text might be needed:  After all the text labels have been 
written, those terminals might need another call to indicate the "end" 
of the boxed label and to output some closing curly brackets etc.  For 
the other terminals that would just be a no-op.

>> The terminal code should also reserve room for enhanced text. But
>> according to the comment, that doesn't work just yet for the cairo
>> terminals.
>
> It works perfectly for enhanced text. That was in fact a major part of the
> original motivation.   It's not so hard to use strlen() and font size to
> approximate the box dimensions required to enclose normal text, but the
> bounding box required for enhanced text with its various fonts, subscripts,
> symbols,  etc cannot be approximated well.
> Which comment is confusing?  Maybe it was left over from an early version.
>

Nice. I didn't do any actual testing. I just assumed this from the comment
  /* Bookkeeping for boxed text (Not working yet) */
in gp_cairo_enhanced_finish().

   Bastian

Re: boxed text

[Ethan M. <eam...@gm...>]

On Tuesday, 21 May 2013, Bastian Märkisch wrote:
> Mojca, I think your interpretation of things is about right.  The 
> treatment you describe is needed to handle e.g. multiline labels. 
> Please note that term/README provides some more information concerning 
> parameters etc. 

Yes.  The description is in term/README.
All uses of the new terminal entry point in the current code are in
gadgets.c (write_label). 

> and the implementation e.g. for cairo clearly shows how 
> things are supposed to work.  

The implementation for Qt turned out to be the simplest.

> While implementing the code for Windows I 
> noticed some oddities, though:
> 
> The core code does not apply linetype before calling boxed_text.  I 
> guess in principle the color of the box should match the current line 
> color, but at least for wxt it always comes out black.  There actually 
> is a corresponding FIXME in the core code.

Please offer suggestions.  Should the linetype be a property of
"set style textbox"?  Should it be the same as the text color?
Some new attribute?
I think the line width is more likely to be an issue than the color.

> It is also not clear to me how to handle rotated labels.  Currently,
>    set label 1 "rotated text" rotate by 45 boxed
> does produce rotated text, but the box is not rotated (wxt terminal). 
> Should that case be handled by enlarging the box or by rotating it?

Rotated text is just too hard to deal with, with the obvious exception
of 90 degree rotation.   I think that will remain a necessary limitation,
since we have no control over the interpretation of a rotated 
"bounding box" by the various underlying graphics libraries. 

> For sake of clarity, I would also propose to provide an enum to define 
> actions (instead of magic numbers).  Also most API sets provide a "draw 
> a filled rectangle with border" function.  So instead of using two 
> successive boxed_text calls, we could save one API call per filled box.

Yeah, that would be a reasonable change.

> The terminal code should also reserve room for enhanced text. But 
> according to the comment, that doesn't work just yet for the cairo 
> terminals.

It works perfectly for enhanced text. That was in fact a major part of the
original motivation.   It's not so hard to use strlen() and font size to
approximate the box dimensions required to enclose normal text, but the
bounding box required for enhanced text with its various fonts, subscripts,
symbols,  etc cannot be approximated well.
Which comment is confusing?  Maybe it was left over from an early version.

> Concerning the spacing around the labels, I personally think it is 
> unfortunate to let terminals decide about the default spacing.  For 
> things like tic marks etc. the core code uses term->hchar/vchar as a 
> "unit" of length.

There is a partially-implemented "margin" property of the textbox
style.   I didn't document it yet because only some of the terminal
types support it at this point.  The various terminals require amazingly
different treatment.    

	Ethan
 
>    Bastian
> 
> Am 21.05.2013 14:15, schrieb Mojca Miklavec:
> > Dear developers,
> >
> > I'm trying to understand how exactly the boxed text should be
> > implemented in a terminal, but it's not clear to me how it even works.
> >
> > Is the implementation of enhanced text mode necessary? I see that the
> > terminal should provide a function
> >      boxed_text(unsigned int x, unsigned int y, int option)
> > but it's not clear to me what the function needs to do.
> >
> > Can I expect a scenario like this one?
> >     boxed_text(...,...,0) # initialize
> >     put_text(<x>,<y>,"some") # label1
> >     put_text(<x>,<y>,"text") # label2
> >     put_text(<x>,<y>,"floating") # label3
> >     put_text(<x>,<y>,"around") # label4
> >     boxed_text(...,...,1)
> > where the last command is supposed to draw a frame around all four
> > labels, no matter where on the picture they are?

No.  The box is drawn around the output from a single call to
term->put_text().   The tricky part is making it work for text
containing enhanced text mode markup like font size changes
and superscripts.

> > If not - how exactly should this work?
> >
> > Mojca

Re: boxed text

[Bastian M. <bma...@we...>]

Mojca, I think your interpretation of things is about right.  The 
treatment you describe is needed to handle e.g. multiline labels. 
Please note that term/README provides some more information concerning 
parameters etc. and the implementation e.g. for cairo clearly shows how 
things are supposed to work.  While implementing the code for Windows I 
noticed some oddities, though:

The core code does not apply linetype before calling boxed_text.  I 
guess in principle the color of the box should match the current line 
color, but at least for wxt it always comes out black.  There actually 
is a corresponding FIXME in the core code.

It is also not clear to me how to handle rotated labels.  Currently,
   set label 1 "rotated text" rotate by 45 boxed
does produce rotated text, but the box is not rotated (wxt terminal). 
Should that case be handled by enlarging the box or by rotating it?

For sake of clarity, I would also propose to provide an enum to define 
actions (instead of magic numbers).  Also most API sets provide a "draw 
a filled rectangle with border" function.  So instead of using two 
successive boxed_text calls, we could save one API call per filled box.

The terminal code should also reserve room for enhanced text. But 
according to the comment, that doesn't work just yet for the cairo 
terminals.

Concerning the spacing around the labels, I personally think it is 
unfortunate to let terminals decide about the default spacing.  For 
things like tic marks etc. the core code uses term->hchar/vchar as a 
"unit" of length.

   Bastian

Am 21.05.2013 14:15, schrieb Mojca Miklavec:
> Dear developers,
>
> I'm trying to understand how exactly the boxed text should be
> implemented in a terminal, but it's not clear to me how it even works.
>
> Is the implementation of enhanced text mode necessary? I see that the
> terminal should provide a function
>      boxed_text(unsigned int x, unsigned int y, int option)
> but it's not clear to me what the function needs to do.
>
> Can I expect a scenario like this one?
>     boxed_text(...,...,0) # initialize
>     put_text(<x>,<y>,"some") # label1
>     put_text(<x>,<y>,"text") # label2
>     put_text(<x>,<y>,"floating") # label3
>     put_text(<x>,<y>,"around") # label4
>     boxed_text(...,...,1)
> where the last command is supposed to draw a frame around all four
> labels, no matter where on the picture they are?
>
> If not - how exactly should this work?
>
> Mojca

boxed text

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

Dear developers,

I'm trying to understand how exactly the boxed text should be
implemented in a terminal, but it's not clear to me how it even works.

Is the implementation of enhanced text mode necessary? I see that the
terminal should provide a function
    boxed_text(unsigned int x, unsigned int y, int option)
but it's not clear to me what the function needs to do.

Can I expect a scenario like this one?
   boxed_text(...,...,0) # initialize
   put_text(<x>,<y>,"some") # label1
   put_text(<x>,<y>,"text") # label2
   put_text(<x>,<y>,"floating") # label3
   put_text(<x>,<y>,"around") # label4
   boxed_text(...,...,1)
where the last command is supposed to draw a frame around all four
labels, no matter where on the picture they are?

If not - how exactly should this work?

Mojca

Re: Oddities with the new contour labels feature

[sfeam (E. Merritt) <eam...@gm...>]

On Saturday, 18 May 2013, Juhász Péter wrote:
> Dear list,
> 
> I've tested the new contour labels feature, and I found a few problems.
> 
> First, when I just say
> 
> splot x**2+y**2
> 
> the program replies with 'warning: This plot style is only for
> datafiles , reverting to "points"'. 

I take it you mean 
   splot x**2+y**2 with labels?
The program always done that.  But you're right that it would now
be more informative to issue a comment about contours and
_not_ revert to points.

> Something like 'You must use "set contours" first to use this feature'
> would be more helpful.
> 
> Let's enable it:
> 
> set contour
> set view map
> 
> Then the real strange thing:
> 
> splot x**2+y**2, x**2+y**2 w labels
> splot x**2+y**2 w labels, x**2+y**2
> 
> The two are not equivalent: the second one puts the legend for the
> contours at the right edge of the canvas.

Dang. I thought I fixed that bug.  The problem is that it is writing
blank title lines in the key for each contour level.  If the blank lines
come last you don't notice them, but if they come first then all the
non-blank lines are shifted to later in the key.   It's a trivial fix, 
I must have lost it somewhere.

Thanks for testing.  I'll take a look at the other issues as well.

	Ethan

> When using pm3d:
> 
> splot x**2+y**2 w labels , x**2+y**2 w pm3d
> 
> The pm3d surface hides the labels. Which is logical, come to think of
> it, but it confused me for a second.
> 
> 'show cntrlabel' does not work.
> 
> 
> Labels are not displayed if contours are drawn at the surface, not at
> the bottom. At least a warning should be issued in this case if this is 
> intentional.
> 
> 
> Otherwise, it is a good thing to have, one that was on top of the
> wishlist for many, I'm sure.
> 
> Peter Juhasz
> 
> ps. I'm sorry for not being active on gnuplot lately, it's just that in
> my current job I don't use it too much anymore, and with all the work to
> do I don't have the incentive to hack on gnuplot.
> 
> 
> 
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Oddities with the new contour labels feature

[Juhász P. <pet...@gm...>]

Dear list,

I've tested the new contour labels feature, and I found a few problems.

First, when I just say

splot x**2+y**2

the program replies with 'warning: This plot style is only for
datafiles , reverting to "points"'. 
Something like 'You must use "set contours" first to use this feature'
would be more helpful.

Let's enable it:

set contour
set view map

Then the real strange thing:

splot x**2+y**2, x**2+y**2 w labels
splot x**2+y**2 w labels, x**2+y**2

The two are not equivalent: the second one puts the legend for the
contours at the right edge of the canvas.

When using pm3d:

splot x**2+y**2 w labels , x**2+y**2 w pm3d

The pm3d surface hides the labels. Which is logical, come to think of
it, but it confused me for a second.


'show cntrlabel' does not work.


Labels are not displayed if contours are drawn at the surface, not at
the bottom. At least a warning should be issued in this case if this is 
intentional.


Otherwise, it is a good thing to have, one that was on top of the
wishlist for many, I'm sure.

Peter Juhasz

ps. I'm sorry for not being active on gnuplot lately, it's just that in
my current job I don't use it too much anymore, and with all the work to
do I don't have the incentive to hack on gnuplot.

Re: Tabular output of this 3D plot style not implemented

[Manfred S. <man...@gm...>]

Am 09.05.2013 01:00, schrieb Ethan Merritt:
> On Wednesday, May 08, 2013 03:04:59 pm Manfred Schwarb wrote:
>> Hi Ethan,
>>

>>
>> Which part of the example below is not clear? One surface plot (2D map)
>> with contours, a second 2D map without surface but only contours,
>> and corresponding contour labels.
>
> It is not clear because it involves complicated scripts that don't work,
> and does not include the associated data files.
> So how am I to know what the intended result looks like?
> For what it's worth, your script doesn't work for me when I try
> it with gnuplot version 4.4.4 either, although the error message is
> different:
>
> $ gnuplot_4.4.4 schwarb.gp
> ** warning: can't use pm3d for 2d plots -- please unset pm3d
>
> I can make it run by moving the second "set pm3d ..." command
> 5 lines down, to after the "load '$TMPGP'", but I don't know if
> that's really what you intended.  Perhaps you have a different
> version of the label_contours.awk script than I do.
>

Sorry, I did not remember any more that I had modified label_contours.awk
by removing the END block, so only the labels are written.


>
> Is it possible that the very first line of the script you posted
> has crept in by error?  If I comment out that line:
>    #set pm3d interpolate 2,2 implicit map
>    unset surface
>    ... rest of script
>
> then the script behaves the same for me in both gnuplot 4.4 and 4.6.
> Maybe that's all you need to get past this problem.
>

Well, I'm quite sure I simply copied some script I found on the net,
and did not think too much about it. So classical cargo-culting.

Perhaps the intention was to influence the contouring by setting
the interpolate option, but this is not the case.

Actually the "map" in the "set pm3d ..." makes the difference, when
removing it, the plot works perfectly.
But then, the remaining "set pm3d interpolate 40,40 implicit" seems without
effect and can be removed, so yes, your suggestion is correct.

As you told, the contouring is not influenced by pm3d settings, the trouble
are the side effects of the "map" option, probably by
setting "set style data pm3d"


>> The really strange thing is, this worked perfectly, but then
>> someone put in some "error: not implemented" statement.
>> How could this be not implemented, if it worked perfectly before?
>
> It was not implemented in version 4.4 either.  The difference is
> that version 4.4 failed to warn you that it couldn't handle
> pm3d mode and silently ignored the "pm3d" keyword.  Version 4.6
> does warn you.   Both 4.4 and 4.6 will dump the coordinates
> identically if you simply say
>     set table FOO
>     splot '$INFILE1'
>
> The change is that if you say instead
>     splot '$INFILE' with pm3d
> it was handled in version 4.4 by silently ignoring the "with pm3d".
> In version 4.6 you get an error message warning you that the
> data generated by pm3d (interpolation/colors) cannot be saved
> as tabular output.

OK, thanks for the explanation. The strange thing is however that
   set table FOO; splot '$INFILE' with pm3d
gives a warning, but
   set pm3d implicit; set table FOO; splot '$INFILE'
does not...


Problem solved, thanks a lot!
Manfred

Re: Tabular output of this 3D plot style not implemented

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

On Wednesday, May 08, 2013 03:04:59 pm Manfred Schwarb wrote:
> Hi Ethan,
> 
> Am 08.05.2013 18:17, schrieb Ethan Merritt:
> > On Wednesday, May 08, 2013 05:33:22 am Manfred Schwarb wrote:
> >> Hi,
> >>
> >> I tried to upgrade from gnuplot 4.4 to 4.6 and faced a new error
> >> in my plot script:
> >> "Tabular output of this 3D plot style not implemented"
> >>
> >> I read the release announcements but found no indication of some
> >> pm3d behaviour changes, so I'm quite baffled. Also searching the
> >> net did not reveal much useful information.
> >>
> >> So how is one supposed to use pm3d in gnuplot 4.6?
> >
> > Could you explain more clearly what you are trying to do?
> 
> Which part of the example below is not clear? One surface plot (2D map)
> with contours, a second 2D map without surface but only contours,
> and corresponding contour labels.

It is not clear because it involves complicated scripts that don't work,
and does not include the associated data files.
So how am I to know what the intended result looks like?
For what it's worth, your script doesn't work for me when I try
it with gnuplot version 4.4.4 either, although the error message is
different:

$ gnuplot_4.4.4 schwarb.gp
** warning: can't use pm3d for 2d plots -- please unset pm3d

I can make it run by moving the second "set pm3d ..." command
5 lines down, to after the "load '$TMPGP'", but I don't know if
that's really what you intended.  Perhaps you have a different
version of the label_contours.awk script than I do.

> But see below.
> 
> > So far as I know, it is not necessary to use tabular output for
> > either pm3d or contour plots.  Similarly the "set multiplot"
> > command in your script seems unnecessary.
> >
> > The simple answer would be:
> >    reset
> >    set contour
> >    splot '$INFILE' with pm3d
> >
> 
> Yes, this works perfectly if I have only one dataset and want to do
> a 2D map with contours.
> 
> But I want to do two contour plots (2D map) in the same graph, one with colored
> surface plus grey contours, the other one with black contours without surface plotting
> using data from another source.
> So this can't be issued in one single splot command.

OK. That was not obvious from the commands you posted.

> Therefore you suggest to overlay multiple splot commands?
>    set multiplot
>    set contour
>    splot '$INFILE1' notitle with pm3d lc rgb "grey"
>    set view map
>    unset surface
>    splot '$INFILE2' notitle with lines lt -1
> 
> This works, but I somehow can't paint the lines black, the "lt -1"
> seems ineffective (also lc rgb "grey" seems not to work).
> But then I have still the problem with the contour labels.
> I really have no idea how to produce them without using tables.
> Please enlighten me.

Let's set aside for the moment the question of how to change the
colors and labels used for contouring. It's worth a separate
discussion, but I think we can get you back on track without it.

 

Is it possible that the very first line of the script you posted
has crept in by error?  If I comment out that line:
  #set pm3d interpolate 2,2 implicit map
  unset surface
  ... rest of script

then the script behaves the same for me in both gnuplot 4.4 and 4.6.
Maybe that's all you need to get past this problem.

> The really strange thing is, this worked perfectly, but then
> someone put in some "error: not implemented" statement.
> How could this be not implemented, if it worked perfectly before?

It was not implemented in version 4.4 either.  The difference is
that version 4.4 failed to warn you that it couldn't handle
pm3d mode and silently ignored the "pm3d" keyword.  Version 4.6
does warn you.   Both 4.4 and 4.6 will dump the coordinates 
identically if you simply say
   set table FOO
   splot '$INFILE1'

The change is that if you say instead
   splot '$INFILE' with pm3d
it was handled in version 4.4 by silently ignoring the "with pm3d".
In version 4.6 you get an error message warning you that the
data generated by pm3d (interpolation/colors) cannot be saved
as tabular output. 

	Ethan

 
> 
> Cheers,
> Manfred
> 
> 
> 
> > Season to taste with your preferred pm3d or contour settings.
> > If there is some particular combination of settings that
> > causes a problem then maybe we can help with that.
> >
> > 	Ethan
> >
> >
> >
> >>
> >> I'd like to to some 2D maps with contours on top of it. My script
> >> looks roughly as follows:
> >>
> >>
> >> set pm3d interpolate 40,40 implicit map
> >> unset surface
> >> set contour
> >> set cntrparam bspline
> >> set cntrparam levels auto 10
> >> set table '$TMPCONT1'
> >> splot '$INFILE1'
> >> unset table
> >>
> >> set cntrparam levels auto 5
> >> set table '$TMPCONT2'
> >> splot '$INFILE2'
> >> unset table
> >>
> >> # Change single blank lines to double blank lines
> >> !awk "NF<2{printf\"\n\"}{print}" <$TMPCONT1 >$TMPCONT1_1
> >> !awk "NF<2{printf\"\n\"}{print}" <$TMPCONT2 >$TMPCONT2_1
> >>
> >> reset
> >> set multiplot
> >>
> >> set pm3d interpolate 40,40 explicit map
> >> #---plot contour labels using Petr Mikulik's script:
> >> !awk -f label_contours.awk -v nth=40 center=1 textcolor=1 inclt=0 $TMPCONT1 >$TMPGP
> >> load '$TMPGP'
> >>
> >> splot '$INFILE2' notitle with pm3d, \
> >>         '$TMPCONT1_1' notitle with lines lt -1, \
> >>         '$TMPCONT2_1' notitle with lines lc rgb "gray70"
> >>
> >>
> >> Thanks!
> >> Manfred
> >>
> >> ------------------------------------------------------------------------------
> >> Learn Graph Databases - Download FREE O'Reilly Book
> >> "Graph Databases" is the definitive new guide to graph databases and
> >> their applications. This 200-page book is written by three acclaimed
> >> leaders in the field. The early access version is available now.
> >> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
> >> _______________________________________________
> >> gnuplot-beta mailing list
> >> gnu...@li...
> >> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> >>
> >
> 
> 

-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742

Re: Tabular output of this 3D plot style not implemented

[Manfred S. <man...@gm...>]

Hi Ethan,

Am 08.05.2013 18:17, schrieb Ethan Merritt:
> On Wednesday, May 08, 2013 05:33:22 am Manfred Schwarb wrote:
>> Hi,
>>
>> I tried to upgrade from gnuplot 4.4 to 4.6 and faced a new error
>> in my plot script:
>> "Tabular output of this 3D plot style not implemented"
>>
>> I read the release announcements but found no indication of some
>> pm3d behaviour changes, so I'm quite baffled. Also searching the
>> net did not reveal much useful information.
>>
>> So how is one supposed to use pm3d in gnuplot 4.6?
>
> Could you explain more clearly what you are trying to do?

Which part of the example below is not clear? One surface plot (2D map)
with contours, a second 2D map without surface but only contours,
and corresponding contour labels. But see below.

> So far as I know, it is not necessary to use tabular output for
> either pm3d or contour plots.  Similarly the "set multiplot"
> command in your script seems unnecessary.
>
> The simple answer would be:
>    reset
>    set contour
>    splot '$INFILE' with pm3d
>

Yes, this works perfectly if I have only one dataset and want to do
a 2D map with contours.

But I want to do two contour plots (2D map) in the same graph, one with colored
surface plus grey contours, the other one with black contours without surface plotting
using data from another source.
So this can't be issued in one single splot command.

Therefore you suggest to overlay multiple splot commands?
   set multiplot
   set contour
   splot '$INFILE1' notitle with pm3d lc rgb "grey"
   set view map
   unset surface
   splot '$INFILE2' notitle with lines lt -1

This works, but I somehow can't paint the lines black, the "lt -1"
seems ineffective (also lc rgb "grey" seems not to work).


But then I have still the problem with the contour labels.
I really have no idea how to produce them without using tables.
Please enlighten me.


The really strange thing is, this worked perfectly, but then
someone put in some "error: not implemented" statement.
How could this be not implemented, if it worked perfectly before?


Cheers,
Manfred



> Season to taste with your preferred pm3d or contour settings.
> If there is some particular combination of settings that
> causes a problem then maybe we can help with that.
>
> 	Ethan
>
>
>
>>
>> I'd like to to some 2D maps with contours on top of it. My script
>> looks roughly as follows:
>>
>>
>> set pm3d interpolate 40,40 implicit map
>> unset surface
>> set contour
>> set cntrparam bspline
>> set cntrparam levels auto 10
>> set table '$TMPCONT1'
>> splot '$INFILE1'
>> unset table
>>
>> set cntrparam levels auto 5
>> set table '$TMPCONT2'
>> splot '$INFILE2'
>> unset table
>>
>> # Change single blank lines to double blank lines
>> !awk "NF<2{printf\"\n\"}{print}" <$TMPCONT1 >$TMPCONT1_1
>> !awk "NF<2{printf\"\n\"}{print}" <$TMPCONT2 >$TMPCONT2_1
>>
>> reset
>> set multiplot
>>
>> set pm3d interpolate 40,40 explicit map
>> #---plot contour labels using Petr Mikulik's script:
>> !awk -f label_contours.awk -v nth=40 center=1 textcolor=1 inclt=0 $TMPCONT1 >$TMPGP
>> load '$TMPGP'
>>
>> splot '$INFILE2' notitle with pm3d, \
>>         '$TMPCONT1_1' notitle with lines lt -1, \
>>         '$TMPCONT2_1' notitle with lines lc rgb "gray70"
>>
>>
>> Thanks!
>> Manfred
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and
>> their applications. This 200-page book is written by three acclaimed
>> leaders in the field. The early access version is available now.
>> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
>> _______________________________________________
>> gnuplot-beta mailing list
>> gnu...@li...
>> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>>
>

Re: Tabular output of this 3D plot style not implemented

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

On Wednesday, May 08, 2013 05:33:22 am Manfred Schwarb wrote:
> Hi,
> 
> I tried to upgrade from gnuplot 4.4 to 4.6 and faced a new error
> in my plot script:
> "Tabular output of this 3D plot style not implemented"
> 
> I read the release announcements but found no indication of some
> pm3d behaviour changes, so I'm quite baffled. Also searching the
> net did not reveal much useful information.
> 
> So how is one supposed to use pm3d in gnuplot 4.6?

Could you explain more clearly what you are trying to do?
So far as I know, it is not necessary to use tabular output for
either pm3d or contour plots.  Similarly the "set multiplot"
command in your script seems unnecessary.

The simple answer would be:
  reset
  set contour
  splot '$INFILE' with pm3d

Season to taste with your preferred pm3d or contour settings.
If there is some particular combination of settings that 
causes a problem then maybe we can help with that.

	Ethan



> 
> I'd like to to some 2D maps with contours on top of it. My script
> looks roughly as follows:
> 
> 
> set pm3d interpolate 40,40 implicit map
> unset surface
> set contour
> set cntrparam bspline
> set cntrparam levels auto 10
> set table '$TMPCONT1'
> splot '$INFILE1'
> unset table
> 
> set cntrparam levels auto 5
> set table '$TMPCONT2'
> splot '$INFILE2'
> unset table
> 
> # Change single blank lines to double blank lines
> !awk "NF<2{printf\"\n\"}{print}" <$TMPCONT1 >$TMPCONT1_1
> !awk "NF<2{printf\"\n\"}{print}" <$TMPCONT2 >$TMPCONT2_1
> 
> reset
> set multiplot
> 
> set pm3d interpolate 40,40 explicit map
> #---plot contour labels using Petr Mikulik's script:
> !awk -f label_contours.awk -v nth=40 center=1 textcolor=1 inclt=0 $TMPCONT1 >$TMPGP
> load '$TMPGP'
> 
> splot '$INFILE2' notitle with pm3d, \
>        '$TMPCONT1_1' notitle with lines lt -1, \
>        '$TMPCONT2_1' notitle with lines lc rgb "gray70"
> 
> 
> Thanks!
> Manfred
> 
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and 
> their applications. This 200-page book is written by three acclaimed 
> leaders in the field. The early access version is available now. 
> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742

Tabular output of this 3D plot style not implemented

[Manfred S. <man...@gm...>]

Hi,

I tried to upgrade from gnuplot 4.4 to 4.6 and faced a new error
in my plot script:
"Tabular output of this 3D plot style not implemented"

I read the release announcements but found no indication of some
pm3d behaviour changes, so I'm quite baffled. Also searching the
net did not reveal much useful information.

So how is one supposed to use pm3d in gnuplot 4.6?

I'd like to to some 2D maps with contours on top of it. My script
looks roughly as follows:


set pm3d interpolate 40,40 implicit map
unset surface
set contour
set cntrparam bspline
set cntrparam levels auto 10
set table '$TMPCONT1'
splot '$INFILE1'
unset table

set cntrparam levels auto 5
set table '$TMPCONT2'
splot '$INFILE2'
unset table

# Change single blank lines to double blank lines
!awk "NF<2{printf\"\n\"}{print}" <$TMPCONT1 >$TMPCONT1_1
!awk "NF<2{printf\"\n\"}{print}" <$TMPCONT2 >$TMPCONT2_1

reset
set multiplot

set pm3d interpolate 40,40 explicit map
#---plot contour labels using Petr Mikulik's script:
!awk -f label_contours.awk -v nth=40 center=1 textcolor=1 inclt=0 $TMPCONT1 >$TMPGP
load '$TMPGP'

splot '$INFILE2' notitle with pm3d, \
       '$TMPCONT1_1' notitle with lines lt -1, \
       '$TMPCONT2_1' notitle with lines lc rgb "gray70"


Thanks!
Manfred

Re: crash when using wxt in Ubuntu 12.04

[Ilya S. <il...@sc...>]

Hi, Dima,

Thanks a lot! It seems that uninstalling of wx2.9, installing wx2.8
and rebuilding gnuplot fixed the crashes.

On Sat, May 4, 2013 at 7:11 PM, Dima Kogan <gn...@di...> wrote:
> Ilya Schurov <il...@sc...> writes:
>
>> Hi there,
>>
>> I suffer from the crash of gnuplot when using wxt terminal. It looks like this:
>>
>> [user@thinkie user #2067]$ gnuplot
>>                                                     ~
>>
>> Terminal type set to 'wxt'
>> gnuplot> plot sin(x)
>> [xcb] Unknown request in queue while dequeuing
>> [xcb] Most likely this is a multi-threaded client and XInitThreads has
>> not been called
>> [xcb] Aborting, sorry about that.
>> gnuplot: ../../src/xcb_io.c:178: dequeue_pending_request: Assertion
>> `!xcb_xlib_unknown_req_in_deq' failed.
>> zsh: abort (core dumped)  gnuplot
>>
>> <snip>
>> ii  libwxgtk2.9-0-unofficial  2.9.4-1~eugenesan~precise wxWidgets
>> Cross-platform C++ GUI toolkit (GTK+ runtime)
>> ii  libwxgtk2.9-dev           2.9.4-1~eugenesan~precise wxWidgets
>> Cross-platform C++ GUI toolkit (GTK+ development)
>> <snip>
>
> I suspect the reason the packaged gnuplot crashes and the built one
> doesn't is your "unofficial" wx 2.9 packages. Can you please run
>
>  ldd ./gnuplot | grep wx
>
> on the gnuplot binaries that you see crashing? I suspect you'll see wx
> 2.9 on those. If that's the case, it'll be interesting to see you
> rebuild gnuplot with wx 2.8, and see if that crashes or not.
>
> This may still be a bug in gnuplot, but it'd be great if you could run
> this test so that the cause can be narrowed down.
>
> dima



-- 
With best regards,
Ilya V. Schurov.

Re: crash when using wxt in Ubuntu 12.04

[Dima K. <gn...@di...>]

Ilya Schurov <il...@sc...> writes:

> Hi there,
>
> I suffer from the crash of gnuplot when using wxt terminal. It looks like this:
>
> [user@thinkie user #2067]$ gnuplot
>                                                     ~
>
> Terminal type set to 'wxt'
> gnuplot> plot sin(x)
> [xcb] Unknown request in queue while dequeuing
> [xcb] Most likely this is a multi-threaded client and XInitThreads has
> not been called
> [xcb] Aborting, sorry about that.
> gnuplot: ../../src/xcb_io.c:178: dequeue_pending_request: Assertion
> `!xcb_xlib_unknown_req_in_deq' failed.
> zsh: abort (core dumped)  gnuplot
>
> <snip>
> ii  libwxgtk2.9-0-unofficial  2.9.4-1~eugenesan~precise wxWidgets
> Cross-platform C++ GUI toolkit (GTK+ runtime)
> ii  libwxgtk2.9-dev           2.9.4-1~eugenesan~precise wxWidgets
> Cross-platform C++ GUI toolkit (GTK+ development)
> <snip>

I suspect the reason the packaged gnuplot crashes and the built one
doesn't is your "unofficial" wx 2.9 packages. Can you please run

 ldd ./gnuplot | grep wx

on the gnuplot binaries that you see crashing? I suspect you'll see wx
2.9 on those. If that's the case, it'll be interesting to see you
rebuild gnuplot with wx 2.8, and see if that crashes or not.

This may still be a bug in gnuplot, but it'd be great if you could run
this test so that the cause can be narrowed down.

dima

crash when using wxt in Ubuntu 12.04

[Ilya S. <il...@sc...>]

Hi there,

I suffer from the crash of gnuplot when using wxt terminal. It looks like this:

[user@thinkie user #2067]$ gnuplot
                                                    ~

    G N U P L O T
    Version 4.7 patchlevel 0    last modified 2013-05-03

    Copyright (C) 1986-1993, 1998, 2004, 2007-2012
    Thomas Williams, Colin Kelley and many others

    gnuplot home:     http://www.gnuplot.info
    mailing list:     gnu...@li...
    faq, bugs, etc:   type "help FAQ"
    immediate help:   type "help"  (plot window: hit 'h')

Terminal type set to 'wxt'
gnuplot> plot sin(x)
[xcb] Unknown request in queue while dequeuing
[xcb] Most likely this is a multi-threaded client and XInitThreads has
not been called
[xcb] Aborting, sorry about that.
gnuplot: ../../src/xcb_io.c:178: dequeue_pending_request: Assertion
`!xcb_xlib_unknown_req_in_deq' failed.
zsh: abort (core dumped)  gnuplot

This crash is unstable, i.e. from time to time I can plot something
with wxt terminal but if I try interacting with this terminal with
mouse, it crashes again. When I use terminal x11, it works fine.

gnuplot is builded from the sources (I tried both latest 4.6 and CVS
versions). I'm using Ubuntu 12.04.

There is gnuplot 4.4 patchlevel 3 installed globally with ubuntu
package, and it works fine with wxt, but I need some features from
4.6.

Related packages has the following status:

[user@thinkie src #2050]$ dpkg-query -l "libcairo*" "libwx*"
"libpango*"                  ~/soft/src/gnuplot-cvs/gnuplot/src
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                      Version                   Description
+++-=========================-=========================-==================================================================
un  libcairo-dev              <none>                    (no
description available)
ii  libcairo-gobject2         1.10.2-6.1ubuntu3         The Cairo 2D
vector graphics library (GObject library)
ii  libcairo-perl             1.081-1build2             Perl interface
to the Cairo graphics library
ii  libcairo-script-interpret 1.10.2-6.1ubuntu3         The Cairo 2D
vector graphics library (script interpreter)
ii  libcairo2                 1.10.2-6.1ubuntu3         The Cairo 2D
vector graphics library
ii  libcairo2-dev             1.10.2-6.1ubuntu3         Development
files for the Cairo 2D graphics library
un  libcairo2-doc             <none>                    (no
description available)
un  libcairomm-1.0-0          <none>                    (no
description available)
ii  libcairomm-1.0-1          1.10.0-1ubuntu1           C++ wrappers
for Cairo (shared libraries)
ii  libpango-perl             1.222-1build1             Perl module to
layout and render international text
ii  libpango1.0-0             1.30.0-0ubuntu3.1         Layout and
rendering of internationalized text
ii  libpango1.0-dev           1.30.0-0ubuntu3.1         Development
files for the Pango
un  libpango1.0-doc           <none>                    (no
description available)
ii  libpangomm-1.4-1          2.28.4-1ubuntu1           C++ Wrapper
for pango (shared libraries)
ii  libwxbase2.8-0            2.8.12.1-6ubuntu2         wxBase library
(runtime) - non-GUI support classes of wxWidgets to
ii  libwxbase2.9-0-unofficial 2.9.4-1~eugenesan~precise wxBase library
(runtime) - non-GUI support classes of wxWidgets to
ii  libwxbase2.9-dev          2.9.4-1~eugenesan~precise wxBase library
(development) - non-GUI support classes of wxWidget
un  libwxgtk2.4-contrib-dev   <none>                    (no
description available)
un  libwxgtk2.6-0-python      <none>                    (no
description available)
ii  libwxgtk2.8-0             2.8.12.1-6ubuntu2         wxWidgets
Cross-platform C++ GUI toolkit (GTK+ runtime)
ii  libwxgtk2.9-0-unofficial  2.9.4-1~eugenesan~precise wxWidgets
Cross-platform C++ GUI toolkit (GTK+ runtime)
ii  libwxgtk2.9-dev           2.9.4-1~eugenesan~precise wxWidgets
Cross-platform C++ GUI toolkit (GTK+ development)


--
With best regards,
Ilya V. Schurov.

Re: [PATCH] gnuplot cairo: enhanced string font attributes

[Maxim N. <m.a...@gm...>]

On 26.04.2013 10:51, sfeam (Ethan Merritt) wrote:
> On Thursday, 25 April 2013, Maxim Nikulin wrote:
>> Handle font style and weight in enhanced strings
>> (e.g. "sin({/Serif:Italic x})") for cairo-based terminals.
>
> So in a nutshell, the basic idea in your patch is to set the font using
> pango_font_description_from_string().  That does seem like a
> promising approach, although it would only address the cairo terminals.

The problem is that gp_cairo_add_attr() function is not aware of font 
attributes.  gp_cairo_set_font() knows about italic and bold fonts but 
it can not be directly employed. I was trying to avoid writing a special 
function for parsing of font attributes or reorganizing of 
gp_cairo_set_font() for more general case. The benefit of 
pango_font_description_from_string() is the ability to omit font family 
retaining only an attribute and, perhaps, support of condensed and small 
caps variants. The limitations are that font size is ignored in the font 
string and that in gnuplot comma is used to separate font and size in 
the term and label options. Pango supports comma-separated list of font 
families for the cases of missed fonts. Personally I do not like that 
there no special values "unspecified" for style, weight, etc. in pango 
text attributes, however font family can be null and font size can be 
zero if there are no explicit values ("{/Bold {/Italic is not bold 
italic}}").

I was looking for a function having functionality similar to fc-match 
fontconfig utility and I found pango_font_description_from_string().

Concerning other terminal, I faced the problem when my old script, 
written for the postscript eps terminal, produced worse figure with 
pdfcairo. I am not an active user of SVG and EMF, so I do not know the 
level of enhanced text support there. I suppose, special font for a part 
of a label is worth only for the plots intended for publications.

In the previous message I forgot to mention that font family can be 
written without spaces (and must be for "{/TimesNewRoman f}" strings).
It can be not obvious to users.

-- 
Maxim Nikulin

Re: [PATCH] gnuplot cairo: enhanced string font attributes

[sfeam (E. Merritt) <eam...@gm...>]

On Thursday, 25 April 2013, Maxim Nikulin wrote:
> Handle font style and weight in enhanced strings
> (e.g. "sin({/Serif:Italic x})") for cairo-based terminals.
> 
> Colon is replaced by spaces and the string is passed
> to pango_font_description_from_string().
> No parsing of 'Italic' and 'Bold' withing gnuplot
> is required anymore. Font size set by pango is ignored
> (e.g. "{/Times:12 x}"). Font size still managed
> by gnuplot in traditional ways ("Serif,16" in term options
> and enhanced strings "{/=16 x}" or "{/*1.4 x}").
> Hyphens in font names should not be touched.
> 
> ---
> It was a bad surprise when I faced that, unlike postscript
> terminal, modern pdfcairo does not allow to set italic font
> in the part of axis label (set xlabel "Distance {/Italic L}, m").
> 
> The implemented simple approach does not support
> inheritance of font attributes in nested braces.
> The string "{/Bold {/Italic Italic}}" produces
> normal italic, not bold.
> 
> The quite close issues have been recently addressed in
> https://groups.google.com/forum/?fromgroups=#!topic/comp.graphics.apps.gnuplot/fzs_uV6Oe8Y
> https://groups.google.com/forum/?fromgroups=#!topic/comp.graphics.apps.gnuplot/YZGWsVBpuTI
> 
> I have no experience with gnuplot sources and pango library,
> so the path below should be carefully inspected.

So in a nutshell, the basic idea in your patch is to set the font using
pango_font_description_from_string().  That does seem like a 
promising approach, although it would only address the cairo terminals.  

I'll have a look at it and think some more about whether it's worth
changing only the cairo terminals rather than trying for a general
extension to the enhanced text mode syntax that could be used by
other terminals as well.

Thanks for the patch. 

	Ethan



> 
> 
> 
> Index: src/wxterminal/gp_cairo.c
> ===================================================================
> RCS file: /cvsroot/gnuplot/gnuplot/src/wxterminal/gp_cairo.c,v
> retrieving revision 1.70
> diff -u -r1.70 gp_cairo.c
> --- src/wxterminal/gp_cairo.c	22 Apr 2013 18:49:17 -0000	1.70
> +++ src/wxterminal/gp_cairo.c	25 Apr 2013 17:09:59 -0000
> @@ -1,5 +1,5 @@
>  /*
> - * $Id: gp_cairo.c,v 1.70 2013/04/22 18:49:17 sfeam Exp $
> + * $Id: gp_cairo.c,v 1.69 2013/03/07 22:06:33 sfeam Exp $
>   */
>  
>  /* GNUPLOT - gp_cairo.c */
> @@ -109,6 +109,9 @@
>  static PangoAttrList *gp_cairo_enhanced_underprinted_AttrList = NULL;
>  /* converts text from symbol encoding to utf8 encoding */
>  static gchar* gp_cairo_convert_symbol_to_unicode(plot_struct *plot, const char* string);
> +/* copy font string to gp_cairo_enhanced_font
> + * and replace ':' to spaces */
> +static void gp_cairo_set_font_enhanced(const char *name);
>  /* add standard attributes (fontsize,fontfamily, rise) to
>   * the specified characters in a PangoAttrList */
>  static void gp_cairo_add_attr(plot_struct *plot, PangoAttrList * AttrList, int start, int end );
> @@ -296,36 +299,27 @@
>  void gp_cairo_set_font(plot_struct *plot, const char *name, int fontsize)
>  {
>      char *c;
> -    char *fname;
>  
>  	FPRINTF((stderr,"set_font \"%s\" %d\n", name,fontsize));
>  
> -	/* Split out Bold and Italic attributes from font name */
> -	fname = strdup(name);
> -	for (c=fname; *c; c++) {
> -	    if (*c == '\\') {
> -		char *d = c;
> -		do { *d = *(d+1); } while (*d++);
> -	    } else {
> -		if (*c == '-') *c = ' ';
> -	    }
> -	}
> -	if ((c = strstr(fname, " Bold"))) {
> -	    do { *c = *(c+5); } while (*c++);
> -	    plot->fontweight = PANGO_WEIGHT_BOLD;
> -	} else
> -	    plot->fontweight = 0;
> -	if ((c = strstr(fname, " Italic"))) {
> -	    do { *c = *(c+7); } while (*c++);
> -	    plot->fontstyle = PANGO_STYLE_ITALIC;
> -	} else
> -	    plot->fontstyle = 0;
> -
> -	strncpy( plot->fontname, fname, sizeof(plot->fontname) );
> -	plot->fontsize = fontsize;
> -	free(fname);
> +	strncpy( plot->fontname, name, sizeof(plot->fontname) );
> +        plot->fontsize = fontsize;
> +        for (c = plot->fontname; *c != '\0'; ++c) {
> +           if (*c == ':')
> +              *c = ' ';
> +        }
>  }
>  
> +void gp_cairo_set_font_enhanced(const char *name)
> +{
> +    char *c;
> +
> +	strncpy(gp_cairo_enhanced_font, name, sizeof(gp_cairo_enhanced_font) );
> +        for (c = gp_cairo_enhanced_font; *c != '\0'; ++c) {
> +           if (*c == ':')
> +              *c = ' ';
> +        }
> +}
>  
>  void gp_cairo_set_linewidth(plot_struct *plot, double linewidth)
>  {
> @@ -789,8 +783,7 @@
>  
>  	pango_layout_set_text (layout, string_utf8, -1);
>  	g_free(string_utf8);
> -	desc = pango_font_description_new ();
> -	pango_font_description_set_family (desc, (const char*) plot->fontname);
> +        desc = pango_font_description_from_string (plot->fontname);
>  #ifdef MAP_SYMBOL
>  	/* restore the Symbol font setting */
>  	if (symbol_font_parsed)
> @@ -798,10 +791,6 @@
>  #endif /*MAP_SYMBOL*/
>  	pango_font_description_set_size (desc, (int) (plot->fontsize*PANGO_SCALE*plot->oversampling_scale) );
>  
> -	pango_font_description_set_weight (desc,
> -		plot->fontweight ? PANGO_WEIGHT_BOLD : PANGO_WEIGHT_NORMAL);
> -	pango_font_description_set_style (desc,
> -		plot->fontstyle ? PANGO_STYLE_ITALIC : PANGO_STYLE_NORMAL);
>  	pango_layout_set_font_description (layout, desc);
>  	pango_font_description_free (desc);
>  
> @@ -1139,22 +1128,22 @@
>  
>  void gp_cairo_add_attr(plot_struct *plot, PangoAttrList * AttrList, int start, int end )
>  {
> -	PangoAttribute *p_attr_rise, *p_attr_size, *p_attr_family;
> -
> -	p_attr_size = pango_attr_size_new ((int) (gp_cairo_enhanced_fontsize*PANGO_SCALE));
> -	p_attr_size->start_index = start;
> -	p_attr_size->end_index = end;
> -	pango_attr_list_insert (AttrList, p_attr_size);
> +	PangoAttribute *p_attr_rise, *p_attr_desc;
> +        PangoFontDescription *desc;
>  
>  	p_attr_rise = pango_attr_rise_new ((int) (gp_cairo_enhanced_base*PANGO_SCALE));
>  	p_attr_rise->start_index = start;
>  	p_attr_rise->end_index = end;
>  	pango_attr_list_insert (AttrList, p_attr_rise);
>  
> -	p_attr_family = pango_attr_family_new (gp_cairo_enhanced_get_fontname(plot));
> -	p_attr_family->start_index = start;
> -	p_attr_family->end_index = end;
> -	pango_attr_list_insert (AttrList, p_attr_family);
> +        desc = pango_font_description_from_string (gp_cairo_enhanced_get_fontname(plot));
> +        pango_font_description_set_size (desc, (int) (gp_cairo_enhanced_fontsize*PANGO_SCALE));
> +        p_attr_desc = pango_attr_font_desc_new (desc);
> +        p_attr_desc->start_index = start;
> +        p_attr_desc->end_index = end;
> +        pango_attr_list_insert (AttrList, p_attr_desc);
> +        
> +        pango_font_description_free (desc);
>  }
>  
>  /* add a blank character to the text string with a custom shape */
> @@ -1289,13 +1278,9 @@
>  		/* Create a PangoLayout, set the font and text */
>  		current_layout = gp_cairo_create_layout (plot->cr);
>  		pango_layout_set_text (current_layout, enhanced_text_utf8, -1);
> -		current_desc = pango_font_description_new ();
> -		pango_font_description_set_family (current_desc, gp_cairo_enhanced_get_fontname(plot));
> +                current_desc = pango_font_description_from_string (
> +                      gp_cairo_enhanced_get_fontname(plot));
>  		pango_font_description_set_size(current_desc,(int) gp_cairo_enhanced_fontsize*PANGO_SCALE);
> -		pango_font_description_set_weight (current_desc,
> -			plot->fontweight ? PANGO_WEIGHT_BOLD : PANGO_WEIGHT_NORMAL);
> -		pango_font_description_set_style (current_desc,
> -			plot->fontstyle ? PANGO_STYLE_ITALIC : PANGO_STYLE_NORMAL);
>  
>  		pango_layout_set_font_description (current_layout, current_desc);
>  		pango_font_description_free (current_desc);
> @@ -1335,13 +1320,8 @@
>  		/* Create a PangoLayout, set the font and text */
>  		hide_layout = gp_cairo_create_layout (plot->cr);
>  		pango_layout_set_text (hide_layout, enhanced_text_utf8, -1);
> -		hide_desc = pango_font_description_new ();
> -		pango_font_description_set_family (hide_desc, gp_cairo_enhanced_get_fontname(plot));
> +                hide_desc = pango_font_description_from_string (gp_cairo_enhanced_get_fontname(plot));
>  		pango_font_description_set_size(hide_desc,(int) gp_cairo_enhanced_fontsize*PANGO_SCALE);
> -		pango_font_description_set_weight (hide_desc,
> -			plot->fontweight ? PANGO_WEIGHT_BOLD : PANGO_WEIGHT_NORMAL);
> -		pango_font_description_set_style (hide_desc,
> -			plot->fontstyle ? PANGO_STYLE_ITALIC : PANGO_STYLE_NORMAL);
>  		pango_layout_set_font_description (hide_layout, hide_desc);
>  		pango_font_description_free (hide_desc);
>  
> @@ -1366,13 +1346,8 @@
>  		/* Create a PangoLayout, set the font and text */
>  		zerowidth_layout = gp_cairo_create_layout (plot->cr);
>  		pango_layout_set_text (zerowidth_layout, enhanced_text_utf8, -1);
> -		zerowidth_desc = pango_font_description_new ();
> -		pango_font_description_set_family (zerowidth_desc, gp_cairo_enhanced_get_fontname(plot));
> +                zerowidth_desc = pango_font_description_from_string (gp_cairo_enhanced_get_fontname(plot));
>  		pango_font_description_set_size(zerowidth_desc,(int) gp_cairo_enhanced_fontsize*PANGO_SCALE);
> -		pango_font_description_set_weight (zerowidth_desc,
> -			plot->fontweight ? PANGO_WEIGHT_BOLD : PANGO_WEIGHT_NORMAL);
> -		pango_font_description_set_style (zerowidth_desc,
> -			plot->fontstyle ? PANGO_STYLE_ITALIC : PANGO_STYLE_NORMAL);
>  		pango_layout_set_font_description (zerowidth_layout, zerowidth_desc);
>  		pango_font_description_free (zerowidth_desc);
>  		pango_layout_get_extents(zerowidth_layout, NULL, &zerowidth_logical_rect);
> @@ -1459,7 +1434,7 @@
>  	if (!gp_cairo_enhanced_opened_string) {
>  		gp_cairo_enhanced_opened_string = TRUE;
>  		gp_cairo_enhanced_char = gp_cairo_enhanced_string;
> -		strncpy(gp_cairo_enhanced_font, fontname, sizeof(gp_cairo_enhanced_font));
> +                gp_cairo_set_font_enhanced (fontname);
>  		gp_cairo_enhanced_fontsize = fontsize*plot->oversampling_scale;
>  		gp_cairo_enhanced_base = base*plot->oversampling_scale;
>  		gp_cairo_enhanced_showflag = showflag;
> @@ -1724,13 +1699,8 @@
>  	/* Create a PangoLayout, set the font and text */
>  	layout = gp_cairo_create_layout (plot->cr);
>  	pango_layout_set_text (layout, "0123456789", -1);
> -	desc = pango_font_description_new ();
> -	pango_font_description_set_family (desc, plot->fontname);
> +        desc = pango_font_description_from_string (plot->fontname);
>  	pango_font_description_set_size(desc,(int) (plot->fontsize*PANGO_SCALE*plot->oversampling_scale));
> -	pango_font_description_set_weight (desc,
> -		plot->fontweight ? PANGO_WEIGHT_BOLD : PANGO_WEIGHT_NORMAL);
> -	pango_font_description_set_style (desc,
> -		plot->fontstyle ? PANGO_STYLE_ITALIC : PANGO_STYLE_NORMAL);
>  	pango_layout_set_font_description (layout, desc);
>  	pango_font_description_free (desc);
>  	pango_layout_get_extents(layout, &ink_rect, &logical_rect);

[PATCH] gnuplot cairo: enhanced string font attributes

[Maxim N. <m.a...@gm...>]

Handle font style and weight in enhanced strings
(e.g. "sin({/Serif:Italic x})") for cairo-based terminals.

Colon is replaced by spaces and the string is passed
to pango_font_description_from_string().
No parsing of 'Italic' and 'Bold' withing gnuplot
is required anymore. Font size set by pango is ignored
(e.g. "{/Times:12 x}"). Font size still managed
by gnuplot in traditional ways ("Serif,16" in term options
and enhanced strings "{/=16 x}" or "{/*1.4 x}").
Hyphens in font names should not be touched.

---
It was a bad surprise when I faced that, unlike postscript
terminal, modern pdfcairo does not allow to set italic font
in the part of axis label (set xlabel "Distance {/Italic L}, m").

The implemented simple approach does not support
inheritance of font attributes in nested braces.
The string "{/Bold {/Italic Italic}}" produces
normal italic, not bold.

The quite close issues have been recently addressed in
https://groups.google.com/forum/?fromgroups=#!topic/comp.graphics.apps.gnuplot/fzs_uV6Oe8Y
https://groups.google.com/forum/?fromgroups=#!topic/comp.graphics.apps.gnuplot/YZGWsVBpuTI

I have no experience with gnuplot sources and pango library,
so the path below should be carefully inspected.



Index: src/wxterminal/gp_cairo.c
===================================================================
RCS file: /cvsroot/gnuplot/gnuplot/src/wxterminal/gp_cairo.c,v
retrieving revision 1.70
diff -u -r1.70 gp_cairo.c
--- src/wxterminal/gp_cairo.c	22 Apr 2013 18:49:17 -0000	1.70
+++ src/wxterminal/gp_cairo.c	25 Apr 2013 17:09:59 -0000
@@ -1,5 +1,5 @@
 /*
- * $Id: gp_cairo.c,v 1.70 2013/04/22 18:49:17 sfeam Exp $
+ * $Id: gp_cairo.c,v 1.69 2013/03/07 22:06:33 sfeam Exp $
  */
 
 /* GNUPLOT - gp_cairo.c */
@@ -109,6 +109,9 @@
 static PangoAttrList *gp_cairo_enhanced_underprinted_AttrList = NULL;
 /* converts text from symbol encoding to utf8 encoding */
 static gchar* gp_cairo_convert_symbol_to_unicode(plot_struct *plot, const char* string);
+/* copy font string to gp_cairo_enhanced_font
+ * and replace ':' to spaces */
+static void gp_cairo_set_font_enhanced(const char *name);
 /* add standard attributes (fontsize,fontfamily, rise) to
  * the specified characters in a PangoAttrList */
 static void gp_cairo_add_attr(plot_struct *plot, PangoAttrList * AttrList, int start, int end );
@@ -296,36 +299,27 @@
 void gp_cairo_set_font(plot_struct *plot, const char *name, int fontsize)
 {
     char *c;
-    char *fname;
 
 	FPRINTF((stderr,"set_font \"%s\" %d\n", name,fontsize));
 
-	/* Split out Bold and Italic attributes from font name */
-	fname = strdup(name);
-	for (c=fname; *c; c++) {
-	    if (*c == '\\') {
-		char *d = c;
-		do { *d = *(d+1); } while (*d++);
-	    } else {
-		if (*c == '-') *c = ' ';
-	    }
-	}
-	if ((c = strstr(fname, " Bold"))) {
-	    do { *c = *(c+5); } while (*c++);
-	    plot->fontweight = PANGO_WEIGHT_BOLD;
-	} else
-	    plot->fontweight = 0;
-	if ((c = strstr(fname, " Italic"))) {
-	    do { *c = *(c+7); } while (*c++);
-	    plot->fontstyle = PANGO_STYLE_ITALIC;
-	} else
-	    plot->fontstyle = 0;
-
-	strncpy( plot->fontname, fname, sizeof(plot->fontname) );
-	plot->fontsize = fontsize;
-	free(fname);
+	strncpy( plot->fontname, name, sizeof(plot->fontname) );
+        plot->fontsize = fontsize;
+        for (c = plot->fontname; *c != '\0'; ++c) {
+           if (*c == ':')
+              *c = ' ';
+        }
 }
 
+void gp_cairo_set_font_enhanced(const char *name)
+{
+    char *c;
+
+	strncpy(gp_cairo_enhanced_font, name, sizeof(gp_cairo_enhanced_font) );
+        for (c = gp_cairo_enhanced_font; *c != '\0'; ++c) {
+           if (*c == ':')
+              *c = ' ';
+        }
+}
 
 void gp_cairo_set_linewidth(plot_struct *plot, double linewidth)
 {
@@ -789,8 +783,7 @@
 
 	pango_layout_set_text (layout, string_utf8, -1);
 	g_free(string_utf8);
-	desc = pango_font_description_new ();
-	pango_font_description_set_family (desc, (const char*) plot->fontname);
+        desc = pango_font_description_from_string (plot->fontname);
 #ifdef MAP_SYMBOL
 	/* restore the Symbol font setting */
 	if (symbol_font_parsed)
@@ -798,10 +791,6 @@
 #endif /*MAP_SYMBOL*/
 	pango_font_description_set_size (desc, (int) (plot->fontsize*PANGO_SCALE*plot->oversampling_scale) );
 
-	pango_font_description_set_weight (desc,
-		plot->fontweight ? PANGO_WEIGHT_BOLD : PANGO_WEIGHT_NORMAL);
-	pango_font_description_set_style (desc,
-		plot->fontstyle ? PANGO_STYLE_ITALIC : PANGO_STYLE_NORMAL);
 	pango_layout_set_font_description (layout, desc);
 	pango_font_description_free (desc);
 
@@ -1139,22 +1128,22 @@
 
 void gp_cairo_add_attr(plot_struct *plot, PangoAttrList * AttrList, int start, int end )
 {
-	PangoAttribute *p_attr_rise, *p_attr_size, *p_attr_family;
-
-	p_attr_size = pango_attr_size_new ((int) (gp_cairo_enhanced_fontsize*PANGO_SCALE));
-	p_attr_size->start_index = start;
-	p_attr_size->end_index = end;
-	pango_attr_list_insert (AttrList, p_attr_size);
+	PangoAttribute *p_attr_rise, *p_attr_desc;
+        PangoFontDescription *desc;
 
 	p_attr_rise = pango_attr_rise_new ((int) (gp_cairo_enhanced_base*PANGO_SCALE));
 	p_attr_rise->start_index = start;
 	p_attr_rise->end_index = end;
 	pango_attr_list_insert (AttrList, p_attr_rise);
 
-	p_attr_family = pango_attr_family_new (gp_cairo_enhanced_get_fontname(plot));
-	p_attr_family->start_index = start;
-	p_attr_family->end_index = end;
-	pango_attr_list_insert (AttrList, p_attr_family);
+        desc = pango_font_description_from_string (gp_cairo_enhanced_get_fontname(plot));
+        pango_font_description_set_size (desc, (int) (gp_cairo_enhanced_fontsize*PANGO_SCALE));
+        p_attr_desc = pango_attr_font_desc_new (desc);
+        p_attr_desc->start_index = start;
+        p_attr_desc->end_index = end;
+        pango_attr_list_insert (AttrList, p_attr_desc);
+        
+        pango_font_description_free (desc);
 }
 
 /* add a blank character to the text string with a custom shape */
@@ -1289,13 +1278,9 @@
 		/* Create a PangoLayout, set the font and text */
 		current_layout = gp_cairo_create_layout (plot->cr);
 		pango_layout_set_text (current_layout, enhanced_text_utf8, -1);
-		current_desc = pango_font_description_new ();
-		pango_font_description_set_family (current_desc, gp_cairo_enhanced_get_fontname(plot));
+                current_desc = pango_font_description_from_string (
+                      gp_cairo_enhanced_get_fontname(plot));
 		pango_font_description_set_size(current_desc,(int) gp_cairo_enhanced_fontsize*PANGO_SCALE);
-		pango_font_description_set_weight (current_desc,
-			plot->fontweight ? PANGO_WEIGHT_BOLD : PANGO_WEIGHT_NORMAL);
-		pango_font_description_set_style (current_desc,
-			plot->fontstyle ? PANGO_STYLE_ITALIC : PANGO_STYLE_NORMAL);
 
 		pango_layout_set_font_description (current_layout, current_desc);
 		pango_font_description_free (current_desc);
@@ -1335,13 +1320,8 @@
 		/* Create a PangoLayout, set the font and text */
 		hide_layout = gp_cairo_create_layout (plot->cr);
 		pango_layout_set_text (hide_layout, enhanced_text_utf8, -1);
-		hide_desc = pango_font_description_new ();
-		pango_font_description_set_family (hide_desc, gp_cairo_enhanced_get_fontname(plot));
+                hide_desc = pango_font_description_from_string (gp_cairo_enhanced_get_fontname(plot));
 		pango_font_description_set_size(hide_desc,(int) gp_cairo_enhanced_fontsize*PANGO_SCALE);
-		pango_font_description_set_weight (hide_desc,
-			plot->fontweight ? PANGO_WEIGHT_BOLD : PANGO_WEIGHT_NORMAL);
-		pango_font_description_set_style (hide_desc,
-			plot->fontstyle ? PANGO_STYLE_ITALIC : PANGO_STYLE_NORMAL);
 		pango_layout_set_font_description (hide_layout, hide_desc);
 		pango_font_description_free (hide_desc);
 
@@ -1366,13 +1346,8 @@
 		/* Create a PangoLayout, set the font and text */
 		zerowidth_layout = gp_cairo_create_layout (plot->cr);
 		pango_layout_set_text (zerowidth_layout, enhanced_text_utf8, -1);
-		zerowidth_desc = pango_font_description_new ();
-		pango_font_description_set_family (zerowidth_desc, gp_cairo_enhanced_get_fontname(plot));
+                zerowidth_desc = pango_font_description_from_string (gp_cairo_enhanced_get_fontname(plot));
 		pango_font_description_set_size(zerowidth_desc,(int) gp_cairo_enhanced_fontsize*PANGO_SCALE);
-		pango_font_description_set_weight (zerowidth_desc,
-			plot->fontweight ? PANGO_WEIGHT_BOLD : PANGO_WEIGHT_NORMAL);
-		pango_font_description_set_style (zerowidth_desc,
-			plot->fontstyle ? PANGO_STYLE_ITALIC : PANGO_STYLE_NORMAL);
 		pango_layout_set_font_description (zerowidth_layout, zerowidth_desc);
 		pango_font_description_free (zerowidth_desc);
 		pango_layout_get_extents(zerowidth_layout, NULL, &zerowidth_logical_rect);
@@ -1459,7 +1434,7 @@
 	if (!gp_cairo_enhanced_opened_string) {
 		gp_cairo_enhanced_opened_string = TRUE;
 		gp_cairo_enhanced_char = gp_cairo_enhanced_string;
-		strncpy(gp_cairo_enhanced_font, fontname, sizeof(gp_cairo_enhanced_font));
+                gp_cairo_set_font_enhanced (fontname);
 		gp_cairo_enhanced_fontsize = fontsize*plot->oversampling_scale;
 		gp_cairo_enhanced_base = base*plot->oversampling_scale;
 		gp_cairo_enhanced_showflag = showflag;
@@ -1724,13 +1699,8 @@
 	/* Create a PangoLayout, set the font and text */
 	layout = gp_cairo_create_layout (plot->cr);
 	pango_layout_set_text (layout, "0123456789", -1);
-	desc = pango_font_description_new ();
-	pango_font_description_set_family (desc, plot->fontname);
+        desc = pango_font_description_from_string (plot->fontname);
 	pango_font_description_set_size(desc,(int) (plot->fontsize*PANGO_SCALE*plot->oversampling_scale));
-	pango_font_description_set_weight (desc,
-		plot->fontweight ? PANGO_WEIGHT_BOLD : PANGO_WEIGHT_NORMAL);
-	pango_font_description_set_style (desc,
-		plot->fontstyle ? PANGO_STYLE_ITALIC : PANGO_STYLE_NORMAL);
 	pango_layout_set_font_description (layout, desc);
 	pango_font_description_free (desc);
 	pango_layout_get_extents(layout, &ink_rect, &logical_rect);

Re: Adding an _arc() terminal entry

[Christoph B. <us...@be...>]

Am 19.04.2013 20:56, schrieb Ethan A Merritt:
> On Thursday, April 18, 2013 11:26:31 pm Christoph Bersch wrote:
>>
>> Yes, I saw this, but didn't know if this information was supposed to be
>> transparent to the terminal drivers.
>
> The word "transparent" has unfortunately become ambiguous in
> [American] English.  I don't know whether you mean "supposed to be
> easily inspected by terminal drivers" or "supposed to be invisible
> to terminal drivers".

I didn't know, if this information was supposed to be easily inspected 
by terminal drivers.

> I think it is preferable to have the core
> code do the clipping so that the result is not terminal-dependent.

Yes, I agree, although additionally allowing terminal-dependent clipping 
would give better results in some cases (e.g. proper clipping of line ends).

I just submitted a patch for improved polygon clipping in the core code 
to sf http://sourceforge.net/p/gnuplot/bugs/1237/

>
> I'm OK with the idea of adding a TBOOLEAN clip property for "set object".

I would like to see this.

Another point related to clipping is different handling of the border of 
a clipped rectangles vs clipped polygon:

reset
set lmargin at screen 0.5
set xrange[0:2]
set yrange[0:2.5]
set macro
obj_style = 'fillstyle empty border lc rgb ''red'' lw 5'
set object rectangle from first -1,1 to 1,0.5 @obj_style
set object polygon from first -1,1.5 to 1,1.5 to 1,2 to -1,2 @obj_style
set object 2 @obj_style
plot x


Christoph

Re: Adding an _arc() terminal entry

[Ethan A M. <sf...@us...>]

On Thursday, April 18, 2013 11:26:31 pm Christoph Bersch wrote:
> Am 18.04.2013 22:40, schrieb Ethan A Merritt:
> > On Thursday, April 18, 2013 12:06:59 pm Christoph Bersch wrote:
> >>
> >> * I would suggest, that the information, whether clipping is necessary,
> >> and to which rectangle it should be clipped is provided by a
> >> terminal-independent function.
> >
> > The current clipping area is maintained in the global structure
> >    gadgets.h:extern BoundingBox *clip_area; /* Current clipping box */
> 
> Yes, I saw this, but didn't know if this information was supposed to be 
> transparent to the terminal drivers.

The word "transparent" has unfortunately become ambiguous in
[American] English.  I don't know whether you mean "supposed to be
easily inspected by terminal drivers" or "supposed to be invisible
to terminal drivers".

As it stands, the clip_area structure is only used by the higher level code.
No existing driver refers to it.   I would say that if it becomes desirable
to pass explicit clipping information to a terminal driver, then a new
terminal entry point should be created for that purpose.  But so far that
has not been necessary.  I think it is preferable to have the core
code do the clipping so that the result is not terminal-dependent.

 
> Yes, in my case it was something like:
> set xrange[0:10]
> set yrange[-1.2:1.2]
> set object circle at graph 0, first 1 radius 0.1
> plot cos(x)
> 
> And specifying this circle center with screen coordinates is somewhat 
> fiddly.

I'm OK with the idea of adding a TBOOLEAN clip property for "set object".
Nevertheless I think that "plot ... with {circles|ellipses}" should
continue to always clip to the graph boundary, just as line or points
are always limited to the graph interior.

	Ethan

Re: Adding an _arc() terminal entry

[Christoph B. <us...@be...>]

Am 18.04.2013 22:40, schrieb Ethan A Merritt:
> On Thursday, April 18, 2013 12:06:59 pm Christoph Bersch wrote:
>>
>> * I would suggest, that the information, whether clipping is necessary,
>> and to which rectangle it should be clipped is provided by a
>> terminal-independent function.
>
> The current clipping area is maintained in the global structure
>    gadgets.h:extern BoundingBox *clip_area; /* Current clipping box */

Yes, I saw this, but didn't know if this information was supposed to be 
transparent to the terminal drivers.

>> In the current implementation
>> the circle object is useless for marking something around the graph
>> boundary (could just be a single dot on the border).
>
> Not really.  You just have to specify the position in screen, rather
> than plot, coordinates.  You wouldn't normally specify the graph
> boundary in plot coordinates anyhow so I don't see this as much of a
> restriction.  It is true that the most obvious way to position
> something on the graph boundary is to use graph coordinates
>     set obj 1 at graph 0, graph 1
> and currently the code in graphics.c would set the corresponding
> clip area to the graph boundary.  Perhaps it shouldn't?  Or perhaps
> that would be where your proposed clipping flag would come in?

Yes, in my case it was something like:

set xrange[0:10]
set yrange[-1.2:1.2]
set object circle at graph 0, first 1 radius 0.1
plot cos(x)

And specifying this circle center with screen coordinates is somewhat 
fiddly.
Also if one plots with circle

>> This might also be
>> implemented as a new value for 'set clip' and could also affect all
>> other objects.
>
> The same clipping area and clipping primitives are used for all
> objects.  The clipping of filled curves is a partial exception,
> since it gets very complicated to determine the correct clipping
> for a filled curves whose vertices are off the edge of the canvas.
>
>> As another thing I would suggest two distinct terminal entries _arc()
>> and filledarc().
>>
>> I'm looking forward to your comments and suggestions,
>
> I suggest that before investing a lot of time in this you first
> dummy up a bit of terminal-specific output and compare it to the
> result of the generic code in do_arc().  You might be surprised
> at how much alike they look.  I originally coded up a postscript
> specific term->arc routine that used the PS Level 2 arc function.
> But the result was not notably better than the generic function
> so I abandoned the idea.  That was before the cairo terminals
> were added, however, so I didn't do the comparison for those.

I already have some code snippets for the cairo, Postscript and SVG 
terminals. You are right, there is hardly any difference, but I liked 
the idea of having an own terminal entries for graphic primitives like 
the circle :-)

Thank you for you comments,
Christoph

Release announcement - gnuplot version 4.6.3

[Ethan A M. <sf...@us...>]

Release 4.6.3 is now available for download from SourceForge.

Yes, only a month has gone by since release 4.6.2.
There are two reasons for such a short interval between releases:

1) Preparation/testing of Windows binaries for 4.6.2 turned up 
   several problems.  These were fixed by backporting changes from
   the development version.  Rather than allowing divergence in 
   the source and binary release packages for "4.6.2" it seemed 
   better to bump the patchlevel and label both as 4.6.3

2) Two regressions related to color handling crept into 4.6.2
   One regression caused the "monochrome" terminal option to be
   ignored in some conditions.  
   The other regression caused the text and graphics color in
   postscript- and cairo- based LaTeX terminals to get out of sync.
   Both regressions have been fixed in 4.6.3 


		happy gnuplotting,

			Ethan (gnuplot development team)



Full Release Notes follow:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

		   GNUPLOT VERSION 4.6.3
	    ===================================

This is an incremental release of gnuplot version 4.6 containing updated
support for Windows installation and fixes for several regressions in
color handling that affected the version 4.6.2 postscript, pdf, cairo, and
associated latex terminals.

A short list of changes since the previous patchlevel (version 4.6.2)
is given below and in the NEWS file.  Detailed information is in ChangeLog.

New features, changes and fixes since gnuplot version 4.6.2
===========================================================

* NEW space raises console for console mode gnuplot on Windows
* CHANGE -persist mode does not open text window of wgnuplot
* FIX -persist mode broken on Windows
* FIX -persist mode results in zombie process if using wxt terminal on Windows
* FIX suppression of color in linetypes after "set term ... mono"
* FIX synchronization of graphics and text color in latex terminals


		 NOTES TO PACKAGERS AND TESTERS 
		===============================

Configuration options for interactive use
-----------------------------------------

The 4.6 source code supports three primary cross-platform output modes
in addition to several platform-specific modes.

1) Cairo/pango/wxWidgets
   These terminals were introduced in version 4.4 and are now the most
   stable and full-featured option.  This set of terminals includes
   - pngcairo, pdfcairo, epscairo, and cairolatex for output to a file
   - wxt for interactive display
   This is the default configuration, but requires prior installation of
   libcairo, libpango, libcairo, libwxgtk, and related support libraries
   To disable these terminals:
       ./configure --disable-wxt --without-cairo

2) Qt
   The new qt terminal supports interactive display with menu-driven
   output to png, svg or pdf.
   Requires libqt version >= 4.5
       ./configure --enable-qt

3) X11 (the "classic" interactive interface)
   This used to be the preferred interactive interface, but the newer
   wxt and qt terminals offer nicer output and a wider range of features.


Options for output to files
---------------------------

Of course the terminals (output modes) present in previous gnuplot versions
are also still available. These include, among many more obscure options:
- png/jpeg/gif output via libgd
- PostScript
- Many flavors of TeX/LaTeX output, including TikZ and ConTeXt (new)
- Bitmapped output to support many older devices (e.g. HP deskjet, epson,
  seiko printers, pbm bitmapped graphics files) is available if needed
  but is no longer configured in by default.  Note that the bitmap code
  copyright is more restrictive than the rest of the gnuplot code.
      ./configure --with-bitmap-terminals

Options for generating interactive plots for web display
--------------------------------------------------------

- Mouseable output for display on the web can be created using either 
  the canvas terminal (HTML5 2D canvas element) or the svg terminal.
  Both allow zooming, toggling plot elements on/off, and user-scriptable
  hot keys.

Online demo plots
-----------------

Demo plots illustrating new and old features are online at

	http://gnuplot.sourceforge.net/demo/


		          OTHER NOTES
		===============================

Installation
------------

You can download a source tarball for gnuplot version 4.6.3 from the 
gnuplot development site on SourceForge.

	http://sourceforge.net/project/showfiles.php?group_id=2055

Installation instructions are available in the source itself; the short
version for linux/unix-like systems is to unpack the tarball and then
build it:
		cd gnuplot-4.6.3 ; ./configure ; make
test it:
		make check
install it:
		make install

Pay careful attention to the output of the ./configure script.
It may indicate that some output drivers have been omitted because the
necessary support libraries were not found.  In general you need to have
previously installed the "*-devel-*" versions of these libraries. 


Known issues
------------

- Mac OSX ships with a terminal input library that appears to be GNU
libreadline, but isn't really.  The program tries to cope with this, but
you may get better results by configuring gnuplot to use either its own
built-in readline routines or the real GNU libreadline.

- The gnuplot build system is not very good at figuring out where to find
or install LaTeX-related files.  This can affect use of the new lua/tikz
and ConTeXt terminals.

- You can configure support for both wxt and qt into the same gnuplot
executable, but only one of these two output modes can be used in any
given gnuplot session.


Support
-------
Please report all bugs and installation problems to the bug tracker
on SourceForge:

	http://sourceforge.net/tracker/?group_id=2055&atid=102055

There is also an gnuplot discussion forum on usenet group

	comp.graphics.apps.gnuplot


Development
-----------
Gnuplot development is quite active. The development branch on SourceForge
contains preliminary implementations of many new features.  The current
development branch is labeled version 4.7, but will probably be released as
version 5.  Feedback and contributions of code are very welcome.

Re: Adding an _arc() terminal entry

[Ethan A M. <sf...@us...>]

On Thursday, April 18, 2013 12:06:59 pm Christoph Bersch wrote:
> Hi,
> 
> I am working on an _arc() terminal entry and during this some questions 
> about possible design/features came up:
> 
> 1. The main issue is about the clipping. In the current implementation, 
> the circles are always clipped at the graph boundaries.

Not quite correct.
The graphics code sets a current clip area and then calls
do_arc(),  which clips to whatever area was set.

For circles the clip area is set to the graph boundaries if the center
is specified in plot ("first" or "second") coordinates or in graph
coordinates, but not if it is specified in screen coordinates.  


> * The clipping of the circles must be done inside each individual 
> terminal implementation (works e.g. with Postscript, cairo-related 
> terminals, SVG and others).
> * I would suggest, that the information, whether clipping is necessary, 
> and to which rectangle it should be clipped is provided by a 
> terminal-independent function.

The current clipping area is maintained in the global structure 
  gadgets.h:extern BoundingBox *clip_area; /* Current clipping box */

If the clipping area is set to the entire canvas, then no clipping is
visible.   Note that this is different from not doing clipping at all.
Some of the older terminals would segfault if lines were drawn off the
edge of the canvas, so clipping to the canvas boundary was important.


> * Should the circle object support a [no]clip parameter, which can 
> control the clipping at the graph border? 

So far I haven't seen a need for that, but maybe you have a new use
case that would want it.

> In the current implementation 
> the circle object is useless for marking something around the graph 
> boundary (could just be a single dot on the border). 

Not really.  You just have to specify the position in screen, rather
than plot, coordinates.  You wouldn't normally specify the graph
boundary in plot coordinates anyhow so I don't see this as much of a
restriction.  It is true that the most obvious way to position 
something on the graph boundary is to use graph coordinates
   set obj 1 at graph 0, graph 1
and currently the code in graphics.c would set the corresponding
clip area to the graph boundary.  Perhaps it shouldn't?  Or perhaps
that would be where your proposed clipping flag would come in? 


> This might also be 
> implemented as a new value for 'set clip' and could also affect all 
> other objects.

The same clipping area and clipping primitives are used for all
objects.  The clipping of filled curves is a partial exception,
since it gets very complicated to determine the correct clipping
for a filled curves whose vertices are off the edge of the canvas.

> As another thing I would suggest two distinct terminal entries _arc() 
> and filledarc().
> 
> I'm looking forward to your comments and suggestions,

I suggest that before investing a lot of time in this you first
dummy up a bit of terminal-specific output and compare it to the
result of the generic code in do_arc().  You might be surprised
at how much alike they look.  I originally coded up a postscript
specific term->arc routine that used the PS Level 2 arc function.
But the result was not notably better than the generic function
so I abandoned the idea.  That was before the cairo terminals
were added, however, so I didn't do the comparison for those.  

	Ethan

Adding an _arc() terminal entry

[Christoph B. <us...@be...>]

Hi,

I am working on an _arc() terminal entry and during this some questions 
about possible design/features came up:

1. The main issue is about the clipping. In the current implementation, 
the circles are always clipped at the graph boundaries.

* The clipping of the circles must be done inside each individual 
terminal implementation (works e.g. with Postscript, cairo-related 
terminals, SVG and others).
* I would suggest, that the information, whether clipping is necessary, 
and to which rectangle it should be clipped is provided by a 
terminal-independent function.

* Should the circle object support a [no]clip parameter, which can 
control the clipping at the graph border? In the current implementation 
the circle object is useless for marking something around the graph 
boundary (could just be a single dot on the border). This might also be 
implemented as a new value for 'set clip' and could also affect all 
other objects.


As another thing I would suggest two distinct terminal entries _arc() 
and filledarc().

I'm looking forward to your comments and suggestions,
Christoph