Axes labels should be able to clip, rather than require padding

[Tyler-Lopez]

I have found the design of the axes labels a little frustrating.

Axes labels require a certain amount of space. If they don't have this space, they will always collapse into "..." (separately, I would love to not have them collapse into that, or customize what they collapse into, but this is a separate concern).

There is a clunky-feeling boolean that exists to ensure labels at the start or end have sufficient padding, but this changes the entire chart domain - pushing the y-axes out to the left and the right. We should simply be able to have the label clip. This is a feature of other chart libraries, like Swift Charts. The x-axis can bleed into the y-axis.

In the following example, notice what happens as I attempt to add a label at the first data point.

Is there any way around this I am missing that is already in the library, and if not - I would love to see this added.

[Tyler-Lopez]

This is also only a problem in Vico with the x-axis, the y-axis can correctly "clip into" the x-axis. For example, if I put a 0 on the y-axis, that would look just fine.

[Gowsky]

Hello, @Tyler-Lopez. There’s no built-in parameter for this at the moment, but we’ll be looking into adding one.

In the meantime, you can achieve this quite easily by subclassing HorizontalAxis. In particular, you should extend the clipping area, modify the maximum width of the first and last labels, and possibly repurpose the horizontal CartesianLayer padding values as horizontal insets (if the extreme x-axis labels may be so long that they stick out past the y-axes).

For unscrollable charts, it’s clear how this feature could be implemented. However, for scrollable ones, it raises the question of where the labels should be clipped as the chart is scrolled, since the current clipping points (the left and right edges of the CartesianLayer area) can no longer be used. Would you like this feature to be added for scrollable charts too? If so, what would be the expected clipping behavior during scrolling?

There is a clunky-feeling boolean that exists to ensure labels at the start or end have sufficient padding

This is a relatively standard solution, as overlaps aren’t always desired, so it’s not necessarily “clunky.” However, offering overlaps as an alternative makes sense.

This is also only a problem in Vico with the x-axis, the y-axis can correctly "clip into" the x-axis. For example, if I put a 0 on the y-axis, that would look just fine.

There actually isn’t any axis overlap here. Currently, the left and right edges of an x-axis align with the left and right edges of the CartesianLayer area, whereas y-axes extend beyond this area vertically.

[claude[bot]]

This is partly addressed in 3.3.0.

The main complaint — that avoiding clipped extreme labels costs you plot area — no longer applies. HorizontalAxis.ItemPlacer gains getShiftExtremeLabels, and HorizontalAxis.ItemPlacer.aligned gains a matching shiftExtremeLabels parameter. When enabled, the first and last labels are end-aligned and start-aligned rather than centered on their x positions, anchoring them to the plot-area edges. They render in full, and no CartesianLayer padding is added, so the plot area keeps its full width and the vertical axes stay where they are. There’s also a new HorizontalAxis.ItemPlacer.extremes, which labels only the first and last x values with that same alignment.

bottomAxis =
  HorizontalAxis.rememberBottom(
    itemPlacer = remember { HorizontalAxis.ItemPlacer.aligned(shiftExtremeLabels = true) }
  )

To be precise about what this isn’t, since it differs from what you proposed:

• Labels are shifted inward, not allowed to overflow. The Swift Charts–style behavior you described, where a HorizontalAxis label bleeds into the VerticalAxis band and clips there, is still not available.
• Customizing what a truncated label collapses into is still unaddressed. The only control remains TextComponent’s textOverflow, which takes Compose’s TextOverflow values — TextOverflow.Clip drops the ellipsis, but an arbitrary indicator isn’t supported.

Leaving this open for those two points.

_{Based on maintainer input.}