On 2008-04-26 16:07-0700 Jerry wrote:

> I'm having a bit of trouble understanding the allowed (or rather,
> intended) range of integers in the argument to plpsty. The docs (on
> the web) say, "Select one of eight predefined area fill patterns to
> use". It further says, "Pattern 1 consists of horizontal lines,
> pattern 2 consists of vertical lines, pattern 3 consists of lines at
> 45 degrees angle (upward), and so on."
>
> So one might assume that the range is 1 to 8. But there is
> contradictory use in the examples. For example, x12c.c, x16c.c, and
> x25c.c have lines plsty(0). But examples x13c.c and x15c.c have the
> lines plpsty((i + 3) % 8 + 1) and plpsty((i + 2) % 8 + 1), indicating
> a range of 1 to 8.
>
> In writing the Ada bindings, I like to put range checks on things
> which is why this has turned up. Obviously I could put the range at 0
> to 8 but if that is allowed then the docs need to be changed.

Thanks, Jerry, for pointing out the problems with the plpsty documentation.

When looking deeper at this issue, I found that
src/plsdef.c says

/*----------------------------------------------------------------------*\
  * void plpsty()
  *
  * Set fill pattern, using one of the predefined patterns.
  * A fill pattern <= 0 indicates hardware fill.
\*----------------------------------------------------------------------*/

Later there is some logic differences depending on whether
patt > 0 or not, but I don't have a good overview of the filling logic
(see question below) so I don't understand those logic differences.

So from this function definition and the later code it appears the pattern
index can formally have the range smallest negative integer to 8.

However, in plP_fill (in plcore.c), it appears that in the logic surrounding
the plpsty call, the pattern index is only tested for whether it is zero or
not.  I think this inconsistency would generate problems for patt < 0 (for
example, no warning if a driver cannot handle hardware fills), but I
am not sure, and our current examples only use patt >= 0.

Maurice, could you please take a look at this to see if the logic needs to
be tightened for a pattern index < 0?  For example, should we simply not
allow pattern index < 0 or change

if (plsc->patt == 0 && ! plsc->dev_fill0) {

to

if (plsc->patt <= 0 && ! plsc->dev_fill0) {

in plP_fill?

I would also appreciate your overview of the fill logic since that would
help me when I rewrite the currently incorrect plpsty documentation.  For
example, I don't understand why so few drivers do anything for PLSTATE_FILL
while those that ignore PLSTATE_FILL seem to handle filling operations
without problems.  Also, what is the exact significance of the plpsty(0);
calls in examples 12, 16, and 25?  Should other examples that do a lot of
filling have similar calls?

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
__________________________

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to