-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Could a dual colour
and/or fill
aesthetic called ink
be supported?
#6181
Comments
colour
and/or fill
aesthetic called ink be supported?
Just noticed this #4121 |
colour
and/or fill
aesthetic called ink be supported?colour
and/or fill
aesthetic called ink
be supported?
Will reopen this just in case, as has been a few years since the afore-mentioned issue was closed - and now that there is the |
I don't think we should have an
I was tempted to say this would be an RTFM issue for new users, but then looked at the relevant part of the vignette, and it does not explain the difference between colour and fill. It is explained in the linked page when you click the colour/fill link in the docs, but this page is less discoverable then the vignette. Moreover, the vignette doesn't explain how |
I disagree that an ink aesthetic would introduce fuzziness. The ink aesthetic would control both colour and fill in a hierarchal way similar to how theme components work in a hierarchal way. If colour or fill was added in addition to ink, then that component would overrule that specified by ink. The other one would still be controlled by ink. The default alpha might need to be changed for boxplot/crossbar - but other than that, I can't see any issues. But agree this might be a pretty big change, and unsure how difficult it might be.. Think it wouldn't break much, as you are adding functionality, rather than taking anything away |
I'm happy to keep this open for the documentation aspect, but for the 'ink as aesthetic'-aspect I'd need @thomasp85's rubberstamp as it is a larger API changing decision. Personally, I have reservations for the following reasons:
|
One additional reservation: All extension packages would also have to implement this. In most cases it would not just carry over from the base ggplot2 code. So you're looking at a long time (possibly years) where extension packages don't implement ink or don't implement it correctly and you get all sorts of weird bugs. I'm not sure this pain is worth it for a feature that basically just provides syntactic sugar. |
I noticed there is an argument to control foreground colour and/or fill in the new
theme_*
functions calledink
.A common confusion for ggplot2 beginners is whether to use
colour
orfill
.From this, I wondered whether ggplot2 would consider fully supporting a dual
colour
and/orfill
aesthetic calledink
? Then in general, users could just defer to always usingink
- unless they were plotting something polygon-ish and wanted to differentiate thecolour
from thefill
.Just an idea. Feel free to close, if you think too much effort relative to any benefit
The text was updated successfully, but these errors were encountered: