You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the domain's length is too large for the range, the step of scaleBand is less than 1. The round option will then collapse it, and all the values end up assigned to the same value, with a bandwith = 0.
A solution would be to say that, rather than collapsing, we simply don't round. The bandwidth might become smaller than 1 but it'll still be (strictly) positive. We get maybe fuzzy shapes, but that's better than zero-width.
Another approach would be to say that, in that case, we don't round the step but still round the resulting values. The shapes are never fuzzy, but two consecutive values might overlap, creating maybe a kind of Moiré pattern (that depends on what we do with the results, of course).
A related issue is that if rounding is here because we want the bars of a bar chart to fall precisely on a pixel, the concept is a bit more fuzzy now. On retina screens, this should become a 0.5px rounding of some sort. This might warrant an added option .roundingPrecision(0.5) [with 0.5 = 1/device pixel ratio]?
The text was updated successfully, but these errors were encountered:
Description of the issue:
When the domain's length is too large for the range, the step of scaleBand is less than 1. The round option will then collapse it, and all the values end up assigned to the same value, with a bandwith = 0.
A solution would be to say that, rather than collapsing, we simply don't round. The bandwidth might become smaller than 1 but it'll still be (strictly) positive. We get maybe fuzzy shapes, but that's better than zero-width.
Another approach would be to say that, in that case, we don't round the step but still round the resulting values. The shapes are never fuzzy, but two consecutive values might overlap, creating maybe a kind of Moiré pattern (that depends on what we do with the results, of course).
A related issue is that if rounding is here because we want the bars of a bar chart to fall precisely on a pixel, the concept is a bit more fuzzy now. On retina screens, this should become a 0.5px rounding of some sort. This might warrant an added option .roundingPrecision(0.5) [with 0.5 = 1/device pixel ratio]?
The text was updated successfully, but these errors were encountered: