search

NOAA-PMEL / PyFerret

The PyFerret program and Python module from NOAA/PMEL
https://ferret.pmel.noaa.gov/Ferret/
The Unlicense
59 stars 22 forks source link

tuple color specification in /GRAT option not parsed correctly #50

Closed karlmsmith closed 6 years ago

karlmsmith commented 6 years ago

Reported by Olivier:

yes? PLOT/COLOR=(60,50,20)/GRATICULE="(DASH,COLOR=RED)" I[I=1:50] ! OK

yes? PLOT/COLOR=(60,50,20)/GRATICULE="(DASH,COLOR=(100,20,20))" I[I=1:50] ! Wrong
 **ERROR: value out of legal range: (100
          Format is (R,G,B) or (R,G,B,A),where R,G,B,A are integer values 0-100

The problem is in fer/plt/set_graticules.F and it appears PARSE_PYFONT_COLOR could be called to correctly parse the color option. Might want to rename that to something like PARSE_OPTION_COLOR, and do some checking for other possible places this might occur.

AnsleyManke commented 6 years ago

The places where /COLOR shows up as qualifiers in the command syntax all check out, using the form /COLOR=(r,g,b) in PyFerret

SET WINDOW/COLOR= SET TEXT/FONT=/COLOR= CANCEL TEXT/COLOR= CONTOUR/COLOR= PLOT/COLOR= VECTOR/COLOR= WIRE/COLOR= POLYGON/LINE/COLOR=

The COLOR= in /GRATICULE ="(COLOR=)" doesn't show up in SHOW COMMANDS. Check also for calls to the Ferret routine EQUAL_COLOR which parses "blue" and turns it into a pplus line number. That check shows only GRATICULE makes use of any kind of COLOR= syntax.

I think fixing graticules to call PARSE_PYFONT_COLOR is all that's needed.

SET MODE GRATICULE:(dash,color=blue) CONTOUR/GRATICULE:(dash,color=blue) PLOT/GRATICULE:(dash,color=blue) POLYGON/GRATICULE:(dash,color=blue) SHADE/GRATICULE:(dash,color=blue) VECTOR/GRATICULE:(dash,color=blue)

karlmsmith commented 6 years ago

Actually was easier to change the code to search for an open parenthesis before the first comma, and is so finish off the command with a closed parenthesis instead of the comma. However, this generates an error that only standard colors are supported at this time, which is indeed the case. Need to investigate further why this is the case, but presumably something to do with this being handled in the ppl/ code.

Checked in changes to parse correctly, but then issue a warning for custom colors and switching to use black to avoid a cascade of errors. Will open another issue to support custom colors