Closed dhardy closed 3 years ago
This has been implemented:
format::Markdown
(see #29). Eventually we should support other parsers such as (limited) HTML. Parsers can already be written in downstream code (e.g. kas::text::AccelString
).format::FormattableText::font_tokens
format::FormattableText::effect_tokens
and/or by downstream code constructing Effect
tokens directly (optionally by directly accessing the text-format object within the Text
)
Formatting for text still needs significant design work. I may not be working on this in the near future, so instead of a planning document this is a series of notes.
There are several sub-issues.
Specification of formatting
I have written a quick hack in KAS to do this:
TextEffect
and its implementation.It looks like the implementation will work best with a series of property selectors, starting from index 0. In the initial hack properties are all optional, but ultimately it may not make sense to do this. An API over an
EffectSequence
could make it easy to change only one property at a given index. Conversion from other APIs (such as spans) can be supported.Font effects
Some effects require use of a different font/scale and thus require separate shaping: font, size, weight (bold), italics.
Currently,
font_id
andfont_scale
are properties ofGlyphRun
. The obvious implementation is thus to use a new run when font properties change. Caveat: currently line breaks are allowed between any run, and justification inserts spaces between all runs on the line. Perhaps a special "must not break" run flag or perhaps another abstraction (likeLineRun
, but for "words") would solve this. The same mechanism should be used for BIDI, which currently incorrectly allows line-breaks in some places.Non-font effects
For font colour, underline and strike-through, font properties do not change and the effects need not be applied until after all other processing steps.
It will be convenient to allow application of non-font properties to be applied temporarily (e.g. in
positioned_glyphs
): examples of short-lived effects are selection changing font colour and underlining of accelerator keys (e.g.&File
renders asFile
withF
underlined only when Alt is held).This means that non-font effects should be specifiable in the
RichText
model and when generating positioned glyphs, with the two specifications being combined.Underline, strike-through and background
These require additional data from the font. This PR works towards exposing
underline_metrics
(and simplifying our font management) but alternately it could be added directly toab-glyph
.Once the metrics are available, this font library needs a way of generating the required rects/other draw commands: underlines may span multiple glyphs and inter-run spaces, but need to break on line-breaks and might in the future have gaps for glyph descenders (or other styling).
There is already precedent for rects generated in this lib:
highlight_lines
andhighlight_runs
. More correctly, these generate rects for text background. This implies that they should be replaced with a "background" formatting option?