[Bug 51765] Text-underline not working inside flowSpan

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=51765

--- Comment #3 from Mario <m....@rug.nl> ---
Created attachment 29267
  --> https://issues.apache.org/bugzilla/attachment.cgi?id=29267&action=edit
Fixes the incorrect positioning of underline, overline and line-through in
flowing text tags

As the previously attached test case illustrates perfectly, the underline is
positioned incorrect. As it seems, it always gets positioned at the top of the
defined flowRegion. This is also true for the overline and line-through text
decorations.
After two to three days of analysing I found that the cause was in the
GlyphLayout class in the code painting the text decorations
(paintDecorations(...)). The protected methods getUnderlineShape(),
getOverlineShape() and getStrikethroughShape() (i.e. SVG calls it
line-through), all use the offset property to determine the offset of the text
decoration in relation to the text. With regular <text> and <tspan> tags
somehow this property gets the right offset values set (probably through manual
x, y tag attributes or derived from parent tags) and the text decoration is
showed correct. However, with flowing text tags (<flowPara>, <flowSpan>) the
offset values do not get set at all (both offset.x and offset.y stay 0.0). That
is probably because flowing text elements have their own <flowRegion> defined
in which the text flows 'freely'. As a result the offset determined for the
text decoration only reaches to the top of the defined flow region. Hence, the
text decoration is always shown at the top. 
To fix this, one could either try to let the GlyphLayout.offset property values
get set and take into account the possible multiline flowing text or instead of
using the offset property, determine the text decoration offset with help of
the available glyph vector. This vector contains all the glyphs (i.e.
typographic representation of characters), that are subject to the text
decoration. Those glyphs have bounds from which their positions can be
determined. And with the other components (line thickness and what not) making
up the total offset the correct position of the text decoration can be
determined.

The latter solution I chose to implement and is attached in the patch. It is
implemented such that for regular <text> and <tspan> tags the
GlyphLayout.offset property (i.e. the original way) is still used, but for
flowing text (i.e. flowPara, flowSpan) the glyph vector is used. That is why
the patch also contains changes in FlowTextPainter.java and
FlowGlyphLayout.java, because I had to change that instances of both of those
classes get loaded when Batik is dealing with flowing text instead of regular
text.

Looking forward to seeing your comments on this fix and possibly how to commit
it to the repository if requested.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org