You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by "James Burton (JIRA)" <ji...@apache.org> on 2014/04/09 05:22:15 UTC
[jira] [Comment Edited] (BATIK-953) Trailing whitespace in tspan
elements breaks text-anchor alignment (only on Windows?)
[ 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-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org