[ 
https://issues.apache.org/jira/browse/BATIK-953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13963741#comment-13963741
 ] 

James Burton edited comment on BATIK-953 at 4/9/14 3:21 AM:
------------------------------------------------------------

We think we have figured this bug out.  It seems to be a bug in 
sun.font.StandardGlyphVector.getGlyphMetrics().  If you ask for the metrics for 
a character that has no glyphs (like a space) and it's not the first character 
in the text chunk, then it calculates the bounds.x value wrong.  This is 
compounded by Batik caching glyph geometry.  I'll attach two svg files with 
this comment that shows the issue.  

The only difference between the SVG files is a leading space in the first text 
node.  If you use Squiggle and view the "leading_space.svg" the text will do a 
"proper" right align on the vertical line.  You will need to close Squiggle 
before viewing the "no_leading_space.svg" because of the aforementioned 
caching.  The no_leading_space.svg totally messes up the alignment.

Another issue with the text-anchor "end" or "middle" is that we feel that 
org.apache.batik.gvt.renderer.StrokingTextPainter.adjustChunkOffsets() should 
not try to calculate the visible bounding box.  What does this mean for a 
trailing space?  We think if you have trailing spaces, they should "show".  
This is the way Firefox and Chrome behave.   

Here is what we changed:

            //visualAdvance = new Point2D.Float(
            //        (float)(chunk.advance.getX() + lastW - 
lastMetrics.getHorizontalAdvance()),
            //        (float)(chunk.advance.getY() + lastH - 
lastMetrics.getVerticalAdvance()));

            visualAdvance = new Point2D.Float(
                    (float)(chunk.advance.getX()),
                    (float)(chunk.advance.getY() + lastH - 
lastMetrics.getVerticalAdvance()));

We left the height alone for now.  The awt bug affects the "lastW" variable, so 
by ignoring it, we get rid of this bug.  Hope this helps.



was (Author: james.evy):
We have figured this bug out.  It has to do with a bug in 
sun.font.StandardGlyphVector.getGlyphMetrics().  If you ask for the metrics for 
a character that has no glyphs (like a space) and it's not the first character 
in the text chunk, then it calculates the bounds.x value wrong.  This is 
compounded by Batik caching glyph geometry.  I'll attach two svg files with 
this comment that shows the issue.  


> Trailing whitespace in tspan elements breaks text-anchor alignment (only on 
> Windows?)
> -------------------------------------------------------------------------------------
>
>                 Key: BATIK-953
>                 URL: https://issues.apache.org/jira/browse/BATIK-953
>             Project: Batik
>          Issue Type: Bug
>          Components: GVT Text
>    Affects Versions: 1.8
>         Environment: Operating System: Windows Vista
> Platform: PC
> URL: 
> http://mail-archives.apache.org/mod_mbox/xmlgraphics-batik-users/201008.mbox/browser#msg-1
>            Reporter: Helder Magalhães
>            Assignee: Batik Developer's Mailing list
>         Attachments: Batik-Bug49736-Testcase.svg, leading_space.svg, 
> no_leading_space.svg
>
>
> Trailing whitespace seems to trigger a weird issue where text contents are 
> thrown right a lot more than expected. It's as if "text-anchor" inheritance 
> was no longer honored in these cases (and reset to "start", the lacuna value).
> Bug's URL points to a thread ("JSVGCanvas Problems - Rendering and Writing") 
> which contains the original test case and a modified test case which doesn't 
> reproduce the issue (basically, with trailing whitespace trimmed).
> According to the thread, the issue doesn't seem to reproduce on Linux. Can 
> anyone else confirm and provide information for MacOS as well?
> BATIK-689 seems tightly related, although the issue is not quite the same (it 
> refers to a MacOS-specific issue). Also, thread "tspans fail to line up" [1] 
> seems related as well. I wonder if all these are the same...?
> A possible workaround is to make sure tspan elements don't contain trailing 
> whitespace.
> [1] 
> http://mail-archives.apache.org/mod_mbox/xmlgraphics-batik-users/200701.mbox/browser#msg-19



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

Reply via email to