Skip to content

Automatic margins based on tick label length #383

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

Open
ericemc3 opened this issue May 12, 2021 · 12 comments · Fixed by #838 · May be fixed by #1722
Open

Automatic margins based on tick label length #383

ericemc3 opened this issue May 12, 2021 · 12 comments · Fixed by #838 · May be fixed by #1722
Labels
enhancement New feature or request

Comments

@ericemc3
Copy link

A Plot could be internally composed in a harmonious and adaptive way, taking into account the actual bounding box of tick labels and axis titles for example, rather than having you to manually specify margins.

Here I need to enter a guestimate marginLeft:110 to accomodate labels width:

image

A manual specification of margins is not robust: if unit or data change, or the font family/size used for the axes, overlaps may occur, or unsightly gaps may appear.

Note: ggplot2 and vega-lite automatically handle margins/padding inferred from axis (and legends) bounding boxes.

Plus, an option comparable to labelOverlap in vega-lite would allow the density of tick labels on a numerical or temporal axis to be managed harmoniously, avoiding any overlap.

PS: Plot is a great library, very intellectually stimulating, and the 21 beautifully written articles in the https://observablehq.com/collection/@observablehq/plot collection should be read by all data scientists!

@Fil
Copy link
Contributor

Fil commented May 12, 2021

Adapting to labels' lengths would also make the chart behave unpredictably. There should be a better method than guesstimating though.

@ericemc3
Copy link
Author

Well i don't see ggplot2 or vega-lite behave unpredictably to that regard, and i have already handle this with D3 in the past (SVG or canvas provides methods for measuring BB and texts length after painting). Could you please elaborate on what you fear might become unpredictable?

@mbostock mbostock added the enhancement New feature or request label May 12, 2021
@mbostock
Copy link
Member

We chose not to do this both to keep things simple and because we want the margins to be consistent across plots for vertical alignment. However, I would like to truncate long labels with ellipsis rather than letting them get cropped by the edge of the chart #394, and I would also like to explore smarter defaults for large numbers (e.g., automatically converting to thousands, millions, or billions) #395.

That said, I could see opting-in to this somehow if the other approaches are insufficient.

@mbostock mbostock changed the title Automatic margins computation Automatic margins based on tick label length May 12, 2021
@ericemc3
Copy link
Author

I agree that in any case a maximum label width should prevail and ellipsis are a convenient and elegant truncation option.

@enjalot
Copy link

enjalot commented Nov 19, 2021

What about a compromise where the default marginLeft for ordinal scales is a bit wider than 60px, as that's often much too short for categorical labels.

Every time I make a Plot with ordinal Y axis I change the margin, because reading the labels is higher priority than the consistency in vertical alignment, especially while I'm in the process of exploring the data and trying to generate many Plots rapidly.

@Fil
Copy link
Contributor

Fil commented Nov 22, 2021

@enjalot would we restrict this to ordinal scales? I could see the defaults being different for numbers and for strings… In practice I often have to marginLeft in both cases, since the defaults for numbers are also a bit too small for 5 or 6 digits, but in that case maybe we just need a few pixels more.

@enjalot
Copy link

enjalot commented Nov 22, 2021

@Fil I too often change the defaults for numbers. but not quite as often and not by as much as for strings.

@enjalot
Copy link

enjalot commented Dec 21, 2021

something I just ran into: the small margin cut off numbers which at first glance didn't look wrong at all. took me a while to notice the problem because the code was so simple i was sure i didn't do anything "wrong"

Screen Shot 2021-12-21 at 12 54 28 PM

@Fil
Copy link
Contributor

Fil commented Dec 21, 2021

This issue was made a bit worse by the new tabular style on numbers.

@kospl
Copy link

kospl commented Feb 8, 2022

Any updates on this? :
image

@mbostock
Copy link
Member

mbostock commented Feb 8, 2022

Please don’t pester for updates. If there are updates, you’ll see them here.

@kospl
Copy link

kospl commented Feb 8, 2022

Of course, just had to post something here to not create another issue, that will be closed as obviously there is better use case then mine, anyway thanks.

Fil added a commit that referenced this issue Apr 5, 2022
since we adopted font-variant="tabular-nums" the left margin is too small for five-digits numbers
@Fil Fil closed this as completed in #838 Apr 5, 2022
Fil added a commit that referenced this issue Apr 5, 2022
since we adopted font-variant="tabular-nums" the left margin is too small for five-digits numbers
@mbostock mbostock reopened this Apr 6, 2022
@yurivish yurivish mentioned this issue Jun 3, 2022
15 tasks
@Fil Fil linked a pull request Sep 21, 2023 that will close this issue
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants