pub struct Run {Show 17 fields
pub text: String,
pub role: String,
pub bold: bool,
pub italic: bool,
pub underline: bool,
pub strike: bool,
pub sup: bool,
pub sub: bool,
pub src: u32,
pub sel: bool,
pub hl: Option<String>,
pub hl_color: Option<String>,
pub mark_color: Option<String>,
pub token: Option<String>,
pub size: Option<String>,
pub font: Option<String>,
pub text_color: Option<String>,
}Expand description
One maximal span of same-styled glyphs on a visual row — the unit the Swift renderer turns into a single styled attributed-string run.
Fields§
§text: StringThe run’s text, glyphs concatenated in column order.
role: StringThe glyph’s semantic role as a renderer class id: body, h1…h6,
code, link, mark, list, quote, rule.
bold: bool§italic: bool§underline: bool§strike: bool§sup: boolRaised off the baseline and drawn smaller — a footnote reference’s [1],
or an author’s ^x^. Mutually exclusive with sub; core’s
Baseline is one value, and these are its two non-default cases flattened
to the flag shape the rest of this record is spelled in.
sub: boolLowered off the baseline and drawn smaller — an author’s ~x~.
src: u32The byte offset in the source this run’s first glyph came from.
What a run means, as opposed to how it looks: a link role says a span
is drawn as a link but not where it points, and the only way back to that
is the source. A frontend drawing part of the document somewhere the caret
isn’t — a footnote’s text in a popover — pairs this with
LeafDoc::link_destination_at or LeafDoc::footnote_at to make those
runs followable.
The alternative was for a frontend to count its way along the row’s text
and ask LeafDoc::offset_for_pos, which means converting between three
units that only agree on ASCII: this is a byte offset, the run’s text is
characters, and a row’s column is a display cell (a wide CJK glyph is
two). Handing the offset over is exact, O(1), and needs none of that.
0 for the runs of the source view, whose rows are split from raw text
rather than laid out from glyphs.
sel: boolWhether this run lies inside the active selection — so the renderer can paint a selection background without re-deriving it from offsets.
hl: Option<String>The id of the host highlight covering this run, if one does — see
LeafDoc::set_highlights. A highlight splits a run the way the
selection does, so a wash begins and ends exactly on its bytes.
hl_color: Option<String>That highlight’s rendering hint (#RRGGBB, or None for the theme’s
default wash), carried beside the id so a renderer needs no lookup.
mark_color: Option<String>The colour the author named on a mark run — "red", "orange",
"yellow", "green", "blue", "purple", "brown" — or absent for a
plain ==highlight== and for every other role.
A name, unlike hl_color’s #RRGGBB, and that is
the difference between the two: a host highlight’s colour is the host’s
own choice and arrives as a value to paint, while this one is the
document’s word for it and the renderer picks the wash. It rides beside
role rather than folding into it ("mark-red") so a renderer that
knows nothing about colours still draws the run as the highlight it is.
token: Option<String>What a code run is to the language its fenced block is written in —
"punctuation", "keyword", "entity", "support", "constant",
"string", "comment", "invalid" — or absent for a run the grammar
left plain, for every run of a block in a language no grammar covers,
for inline code, and for every other role.
A class id like role, and beside it for the reason mark_color is: a
renderer that knows nothing about tokens still draws the run as the code
it is, and one that does keys a palette on the name.
size: Option<String>How large this run is set relative to the text around it — "xx-small",
"x-small", "small", "large", "x-large", "xx-large",
"xxx-large" — or absent for the theme’s own size, which is every run
there was before the presentation vocabulary.
A step, never a measurement, and a name for mark_color’s
reason: the document says how much bigger, the renderer’s theme says how
big. leaf_core::SizeStep::scale carries CSS’s own ratios for a renderer
that wants a default ramp rather than one of its own.
font: Option<String>The face this run is set in — "serif", "sans-serif", "monospace",
"cursive" — or absent for the theme’s body face.
A CSS generic rather than a family name, for size’s
reason: the theme names the concrete face, so serif is whichever serif
this platform’s theme has and a document never asks for one that isn’t
installed.
text_color: Option<String>The run’s foreground colour, by the same seven names
mark_color carries — or absent for the theme’s text
colour.
Not mark_color, though they share a vocabulary on
purpose: that is a highlight’s background and reaches a run through its
mark role, this is what the letters themselves are painted. A renderer
with a red for a highlight has a red for text, and both should be that
red.