You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by kototama kototama <ko...@gmail.com> on 2013/11/19 18:14:56 UTC
getBBox values not consistent with Chrome
Hello,
I'm calculating the bbox value of a group containing a rectangle to adapt
its dimension to the text it contained.
The generated SVG looks like this:
<g xmlns="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?
Re: getBBox values not consistent with Chrome
Posted by Robert Marcano <ro...@marcanoonline.com>.
On 11/20/2013 05:49 AM, kototama kototama wrote:
> I'm modifying the DOM on the server (with Clojure) to serve it on a web
> client. The DOM is exported to a stream and served.
>
> I suppose SVGGraphics2D do not work in this context?
yea Graphics2D works on a headless server, but what you are doing looks
like doesn't involves drawing using Java2D, you will need to investigate
about how to do text to shapes using the Batik GVT API
>
> Exporting texts to paths is maybe not a solution for us as we would
> loose the ability to search the text (with Ctrl-f for the user) in the
> browser.
If text search is critical for you, there is one option to try and that
is to use browser loadable fonts
>
> Doing the manipulation in JavaScript is also problematic since resizing
> a rectangle (node) on the client means adapting the coordinate of the
> edges connecting two rectangles (we wrote layout algorithms on the
> server for graphs).
>
>
>
>
> On Tue, Nov 19, 2013 at 10:33 PM, Andrew Rowlands <a.rowlands@uq.edu.au
> <ma...@uq.edu.au>> wrote:
>
> I would go with Robert’s text to shape suggestion for this.
> Converting text to paths is the only reliable way to ensure the
> text will render as you expect across platforms. This also applies
> for certain functions that are not supported by some versions of
> browsers, e.g. text on path. Anything else will almost certainly
> not get the results you are after.
>
> Another way to do this (entirely depending on your application of
> course) is to do the manipulation in javascript - BUT - this
> obviously requires that the end user is running a nice
> latest-version browser with decent SVG support ;)
>
>
> On 20 Nov 2013, at 5:22 am, Robert Marcano <robert@marcanoonline.com
> <ma...@marcanoonline.com>> wrote:
>
> > 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
> >> <robert@marcanoonline.com <ma...@marcanoonline.com>
> <mailto:robert@marcanoonline.com <ma...@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
> <http://xmlgraphics.apache.org>
> >> <mailto:batik-users-unsubscribe@xmlgraphics.apache.org
> <ma...@xmlgraphics.apache.org>>
> >> For additional commands, e-mail:
> >> batik-users-help@xmlgraphics.__apache.org <http://apache.org>
> >> <mailto:batik-users-help@xmlgraphics.apache.org
> <ma...@xmlgraphics.apache.org>>
> >>
> >>
> >>
> >>
> ------------------------------__------------------------------__---------
> >> To unsubscribe, e-mail:
> >> batik-users-unsubscribe@__xmlgraphics.apache.org
> <http://xmlgraphics.apache.org>
> >> <mailto:batik-users-unsubscribe@xmlgraphics.apache.org
> <ma...@xmlgraphics.apache.org>>
> >> For additional commands, e-mail:
> >> batik-users-help@xmlgraphics.__apache.org <http://apache.org>
> >> <mailto:batik-users-help@xmlgraphics.apache.org
> <ma...@xmlgraphics.apache.org>>
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> batik-users-unsubscribe@xmlgraphics.apache.org
> <ma...@xmlgraphics.apache.org>
> > For additional commands, e-mail:
> batik-users-help@xmlgraphics.apache.org
> <ma...@xmlgraphics.apache.org>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> batik-users-unsubscribe@xmlgraphics.apache.org
> <ma...@xmlgraphics.apache.org>
> For additional commands, e-mail:
> batik-users-help@xmlgraphics.apache.org
> <ma...@xmlgraphics.apache.org>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: getBBox values not consistent with Chrome
Posted by kototama kototama <ko...@gmail.com>.
I'm modifying the DOM on the server (with Clojure) to serve it on a web
client. The DOM is exported to a stream and served.
I suppose SVGGraphics2D do not work in this context?
Exporting texts to paths is maybe not a solution for us as we would loose
the ability to search the text (with Ctrl-f for the user) in the browser.
Doing the manipulation in JavaScript is also problematic since resizing a
rectangle (node) on the client means adapting the coordinate of the edges
connecting two rectangles (we wrote layout algorithms on the server for
graphs).
On Tue, Nov 19, 2013 at 10:33 PM, Andrew Rowlands <a....@uq.edu.au>wrote:
> I would go with Robert’s text to shape suggestion for this. Converting
> text to paths is the only reliable way to ensure the text will render as
> you expect across platforms. This also applies for certain functions that
> are not supported by some versions of browsers, e.g. text on path.
> Anything else will almost certainly not get the results you are after.
>
> Another way to do this (entirely depending on your application of course)
> is to do the manipulation in javascript - BUT - this obviously requires
> that the end user is running a nice latest-version browser with decent SVG
> support ;)
>
>
> On 20 Nov 2013, at 5:22 am, Robert Marcano <ro...@marcanoonline.com>
> wrote:
>
> > 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
> >> <robert@marcanoonline.com <ma...@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
> >> <ma...@xmlgraphics.apache.org>
> >> For additional commands, e-mail:
> >> batik-users-help@xmlgraphics.__apache.org
> >> <ma...@xmlgraphics.apache.org>
> >>
> >>
> >>
> >>
> ------------------------------__------------------------------__---------
> >> To unsubscribe, e-mail:
> >> batik-users-unsubscribe@__xmlgraphics.apache.org
> >> <ma...@xmlgraphics.apache.org>
> >> For additional commands, e-mail:
> >> batik-users-help@xmlgraphics.__apache.org
> >> <ma...@xmlgraphics.apache.org>
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
Re: getBBox values not consistent with Chrome
Posted by Andrew Rowlands <a....@uq.edu.au>.
I would go with Robert’s text to shape suggestion for this. Converting text to paths is the only reliable way to ensure the text will render as you expect across platforms. This also applies for certain functions that are not supported by some versions of browsers, e.g. text on path. Anything else will almost certainly not get the results you are after.
Another way to do this (entirely depending on your application of course) is to do the manipulation in javascript - BUT - this obviously requires that the end user is running a nice latest-version browser with decent SVG support ;)
On 20 Nov 2013, at 5:22 am, Robert Marcano <ro...@marcanoonline.com> wrote:
> 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
>> <robert@marcanoonline.com <ma...@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
>> <ma...@xmlgraphics.apache.org>
>> For additional commands, e-mail:
>> batik-users-help@xmlgraphics.__apache.org
>> <ma...@xmlgraphics.apache.org>
>>
>>
>>
>> ------------------------------__------------------------------__---------
>> To unsubscribe, e-mail:
>> batik-users-unsubscribe@__xmlgraphics.apache.org
>> <ma...@xmlgraphics.apache.org>
>> For additional commands, e-mail:
>> batik-users-help@xmlgraphics.__apache.org
>> <ma...@xmlgraphics.apache.org>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: getBBox values not consistent with Chrome
Posted by Robert Marcano <ro...@marcanoonline.com>.
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
> <robert@marcanoonline.com <ma...@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
> <ma...@xmlgraphics.apache.org>
> For additional commands, e-mail:
> batik-users-help@xmlgraphics.__apache.org
> <ma...@xmlgraphics.apache.org>
>
>
>
> ------------------------------__------------------------------__---------
> To unsubscribe, e-mail:
> batik-users-unsubscribe@__xmlgraphics.apache.org
> <ma...@xmlgraphics.apache.org>
> For additional commands, e-mail:
> batik-users-help@xmlgraphics.__apache.org
> <ma...@xmlgraphics.apache.org>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: getBBox values not consistent with Chrome
Posted by kototama kototama <ko...@gmail.com>.
Yes I'm calculating before the creation of the SVG.
For solution 1), is there a standard function to do that?
For solution 2), isn't Helvetica a browser font?
Also why the same fonts can have different metrics in different browsers?
On Tue, Nov 19, 2013 at 6:35 PM, Robert Marcano <ro...@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" 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
>> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
Re: getBBox values not consistent with Chrome
Posted by Robert Marcano <ro...@marcanoonline.com>.
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" 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
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org