1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
//! [`Footnote`] — one footnote's own body content (typography-gap WAVE 3).
//!
//! A footnote is spliced into a [`crate::scene::Block::Paragraph`] via an
//! INLINE MARKER, not a new [`crate::scene::Block`] variant: the author
//! writes the visible superscript digit as an ordinary
//! `uzor_text::StyledRun` with `vertical_align: uzor_text::VerticalAlign::
//! Super` (wave-2 machinery, reused verbatim per this feature's own brief),
//! then splices a zero-size `uzor_text::InlineBox::out_of_flow(local_index)`
//! at the SAME byte offset — `local_index` being this footnote's own
//! 0-based position within [`crate::scene::BlockNode::footnotes`]. The
//! `InlineBox` contributes NOTHING to wrap/advance (see that type's own doc
//! comment); its only job is recoverability: once a paragraph is placed
//! into a page, `crate::slice::pages` reads `ParagraphLayout::boxes` back
//! off the placed layout to learn WHICH page each footnote marker actually
//! landed on (the same `InlineBox`-as-correlation-token convention
//! `crate::toc`'s own indent spacer already established, applied here to
//! recover page ASSIGNMENT instead of a paint position).
//!
//! This is a documented authoring convention (like `crate::toc`'s own
//! leading-`InlineBox`-not-literal-whitespace rule) — not automatically
//! wired the way [`crate::scene::BlockNode::with_outline`] is, because a
//! footnote marker's position is inherently mid-run, not a whole-block
//! property.
use crateBlockNode;
/// One footnote's own body content — `&'a [BlockNode<'a>]`, the same "cell
/// content" scoping [`crate::scene::TableCell`]/[`crate::scene::ListItem`]
/// already use. No `number` field: like [`crate::scene::OutlineTag`], the
/// resolved number is a property of WHERE this footnote sits in document
/// order, computed by [`crate::slice::pages`] at slice time, never
/// authored.