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 Cameron McCormack <ca...@mcc.id.au> on 2006/04/28 02:40:08 UTC
SVGTextContent.getExtentOfChar returning incorrect values
Hi Thomas.
Bjoern pointed out to me that getExtentOfChar returns SVGRects with
incorrect values. For example with this file:
<svg xmlns='http://www.w3.org/2000/svg' version='1.1'>
<text font-size="50" x="50" y="50" id="t">x x</text>
<script>
alert(document.getElementById('t').getExtentOfChar(0).x);
alert(document.getElementById('t').getExtentOfChar(1).x);
alert(document.getElementById('t').getExtentOfChar(2).x);
</script>
</svg>
the x value of the extent of the second character (the space) is 0. (In
fact the returned rect is [0,0,0,0].) This seems to be because
SVGTextElementBridge.getExtentOfChar gets the GVTGlyphVector from the
font, which, for AWT fonts at least, gets the bounding box of the actual
glyph shape. Since the space character has no shape, this empty
bounding box is returned.
The spec says:
getExtentOfChar
Returns a tightest rectangle which defines the minimum and maximum
X and Y values in the user coordinate system for rendering the
glyph(s) that correspond to the specified character. The
calculations assume that all glyphs occupy the full standard glyph
cell for the font. If multiple consecutive characters are rendered
inseparably (e.g., as a single glyph or a sequence of glyphs), then
each of the inseparable characters will return the same extent.
I think that this means it should be returning the a bounding box for
the metrics of the glyph as specified in the font (e.g. the width of the
returned SVGRect should be the advance of the glyph), rather than the
actual shape. Do you agree? If so, we could use Font.getStringBounds
for AWTGVTFonts (and look up the appropriate advance value from
SVGGVTFonts).
--
Cameron McCormack ICQ: 26955922
cam (at) mcc.id.au MSN: cam (at) mcc.id.au
http://mcc.id.au/ JBR: heycam (at) jabber.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: SVGTextContent.getExtentOfChar returning incorrect values
Posted by Tonny Kohar <to...@kiyut.com>.
Hi,
On Fri, 2006-04-28 at 10:40 +1000, Cameron McCormack wrote:
> Hi Thomas.
>
> Bjoern pointed out to me that getExtentOfChar returns SVGRects with
> incorrect values. For example with this file:
>
> the x value of the extent of the second character (the space) is 0. (In
> fact the returned rect is [0,0,0,0].) This seems to be because
> SVGTextElementBridge.getExtentOfChar gets the GVTGlyphVector from the
> font, which, for AWT fonts at least, gets the bounding box of the actual
> glyph shape. Since the space character has no shape, this empty
> bounding box is returned.
Is this behavior the same with SVGTextContentElement class
- getStartPositionOfChar(int)
- getEndPositionOfChar(int)
Because I have been using those methods, and no problem found :)
You could also get the rotation of char using
getRotationOfChar(int)
Regards
Tonny Kohar
--
Sketsa
SVG Graphics Editor
http://www.kiyut.com
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: SVGTextContent.getExtentOfChar returning incorrect values
Posted by Cameron McCormack <ca...@mcc.id.au>.
Thomase DeWeese:
> Sure, except actually I think it needs to be the 'rotated' glyph
> cell. So for text on a path you need to construct a rect that is
> roughly glyphPosition.x, glyphPosition.y-ascent ->
> glyphPosition.x+advance, glyphPosition.y+descent
>
> Then that needs to be rotated around the point
> glyphPosition.x+advance/2
> to match the text path (if any).
Ok.
> > If so, we could use Font.getStringBounds for AWTGVTFonts (and look up
> > the appropriate advance value from SVGGVTFonts).
>
> I think you should use the values from the GVTGlyphVector to get
> the position and advance of the glyph (you might need to add an interface
> to get the ascent/descent).
Ah cool, didn't notice that the metrics are exposed (or at least in
there) in GVTGlyphVector.
--
Cameron McCormack ICQ: 26955922
cam (at) mcc.id.au MSN: cam (at) mcc.id.au
http://mcc.id.au/ JBR: heycam (at) jabber.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: SVGTextContent.getExtentOfChar returning incorrect values
Posted by Cameron McCormack <ca...@mcc.id.au>.
Thomas DeWeese:
> Sure, except actually I think it needs to be the 'rotated' glyph
> cell. So for text on a path you need to construct a rect that is
> roughly glyphPosition.x, glyphPosition.y-ascent ->
> glyphPosition.x+advance, glyphPosition.y+descent
>
> Then that needs to be rotated around the point
> glyphPosition.x+advance/2
> to match the text path (if any).
>
>
> > If so, we could use Font.getStringBounds for AWTGVTFonts (and look up
> > the appropriate advance value from SVGGVTFonts).
>
> I think you should use the values from the GVTGlyphVector to get
> the position and advance of the glyph (you might need to add an interface
> to get the ascent/descent).
Actually I think that using the "logical" bounds of the glyphs will
correspond to the right values (before rotation), after having a look at
the code.
--
Cameron McCormack ICQ: 26955922
cam (at) mcc.id.au MSN: cam (at) mcc.id.au
http://mcc.id.au/ JBR: heycam (at) jabber.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: SVGTextContent.getExtentOfChar returning incorrect values
Posted by th...@kodak.com.
Hi Cameron,
Cameron McCormack <ca...@mcc.id.au> wrote on 04/27/2006 08:40:08 PM:
> Bjoern pointed out to me that getExtentOfChar returns SVGRects with
> incorrect values.
> This seems to be because SVGTextElementBridge.getExtentOfChar gets
> the GVTGlyphVector from the font, which, for AWT fonts at least,
> gets the bounding box of the actual glyph shape. Since the space
> character has no shape, this empty bounding box is returned.
> The spec says:
>
> getExtentOfChar
> Returns a tightest rectangle which defines the minimum and maximum
> X and Y values in the user coordinate system for rendering the
> glyph(s) that correspond to the specified character. The
> calculations assume that all glyphs occupy the full standard glyph
> cell for the font. If multiple consecutive characters are rendered
> inseparably (e.g., as a single glyph or a sequence of glyphs), then
> each of the inseparable characters will return the same extent.
>
> I think that this means it should be returning the a bounding box for
> the metrics of the glyph as specified in the font (e.g. the width of the
> returned SVGRect should be the advance of the glyph), rather than the
> actual shape. Do you agree?
Sure, except actually I think it needs to be the 'rotated' glyph
cell. So for text on a path you need to construct a rect that is
roughly glyphPosition.x, glyphPosition.y-ascent ->
glyphPosition.x+advance, glyphPosition.y+descent
Then that needs to be rotated around the point
glyphPosition.x+advance/2
to match the text path (if any).
> If so, we could use Font.getStringBounds for AWTGVTFonts (and look up
> the appropriate advance value from SVGGVTFonts).
I think you should use the values from the GVTGlyphVector to get
the position and advance of the glyph (you might need to add an interface
to get the ascent/descent).
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org