Skip to content
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

Added three new aesthetics #233

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

ripkrizbi
Copy link

  • label.col.alpha
  • label.fill.alpha

these can be used to decouple transparency values of label background and frame from the overall transparency of the shape, thus enabling the text to be rendered without alpha while having the possibility to make the background transparent.

if any of the two (or both) are defined (not NULL), their values will override the general alpha aesthetic, and if not, both values will revert to alpha

  • segment.linewidth

segment.size might be somewhat misleading as it implies the length of the segment, so segment.linewidth can be used instead (it will not be converted to points like segment.size, though)

- label.col.alpha
- label.fill.alpha

these can be used to decouple transparency values of label background and frame from the overall transparency of the shape, thus enabling the text to be rendered without alpha while having the possiblity to make the background transparent.

if any of the two (or both) are defined (not NULL), their values will override the general alpha parameter, and if not, alpha will be used to make everything transparent.

- segment.linewidth

segment.size is somewhat misleading as it implies the length of the segment, so segment.linewidth can be used instead (it will not be converted to points like segment.size, though)
lwd = x$label.size * .pt
),
segment.gp = gpar(
col = scales::alpha(row$segment.colour %||% row$colour, row$segment.alpha %||% row$alpha),
lwd = row$segment.size * .pt,
lwd = (row$segment.size * .pt) %||% row$segment.linewidth,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the default value for segment.size is 0.5, the value for segment.linewidth will not be used.

I'm willing to have another look at this suggestion, if you can help me to understand the intent of this change and how it should work for users. Backward compatibility is important to me, so I want to try to avoid breaking old code if possible.

@slowkow
Copy link
Owner

slowkow commented Jan 2, 2024

Hi @ripkrizbi

Thanks for the pull request, and I apologize for the long delay before my reply.

I tried to modify your changes, and you can see my changes here 5820eb2 and here fa66e1f

Also, I want to ask if you might be able to clarify your intent for segment.linewidth, so I can re-consider those changes in the future. Perhaps we can do that in a new PR? It might be easier to keep this PR focused just on the label alpha aesthetics.

(I want to make changes on top of your changes while giving you credit for the changes, but I also want to preserve the latest changes to ggrepel ... so I'm not sure what is the best path forward regarding commits, branches, merges, etc.)

Here are two examples I added to examples.Rmd to demonstrate how your new aesthetics might be used:

library(ggrepel)
set.seed(42)

dat <- subset(mtcars, wt > 2.75 & wt < 3.45)
dat$car <- rownames(dat)

p <- ggplot(dat, aes(wt, mpg, label = car)) +
  geom_point(color = "red")
# transparent label border
p + geom_label_repel(label.color.alpha = 0)
# transparent label fill
p + geom_label_repel(label.fill.alpha = 0)

@aphalo
Copy link
Contributor

aphalo commented Jan 3, 2024

@slowkow @ripkrizbi
Hi Kamil!
After quite a bit of thought related to adding new aesthetics in 'ggpp' I decided not to rely on new aesthetics to control features that are unlikely to be mapped to data. In fact, I rather recently removed support for some aesthetics that I had already added in 'ggpp'. One reason is that such use in my view goes against the expectations of the grammar of graphics and another reason is the difficulty of how to implement guides for multiple aesthetics that graphically implement the same property. So, what I implemented in geom_label_s() are parameters that control to which graphical elements the mapped aesthetics, alpha, colour, etc., are applied and which ones keep a constant value set as default. This approach makes it possible to have a single mapping, say to alpha in the whole plot, but still control which elements of, for example a label with a connecting segment, obey the mapping and which ones ignore it. This enforces the grammar of graphics expectations, that a given aesthetic has a single "meaning", while giving some flexibility when complex grobs are used. The guides remain a problem that I haven't yet tackled. The two approaches, creating new aesthetics or using parameters, have advantages and disadvantages. In 'ggpp' I am trying to stick as much as possible to the spirit of the grammar of graphics. I am not sure about which approach is better, anyway, I share these ideas in case you find them useful.

@aphalo
Copy link
Contributor

aphalo commented Jan 3, 2024

@slowkow @ripkrizbi
segment.linewidth would be more intuitive given the recent adoption of linewidth in 'ggplot2'. Anyway, I would expect 'ggplot2' 3.5.0 to be released rather soon. From inspecting the code in GitHub, it will include some important changes in the internals, including a new implemetation guides, and support for angle in geom_label(). The implementation of geom_label() in this new version has been revised, I have updated geom_label_s() in 'ggpp' for compatibility and to add support for angle.

@slowkow
Copy link
Owner

slowkow commented Jan 3, 2024

Great to hear from you, Pedro! It's always a joy to learn from you.

Your ideas about aesthetics are very interesting. I have similar reservations about adding more and more parameters, and then trying to figure out how to keep them all organized.

I very much like your idea of using colour.target = "text" or colour.target = c("box", "segment"). This is something I've always wanted for a long time, but I didn't know how to do it or whether it is possible. I'll need to read your code to see how you go about it.

Now I'm thinking that maybe I might plan to modify ggrepel in a future version to copy your ideas about colour.target and so on. I'm a little bit concerned about backwards compatibility, so I'll need to digest this for a while.

Regarding guides, I have an inkling that you might appreciate ggnewscale, but I have not tried it yet and I don't know if it satisfies your needs. I might need to have a look at it next time I am struggling with guides.

These examples in your ggpp documentation are very helpful: https://docs.r4photobiology.info/ggpp/reference/geom_text_s.html

Screenshot 2024-01-03 at 12 46 22 PM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants