plplot-general — PLplot user discussion group

Re: [Plplot-general] Installation problem on Linux RH3

[Werner S. <sm...@ia...>]

Hi Hans,

I just commited a change to svn, although I couldn't test it. Anyway,  
I think there was a function definition still not encompassed by the  
correct #ifdef/#endif code. Either check out the latest svn or change  
the following lines in drivers/gd.c:

from line 233 on:

int plToGdAlpha( PLFLT a ) {
   int tmp = (int)((1.0-a)*gdAlphaMax);
   return tmp;
}

to

#if GD2_VERS >= 2
int plToGdAlpha( PLFLT a ) {
   int tmp = (int)((1.0-a)*gdAlphaMax);
   return tmp;
}
#endif

Let us know if this works for you, since nobody here still has gd 1.8.

Thanks,
Werner

On 10.12.2008, at 11:44, <Han...@sh...> <Han...@sh... 
 > wrote:

> Andrew,
>
> I just downloaded the 5.9.0 release and get the same error about the  
> alpha channel again. Did the fix not make it into this release and  
> if not in which release will it be ?
>
> Thanks,
> Hans
>
>

--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: sm...@ia...
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499

Re: [Plplot-general] Installation problem on Linux RH3

[<Han...@sh...>]

Andrew,

I just downloaded the 5.9.0 release and get the same error about the alpha channel again. Did the fix not make it into this release and if not in which release will it be ?

Thanks,
Hans

-----Original Message-----
From: Andrew Ross [mailto:and...@us...]
Sent: Thursday, January 17, 2008 13:27
To: Rijneke, Hans H SIEP-EPT-RIS
Cc: plp...@li...
Subject: Re: [Plplot-general] Installation problem on Linux RH3



Excellent. Glad to hear it.

Andrew

