Skip to content

Smarter (more generous) padding for categorical axes with few levels - #732

Merged
grantmcdermott merged 12 commits into
mainfrom
cat-axis-pad
Sep 15, 2026
Merged

grantmcdermott merged 12 commits into
mainfrom
cat-axis-pad

Conversation

@grantmcdermott

@grantmcdermott grantmcdermott commented Sep 13, 2026

Copy link
Copy Markdown
Owner

Follow up to #729

The default padding at the end of categorical axes has bothered me for a while. Specifically, our plots don't look great when a categorical axis contains few levels (categories), since the outer plot elements are pressed flush against the axis limits, whilst leaving a lot of dead space in between.

At the same time, this isn't really an issue for plot types with "wider" glyphs (e.g., boxplots, violin, or jittered points). These generally look fine under the current defaults, even with few categories Sometimes this is b/c they ship their own spacing (type = "boxplot" does this, for example) and other times it's just because the wider glyph area naturally helps to balance the plot (jittered point do this, for example).

I've wanted to implement a more balanced default, which improves the overall plot aesthetic by being responsive to underlying plot type (glpyh) and overall spacing requirements (number of categories).

This PR builds on the new x/ypad machinery (#729), by implementing more generous end padding for categorical axis types when:

  1. there are relatively few (<8) categories, and
  2. we are drawing a point-alike glyph that is relatively thin, e.g. "p", "pointrange", etc.

If both (1) and (2) true, then axis padding is set to to 25% of the gap between the interior tick intervals. In other words, the outer ticks get a quarter of the regular spacing from edges of the plot frame.

If either (1) or (2) is not true, then the padding reverts back to its normal behaviour, i.e, 4% expansion in most cases; larger for "wide" glyphs like boxplots.

MWE

The end result is easier to visualize than explain, so see the comparison of Current vs Proposed outcomes for the "p" and "pointrange" types below.

library(broom)
library(tinyplot)
# 2 categoricals
plt(bill_len ~ sex, data = penguins,
  type = "p",
  main = "points + 2 categoricals (x-axis)")
coefs2 = tidy(lm(bill_len ~ 0 + sex, data = penguins), conf.int = TRUE)
plt(estimate ~ term, ymin = conf.low, ymax = conf.high, data = coefs2,
  type = "pointrange", pch = 19,
  main = "pointrange + 2 categoricals (x-axis)")
# 3 categoricals
plt(bill_len ~ species, data = penguins,
  type = "p",
  main = "points + 3 categoricals (x-axis)")
coefs3 = tidy(lm(bill_len ~ 0 + species, data = penguins), conf.int = TRUE)
plt(estimate ~ term, ymin = conf.low, ymax = conf.high, data = coefs3,
  type = "pointrange", pch = 19,
  main = "pointrange + 3 categoricals (x-axis)")
Current Proposed (changed)

Again, I emphasize is that this expanded padding doesn't kick in all the time. Below I show some types where the end result is identical for the Current and Proposed branches b/c of the "smart" overrides (e.g., when a large number of categorical groups is detected, as in the bottom row).

plt(bill_len ~ species, data = penguins, type = "j")
plt(bill_len ~ species, data = penguins, type = "box")
plt(x = LETTERS[1:10], y = 1:10, type = "p")
Current Proposed (stay the same)

@grantmcdermott

grantmcdermott commented Sep 13, 2026

Copy link
Copy Markdown
Owner Author

@zeileis @vincentarelbundock I know that you're both busy, but I'd appreciate a quick thumbs up if you're supportive of the basic idea. (No need to look at the code.)

@grantmcdermott
grantmcdermott requested a balanced review from Copilot September 13, 2026 23:36

This comment was marked as off-topic.

This comment was marked as resolved.

@vincentarelbundock

Copy link
Copy Markdown
Collaborator

Thanks, I think this looks better!

@grantmcdermott
grantmcdermott merged commit 093daab into main Sep 15, 2026
3 checks passed
@grantmcdermott

Copy link
Copy Markdown
Owner Author

Thanks Vincent! I think so too, so taking a majority vote ;-)

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