docs: correct three header comments that had drifted from the code
This commit is contained in:
1 parent
040e40254d
commit
81792dcd05
3 files changed
+14
-6
No files matched your search
@@ -22,7 +22,9 @@ namespace plot {
|
||||
/// and `dash_off` are independent, so a caller may override only the dash, or only the
|
||||
/// width, and leave the rest to the style.
|
||||
struct CrosshairStyle {
|
||||
f32 width = -1.0f; ///< logical stroke width; `< 0` takes `Style::crosshair_width`.
|
||||
f32 width = -1.0f; ///< logical stroke width; `< 0` takes `Style::crosshair_width`
|
||||
///< (the default). Only a *negative* value defers: `0` is used
|
||||
///< literally and draws an invisible line.
|
||||
f32 dash_on = -1.0f; ///< logical ink length; `< 0` takes `Style::crosshair_dash_on`.
|
||||
f32 dash_off = -1.0f; ///< logical gap; `< 0` takes `Style::crosshair_dash_off`, and `0`
|
||||
///< (once resolved) means solid.
|
||||
|
||||
@@ -554,9 +554,11 @@ class Plot {
|
||||
|
||||
/// A floor on the left gutter `layout()` reserves, in device pixels: the label
|
||||
/// strip and the title column together are never narrower than this, so `axes`
|
||||
/// never starts left of `viewport().x + min_y_gutter()`. 0.0 -- the default --
|
||||
/// imposes nothing and the plot sizes its strip from its own widest tick label,
|
||||
/// which is what a plot standing on its own has always done.
|
||||
/// starts no further left than `viewport().x + min_y_gutter()` **up to the cap
|
||||
/// below** -- a floor wider than half the viewport is clamped exactly as the
|
||||
/// measured strip is, so the guarantee is `min(min_y_gutter(), y_budget)`. 0.0
|
||||
/// -- the default -- imposes nothing and the plot sizes its strip from its own
|
||||
/// widest tick label, which is what a plot standing on its own has always done.
|
||||
///
|
||||
/// It exists for `Figure`, which is the only thing that can know the answer: a row
|
||||
/// cannot see its siblings' tick labels, so the figure lays each row out once to
|
||||
|
||||
@@ -53,8 +53,12 @@ struct Style {
|
||||
/// (`Trace`'s default, 0x40C0FF) that a hue-based reading cannot tell from a cyan crosshair --
|
||||
/// only lightness would separate them, which no reader can rely on. A near-white can never be a
|
||||
/// saturated trace of *any* hue, and it is still plainly not `cursor`'s orange, which is what
|
||||
/// the spec asks for. The 1 px stroke is kept: form (a full-height thin line over a polyline) is
|
||||
/// already distinct, so no dashes.
|
||||
/// the spec asks for.
|
||||
///
|
||||
/// The stroke is thin and dashed by default -- see `crosshair_width`, `crosshair_dash_on` and
|
||||
/// `crosshair_dash_off` below for the values: thinner than a trace so the instrument reads as
|
||||
/// chrome rather than data, and dashed so it is distinguishable by *form* as well as by
|
||||
/// lightness.
|
||||
Color crosshair = Color::hex(0xE6EBF2);
|
||||
|
||||
/// The crosshair's stroke and dash, in logical pixels (spec §17). The crosshair is a
|
||||
|
||||
Reference in new issue
Block a user