kas-gui / kas-text

Rich text processing
Apache License 2.0
59 stars 2 forks source link

Rich Text — design #14

Closed dhardy closed 3 years ago

dhardy commented 4 years ago

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 and font_scale are properties of GlyphRun. 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 (like LineRun, 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 as File with F 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 to ab-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 and highlight_runs. More correctly, these generate rects for text background. This implies that they should be replaced with a "background" formatting option?

dhardy commented 3 years ago

This has been implemented: