Feature request - multiple labels per line

[tjebo]

Allan, first of all, you know that I am a big fan of this package. Incredible feat!

I just tried to create a slope graph with it (I wanted to add to my answer to this Stackoverflow thread, but it failed, because apparently it only allows one label per line (maybe I've overlooked something).

I am adding my ggh4x approach to show the current in my opinion most straight forward solution for a slope graph, but it would be cool to be able to do this with geom_textpath.

I can see that the use cases would be fairly limited and thus I'd understand if this should not have high priority for development. Anyways :)

library(ggh4x)
#> Loading required package: ggplot2

df <- data.frame(x = rep(1:5, each = 5), 
                 y = c(outer(seq(0, .8, .2), seq(0.02, 0.1, 0.02), `+`)),
                 cat = rep(paste0("a", 1:5)))

ggplot(df, aes(x, y)) +
  geom_text(aes(label = cat)) +
  geom_pointpath(aes(group = cat, shape = NA))

library(geomtextpath)
ggplot(df) +
  geom_textline(aes(x, y, label = cat, group = cat)) 

^{Created on 2022-05-29 by the reprex package (v2.0.1)}

[AllanCameron]

Thanks @tjebo . I know this is something that @teunbrand had envisioned at an early stage of the package's development. I can't remember now if we shelved it for reasons of complexity or simply forgot about it. It's probably not as niche as you think. Repeated labels on longer paths, or multiple labels highlighting different features on a line could be helpful. I'm happy to look at this unless Teun has any objections.

[teunbrand]

I think it is a good idea in principle. I don't know how difficult it would be to implement: I can imagine that we've foreseen only one label per line in places like calculating where the gaps should be. This could get hairy quite quickly, but it shouldn't be undoable. How would you imagine this on the user's end, simply a parameter that says rep_label = 5 or something of the sort?

[AllanCameron]

If we allowed multiple different strings per line then the user interface probably becomes too complex (multiple hjust per string would be very difficult to implement and probably break existing hjust scales). I guess just allowing repeats and ignoring hjust (or reinterpreting it in the case of repeats) would be best.

[tjebo]

I think if you're indeed thinking of implementing it, then it would make sense to go all the way and allow different strings - and intuitively it would make sense to just pass the labels as an aesthetic. Maybe as a different one, e.g. "multi_labels" or so. Regarding hjust - of course I don't know how your magic really works under the hood, and it seems amazing, but I am not sure if hjust would be such a problem. For example, an often forgotten feature of hjust is that you can actually pass it as an aesthetic...

e.g. (random example)

library(ggplot2)
ggplot(head(mtcars)) +
  geom_vline(aes(xintercept = mpg), lty = 2) +
## vs just contains 0 and 1
  geom_label(aes(mpg, disp, label = gear, hjust = vs))

But yeah, this might be difficult to implement in your geom.

^{Created on 2022-05-29 by the reprex package (v2.0.1)}

[teunbrand]

multiple hjust per string would be very difficult to implement

Indeed, I think it'd just be undefined at that point. There are different options on how to deal with text and spacing though, if we assume w is text that we want to repeat up to 3 times and - a unit of space, we can have:

w--w--w
-w--w--w-
--w--w--w--

I.e, do we put the text at the extremes, do we pad the ends with half-spacings or do we pad the ends with full spacing.

[teunbrand]

Another thought occured to me, we might be able to simply cheese this by splitting the line into several ones. Every individual linepiece would then be treated as a line, which would resolve potential nightmares with reserving space for multiple labels.

[AllanCameron]

Another thought occured to me, we might be able to simply cheese this by splitting the line into several ones. Every individual linepiece would then be treated as a line, which would resolve potential nightmares with reserving space for multiple labels.

This sounds like the most promising approach, assuming the line joins are seamless.

@tjebo the hjust is already handled as an aesthetic - in fact, we added specific scale_hjust_* and scale_vjust_* functions to control the mapping. I didn't think they would get much use, but they come in handy occasionally; in fact I used them earlier today with good effect