On 11/19/2013 01:34 PM, kototama kototama wrote:
Yes I'm calculating before the creation of the SVG.
For solution 1), is there a standard function to do that?
Are you drawing to a Batik SVGGraphics2D? if true, use the Java2D APIs
to do that:
TextLayout layout = new TextLayout("This is a string", font, frc);
Shape shape = layout.getOutline(null); // null if no transformation is
needed
g.draw(shape);
SVGGraphics2D should probably have an API for enabling that, but I
didn't find one
If you are using Batik GVT, I don't remember much about it but I
remember that you can get Java2D shapes from elements
For solution 2), isn't Helvetica a browser font?
Browsers generally don't provide fonts (on Android some do because they
need to embed them because the OS only provides basic UI fonts), they do
some mapping to the OS available fonts. Someone that names a font
Helvetica should try to provide the same metrics, on common Linux
distributions Helvetica is mapped to Nimbus Sans L, that apparently
tries to do that.
Trying to draw pixel perfect fonts with SVG on browsers is like trying
to draw pixel perfect HTML text. There are many issues that can make
your drawing not look the same, for example differences in how the text
layout code of the browser paint each glyph, if ligatures are supported,
etc.
But assuming the browser is using the exact same font you are using on
Java (same computer both tests), you can try using the viewbox attribute
http://www.w3.org/TR/SVG/coords.html#ViewBoxAttribute . Everytime I get
an SVG file that mixes pixel units and relative units like pt, in, cm,
etc. Everything looks distorted on other viewers/User Agents that use
different base DPI values
Also why the same fonts can have different metrics in different browsers?
On Tue, Nov 19, 2013 at 6:35 PM, Robert Marcano
<rob...@marcanoonline.com <mailto:rob...@marcanoonline.com>> wrote:
On 11/19/2013 12:44 PM, kototama kototama wrote:
Hello,
I'm calculating the bbox value of a group containing a rectangle to
adapt its dimension to the text it contained.
If the calculation is not dynamic, but done on Java before dumping
the SVG XML, the problem may be related to the real font used. There
is no guarantee that the UA displaying the SVG has the font, or the
font has exactly the same metric that the one you used to calculate
the sizes
In an ideal world were everyone comply with the latest standard, you
have a few options:
1- Transform the text to shapes
The infallible solution
2- Make the font available to the browser using a browser supported
font format
Never tried this, but it could work for no complex western
languages where laying out text hasn't complex rules
2- Transform the font to a SVG Font
Not all UA/browsers have support for SVG Fonts (Firefox hasn't,
not sure about Chrome)
3- User SVG flow elements
Batik has some extensions for this, no standard, SVG 1.2 has
proposal for that but there isn't any 1.2 compliant browser, and
Batik isn't 1.2 compliant either
The generated SVG looks like this:
<g xmlns="http://www.w3.org/2000/__svg
<http://www.w3.org/2000/svg>" class="rectangle-node" id="node3"
transform="translate(200, 225)">
<rect style=" fill: white; stroke: black; " width="100.0"
height="40.0"/>
<text x="50" font-size="12px" y="20" style=" dominant-baseline:
central;
" font-family="helvetica" text-anchor="middle">Stuff</__text>
</g>
As you can see on the attached image this works well with Batik
(on the
right of the image) but the same SVG displayed in Chrome (on the
left)
is not correct. The text flows out of the rectangle.
Why does this calculation is not renderer independent given the font
size and font are specified?
What kind of solution can I implement to solve this problem?
------------------------------__------------------------------__---------
To unsubscribe, e-mail:
batik-users-unsubscribe@__xmlgraphics.apache.org
<mailto:batik-users-unsubscr...@xmlgraphics.apache.org>
For additional commands, e-mail:
batik-users-help@xmlgraphics.__apache.org
<mailto:batik-users-h...@xmlgraphics.apache.org>
------------------------------__------------------------------__---------
To unsubscribe, e-mail:
batik-users-unsubscribe@__xmlgraphics.apache.org
<mailto:batik-users-unsubscr...@xmlgraphics.apache.org>
For additional commands, e-mail:
batik-users-help@xmlgraphics.__apache.org
<mailto:batik-users-h...@xmlgraphics.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-h...@xmlgraphics.apache.org
