pub struct PositionedGlyph {Show 16 fields
pub glyph_id: u16,
pub x_offset: f64,
pub y_offset: f64,
pub x_advance: f64,
pub font_size: f64,
pub font_family: Arc<str>,
pub font_weight: u32,
pub font_style: FontStyle,
pub char_value: char,
pub color: Option<Color>,
pub href: Option<String>,
pub text_decoration: TextDecoration,
pub letter_spacing: f64,
pub cluster_text: Option<String>,
pub extraction_text: Option<String>,
pub ligature: bool,
}Fields§
§glyph_id: u16Glyph ID. For custom fonts with shaping, this is a real GID from GSUB.
For standard fonts, this is char as u16 (Unicode codepoint).
x_offset: f64X position relative to line start.
y_offset: f64Y offset from GPOS (e.g., mark positioning). Usually 0.0.
x_advance: f64Actual advance width of this glyph in points (from shaping or font metrics).
font_size: f64§font_family: Arc<str>Shared font family. Arc<str> (not String) so cloning a glyph — which
happens millions of times per large doc via TextLine/subtree clones and
measure trial-layouts — is a refcount bump, not a heap allocation. dhat
flagged this field’s per-glyph String clone as the #1 site by count
(~29% of all allocations). See benchmarks/harness/dhat-top.mjs.
font_weight: u32§font_style: FontStyle§char_value: charThe character this glyph represents. For ligatures, the first char of the cluster.
color: Option<Color>Per-glyph color (for text runs with different colors).
href: Option<String>Per-glyph href (for inline links within runs).
text_decoration: TextDecorationPer-glyph text decoration (for runs with different decorations).
letter_spacing: f64Letter spacing applied to this glyph.
cluster_text: Option<String>For glyphs of a cluster spanning several chars, the full cluster text
(e.g., “fi” for an fi ligature). None for 1:1 char-to-glyph mappings.
extraction_text: Option<String>The source text assigned to this glyph for PDF extraction.
ligature: boolTrue when this glyph ALONE stands for every char of cluster_text: a
many-to-one substitution such as the “ffi” ligature. The PDF writer
maps such a glyph to its whole cluster in the ToUnicode CMap, so text
extraction reads “office” and not “ofice” (issue #156).
False for glyphs that SHARE a multi-char cluster with other glyphs
(Indic reordering, base plus mark). Those carry the same
cluster_text on every glyph, so no single one of them may claim the
whole string in the CMap: a shared matra glyph would otherwise map to
whichever base it was first seen with.