because it breaks the invariant that the pango layout used for
navigating in the on-canvas editor must be a 1:1 view on the text
buffer used for editing. Will have to fix that somehow...
because we will soon use temporary buffers to turn stuff into markup
and back, and these temporary buffers won't have their tags registered
like the original GimpTextBuffer does.
Add a list of available baseline tags to GimpTextBuffer and
automatically create baseline tags as needed. They get serialized as
<span rise="value">, so add attribute and value parameters to the
buffer's tag_to_name() and name_to_tag() functions. Properly managing
the rise's amount is a TODO, currently each keystroke changes the
baseline by 1024 pango units, which might be whatever depending on the
output grid.
When turning overlapping tags into a strictly nested markup structure,
make sure we don't treat tags that are ending at an iter like tags
that were only closed because overlapping spans don't exist in markup.
Chew on this sentence a bit, it took ages to write it.
- keep around tags for styles in GimpTextBuffer. For now only bold,
italic, underline and strikethrough.
- add GimpTextStyleEditor, a widget which allows setting tags on
a GimpTextBuffer's selection.
- add serialize/deserialize code to/from pango markup using
GtkTextBuffer's rich text (de)serialization infrastructure.
Doesn't produce or handle <span> yet.
Massimo Valentini