https://issues.apache.org/bugzilla/show_bug.cgi?id=51765
--- Comment #3 from Mario <[email protected]> --- 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: [email protected] For additional commands, e-mail: [email protected]
