Inkscape

Bug #1269206
Comment #15

Comment 15 for bug 1269206

Revision history for this message

David Mathog (mathog) wrote on 2014-01-29:

#15

changes_2014_01_28b.patch Edit (148.8 KiB, text/plain)

The attached patch takes the text decorations into full compliance (I think) with SVG 1.1, while still supporting
SVG 2's CSS 3. Changes:

1. It draws underline and overline underneath the text, strike-through over it.
2. It supports patterns in the fill and stroke. For instance, the letters can be "packed circles" with a red boundary, and the decorations will be that way too.
3. Added "dotted" to the text and font dialog (for CSS 3).
4. Fixed a glitch where occasionally a CSS 3 "text-decoration" would have the extra style value, but without color.

This patch includes all of the dc->ct changes from bug #1272073. (That is a partial step in making the text decoration code reusable for "render", as in going to PDF through Cairo.)

Known issues:

1. The font and text dialog still does not always pick up the right font size for a selected region of text. Consequently when the text decorations are added it sometimes unexpectedly changes the font. (Usually the size, sometimes the face.)
That seems to be a (pre-existing) problem in the method it uses to retrieve these values.
2. CSS 3 allows the "color" to be set, but there are both "fill" and "stroke". So when text-decoration-color or the longer text-decoration tags are used they only set "fill".
3. The dash property is not supported for stroke on text decorations. It was omitted because there are all sorts of problems getting the dashes to phase out properly when there are multiple tspans within one text. Bottom line, using dashed strokes looked dreadful when I was experimenting with them, so I did not implement it.

Suspected issues:

1. fill and stroke are set pervasively on objects and text-decoration-fill and text-decoration-stroke are derived from them. The current implementation has these new fields for all "style" objects, 99.9% of them with all text-decoration values clear, which is probably wasting a fair amount of memory since only text objects can use these fields. It would be more space efficient to bundle all of these optional pieces into a data structure accessed via a pointer, so the overhead would only be one NULL pointer per object.

Will post some examples tomorrow, after bug 1273900 is resolved, which at the moment is keeping me from rebuilding at the current trunk revision.

The attached patch takes the text decorations into full compliance (I think) with SVG 1.1, while still supporting
SVG 2's CSS 3.   Changes:

1.  It draws underline and overline underneath the text, strike-through over it.
2.  It supports patterns in the fill and stroke.  For instance, the letters can be "packed circles" with a red boundary, and the decorations will be that way too.  
3.  Added "dotted" to the text and font dialog (for CSS 3).
4.  Fixed a glitch where occasionally a CSS 3 "text-decoration" would have the extra style value, but without color.

This patch includes all of the dc->ct changes from bug #1272073.   (That is a partial step in making the text decoration code reusable for "render", as in going to PDF through Cairo.)

Known issues:

1.  The font and text dialog still does not always pick up the right font size for a selected region of text.  Consequently when the text decorations are added it sometimes unexpectedly changes the font.  (Usually the size, sometimes the face.)
That seems to be a (pre-existing)  problem in the method it uses to retrieve these values.
2.  CSS 3 allows the "color" to be set, but there are both "fill" and "stroke".  So when text-decoration-color or the longer text-decoration tags are used they only set "fill".
3.  The dash property is not supported for stroke on text decorations.   It was omitted because there are all sorts of problems getting the dashes to phase out properly when there are multiple tspans within one text.  Bottom line, using dashed strokes looked dreadful when I was experimenting with them, so I did not implement it.

Suspected issues:

1.  fill and stroke are set pervasively on objects and text-decoration-fill and text-decoration-stroke are derived from them.  The current implementation has these new fields for all "style" objects, 99.9% of them with all text-decoration values clear, which is probably wasting a fair amount of memory since only text objects can use these fields.  It would be more space efficient to bundle all of these optional pieces into a data structure accessed via a pointer, so the overhead would only be one NULL pointer per object.

Will post some examples tomorrow, after bug 1273900 is resolved, which at the moment is keeping me from rebuilding at the current trunk revision.