Menu

#813 Enabling the use of 'lc rgb variable' in 'splot with polygons'

Version 5
closed-accepted
nobody
None
5
2025-01-03
2024-04-04
No

This patch is to allow 'lt rgb variable' to specify colors from extra data columns in 'splot with polygons'.

Currently in 'splot with polygons',

  • lt variable
  • fc rgb variable

are only allowed. These are used in polygons.dem.

On the other hand, the help page for polygons says

Each polygon may be assigned a separate RGB color by providing a fourth using
specifier and the keywords lc variable (value is interpreted as a linetype)
Each polygon may be assigned a separate RGB color by providing a fourth using specifier and the keywords lc variable (value is interpreted as a linetype).
Only the color value from the first vertex of the polygon is used.

However, lc rgb variable does not work without any warning in the current implementation.

1 Attachments

Discussion

  • Ethan Merritt

    Ethan Merritt - 2024-04-04

    I am having trouble reproducing this. Could you provide an example script that shows a before/after difference?

    Starting with the polygons.dem example script, I tried
    splot 'dodecahedron.dat' using 1:2:3:(rgbcolor("gold")) with polygons fillcolor variable
    which works, and
    splot 'dodecahedron.dat' using 1:2:3:(rgbcolor("gold")) with polygons linecolor variable
    which does not work.

    After applying the patch I see the same behaviour: "fc rgb variable" works and "lc rgb variable" does not. Am I testing the wrong thing? What case exactly is your patch trying to handle?

    Background:

    I have been struggling for a long time with the difference between "linecolor" (lc) and "fillcolor" (fc) and "border color".

    The problem is that filled-area objects can have both a fill color and a border color. The original implementation of objects and certain plot styles like with boxes made the border color part of the fill style specification. The pm3d implementation, however, made it part of the pm3d specification. That means that 3D plots with polygons for example would pull the border color from the pm3d style, but plots with circles for example would pull the border color from the fill style (more specifically from the circle object fill style). Confusingly, both would use "lc" as the fill color.

    Both 2D and 3D plots suffer from a further issue of what happens when the fill style is empty. It seems obvious that set style fill solid; plot FOO with boxes lc "green" should use green for the fill color to produce solid green boxes, but set style fill empty; plot FOO with boxes lc "green" should use green for the border color rather than the fill color. But the border color and the fill color are two different things, so the program has to distinguish a lot of possible combinations of fill style, line type, line color, pm3d properties, object properties, and probably more that I am not thinking of at the moment. It's a mess.

    If a time machine were available I could go back and redesign the whole mess, but in reality it's a continuing process of trying to handle things in a way that seems 'obvious' to [most] users. I think or at least hope that in version 6 it is always safe to use "fillcolor" to specify the interior fill color.

     
    • Hiroki Motoyoshi

      I am attaching a sample script.

      Sorry for the insufficient verification.

      * lc variable
              NG 5.4.8
              OK 6.0.0
              OK develop
      
      * fc rgb variable
              NG 5.4.8
              OK 6.0.0
              OK develop
      
      * lc rgb variable
              NG 5.4.8
              OK 6.0.0
              NG develop
      

      I didn't notice because I usually work with the develop version, but 'lc rgb variable' worked fine in 6.0.0. On the other hand, 'lc rgb variable' does not work in the develop version. Maybe there was a change somewhere that made it not work. So it might be better to investigate the above changes instead of my patch method.

      Starting with the polygons.dem example script, I tried
      splot 'dodecahedron.dat' using 1:2:3:(rgbcolor("gold")) with polygons fillcolor variable
      which works, and
      splot 'dodecahedron.dat' using 1:2:3:(rgbcolor("gold")) with polygons linecolor variable
      which does not work.

      For your example, I think these should be

      splot 'dodecahedron.dat' using 1:2:3:(rgbcolor("gold")) with polygons fillcolor rgb variable
      splot 'dodecahedron.dat' using 1:2:3:(rgbcolor("gold")) with polygons linecolor rgb variable
      
       
  • Ethan Merritt

    Ethan Merritt - 2024-04-05
    • summary: Enabling the use of 'lt rgb variable' in 'splot with polygons' --> Enabling the use of 'lc rgb variable' in 'splot with polygons'
     
  • Ethan Merritt

    Ethan Merritt - 2024-04-05

    OK, I get it. The documentation says "lc rgb variable" should work, but actually the only thing that works is "fc rgb variable". I will apply the patch because accepting "lc" is better than drawing everything in black. But I will also change the documentation to say explicitly that "fillcolor" is the property that should be used.

    I would ideally prefer that specifying the line color (as opposed to the fill color) should change the border rather than the interior of the polygon. But the current implementation design does not make that easy.

    Proposed commit message:

    Author: Hiroki Motoyoshi binzo@users.sf.net
    Date: Thu Apr 4 19:51:23 2024 -0700

    Enable the use of 'lc rgb variable' in 'splot with polygons'
    
    Version 6 is moving toward a distinction between linecolor and fillcolor
    properties for filled-area objects, including polygons.  It is not there
    yet but in the meantime it is better to accept "lc rgb variable" as if it
    were "fc rgb variable" rather than discarding the specified color and
    using black instead.
    
     

    Last edit: Ethan Merritt 2024-04-05
    • Hiroki Motoyoshi

      Thank you for the detailed explanation.
      I now understand the direction regarding colour fills in Version 6.

      Unrelated to this ticket, but regarding fillcolor, I sometimes encounter a bit strange behaviour in 2D plots: with circles, for example, only the fourth plot in the script below does not work as expected. It seems that the colour filling behaviour may be sensitive to the positional relationship between fillcolor and fillstyle. I have been unable to determine whether this is a bug or a specification, but this may be something that also should be fixed in Version 6.

      set term wxt 
      
      $data <<EOD
      1 1 
      2 3 
      3 3
      2 2 
      4 3 
      3 4 
      EOD
      
      set xrange [0:5]
      set yrange [0:5]
      
      set title "1. fc var fs solid border lc 'black'"
      plot $data using 1:2:(0.1):($0+1) with circles \
                 fc var fs solid border lc 'black'
      pause -1
      
      set title "2. lc var fs solid border lc 'black'"
      plot $data using 1:2:(0.1):($0+1) with circles \
                 lc var fs solid border lc 'black'
      pause -1
      
      set title "3. fs solid border lc 'black' lc var"
      plot $data using 1:2:(0.1):($0+1) with circles \
                 fs solid border lc 'black' lc var 
      pause -1
      
      set title "4. fs solid border lc 'black' fc var"
      plot $data using 1:2:(0.1):($0+1) with circles \
                  fs solid border lc 'black' fc var
      pause -1
      
       
      • Ethan Merritt

        Ethan Merritt - 2024-04-05

        I agree that plot #4 shows a bug. It is also an example of how the use of fillcolor and linecolor is confusing.

         
  • Ethan Merritt

    Ethan Merritt - 2024-04-05

    Both the patch and the fix for the bug in plot #4 are now in 6.1 and pending for the next patchlevel release of 6.0

     
  • Ethan Merritt

    Ethan Merritt - 2024-04-05
    • status: open --> pending-accepted
     
  • Ethan Merritt

    Ethan Merritt - 2025-01-03
    • status: pending-accepted --> closed-accepted
     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.