On Thu, Jan 17, 2008 at 12:25:20PM +0100, Han...@sh... wrote:
> Andrew,
> 
> Got the new source tree and now it compiled without any problems.
> 
> Thanks a lot.
> 
> Regards,
> Hans Rijneke.
> 
> Shell International Exploration and Production B.V.
> The Hague, The Netherlands - Trade Register no. 27002688
> Address: Kessler Park 1, 2280 GS  Rijswijk, The Netherlands
> 
> (: +31 070 447 2737
> *: <mailto:han...@sh...>
> 6: <http://www.shell.com/eandp-en>
> 
> Disclaimer of Liability: 
> This message, any attachment and response string are confidential and may be legally  privileged. It is intended only for the use of the parties to  whom it is addressed. If you are not the addressee indicated  in this message please notify the sender immediately by reply  email and destroy this message.
> All information and  attachments remain the property of Shell
> 
> 
> -----Original Message-----
> From: Andrew Ross [mailto:and...@us...]
> Sent: woensdag 16 januari 2008 15:39
> To: Rijneke, Hans H SIEP-EPT-RIS
> Cc: plp...@li...
> Subject: Re: [Plplot-general] Installation problem on Linux RH3
> 
> 
> 
> 
> Hans,
> 
> I have commited the necessary changes to svn to fix the gd problem you
> were seeing. Alpha channel support is only enabled for gd version >=2
> now.
> 
> Please let me know if this works for you.
> 
> Andrew
> 
> 
> 
> On Wed, Jan 16, 2008 at 12:54:01PM +0100, Han...@sh... wrote:
> > Hi Werner,
> > 
> > Thanks, I'll see what to do.
> > 
> > Regards,
> > Hans
> > 
> > Regards,
> > Hans Rijneke.
> > 
> > Shell International Exploration and Production B.V.
> > The Hague, The Netherlands - Trade Register no. 27002688
> > Address: Kessler Park 1, 2280 GS  Rijswijk, The Netherlands
> > 
> > (: +31 070 447 2737
> > *: <mailto:han...@sh...>
> > 6: <http://www.shell.com/eandp-en>
> > 
> > Disclaimer of Liability: 
> > This message, any attachment and response string are confidential and may be legally  privileged. It is intended only for the use of the parties to  whom it is addressed. If you are not the addressee indicated  in this message please notify the sender immediately by reply  email and destroy this message.
> > All information and  attachments remain the property of Shell
> > 
> > 
> > -----Original Message-----
> > From: plp...@li...
> > [mailto:plp...@li...]On Behalf Of Werner
> > Smekal
> > Sent: woensdag 16 januari 2008 12:41
> > To: plp...@li...
> > Subject: Re: [Plplot-general] Installation problem on Linux RH3
> > 
> > 
> > Hi Hans,
> > 
> > > I indeed did all removing all stuff and have a fresh build.
> > > I digged some deeper (indeed in the gd.c) and noticed the "ifdef" contruction for GD2_VERS >=2
> > > So looking to my system, I have gd.1.8.0 and in the gd.h file is no definition of glAlphaMax.
> > > Going to a RH4 system and looking at the gd.h file (of a here 2.0 version), I see the definition of gdAlpahMax.
> > > So, why is gd.c using gdAlphaMax for a gd version < 2 ?
> > > Is there a way around ?
> > 
> > Ok, you found the problem. Andrew Ross just recently (January 8th) added 
> >   the capability of using the alpha channels to the gd driver. Obviously 
> > this only works for gd library version 2 and therefore this needs to be 
> > taken care of (with some #ifdefs :).
> > 
> > Anyway, a short way around is to get a version of plplot via svn from 
> > before January 8th (don't know the exact svn command, but should be 
> > straight forward) until we fixed this bug. There was not so much changed 
> > in the last week, especially regarding the xwin and gd driver, so 
> > getting an older revision of plplot should have no disadvantages for you.
> > 
> > Regards,
> > Werner
> > 
> > > 
> > > Regards,
> > > Hans Rijneke.
> > 
> > -- 
> > Dr. Werner Smekal
> > Institut fuer Allgemeine Physik
> > Technische Universitaet Wien
> > Wiedner Hauptstr 8-10
> > A-1040 Wien
> > Austria
> > 
> > email: sm...@ia...
> > web:   http://www.iap.tuwien.ac.at/~smekal
> > phone: +43-(0)1-58801-13463 (office)
> >         +43-(0)1-58801-13469 (laboratory)
> > fax:   +43-(0)1-58801-13499
> > 
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Plplot-general mailing list
> > Plp...@li...
> > https://lists.sourceforge.net/lists/listinfo/plplot-general
> > 
> > 
> > 
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Plplot-general mailing list
> > Plp...@li...
> > https://lists.sourceforge.net/lists/listinfo/plplot-general
> > 
> 
> 
> 

Re: [Plplot-general] How to clear/reset a plot in the wxWidgets driver?

[Werner S. <sm...@ia...>]

Hi Robert,
>

> Yes, thank you, this switching to a new page clears the plot window -
> but the growing memory consumption indicates that the content of the
> original page still exists.

I fixed the problem now, the page is cleared now if you use plclear()  
and do a consecutive replot/remake. This was actually not a problem of  
the wxWidgets driver, but of the plot buffer (which took me a while to  
sort out). Anyway, this solution might also be not optimal since the  
plot buffer is not cleared - if you replot the whole (old) plot will  
be plotted which is cleared at the end :). But I also did some other  
improvements, so you might try out the latest svn revision.

One solution would be to clear the plot buffer for such a command, but  
this is problematic, since not everything should be cleared I think,  
this has to be checked and tested. On the other hand it may be better  
to stick with pladv(0) and sort out the increasing memory consumption.  
At least plcear() does now what it should do even if it does it not  
"optimal".

Thanks for the report.

Regards,
Werner


--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: sm...@ia...
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499

Re: [Plplot-general] How to clear/reset a plot in the wxWidgets driver?

[Robert P. <rob...@jk...>]

Werner Smekal wrote:
> You could use
> 
>     pls->adv(0);
> 
> instead of the clear(); statement. This will clear the plot, since a new
> one is started.

Yes, thank you, this switching to a new page clears the plot window -
but the growing memory consumption indicates that the content of the
original page still exists.

--Robert

Re: [Plplot-general] How to clear/reset a plot in the wxWidgets driver?

[Werner S. <sm...@ia...>]

Hi Robert,

I can duplicate this bug/feature here on Mac OS X with the latest  
PLplot revision. You could use

	pls->adv(0);

instead of the clear(); statement. This will clear the plot, since a  
new one is started. I have to to look at the clear function in plplot  
what is supposed to happen.

Regards,
Werner

On 09.12.2008, at 10:28, Robert Pollak wrote:

> Hello Werner,
>
> I am just trying to clear a plot to prepare plotting of a modified  
> diagram.
>
> How is this done? When I try it as follows, the plot window is not
> cleared, and the new title text superimposes the old one instead.
>
> Best regards,
> Robert
>
>
> --- examples/c++/wxPLplotDemo.cpp	(revision 8888)
> +++ examples/c++/wxPLplotDemo.cpp	(working copy)
> @@ -205,4 +205,10 @@
> {
>   wxMessageBox( _T("This is the About dialog of the wxPLplot demo. 
> \n"),
> _T("About wxPLplot"),
>                 wxOK | wxICON_INFORMATION, this );
> +
> +  wxPLplotstream* pls=plotwindow->GetStream();
> +
> +  pls->clear();
> +  pls->lab( "x", "y", "An Empty Plot" );
> +  plotwindow->RenewPlot();
> }

--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: sm...@ia...
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499

[Plplot-general] How to clear/reset a plot in the wxWidgets driver?

[Robert P. <rob...@jk...>]

Hello Werner,

I am just trying to clear a plot to prepare plotting of a modified diagram.

How is this done? When I try it as follows, the plot window is not
cleared, and the new title text superimposes the old one instead.

Best regards,
Robert


--- examples/c++/wxPLplotDemo.cpp	(revision 8888)
+++ examples/c++/wxPLplotDemo.cpp	(working copy)
@@ -205,4 +205,10 @@
 {
   wxMessageBox( _T("This is the About dialog of the wxPLplot demo.\n"),
_T("About wxPLplot"),
                 wxOK | wxICON_INFORMATION, this );
+
+  wxPLplotstream* pls=plotwindow->GetStream();
+
+  pls->clear();
+  pls->lab( "x", "y", "An Empty Plot" );
+  plotwindow->RenewPlot();
 }

Re: [Plplot-general] Fwd: peculiar "segmented" fills using shade plots / plplot 5.8.0 & 5.9.0

[Jerry <lan...@qw...>]

Hi David,

FYI, this discussion has jumped to the developers' list:
Plp...@li...

Jerry


On Nov 19, 2008, at 4:25 AM, David Seery wrote:

>
> On 18 Nov 2008, at 23:02, Werner Smekal wrote:
>
> Hi Werner and Jerry,
>
>> actually such "hairlines" showed up when I worked on the AGG backend
>> of
>> the wxWidgets drivers (which produces antialiased plots as well)
>> when I
>> only filled a "filled polygon" and didn't add a stroke around it,  
>> i.e.
>> draw a line around it.
>
>
> Thanks very much for the illuminating responses. I'd noticed the issue
> with the peculiar shape of the boundary lines, but these wiggles don't
> show up much on screen or when printed out, so I was less worried
> about them than about the hairline cracks.
>
> As far as I can tell, I get this behaviour using the "ps", "psc", or
> "pdf" devices; and using any of the Cairo one, either "pdfcairo" or
> "pscairo".
>
> If the issue is that the polygons don't have boundary strokes, might
> there be a simple way to modify the code so that such strokes are  
> added?
>
> Best wishes
> David
>
> ---------------------------------------------------------------------- 
> ---
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general
>

Re: [Plplot-general] Fwd: peculiar "segmented" fills using shade plots / plplot 5.8.0 & 5.9.0

[David S. <dj...@ca...>]

On 18 Nov 2008, at 23:02, Werner Smekal wrote:

Hi Werner and Jerry,

> actually such "hairlines" showed up when I worked on the AGG backend  
> of
> the wxWidgets drivers (which produces antialiased plots as well)  
> when I
> only filled a "filled polygon" and didn't add a stroke around it, i.e.
> draw a line around it.


Thanks very much for the illuminating responses. I'd noticed the issue  
with the peculiar shape of the boundary lines, but these wiggles don't  
show up much on screen or when printed out, so I was less worried  
about them than about the hairline cracks.

As far as I can tell, I get this behaviour using the "ps", "psc", or  
"pdf" devices; and using any of the Cairo one, either "pdfcairo" or  
"pscairo".

If the issue is that the polygons don't have boundary strokes, might  
there be a simple way to modify the code so that such strokes are added?

Best wishes
David

Re: [Plplot-general] Fwd: peculiar "segmented" fills using shade plots / plplot 5.8.0 & 5.9.0

[Jerry <lan...@qw...>]

Not sure why those files are now hard to download but here are the  
direct links. Probably nothing surprising to the developers except  
for the very odd-looking lines in David's zoomed plot.
Jerry

http://idisk.mac.com/oscarruitt-Public/PDFkit%20screen%20shot.pdf
http://idisk.mac.com/oscarruitt-Public/Adobe%20Reader%20screen% 
20shot.pdf
http://idisk.mac.com/oscarruitt-Public/David's%20plot%20antialiased.pdf
http://idisk.mac.com/oscarruitt-Public/David's%20plot%20not% 
20antialiased.pdf

Jerry

On Nov 18, 2008, at 1:41 PM, Jerry wrote:

>
>
> Begin forwarded message:
>
> From: Jerry Bauck <osc...@ma...>
> Date: November 18, 2008 1:40:20 PM MST
> To: plplot_general <plp...@li...>
> Subject: Fwd: [Plplot-general] peculiar "segmented" fills using shade
> plots / plplot 5.8.0 & 5.9.0
>
>
>
> Begin forwarded message:
>
> From: Jerry <lan...@qw...>
> Date: November 18, 2008 1:11:07 AM MST
> To: plplot_general <plp...@li...>
> Subject: Re: [Plplot-general] peculiar "segmented" fills using shade
> plots / plplot 5.8.0 & 5.9.0
>
>
> On Nov 14, 2008, at 7:06 PM, Hezekiah M. Carty wrote:
>
>> On Fri, Nov 14, 2008 at 7:59 PM, David Seery <dj...@ca...> wrote:
>>> I would like to produce contour plots in which the contours are
>>> filled
>>> with a solid colour. Although the documentation implies that this is
>>> not possible, I gather from reading the examples that it is achieved
>>> by calling plpsty(0). Unfortunately, subsequent calls to plshades
>>> produce weirdly segmented images, in which the solid fill is
>>> broken up
>>> with unwanted lines, like this:
>>>
>>> http://www.damtp.cam.ac.uk/user/djs61/figures.pdf
>>
>> This is, at least in part, due to the fact the the plshade functions
>> in PLplot draw the filled contours as a series of polygons.   
>> Depending
>> on the output device settings used and (in the case of SVG, PS and  
>> PDF
>> output) the viewer used, you may see gaps between these individual
>> polygons.  You can see this in the PNG output for example 21 on the
>> PLplot web site (see the middle image at the bottom of the page)::
>>
>> http://plplot.sourceforge.net/examples.php?demo=21
>
> I have seen this phenomenon routinely when looking at Postscript or
> PDF using Apple's PDFkit rendering. I have no idea if it shows up on
> other platforms or file formats. Typically there is a hairline gap
> between polygons which does _not_ scale when zoomed--the hairline
> remains a hairline at all zoom levels. With a surface plot in which a
> front surface made of many polygons hides a hidden surface, the front
> surface actually appears translucent because of the many "cracks."
> The first time I saw this I thought that PLplot had an alpha channel.
> (This was before it _did_ have an alpha channel.) Here is a screen
> shot (from Skim, which uses PDFkit) of Example 21 from my Mac's
> screen--note that the red grid lines are visible behind the surface,
> too.
>
> (Go to http://public.me.com/oscarruitt and open PDFkit screen  
> shot.pdf)
>
>
> I have assumed in the past that this is a rounding bug in Apple's
> rendering routine. However, since the cracks disappear when
> antialiasing is turned off (as Hez noted earlier in this thread), it
> seems that it is an artifact of the antialiasing. Indeed, one can
> easily see where it comes from if each polygon is individually
> rendered against the dark or differently-colored background without
> regard to the adjoining polygons. The edge of each polygon is
> smoothed with the background, forming the dark (or colored) edge.
> Then the adjoining polygon is rendered the same way, making its own
> dark edge. Then the two images are laid next to one another and the
> two dark edges line up (maybe with one obscuring the other) and form
> the dark crack. The reason that they don't appear on prints is that
> either they are much smaller since printer resolution is much better
> than screen resolution and/or printers don't use antialiasing.
>
> For comparison, this is a screen shot from Adobe Reader 8.1.2 (which
> I rarely use because, well, just look at Preview or Skim.) The
> problem is better but still noticeable.
>
> (Go to http://public.me.com/oscarruitt and open Adobe Reader screen
> shot.pdf)
>
>
> I believe that Adobe bypasses Apple's antialiasing routines in favor
> of their own which are less aggressive.
>
>
> I zoomed in on David's plot at http://www.damtp.cam.ac.uk/user/djs61/
> figures.pdf, specifically the lines to the left. I was surprised to
> see that they have an unusual appearance:
>
> Antialiased:
> (Go to http://public.me.com/oscarruitt and open David's plot
> antialiased.pdf)
>
> Not antialiased:
> (Go to http://public.me.com/oscarruitt and open David's plot no
> antialiased.pdf)
>
>
> Not sure what is going on here. Surely a line is represented
> mathematically as a line and not a bunch of squiggles.
>
> Jerry
>
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general
>

Re: [Plplot-general] Fwd: peculiar "segmented" fills using shade plots / plplot 5.8.0 & 5.9.0

[Werner S. <sm...@ia...>]

Hi Jerry and David,

actually such "hairlines" showed up when I worked on the AGG backend of
the wxWidgets drivers (which produces antialiased plots as well) when I
only filled a "filled polygon" and didn't add a stroke around it, i.e.
draw a line around it.

Actually I believe that our cairo device shows this behaviour no matter
which driver you use (pdf, xcairo, ...) because it uses only cairo_fill
and not cairo_stroke in addition to draw filled polygons. I can't check
that at the moment but will do that tomorrow (need sleep).

Also the pdf driver which is based on haru pdf library, doesn't show
this hairlines (if I'm not wrong) and this driver also fills and strokes
filled polygons.

Regards,
Werner

On Tue, 2008-11-18 at 13:41 -0700, Jerry wrote:
> 
> Begin forwarded message:
> 
> From: Jerry Bauck <osc...@ma...>
> Date: November 18, 2008 1:40:20 PM MST
> To: plplot_general <plp...@li...>
> Subject: Fwd: [Plplot-general] peculiar "segmented" fills using shade  
> plots / plplot 5.8.0 & 5.9.0
> 
> 
> 
> Begin forwarded message:
> 
> From: Jerry <lan...@qw...>
> Date: November 18, 2008 1:11:07 AM MST
> To: plplot_general <plp...@li...>
> Subject: Re: [Plplot-general] peculiar "segmented" fills using shade  
> plots / plplot 5.8.0 & 5.9.0
> 
> 
> On Nov 14, 2008, at 7:06 PM, Hezekiah M. Carty wrote:
> 
> > On Fri, Nov 14, 2008 at 7:59 PM, David Seery <dj...@ca...> wrote:
> >> I would like to produce contour plots in which the contours are  
> >> filled
> >> with a solid colour. Although the documentation implies that this is
> >> not possible, I gather from reading the examples that it is achieved
> >> by calling plpsty(0). Unfortunately, subsequent calls to plshades
> >> produce weirdly segmented images, in which the solid fill is  
> >> broken up
> >> with unwanted lines, like this:
> >>
> >> http://www.damtp.cam.ac.uk/user/djs61/figures.pdf
> >
> > This is, at least in part, due to the fact the the plshade functions
> > in PLplot draw the filled contours as a series of polygons.  Depending
> > on the output device settings used and (in the case of SVG, PS and PDF
> > output) the viewer used, you may see gaps between these individual
> > polygons.  You can see this in the PNG output for example 21 on the
> > PLplot web site (see the middle image at the bottom of the page)::
> >
> > http://plplot.sourceforge.net/examples.php?demo=21
> 
> I have seen this phenomenon routinely when looking at Postscript or  
> PDF using Apple's PDFkit rendering. I have no idea if it shows up on  
> other platforms or file formats. Typically there is a hairline gap  
> between polygons which does _not_ scale when zoomed--the hairline  
> remains a hairline at all zoom levels. With a surface plot in which a  
> front surface made of many polygons hides a hidden surface, the front  
> surface actually appears translucent because of the many "cracks."  
> The first time I saw this I thought that PLplot had an alpha channel.  
> (This was before it _did_ have an alpha channel.) Here is a screen  
> shot (from Skim, which uses PDFkit) of Example 21 from my Mac's  
> screen--note that the red grid lines are visible behind the surface,  
> too.
> 
> (Go to http://public.me.com/oscarruitt and open PDFkit screen shot.pdf)
> 
> 
> I have assumed in the past that this is a rounding bug in Apple's  
> rendering routine. However, since the cracks disappear when  
> antialiasing is turned off (as Hez noted earlier in this thread), it  
> seems that it is an artifact of the antialiasing. Indeed, one can  
> easily see where it comes from if each polygon is individually  
> rendered against the dark or differently-colored background without  
> regard to the adjoining polygons. The edge of each polygon is  
> smoothed with the background, forming the dark (or colored) edge.  
> Then the adjoining polygon is rendered the same way, making its own  
> dark edge. Then the two images are laid next to one another and the  
> two dark edges line up (maybe with one obscuring the other) and form  
> the dark crack. The reason that they don't appear on prints is that  
> either they are much smaller since printer resolution is much better  
> than screen resolution and/or printers don't use antialiasing.
> 
> For comparison, this is a screen shot from Adobe Reader 8.1.2 (which  
> I rarely use because, well, just look at Preview or Skim.) The  
> problem is better but still noticeable.
> 
> (Go to http://public.me.com/oscarruitt and open Adobe Reader screen  
> shot.pdf)
> 
> 
> I believe that Adobe bypasses Apple's antialiasing routines in favor  
> of their own which are less aggressive.
> 
> 
> I zoomed in on David's plot at http://www.damtp.cam.ac.uk/user/djs61/ 
> figures.pdf, specifically the lines to the left. I was surprised to  
> see that they have an unusual appearance:
> 
> Antialiased:
> (Go to http://public.me.com/oscarruitt and open David's plot  
> antialiased.pdf)
> 
> Not antialiased:
> (Go to http://public.me.com/oscarruitt and open David's plot no  
> antialiased.pdf)
> 
> 
> Not sure what is going on here. Surely a line is represented  
> mathematically as a line and not a bunch of squiggles.
> 
> Jerry
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general
-- 
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: sm...@ia...
web:   http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office)
       +43-(0)1-58801-13469 (laboratory)
fax:   +43-(0)1-58801-13499

[Plplot-general] Fwd: peculiar "segmented" fills using shade plots / plplot 5.8.0 & 5.9.0

[Jerry <lan...@qw...>]

Begin forwarded message:

From: Jerry Bauck <osc...@ma...>
Date: November 18, 2008 1:40:20 PM MST
To: plplot_general <plp...@li...>
Subject: Fwd: [Plplot-general] peculiar "segmented" fills using shade  
plots / plplot 5.8.0 & 5.9.0



Begin forwarded message:

From: Jerry <lan...@qw...>
Date: November 18, 2008 1:11:07 AM MST
To: plplot_general <plp...@li...>
Subject: Re: [Plplot-general] peculiar "segmented" fills using shade  
plots / plplot 5.8.0 & 5.9.0


On Nov 14, 2008, at 7:06 PM, Hezekiah M. Carty wrote:

> On Fri, Nov 14, 2008 at 7:59 PM, David Seery <dj...@ca...> wrote:
>> I would like to produce contour plots in which the contours are  
>> filled
>> with a solid colour. Although the documentation implies that this is
>> not possible, I gather from reading the examples that it is achieved
>> by calling plpsty(0). Unfortunately, subsequent calls to plshades
>> produce weirdly segmented images, in which the solid fill is  
>> broken up
>> with unwanted lines, like this:
>>
>> http://www.damtp.cam.ac.uk/user/djs61/figures.pdf
>
> This is, at least in part, due to the fact the the plshade functions
> in PLplot draw the filled contours as a series of polygons.  Depending
> on the output device settings used and (in the case of SVG, PS and PDF
> output) the viewer used, you may see gaps between these individual
> polygons.  You can see this in the PNG output for example 21 on the
> PLplot web site (see the middle image at the bottom of the page)::
>
> http://plplot.sourceforge.net/examples.php?demo=21

I have seen this phenomenon routinely when looking at Postscript or  
PDF using Apple's PDFkit rendering. I have no idea if it shows up on  
other platforms or file formats. Typically there is a hairline gap  
between polygons which does _not_ scale when zoomed--the hairline  
remains a hairline at all zoom levels. With a surface plot in which a  
front surface made of many polygons hides a hidden surface, the front  
surface actually appears translucent because of the many "cracks."  
The first time I saw this I thought that PLplot had an alpha channel.  
(This was before it _did_ have an alpha channel.) Here is a screen  
shot (from Skim, which uses PDFkit) of Example 21 from my Mac's  
screen--note that the red grid lines are visible behind the surface,  
too.

(Go to http://public.me.com/oscarruitt and open PDFkit screen shot.pdf)


I have assumed in the past that this is a rounding bug in Apple's  
rendering routine. However, since the cracks disappear when  
antialiasing is turned off (as Hez noted earlier in this thread), it  
seems that it is an artifact of the antialiasing. Indeed, one can  
easily see where it comes from if each polygon is individually  
rendered against the dark or differently-colored background without  
regard to the adjoining polygons. The edge of each polygon is  
smoothed with the background, forming the dark (or colored) edge.  
Then the adjoining polygon is rendered the same way, making its own  
dark edge. Then the two images are laid next to one another and the  
two dark edges line up (maybe with one obscuring the other) and form  
the dark crack. The reason that they don't appear on prints is that  
either they are much smaller since printer resolution is much better  
than screen resolution and/or printers don't use antialiasing.

For comparison, this is a screen shot from Adobe Reader 8.1.2 (which  
I rarely use because, well, just look at Preview or Skim.) The  
problem is better but still noticeable.

(Go to http://public.me.com/oscarruitt and open Adobe Reader screen  
shot.pdf)


I believe that Adobe bypasses Apple's antialiasing routines in favor  
of their own which are less aggressive.


I zoomed in on David's plot at http://www.damtp.cam.ac.uk/user/djs61/ 
figures.pdf, specifically the lines to the left. I was surprised to  
see that they have an unusual appearance:

Antialiased:
(Go to http://public.me.com/oscarruitt and open David's plot  
antialiased.pdf)

Not antialiased:
(Go to http://public.me.com/oscarruitt and open David's plot no  
antialiased.pdf)


Not sure what is going on here. Surely a line is represented  
mathematically as a line and not a bunch of squiggles.

Jerry

Re: [Plplot-general] Plot line width

[Alan W. I. <ir...@be...>]

On 2008-11-16 08:20-0800 R C wrote:

> Hi,
> Is there a way to increase the plot line width  for eps output? plwid works for png but not for ps or psttf.

Each of the various file and library standards interpret width differently.
Some take a float representing the width, some take an integer representing
the width.  All have various interpretations about how the width value that
is specified translates into visual appearance.  For example, the PostScript
file standard has rather high width resolution, i.e., each change in integer
value results in a rather small visual change in width.  Currently, the
PLplot approach is to interpret the width value specified by the user with
plwid as a "raw" value to be directly interpreted (differently) by the
various file and library standards.

Thus, to solve your immediate problem try setting a substantially larger
value (2x or 3x) of the width to see an obvious visual change for PostScript
devices.

At one point we did try scaling the width values so that each device
interprets the PLplot width with similar visual results. However, the
implementation was done in such a way that devices with coarse width
resolution were interpreted the same as before while the devices with fine
width resolution such as PostScript became unacceptably coarse so we
abandoned that approach.  There are some possible ways out of this mess, but
they all imply serious disruptions for our users such as changing the plwid
argument from an integer to a float with a value of 1.0 looking the same for
all devices.  We will have to think very clearly about this issue and
ultimately we may just decide to minimize the disruption for our users and
continue with the present "raw" width approach despite its obvious drawbacks.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-general] Plot line width

[R C <re...@ya...>]

Hi,
 Is there a way to increase the plot line width  for eps output? plwid works for png but not for ps or psttf.

Thanks,
Recif

Re: [Plplot-general] peculiar "segmented" fills using shade plots / plplot 5.8.0 & 5.9.0

[David S. <dj...@ca...>]

On 15 Nov 2008, at 02:06, Hezekiah M. Carty wrote:

> On Fri, Nov 14, 2008 at 7:59 PM, David Seery <dj...@ca...> wrote:
>> I would like to produce contour plots in which the contours are  
>> filled
>> with a solid colour. Unfortunately, ... calls to plshades
>> produce weirdly segmented images, in which the solid fill is broken  
>> up
>> with unwanted lines, like this:
>>
>> http://www.damtp.cam.ac.uk/user/djs61/figures.pdf
>
> This is, at least in part, due to the fact the the plshade functions
> in PLplot draw the filled contours as a series of polygons.

Thanks very much for your helpful and comprehensive answer. I had  
tried to exclude this possibility by checking the output of the png  
driver, but clearly some mishap occurred (perhaps I looked at the  
wrong file by mistake).

> Vector-based file output (including your example PDF) does not exhibit
> this trait if it is viewed from gv with anti-aliasing disabled.
> Evince (the default PDF viewer in Ubuntu/Gnome) anti-aliases its
> output and does show these inter-polygon lines.  I do not know if
> these lines show up on a printed version of these PDFs.

They don't show up on printed versions, at least on those printers I  
have access to. The anti-aliasing shows up in the same way using  
Apple's Preview, which is partly what made me think the effect was real.

> I have seen this same issue in output from other plotting packages as
> well.  One possible workaround is to plot the shaded regions as a
> bitmap embedded in the PS/PDF/SVG output.  PLplot does not have
> support for this directly at this time.  However, you can accomplish
> this with extra effort using the extcairo driver and a few Cairo
> tricks.  I can go in to how to do this in more detail if desired.

That would be extremely useful if it were possible! I'm trying to  
produce a graph which is scalable and can be embedded within another  
document. It probably won't be possible to turn anti-aliasing off when  
the document is viewed, so this would otherwise seem to be an  
insurmoutable obstacle. I'm slightly perplexed, because I am sure I  
have seen plplot output before which contains contiguous shaded regions.

Thanks very much,
David

Re: [Plplot-general] peculiar "segmented" fills using shade plots / plplot 5.8.0 & 5.9.0

[Hezekiah M. C. <hc...@at...>]

On Fri, Nov 14, 2008 at 7:59 PM, David Seery <dj...@ca...> wrote:
> I would like to produce contour plots in which the contours are filled
> with a solid colour. Although the documentation implies that this is
> not possible, I gather from reading the examples that it is achieved
> by calling plpsty(0). Unfortunately, subsequent calls to plshades
> produce weirdly segmented images, in which the solid fill is broken up
> with unwanted lines, like this:
>
> http://www.damtp.cam.ac.uk/user/djs61/figures.pdf

This is, at least in part, due to the fact the the plshade functions
in PLplot draw the filled contours as a series of polygons.  Depending
on the output device settings used and (in the case of SVG, PS and PDF
output) the viewer used, you may see gaps between these individual
polygons.  You can see this in the PNG output for example 21 on the
PLplot web site (see the middle image at the bottom of the page)::

http://plplot.sourceforge.net/examples.php?demo=21

Conversely, for example 16, anti-aliasing has been disabled for the
graphics in the plots and these lines do not show up for the PNG
output:

http://plplot.sourceforge.net/examples.php?demo=16

Vector-based file output (including your example PDF) does not exhibit
this trait if it is viewed from gv with anti-aliasing disabled.
Evince (the default PDF viewer in Ubuntu/Gnome) anti-aliases its
output and does show these inter-polygon lines.  I do not know if
these lines show up on a printed version of these PDFs.

I have seen this same issue in output from other plotting packages as
well.  One possible workaround is to plot the shaded regions as a
bitmap embedded in the PS/PDF/SVG output.  PLplot does not have
support for this directly at this time.  However, you can accomplish
this with extra effort using the extcairo driver and a few Cairo
tricks.  I can go in to how to do this in more detail if desired.

I hope this helps.

Hez

-- 
Hezekiah M. Carty
Graduate Research Assistant
University of Maryland
Department of Atmospheric and Oceanic Science

[Plplot-general] peculiar "segmented" fills using shade plots / plplot 5.8.0 & 5.9.0

[David S. <dj...@ca...>]

Hello,

I am using plplot to produce some "shade" plots and have encountered  
some problems. I am running an out-of-the-box version of plplot 5.9.0  
installed via darwinports under Mac OS. I'm interacting with plplot  
via the C library bindings.

I would like to produce contour plots in which the contours are filled  
with a solid colour. Although the documentation implies that this is  
not possible, I gather from reading the examples that it is achieved  
by calling plpsty(0). Unfortunately, subsequent calls to plshades  
produce weirdly segmented images, in which the solid fill is broken up  
with unwanted lines, like this:

http://www.damtp.cam.ac.uk/user/djs61/figures.pdf

(This plot was produced by allowing plshades to consolidate  
rectangular fills - disabling this option produces an image formed by  
tiny areas of solid fill bordered by white lines. The plot comes from  
the pdfcairo device, but the same output is produced by any driver. By  
zooming in on the image, it's possible to see that the black lines  
which mark the contours are afflicted by a similar unwanted patterning  
with white lines.)

I have checked that the same effect is present if I compile the  
supplied examples which use plshades. To check that it's not just an  
issue with the version of plplot I have installed, I have checked that  
I get identical results running the out-of-the-box packaging of plplot  
available in Ubuntu, currently version 5.8.0.

Has anyone encountered this problem before, or could anyone suggest  
what might be the case?

Thanks very much in advance for your help,
Best wishes
David

Re: [Plplot-general] Undistorted circles

[Robert P. <rob...@jk...>]

Alan W. Irwin wrote:
>> I tried the following, but it gives
>> me ellipses, e.g. when called in x12c.c:
[...]
>>    /* get axis ratio */
>>    plgvpw(&vpxmin, &vpxmax, &vpymin, &vpymax);
>>    ratio = (vpxmax -vpxmin) / (vpymax -vpymin);
> 
> What you appear to need is something that returns real device units 
> (whether they are in pixels, points, or mm doesn't matter since it is
>  only the ratio the determines the aspect ratio). I therefore suggest
> you try plgspa or plgpage.

Thank you - the following works for me:

    /* get ratio s.t. ellipse appears as circle */
    plgvpw(&vpxmin, &vpxmax, &vpymin, &vpymax);
    axisratio = (vpxmax -vpxmin) / (vpymax -vpymin);

    plgpage(&px, &py, &pxlen, &pylen, &pxoff, &pyoff);
    pageratio = pxlen * 1. / pylen;

    ratio = axisratio / pageratio;

-- Robert

Re: [Plplot-general] Undistorted circles (was Re: box-and-whisker plots supported?)

[Alan W. I. <ir...@be...>]

On 2008-10-13 18:22+0200 Robert Pollak wrote:

> Hi Alan,
>
>> I assume you are referring to the kind of plot that is discussed in
>> http://en.wikipedia.org/wiki/Box_plot.
>
> Yes, that's what I mean.
>
>> We currently have no higher-level API to support that.  Of course,
>> you could make your own function to do that using lower-level PLplot
>> commands.
>
> I am now drawing such a box plot. I also want to mark outliers with
> circles. Which aspect ratio do I need to draw undistorted circles?
> (In other words: How to map world to device coordinates?)
>
> As I don't want to use "o" letters [...]

<aside>

We actually have access to circular symbols (better than the "o" character)
that are not subject to aspect ratio problems so I tried some experiments
with those using the following python test script.

********
#!/usr/bin/env python

# Append to effective python path so that can find plplot modules.
from plplot_python_start import *

import sys
from plplot import *
from numpy import *

# Parse and process command line arguments
plparseopts(sys.argv, PL_PARSE_FULL)

# Initialize plplot
plinit()
# Like yellow lines better.
plcol0(2)
pladv(0)
plvpor(0.1, 0.9, 0.1, 0.9)
plwind(0., 1., 0., 1.)
# Just to show edges of viewport
plbox("bc", 0., 0, "bc", 0., 0)
x = [0.5]
y = [0.5]
ifplsym = False
ifunicode = True
for size in 1.0+arange(10):
   if ifplsym:
     plssym(0., size)
     plsym(x, y, 907)
   else:
     if ifunicode:
       plschr(0., 2.*size)
       plptex(0.5, 0.5, 1., 0., 0.5, "#[0x25ef]")
     else:
       plschr(0., size)
       plptex(0.5, 0.5, 1., 0., 0.5, "#(907)")

# Terminate plplot
plend()
********

To see results from that script you have to run it in the examples/python
directory within the installed directory tree (not the source or build
tree).

The Hershey symbol version (using plsym [ifplsym == True]) actually gives a
pretty good-looking circle, but you can probably make something that looks
smoother if you use more points to represent it.  Thus, I don't think the
plsym version is quite suitable for your needs although it comes close so
you should at least try it.  The plptex version without unicode gives the
same result as the plsym variant for drivers that use the Hershey fonts, but
for drivers that use Unicode fonts (ifunicode == True), plptex has an
obvious bug (repeated strings in the same position are not plotted in the
same position) and the magnification done with plschr also magnifies the
width of the line in a way that might make it unsuitable for your needs.

In sum, plsym might give you what you need, but you will have to check, while
plptex has a bug currently, and furthermore, even when that is fixed the
magnification of the line width may be a concern.  Anyhow, try some of
these variants and see whether there are any of them that you like (assuming
the positional bug gets fixed).

</aside>

> I tried the following, but it gives
> me ellipses, e.g. when called in x12c.c:
>
> plcircle(PLFLT x, PLFLT y)
> {
>    PLFLT vpxmin, vpxmax, vpymin, vpymax;
>    PLFLT ratio, rx, ry;
>    int i;
>    static PLFLT cx[31], cy[31];
>
>    /* get axis ratio */
>    plgvpw(&vpxmin, &vpxmax, &vpymin, &vpymax);
>    ratio = (vpxmax -vpxmin) / (vpymax -vpymin);
>
>    ry = 1.;
>    rx = ratio * ry;
>    for (i = 0; i <= 30; ++i) {
> 	cx[i] = x + cos(i / 30. * 2. * M_PI) * rx;
> 	cy[i] = y + sin(i / 30. * 2. * M_PI) * ry;
>    }
>
>    pllsty(1);
>    plline(31, cx, cy);
> }
>
> (I also don't understand the meaning of plgvpd(). What exactly are
> "normalized device coordinates", e.g. when I use the wxwidgets device?)

I suggest you review
http://plplot.sourceforge.net/docbook-manual/plplot-html-5.9.0/viewport_window.html
to get definitions of what you need to know and lots of other useful links
to documentation of individual commands. However, it's pretty clear to me
this documentation could use a rewrite.  So if after digging through this
documentation and comparing with what actually happens in the code, you have
some improved wording to suggest, please let me know.  A patch on
doc/docbook/source/*.xml is the best form to communicate suggested changes
to our documentation, but ascii is OK as well.

To answer your general question about aspect ratio, plgvpw is not suitable
for your needs because it returns world coordinates and not device
coordinates.  From the definition of "normalized device coordinates" in the
above URL, it appears plgvpd is also not suitable for your needs.

What you appear to need is something that returns real device units (whether
they are in pixels, points, or mm doesn't matter since it is only the ratio
the determines the aspect ratio).  I therefore suggest you try plgspa or
plgpage.  However, I haven't tried those, and I think it is probably best
that you survey all the modern device driver codes to be sure everything you
need will be defined for whichever command (plgspa or plgpage) that you
decide to use.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-general] Undistorted circles (was Re: box-and-whisker plots supported?)

[Robert P. <rob...@jk...>]

Hi Alan,

> I assume you are referring to the kind of plot that is discussed in 
> http://en.wikipedia.org/wiki/Box_plot.

Yes, that's what I mean.

> We currently have no higher-level API to support that.  Of course,
> you could make your own function to do that using lower-level PLplot
> commands.

I am now drawing such a box plot. I also want to mark outliers with
circles. Which aspect ratio do I need to draw undistorted circles?
(In other words: How to map world to device coordinates?)

As I don't want to use "o" letters, I tried the following, but it gives
me ellipses, e.g. when called in x12c.c:

plcircle(PLFLT x, PLFLT y)
{
    PLFLT vpxmin, vpxmax, vpymin, vpymax;
    PLFLT ratio, rx, ry;
    int i;
    static PLFLT cx[31], cy[31];

    /* get axis ratio */
    plgvpw(&vpxmin, &vpxmax, &vpymin, &vpymax);
    ratio = (vpxmax -vpxmin) / (vpymax -vpymin);

    ry = 1.;
    rx = ratio * ry;
    for (i = 0; i <= 30; ++i) {
	cx[i] = x + cos(i / 30. * 2. * M_PI) * rx;
	cy[i] = y + sin(i / 30. * 2. * M_PI) * ry;
    }

    pllsty(1);
    plline(31, cx, cy);
}

(I also don't understand the meaning of plgvpd(). What exactly are
"normalized device coordinates", e.g. when I use the wxwidgets device?)


-- Robert

Re: [Plplot-general] Bold text in non-unicode build?

[Alan W. I. <ir...@be...>]

On 2008-10-10 18:39+0200 Robert Pollak wrote:

> Hi,
>
> according to the manual and to plsym.c, for non-unicode builds there is
> (among some other escape sequences) "#fi" for italic font.
> Why isn't there something like "#fb" for boldface?

non-unicode means you are limited to the traditional Hershey fonts.  To see
what is available for those fonts look at example 7. With -dev xwin (which
always uses Hershey) it looks like the block starting at 2000 may have bold
characters. You can address that block with the traditional #(nnn) escape
sequence documented at
http://plplot.sourceforge.net/docbook-manual/plplot-html-5.9.0/characters.html
and also used in example 7.

>From the quality of those characters, I conclude there is not much point in
making all the code changes to make those characters more readily accessible
using your suggested #fb escape sequence since there are much better
alternatives available with the unicode approach. In sum, because the
Hershey glyphs don't look very good nobody is working on developing the
Hershey approach any more, and instead our focus is on the unicode approach.

>
> According to the manual, I can only get bold font with #<bold/>, which
> is unicode only.
>
> I also tried plsfont(-1, -1, PL_FCI_BOLD), e.g. before the pllab call of
> example 12, but see no effect.
>
>
> --Robert
>
> (I know, it's time to switch to unicode apps ...)

Yes.  :-)

Alan

__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-general] Bold text in non-unicode build?

[Robert P. <rob...@jk...>]

Hi,

according to the manual and to plsym.c, for non-unicode builds there is
(among some other escape sequences) "#fi" for italic font.
Why isn't there something like "#fb" for boldface?

According to the manual, I can only get bold font with #<bold/>, which
is unicode only.

I also tried plsfont(-1, -1, PL_FCI_BOLD), e.g. before the pllab call of
example 12, but see no effect.


--Robert

(I know, it's time to switch to unicode apps ...)

Re: [Plplot-general] box-and-whisker plots supported?

[Alan W. I. <ir...@be...>]

On 2008-10-07 10:09+0200 Robert Pollak wrote:

> Hello,
> does PLplot support box-and-whisker plots? If yes, is there some
> example screenshot on the web? There is none at
> http://plplot.sourceforge.net/examples.php .

I assume you are referring to the kind of plot that is discussed in
http://en.wikipedia.org/wiki/Box_plot. We currently have no higher-level API
to support that.  Of course, you could make your own function to do
that using lower-level PLplot commands.

If you donated such a function to PLplot with no external dependencies and
with a corresponding example to show off that functionality, I believe there
is a pretty good chance we would accept it (which means a fair amount of
work on our part propagating the API and example to our different languages)
since it appears from the above article to be a well-accepted plot style for
quickly describing statistical distributions without the well-known
drawbacks of histograms.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-general] box-and-whisker plots supported?

[Robert P. <rob...@gm...>]

Hello,
does PLplot support box-and-whisker plots? If yes, is there some
example screenshot on the web? There is none at
http://plplot.sourceforge.net/examples.php .

Thank you,
Robert Pollak

Re: [Plplot-general] Viewport clipping

[Hezekiah M. C. <hc...@at...>]

On Mon, Sep 29, 2008 at 4:16 AM, Andrew Ross
<and...@us...> wrote:
> In my view your proposal to reverse the adjustment for plgvpw makes
> sense. The user would expect to get back the values they put in. A
> patch to correct this would be acceptable to me at least as a temporary
> fix.
<snip>
> I suggest further followup goes to plplot-devel as this is a development
> issue.

Andrew,

Thanks for the response.  I have an inital patch for plgvpw, so I will
move this discussion over to the development list.

Hez

-- 
Hezekiah M. Carty
Graduate Research Assistant
University of Maryland
Department of Atmospheric and Oceanic Science

Re: [Plplot-general] Viewport clipping

[Andrew R. <and...@us...>]

On Sat, Sep 27, 2008 at 11:26:40PM -0400, Hezekiah M. Carty wrote:
> On Thu, Sep 25, 2008 at 10:05 AM, Davide Cesari <dc...@ar...> wrote:
> >        I would like to repeatedly enable/disable viewport clipping while
> > plotting, in order to draw lines, symbols, etc. in a legend outside the
> > plot, while retaining clipping when data is plotted. Is there a simple
> > way to do this in plplot, or is clipping-disable in the TODO list?
> >        Up to now i found a suboptimal solution (see fortran subroutine further
> > in text) by calling plgvpd/plgvpw to get viewport/window settings,
> > setting viewport to [0.,1.],[0.,1.] and enlarging correspondingly the
> > plotting window, then switching back to the initial settings when
> > desired. However in this way, after a disable/enable cycle, the plotting
> > window is not the same as before because the values obtained by plgwpd
> > are not exactly the one previously passed to plwind, a little correction
> > of 1.e-5 is made in the plwind code. Maybe adding a function similar to
> > the one I propose in the C api (with exact window settings) could be a
> > simple approach!? I could try provide a patch if this may help.
> 
> While I do not have a better method to propose at this time, I have
> faced the same plgvpw offset issue.  This 1.0e-5 offset seems to be an
> intentional adjustment - see plwind.c, starting at line 56:
> 
> --- FROM plwind.c, STARTING AT LINE 56 ---
>     dx = (xmax - xmin) * 1.0e-5;
>     dy = (ymax - ymin) * 1.0e-5;
> 
> /* The true plot window is made slightly larger than requested so that */
> /* the end limits will be on the graph  */
> 
>     plsc->vpwxmi = xmin - dx;
>     plsc->vpwxma = xmax + dx;
>     plsc->vpwymi = ymin - dy;
>     plsc->vpwyma = ymax + dy;
> --- END OF plwind.c PASTE ---
> 
> plsc->pvpw* are the values returned by plgvpw.  The simplest immediate
> solution would be to invert the above viewport adjustments to retrieve
> the original viewport dimensions.
> 
> For the PLplot core developers - would it be an acceptable change to
> have plgvpw return the proper xmin, xmax, ymin, ymax values rather
> than these adjusted values?  It would probably be less surprising for
> a user than the current function return values.  It is a change from
> how the function has worked in the past but I think it may be a
> worthwhile one.
> 
> If this is an acceptable change I would be happy to supply a patch to
> implement this. Another option would be to create a new function which
> returns the properly transformed plot limits.

Hez, 

In my view your proposal to reverse the adjustment for plgvpw makes
sense. The user would expect to get back the values they put in. A
patch to correct this would be acceptable to me at least as a temporary
fix.

Adding and removing this small adjustment leads to the possibility of 
rounding errors, so in the long term a better way might have to be
sought. The adjustment itself seems a bit of a fudge and there might
well be a better way of handling the edges of the viewport to ensure the
end limits do appear on the graph. This won't actually be required for
all applications of the viewport anyway, only if the viewport has axis
tics on it. This might need thinking about further.

I suggest further followup goes to plplot-devel as this is a development
issue.

Cheers

Andrew