Area-based plot types: light opaque multi-group color

[zeileis]

In the discussion of #614 we decided to use lighter opaque (non-transparent) colors for area-based displays. However, it seems like we only implemented this for the single-group case but not the multi-group case.

In the multi-group case we still get semi-transparent (and hence light) colors for histograms and boxplots and dark opaque colors for barplots. Hence, the difference is really striking for barplots:

library("tinyplot")
tinytheme("clean2")
tinyplot(~ species, data = penguins)
tinyplot(~ species | island, data = penguins)

For boxplots the difference is more subtle but if you know it it's hard to overlook it in themes with grid lines:

tinyplot(body_mass ~ species, data = penguins)
tinyplot(body_mass ~ species | sex, data = penguins)

For the multi-group histograms one could argue, though, that semi-transparency is the right thing because the distributions will often be overlapping:

tinyplot(body_mass ~ 1, data = penguins)
tinyplot(body_mass ~ 1 | sex, data = penguins)

[grantmcdermott]

Good catch.

It's hard to know what to do here. I feel like some level of inconsistency (either across types, or w.r.t. to base R) is unavoidable. I guess we could switch to the lighter fills as a default for these cases, but then allow users to control this by adding an argument (type_barplot(lighten = FALSE)?).

[grantmcdermott]

Related issue: How should we treat alpha (transparent) fills? Specifically, should the transparency be applied on top of the "base" colour, or the lightened colour? Current behaviour is the former, but this leads to counterintuitive outcomes where applying an alpha fill can lead to a darkening of the interior.

library("tinyplot")
tinytheme("clean2")
tinyplot(~ species, data = penguins)

tinyplot(~ species, data = penguins, fill = 0.7)

^{Created on 2026-06-28 with reprex v2.1.1}

[zeileis]

Good points. I haven't got good answers but only some possibly useful comments/observations:

• At the moment the default filling style is inferred but cannot be controlled directly.
• If there were an argument for (say fill.default or fill.style or something along those lines) we could declare that for barplots and boxplots the default is to lighten and for histograms and densities it is to use transparency. Additional options would be no filling or filling with the unmodified color from the palette.
• But in the addition to the style we would probably need to be able to control how much the colors should be lightened or made transparent.
• For the transparency we have the alpha argument and also the convenience fill = <numeric> shortcut. So maybe we would need a lighten top-level argument in tinyplot.default() as well?
• The problem with alpha and lighten then would be that there is no easy way to say that this should only apply to the filling color and not to the border color, I guess.
• One could argue that similar reasoning could be applied to bg colors for pch that support it.

As an example for the last point: Is there a way to specify different alpha for the line (1, opaque) and background (0.3, semi-transparent) in scatterplots like the one below? I was only able to do it by manually calling the correct palette with the additional alpha argument.

tinytheme("clean2", grid.lty = 1, grid.col = "slategray")
tinyplot(bill_dep ~ bill_len | species, data = penguins, pch = 21,
  bg = palette.colors(3, "Tableau 10", alpha = 0.3), cex = 2.5, lwd = 2)

This is similar to the situation we currently have with the filling for histograms. If I want the lightened opaque colors I think I can only set them up by hand beforehand but not inherit them from the palette in some way.

tinyplot(bill_dep ~ 1 | species, data = penguins,
  fill = colorspace::lighten(palette.colors(3, "Tableau 10"), 0.8))

Apologies if this creates more questions than it answers. But I felt I needed to write these things down for myself and then thought I would share them here in case they are useful for you too.

I'm also convinced that it's neither possible nor necessary to cover all possible combinations with convenient shortcuts. Given that it is reasonably easy to specify things by hand, as I do above. But maybe we can cover a few more cases than we currently do. Maybe it would also help to expose a function, say theme.palette(), so that one could do fill = theme.palette(lighten = 0.3) or something like that?

Further thoughts and ideas welcome...

[grantmcdermott]

I need to write up a longer reply, since I'm nearly ready with a PR that (hopefully) addresses several of these issues. But just quickly on:

As an example for the last point: Is there a way to specify different alpha for the line (1, opaque) and background (0.3, semi-transparent) in scatterplots like the one below? I was only able to do it by manually calling the correct palette with the additional alpha argument.

We already support this via bg/fill = [0,1], no? At least, we have several documentation examples showing off similar functionality IINM. So for your use case, I would just do:

tinyplot(bill_dep ~ bill_len | species, data = penguins, pch = 21,
  bg = 0.3, cex = 2.5, lwd = 2)

(You can also pass an alpha arg to adjust the the transparency of the circle outlines; this is handled separately from the bg value.)

[grantmcdermott]

Okay, longer follow-up now that my PR for this issue is nearly ready :-)

Again, I'm hoping to finalize the PR by this evening or tomorrow, but here's what it does in summary:

• Grouped barplot, boxplot, and violin now use the same lighter-but-opaque fill as their single-group counterparts. This fixes the the original inconsistency that you pointed out at the top of this issue (dark saturated bars vs. semi-transparent boxes).
  • The way that this works is that each of these types gains a lighten argument (default TRUE). So, for example, you could override with type_barplot(lighten = FALSE) to fall back to the old saturated palette colour.
  • spineplot also gets a similar lightening treatment, but only for the special y == by case. I've also made sure that these get consistent (black) borders regardless of grouping. (Honestly, spineplot type is the one that I've wrestled with the most during this PR... I decided to go ahead with lightening the y==by case, b/c otherwise the spineplots in the tinyplot.data.frame(..., by = <by>) call look too saturated against their sister bar/boxplots. But you can give me your feedback once the PR lands. EDIT: I've decided to make lighten FALSE for spineplots after all. To0 many moving pieces otherwise.)
• The alpha-darkening bug is fixed. We now resolve the palette opaque, lighten, and then layer any transparency on top.

On your specific points:

the default filling style is inferred but cannot be controlled directly

Again, now (partly) controllable via lighten. It's a boolean rather than your fuller style menu, but the type-appropriate default is baked in exactly as you describe (bars/boxes => lighten, histograms/densities => transparency).

a fill.default/fill.style argument … {lighten, transparency, none, raw}

I don't think that this is a good idea (at least for now). While this is partly is partly sunk cost fallacy on my side (given the near-ready state of my current PR), these arguments would also overlap heavily with lighten + fill/alpha, and reintroduce the border-vs-fill ambiguity. The one thing it would uniquely buy us is letting a histogram opt into lightened-opaque, or a barplot into transparency. But I don't think that's worth a new enum yet. Happy to revisit later.

no easy way to say [alpha] should only apply to the filling color and not to the border

For the fill/bg path this already works. On area types, fill = 0.7 yields an opaque saturated border with a semi-transparent (lightened) fill, while the border and fill alpha are handled separately. This is basically the same mechanism as the pch = 21, bg = 0.3 scatterplot case from my previous reply.

we'd probably need to control how much to lighten … maybe expose theme.palette(lighten = 0.3)

This is a cool idea... and in comparison my current PR only allows single (boolean) lighten values. Again, though I'd put this down as a follow-up item.

Strong agree on your closing point. We can't (shouldn't) cover every combination with shortcuts. Hopefully we're getting the general balance right, but a palette helper feels like the natural next step if we want to go further.

[zeileis]

OK, great, thanks for the feedback. Then my only additional suggestion would be to also support lighten = 0.3 etc. I can have a look at this and add some internal function for more flexible lightening.

For the spineplot I need to have at what you propose exactly and whether I agree. For the tinyplot.data.frame method it would also be important that type_spineplot properly supports by variables. This has been on my wishlist for a long time but I never found the time to try to accomplish this.