On Wed, 2014-01-08 at 11:13 -0800, mathog wrote:
Display of text decorations is in trunk and it can display things as shown in this example:
https://launchpadlibrarian.net/140347078/text_decorations.png
A long-long-long awaited feature! I eagerly await being able to try it out.
I am not sure that we should be including CSS3 text decorations at this point (at least in the GUI). We need to decide on a general framework for handling SVG2/CSS3 features. CSS3 text decoration also doesn't seem to have been implemented by any of the browsers yet and the SVG WG hasn't discussed how CSS3 text decoration will work in the context of SVG2. We don't want a repeat of the "flowed-text" debacle. (I am not suggesting CSS3 text decoration code be removed, just not exposed to the user... we'll surely need the code soon enough.)
Note that SVG has specific rules for how color inherits for text-decoration:
http://www.w3.org/TR/SVG/text.html#TextDecorationProperties
I'm not sure how compatible they are with CSS2. In any case, we should follow SVG's rules.
(Note install the last patch in https://bugs.launchpad.net/inkscape/+bug/1243401 to see these again, as a recent change to trunk broke them.)
Text decoration control requires three GUI fields:
Line: NONE, or any combination of: underline, overline, linethrough, blink Style: solid, double, dashed, wavy Color: From Text or (Color setting widget)
I'm thinking about what the GUI should look like to access these. My first thought was to add them to the "A" (Create and edit text objects) part of the GUI, since text decoration does not make a lot of sense without text to decorate, and this sort of thing would be in a part of the GUI like that in a Word processor. But that part of the GUI is already packed with options, to the extent that on my computer I can only see all the options when Inkscape fills the entire screen. If text decoration was added there, it would never all fit.
So my second thought was to maybe put these in "A (with a wavy line through it)" as (Create and edit text decorations). That would let it fit on screen better, at the cost of making the line of icons down the left side of the screen one longer.
The third option is to add a second line of options to the existing "A". That would use up more vertical screen space, but it would have the advantage that all of the text and text decoration formatting options could be on screen at once. This is more of a departure for the GUI, since it seems not to happen anywhere else.
Thoughts?
Josh had an idea for context sensitive menus that would pop on the screen when needed. What if the text-decoration GUI would became part of the menu that you get when you right-click on the screen when using the Text tool ("A")?
Tav