Support more of the available gnuplot color specifications

[etfrogers]

Gnuplot support multiple ways of specifying colors, but Rust Gnuplot only supports a subset of these.

From the colorspec documentation, the available forms are

Syntax:

  ... {linecolor | lc} {"colorname" | <colorspec> | <n>}
  ... {textcolor | tc} {<colorspec> | {linetype | lt} <n>}
  ... {fillcolor | fc} {<colorspec> | linetype <n> | linestyle <n>}

where <colorspec> has one of the following forms:

  rgbcolor "colorname"    # e.g. "blue"
  rgbcolor "0xRRGGBB"     # string containing hexadecimal constant
  rgbcolor "0xAARRGGBB"   # string containing hexadecimal constant
  rgbcolor "#RRGGBB"      # string containing hexadecimal in x11 format
  rgbcolor "#AARRGGBB"    # string containing hexadecimal in x11 format
  rgbcolor <integer val>  # integer value representing AARRGGBB
  rgbcolor variable       # integer value is read from input file
  palette frac <val>      # <val> runs from 0 to 1
  palette cb <value>      # <val> lies within cbrange
  palette z
  palette <colormap>      # use named colormap rather than current palette
  variable                # color index is read from input file
  background or bgnd      # background color
  black

The "<n>" is the linetype number the color of which is used, see test.

The way Color, TextColor etc. are currently implemented supports the first 5 of these, as they all output something of the form:
... rgb "input_str"

I would like to expand color support to the other options, and am considering a PR to do it, but what is the right API?

I could leave Color as is and try adding more types, but it gets messy. I think to cover all possibilities you'd naively need: IntegerColor(u16), VariableColor, PaletteFracColor(f32), PaletteCBColor(f32) PaletteZColor, PaletteColorMap(&str), VariableColor, BackgroundColor, IndexColor (where IndexColor(u32) is for the <n> form).

Nine new enum variants, and associated writer/handling code, seems like overkill. Maybe Color: ColorType where ColorType becomes an enum, with these as its variants? Or possibly Color(ColorType). I think either of these last two would be a breaking change though. Potentially (if you rename things carefully) you could make a function Color that generates something in the new API that corresponds to existing behaviour.

I guess my questions are

1. Is this useful additional functionality?
2. Is there an "idiomatic" (within this project) way of handling this?
3. Is one of the forms above preferred, or a better option that I have missed?
4. How bad is a breaking change?

[etfrogers]

Would address #86

[SiegeLord]

Is this useful additional functionality?

Yeah, for some of them at least. E.g. palettes. I think my primary concern is that I don't understand what half those do. Like rgbcolor <integer val> doesn't seem useful for a Rust wrapper, rgbcolor variable is not obvious to me which file it is referring to etc. It seems like some of these may require some supporting APIs.

Is there an "idiomatic" (within this project) way of handling this?

I'd try introducing a trait IntoColor and use it as the type bound for PlotOption, then implement it for an enum that encompasses the types of colors. It could be implemented for strings to maintain backwards compatibility, although...

How bad is a breaking change?

...breaking changes are not a particularly concerning if they provide enough benefit.

[etfrogers]

Thanks. That all makes sense. After I posted the above, I also thought of the "trait also implemented for strings" option. This trait would allow the `Color` type to produce its own string representation in the relevant format and the writer code could remain roughly as is. I'll give it a try and see how it works. As for the usefulness/understandability question: I think it is most sensible if I implement the subset that make sense and not the others. To decide which ones make sense: if I can produce useful documentation and examples, then it's probably OK. If not.... Regards, Ed

…

________________________________ From: SiegeLord ***@***.***> Sent: Tuesday, February 11, 2025 3:07:52 AM To: SiegeLord/RustGnuplot ***@***.***> Cc: etfrogers ***@***.***>; Author ***@***.***> Subject: Re: [SiegeLord/RustGnuplot] Support more of the available gnuplot color specifications (Issue #105) Is this useful additional functionality? Yeah, for some of them at least. E.g. palettes. I think my primary concern is that I don't understand what half those do. Like rgbcolor <integer val> doesn't seem useful for a Rust wrapper, rgbcolor variable is not obvious to me which file it is referring to etc. It seems like some of these may require some supporting APIs. Is there an "idiomatic" (within this project) way of handling this? I'd try introducing a trait IntoColor and use it as the type bound for PlotOption, then implement it for an enum that encompasses the types of colors. It could be implemented for strings to maintain backwards compatibility, although... How bad is a breaking change? ...breaking changes are not a particularly concerning if they provide enough benefit. — Reply to this email directly, view it on GitHub<#105 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AD3Z2B2XPQOJNVSJY6AAKFT2PFSQRAVCNFSM6AAAAABW3ULEIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNBZG4YDSNRYGY>. You are receiving this because you authored the thread.Message ID: ***@***.***>