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 Charles Seelig <ch...@gmail.com> on 2012/02/20 21:16:00 UTC
Bounding Box accuracy for text containing ISO (Æ) characters
Hello, all.
I'm wondering if anyone could point me in the right direction re: coaxing
an SVGTextElement to return a correct bounding box when the text contains
ISO encoded characters.
SVGDocument doc = makeSvgDocument(svgString);
SVGTextElement svgTextElement = (SVGTextElement) doc.getElementById("textID"
);
svgTextElement.getFirstChild().setNodeValue("ΑΩ");
float width = svgTextElement.getBBox().getWidth();
My document is created as follows -
protected SVGDocument makeSvgDocument(String svgString) {
SVGDocument svgDoc = null;
@SuppressWarnings("unused")
GraphicsNode rootGN;
UserAgent userAgent = new UserAgentAdapter();
DocumentLoader loader = new DocumentLoader(userAgent);
BridgeContext ctx = new BridgeContext(userAgent, loader);
GVTBuilder builder = new GVTBuilder();
SAXSVGDocumentFactory factory = new
SAXSVGDocumentFactory(SAXParser.class.getCanonicalName(),
true);
try {
svgDoc = (SVGDocument) factory.createDocument("file:///dummy/dummy/file.svg",
new StringReader(svgString));
ctx.setDynamicState(BridgeContext.DYNAMIC);
rootGN = builder.build(ctx, svgDoc);
} catch (IOException e) {
e.printStackTrace();
}
return svgDoc;
}
It appears to me that the result (especially evident for width) is
calculated as if the 1 character is actually 6 characters.
Thank you.
Best regards,
Charles Seelig
Re: Bounding Box accuracy for text containing ISO (Æ)
characters
Posted by Andrew Rowlands <a....@uq.edu.au>.
Hi Charles,
I'm not sure if this helps you, but I've found bbox to be flakey in some situations when the element you're using is text. Of course, it might've been how I was doing things (likely), but if you're not after the bbox per se and just need some width measurement you could try getComputedTextLength().
Cheers,
Andrew
On 21/02/2012, at 9:16 AM, Charles Seelig wrote:
Hello, all.
I'm wondering if anyone could point me in the right direction re: coaxing an SVGTextElement to return a correct bounding box when the text contains ISO encoded characters.
SVGDocument doc = makeSvgDocument(svgString);
SVGTextElement svgTextElement = (SVGTextElement) doc.getElementById("textID");
svgTextElement.getFirstChild().setNodeValue("ΑΩ");
float width = svgTextElement.getBBox().getWidth();
My document is created as follows -
protected SVGDocument makeSvgDocument(String svgString) {
SVGDocument svgDoc = null;
@SuppressWarnings("unused")
GraphicsNode rootGN;
UserAgent userAgent = new UserAgentAdapter();
DocumentLoader loader = new DocumentLoader(userAgent);
BridgeContext ctx = new BridgeContext(userAgent, loader);
GVTBuilder builder = new GVTBuilder();
SAXSVGDocumentFactory factory = new SAXSVGDocumentFactory(SAXParser.class.getCanonicalName(), true);
try {
svgDoc = (SVGDocument) factory.createDocument("file:///dummy/dummy/file.svg", new StringReader(svgString));
ctx.setDynamicState(BridgeContext.DYNAMIC);
rootGN = builder.build(ctx, svgDoc);
} catch (IOException e) {
e.printStackTrace();
}
return svgDoc;
}
It appears to me that the result (especially evident for width) is calculated as if the 1 character is actually 6 characters.
Thank you.
Best regards,
Charles Seelig
Re: Bounding Box accuracy for text containing ISO (Æ) characters
Posted by Charles Seelig <ch...@gmail.com>.
Hello, Thomas.
That does the trick.
Thank you.
Charles
On Mon, Feb 20, 2012 at 7:40 PM, Thomas DeWeese <th...@gmail.com>wrote:
> Hi Charles,
> I'm fairly certain the problem is that you should be giving a Java
> string that has the actual char you want in it already. You shouldn't be
> using XML notation in that string.
>
> Thomas DeWeese
>
>
> On Feb 20, 2012, at 6:01 PM, Charles Seelig <ch...@gmail.com>
> wrote:
>
> Hello, Martin.
>
> Interesting (and freightening!) idea. Freightening because it's a
> dimension of the problem I had not considered :-)
>
> On the other hand, I can report, not as a refutation - but merely as an
> additional observation, that the "fetch BB immediately after setting text"
> technique that I'm using works flawlessly for plain old text. I use the BB
> for subsequent resize-to-fit and centering manipulations, and it never
> fails. It is only this case - where (only a guess) the representation of a
> single character of text requires 6 characters. It is as if the engine is
> using a non-decoded input to perform the text metrics calculation.
>
> I've been wondering if there's some requirement (not met) to assure that
> the ISO encodings are valid. They seem to work to a limited degree - in
> that they are rendered as I expect. It seems to be only the BB metrics that
> are not "getting it."
>
> Anyhow, thank you for spending time thinking about this. Very much
> appreciated.
>
> Charles
>
> On Mon, Feb 20, 2012 at 5:04 PM, Martin J <ja...@gmail.com>wrote:
>
>> Charles,
>>
>> bbox() is indeed tricky! Try doing it on rotated text, or worse, text
>> on a path! However, your problem may only be a timing issue -- Batik
>> only knows the bbox once the text has been rendered, and in your
>> example there's probably not time for the renderer to have done its
>> work when you interrogate the properties.
>>
>> HTH
>> Martin
>>
>> On 20 February 2012 22:16, Charles Seelig <ch...@gmail.com>
>> wrote:
>> > Hello, all.
>> >
>> > I'm wondering if anyone could point me in the right direction re:
>> coaxing
>> > an SVGTextElement to return a correct bounding box when the text
>> contains
>> > ISO encoded characters.
>> >
>> > SVGDocument doc = makeSvgDocument(svgString);
>> >
>> > SVGTextElement svgTextElement = (SVGTextElement)
>> > doc.getElementById("textID");
>> >
>> > svgTextElement.getFirstChild().setNodeValue("ΑΩ");
>> >
>> > float width = svgTextElement.getBBox().getWidth();
>> >
>> >
>> > My document is created as follows -
>> >
>> > protected SVGDocument makeSvgDocument(String svgString) {
>> >
>> > SVGDocument svgDoc = null;
>> >
>> > @SuppressWarnings("unused")
>> >
>> > GraphicsNode rootGN;
>> >
>> > UserAgent userAgent = new UserAgentAdapter();
>> >
>> > DocumentLoader loader = new DocumentLoader(userAgent);
>> >
>> > BridgeContext ctx = new BridgeContext(userAgent, loader);
>> >
>> > GVTBuilder builder = new GVTBuilder();
>> >
>> > SAXSVGDocumentFactory factory = new
>> > SAXSVGDocumentFactory(SAXParser.class.getCanonicalName(), true);
>> >
>> > try {
>> >
>> > svgDoc = (SVGDocument)
>> > factory.createDocument("file:///dummy/dummy/file.svg", new
>> > StringReader(svgString));
>> >
>> > ctx.setDynamicState(BridgeContext.DYNAMIC);
>> >
>> > rootGN = builder.build(ctx, svgDoc);
>> >
>> > } catch (IOException e) {
>> >
>> > e.printStackTrace();
>> >
>> > }
>> >
>> > return svgDoc;
>> >
>> > }
>> >
>> >
>> > It appears to me that the result (especially evident for width) is
>> > calculated as if the 1 character is actually 6 characters.
>> >
>> > Thank you.
>> >
>> > Best regards,
>> >
>> > Charles Seelig
>> >
>>
>>
>>
>> --
>> From my MacBook Pro
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>>
>>
>
Re: Bounding Box accuracy for text containing ISO (Æ) characters
Posted by Thomas DeWeese <th...@gmail.com>.
Hi Charles,
I'm fairly certain the problem is that you should be giving a Java string that has the actual char you want in it already. You shouldn't be using XML notation in that string.
Thomas DeWeese
On Feb 20, 2012, at 6:01 PM, Charles Seelig <ch...@gmail.com> wrote:
> Hello, Martin.
>
> Interesting (and freightening!) idea. Freightening because it's a dimension of the problem I had not considered :-)
>
> On the other hand, I can report, not as a refutation - but merely as an additional observation, that the "fetch BB immediately after setting text" technique that I'm using works flawlessly for plain old text. I use the BB for subsequent resize-to-fit and centering manipulations, and it never fails. It is only this case - where (only a guess) the representation of a single character of text requires 6 characters. It is as if the engine is using a non-decoded input to perform the text metrics calculation.
>
> I've been wondering if there's some requirement (not met) to assure that the ISO encodings are valid. They seem to work to a limited degree - in that they are rendered as I expect. It seems to be only the BB metrics that are not "getting it."
>
> Anyhow, thank you for spending time thinking about this. Very much appreciated.
>
> Charles
>
> On Mon, Feb 20, 2012 at 5:04 PM, Martin J <ja...@gmail.com> wrote:
> Charles,
>
> bbox() is indeed tricky! Try doing it on rotated text, or worse, text
> on a path! However, your problem may only be a timing issue -- Batik
> only knows the bbox once the text has been rendered, and in your
> example there's probably not time for the renderer to have done its
> work when you interrogate the properties.
>
> HTH
> Martin
>
> On 20 February 2012 22:16, Charles Seelig <ch...@gmail.com> wrote:
> > Hello, all.
> >
> > I'm wondering if anyone could point me in the right direction re: coaxing
> > an SVGTextElement to return a correct bounding box when the text contains
> > ISO encoded characters.
> >
> > SVGDocument doc = makeSvgDocument(svgString);
> >
> > SVGTextElement svgTextElement = (SVGTextElement)
> > doc.getElementById("textID");
> >
> > svgTextElement.getFirstChild().setNodeValue("ΑΩ");
> >
> > float width = svgTextElement.getBBox().getWidth();
> >
> >
> > My document is created as follows -
> >
> > protected SVGDocument makeSvgDocument(String svgString) {
> >
> > SVGDocument svgDoc = null;
> >
> > @SuppressWarnings("unused")
> >
> > GraphicsNode rootGN;
> >
> > UserAgent userAgent = new UserAgentAdapter();
> >
> > DocumentLoader loader = new DocumentLoader(userAgent);
> >
> > BridgeContext ctx = new BridgeContext(userAgent, loader);
> >
> > GVTBuilder builder = new GVTBuilder();
> >
> > SAXSVGDocumentFactory factory = new
> > SAXSVGDocumentFactory(SAXParser.class.getCanonicalName(), true);
> >
> > try {
> >
> > svgDoc = (SVGDocument)
> > factory.createDocument("file:///dummy/dummy/file.svg", new
> > StringReader(svgString));
> >
> > ctx.setDynamicState(BridgeContext.DYNAMIC);
> >
> > rootGN = builder.build(ctx, svgDoc);
> >
> > } catch (IOException e) {
> >
> > e.printStackTrace();
> >
> > }
> >
> > return svgDoc;
> >
> > }
> >
> >
> > It appears to me that the result (especially evident for width) is
> > calculated as if the 1 character is actually 6 characters.
> >
> > Thank you.
> >
> > Best regards,
> >
> > Charles Seelig
> >
>
>
>
> --
> From my MacBook Pro
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
Re: Bounding Box accuracy for text containing ISO (Æ) characters
Posted by Charles Seelig <ch...@gmail.com>.
Hello, Martin.
Interesting (and freightening!) idea. Freightening because it's a dimension
of the problem I had not considered :-)
On the other hand, I can report, not as a refutation - but merely as an
additional observation, that the "fetch BB immediately after setting text"
technique that I'm using works flawlessly for plain old text. I use the BB
for subsequent resize-to-fit and centering manipulations, and it never
fails. It is only this case - where (only a guess) the representation of a
single character of text requires 6 characters. It is as if the engine is
using a non-decoded input to perform the text metrics calculation.
I've been wondering if there's some requirement (not met) to assure that
the ISO encodings are valid. They seem to work to a limited degree - in
that they are rendered as I expect. It seems to be only the BB metrics that
are not "getting it."
Anyhow, thank you for spending time thinking about this. Very much
appreciated.
Charles
On Mon, Feb 20, 2012 at 5:04 PM, Martin J <ja...@gmail.com> wrote:
> Charles,
>
> bbox() is indeed tricky! Try doing it on rotated text, or worse, text
> on a path! However, your problem may only be a timing issue -- Batik
> only knows the bbox once the text has been rendered, and in your
> example there's probably not time for the renderer to have done its
> work when you interrogate the properties.
>
> HTH
> Martin
>
> On 20 February 2012 22:16, Charles Seelig <ch...@gmail.com>
> wrote:
> > Hello, all.
> >
> > I'm wondering if anyone could point me in the right direction re: coaxing
> > an SVGTextElement to return a correct bounding box when the text contains
> > ISO encoded characters.
> >
> > SVGDocument doc = makeSvgDocument(svgString);
> >
> > SVGTextElement svgTextElement = (SVGTextElement)
> > doc.getElementById("textID");
> >
> > svgTextElement.getFirstChild().setNodeValue("ΑΩ");
> >
> > float width = svgTextElement.getBBox().getWidth();
> >
> >
> > My document is created as follows -
> >
> > protected SVGDocument makeSvgDocument(String svgString) {
> >
> > SVGDocument svgDoc = null;
> >
> > @SuppressWarnings("unused")
> >
> > GraphicsNode rootGN;
> >
> > UserAgent userAgent = new UserAgentAdapter();
> >
> > DocumentLoader loader = new DocumentLoader(userAgent);
> >
> > BridgeContext ctx = new BridgeContext(userAgent, loader);
> >
> > GVTBuilder builder = new GVTBuilder();
> >
> > SAXSVGDocumentFactory factory = new
> > SAXSVGDocumentFactory(SAXParser.class.getCanonicalName(), true);
> >
> > try {
> >
> > svgDoc = (SVGDocument)
> > factory.createDocument("file:///dummy/dummy/file.svg", new
> > StringReader(svgString));
> >
> > ctx.setDynamicState(BridgeContext.DYNAMIC);
> >
> > rootGN = builder.build(ctx, svgDoc);
> >
> > } catch (IOException e) {
> >
> > e.printStackTrace();
> >
> > }
> >
> > return svgDoc;
> >
> > }
> >
> >
> > It appears to me that the result (especially evident for width) is
> > calculated as if the 1 character is actually 6 characters.
> >
> > Thank you.
> >
> > Best regards,
> >
> > Charles Seelig
> >
>
>
>
> --
> From my MacBook Pro
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
Re: BBox for text on path
Posted by Andrew Rowlands <a....@uq.edu.au>.
Hi again Thomas,
Thanks for the reply. Ahh, this does sound like something that would definitely contribute to the issue.. non-displayed text not contributing to the bbox hadn't actually crossed my mind, but it makes sense.. it was probably pure luck that the combination of certain characters centred on the path caused a slightly different bbox width calc that triggered a resize.
Not to worry, since the other approach works well there's plenty of other things to lose sleep over instead ;)
Cheers,
Andrew
On 08/03/2012, at 10:23 AM, DeWeese Thomas wrote:
> Hi Andrew,
>
> So it's a little hard to say based just on the code, but since it was text on a path, I suspect that the problem is that if text doesn't fit on the path then the text is not displayed so it doesn't count against the bbox. So if the text was too long it might look like it fit because the text that was too long would simply be dropped. In this case you did exactly the right thing using getComputedTextLength.
>
> Does it sound like that might have been your issue?
>
> Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: BBox for text on path
Posted by DeWeese Thomas <th...@gmail.com>.
Hi Andrew,
So it's a little hard to say based just on the code, but since it was text on a path, I suspect that the problem is that if text doesn't fit on the path then the text is not displayed so it doesn't count against the bbox. So if the text was too long it might look like it fit because the text that was too long would simply be dropped. In this case you did exactly the right thing using getComputedTextLength.
Does it sound like that might have been your issue?
Thomas
On Mar 7, 2012, at 6:08 PM, Andrew Rowlands wrote:
> You might remember I mentioned I previously had issues with the bbox when using text on path. The idea was to resize the text so that the entire string would fit along the path such that the bbox would be <= a certain width.
>
> Basically, the kind of approach I was taking was as below (no canvas, running as servlet under Tomcat). For certain strings though, bbox didn't seem to calculate the bbox correctly.
>
> In the end I used getComputedTextLength() instead which worked out great.. but I really would be interested to know any ideas why using bbox didn’t work so well…
> ---
> String parser = XMLResourceDescriptor.getXMLParserClassName();
> SAXSVGDocumentFactory factory = new SAXSVGDocumentFactory(parser);
> curDocument = factory.createSVGDocument(
> new File(svgFileName).toURL().toString());
>
> UserAgent userAgent = new UserAgentAdapter();
> DocumentLoader loader = new DocumentLoader(userAgent);
> BridgeContext ctx = new BridgeContext(userAgent, loader);
> ctx.setDynamicState(BridgeContext.DYNAMIC);
> GVTBuilder builder = new GVTBuilder();
> builder.build(ctx, curDocument);
>
> // Text element to update
> Element elem = curDocument.getElementById("text_element");
> Node n = elem.getFirstChild();
> Text text;
>
> // There is a textPath that wraps the text
> text = (Text) n.getFirstChild();
> text.setNodeValue("a b c d e f g h i j k l m n");
>
> // Resize text
> this.resizeTextSizeToFit("text_element");
>
> // The SVG was then saved using the transcoder
> // ...
>
> // Resize function:
> public void resizeTextSizeToFit(String elemID) {
>
> Element elem = curDocument.getElementById(elemID);
> if (elem == null) {
> return;
> }
>
> SVGLocatable elemLocatable = (SVGLocatable) curDocument.getElementById(elemID);
> float currentFontSize;
>
> SVGRect bbox = elemLocatable.getBBox();
> float width = bbox.getWidth();
>
> System.out.println("Original width: " + Float.toString(width));
>
> if (width >= 430) {
> float currentFontSize = Float.parseFloat(elem.getAttribute("font-size"));
> currentFontSize -= 2;
> elem.setAttributeNS(null, "font-size", Float.toString(currentFontSize));
> this.resizeTextSizeToFit(elemID);
> }
>
> }
>
> ________________________________________
> From: Thomas DeWeese [thomas.deweese@gmail.com]
> Sent: 22 February 2012 10:12
> To: batik-users@xmlgraphics.apache.org
> Cc: batik-users@xmlgraphics.apache.org
> Subject: Re: Bounding Box accuracy for text containing ISO (Æ) characters
>
> The bbox and other APIs in Batik should always return the right value as long as you don't have multiple threads manipulating the tree at the same time.
>
>
BBox for text on path
Posted by Andrew Rowlands <a....@uq.edu.au>.
Hi Thomas,
You might remember I mentioned I previously had issues with the bbox when using text on path. The idea was to resize the text so that the entire string would fit along the path such that the bbox would be <= a certain width.
Basically, the kind of approach I was taking was as below (no canvas, running as servlet under Tomcat). For certain strings though, bbox didn't seem to calculate the bbox correctly.
In the end I used getComputedTextLength() instead which worked out great.. but I really would be interested to know any ideas why using bbox didn't work so well...
Cheers,
Andrew
---
String parser = XMLResourceDescriptor.getXMLParserClassName();
SAXSVGDocumentFactory factory = new SAXSVGDocumentFactory(parser);
curDocument = factory.createSVGDocument(
new File(svgFileName).toURL().toString());
UserAgent userAgent = new UserAgentAdapter();
DocumentLoader loader = new DocumentLoader(userAgent);
BridgeContext ctx = new BridgeContext(userAgent, loader);
ctx.setDynamicState(BridgeContext.DYNAMIC);
GVTBuilder builder = new GVTBuilder();
builder.build(ctx, curDocument);
// Text element to update
Element elem = curDocument.getElementById("text_element");
Node n = elem.getFirstChild();
Text text;
// There is a textPath that wraps the text
text = (Text) n.getFirstChild();
text.setNodeValue("a b c d e f g h i j k l m n");
// Resize text
this.resizeTextSizeToFit("text_element");
// The SVG was then saved using the transcoder
// ...
// Resize function:
public void resizeTextSizeToFit(String elemID) {
Element elem = curDocument.getElementById(elemID);
if (elem == null) {
return;
}
SVGLocatable elemLocatable = (SVGLocatable) curDocument.getElementById(elemID);
float currentFontSize;
SVGRect bbox = elemLocatable.getBBox();
float width = bbox.getWidth();
System.out.println("Original width: " + Float.toString(width));
if (width >= 430) {
float currentFontSize = Float.parseFloat(elem.getAttribute("font-size"));
currentFontSize -= 2;
elem.setAttributeNS(null, "font-size", Float.toString(currentFontSize));
this.resizeTextSizeToFit(elemID);
}
}
________________________________________
From: Thomas DeWeese [thomas.deweese@gmail.com]
Sent: 22 February 2012 10:12
To: batik-users@xmlgraphics.apache.org<ma...@xmlgraphics.apache.org>
Cc: batik-users@xmlgraphics.apache.org<ma...@xmlgraphics.apache.org>
Subject: Re: Bounding Box accuracy for text containing ISO (Æ) characters
The bbox and other APIs in Batik should always return the right value as long as you don't have multiple threads manipulating the tree at the same time.
RE: Bounding Box accuracy for text containing ISO (Æ)
characters
Posted by Andrew Rowlands <a....@uq.edu.au>.
Hi Thomas,
I don't have access to the code I was using at the mo, but next week I'll be sure to pick your brain on this one a bit. I had bbox issues for certain strings and only when on a path, not using canvas. I wrestled with it for some time but never made it work reliably, so would be very interested to learn of a sound way to use bbox with text on path.
Cheers,
Andrew
________________________________________
From: Thomas DeWeese [thomas.deweese@gmail.com]
Sent: 22 February 2012 10:12
To: batik-users@xmlgraphics.apache.org
Cc: batik-users@xmlgraphics.apache.org
Subject: Re: Bounding Box accuracy for text containing ISO (Æ) characters
Hi Charles,
On Feb 20, 2012, at 6:37 PM, Andrew Rowlands <a....@uq.edu.au> wrote:
> FWIW, I thought timing was a problem too with bbox(),
I don't think so. If you are using the canvas you need to be very careful about threading since changing the document during rendering is going to cause problems.
The bbox and other APIs in Batik should always return the right value as long as you don't have multiple threads manipulating the tree at the same time.
> but when I was modifying text nodes (on a path) using UpdateManager and subsequently calling bbox it would fail (reproducibly and in the same way as not using UM)
This probably indicates some misunderstanding in how the update manager works. If you care to explain things a bit more I might be able to help you understand the issue.
Thomas DeWeese
> On 21/02/2012, at 11:04 AM, Martin J wrote:
>
>> Charles,
>>
>> bbox() is indeed tricky! Try doing it on rotated text, or worse, text
>> on a path! However, your problem may only be a timing issue -- Batik
>> only knows the bbox once the text has been rendered, and in your
>> example there's probably not time for the renderer to have done its
>> work when you interrogate the properties.
>>
>> HTH
>> Martin
>>
>> On 20 February 2012 22:16, Charles Seelig <ch...@gmail.com> wrote:
>>> Hello, all.
>>>
>>> I'm wondering if anyone could point me in the right direction re: coaxing
>>> an SVGTextElement to return a correct bounding box when the text contains
>>> ISO encoded characters.
>>>
>>> SVGDocument doc = makeSvgDocument(svgString);
>>>
>>> SVGTextElement svgTextElement = (SVGTextElement)
>>> doc.getElementById("textID");
>>>
>>> svgTextElement.getFirstChild().setNodeValue("ΑΩ");
>>>
>>> float width = svgTextElement.getBBox().getWidth();
>>>
>>>
>>> My document is created as follows -
>>>
>>> protected SVGDocument makeSvgDocument(String svgString) {
>>>
>>> SVGDocument svgDoc = null;
>>>
>>> @SuppressWarnings("unused")
>>>
>>> GraphicsNode rootGN;
>>>
>>> UserAgent userAgent = new UserAgentAdapter();
>>>
>>> DocumentLoader loader = new DocumentLoader(userAgent);
>>>
>>> BridgeContext ctx = new BridgeContext(userAgent, loader);
>>>
>>> GVTBuilder builder = new GVTBuilder();
>>>
>>> SAXSVGDocumentFactory factory = new
>>> SAXSVGDocumentFactory(SAXParser.class.getCanonicalName(), true);
>>>
>>> try {
>>>
>>> svgDoc = (SVGDocument)
>>> factory.createDocument("file:///dummy/dummy/file.svg", new
>>> StringReader(svgString));
>>>
>>> ctx.setDynamicState(BridgeContext.DYNAMIC);
>>>
>>> rootGN = builder.build(ctx, svgDoc);
>>>
>>> } catch (IOException e) {
>>>
>>> e.printStackTrace();
>>>
>>> }
>>>
>>> return svgDoc;
>>>
>>> }
>>>
>>>
>>> It appears to me that the result (especially evident for width) is
>>> calculated as if the 1 character is actually 6 characters.
>>>
>>> Thank you.
>>>
>>> Best regards,
>>>
>>> Charles Seelig
>>>
>>
>>
>>
>> --
>> From my MacBook Pro
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
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: Bounding Box accuracy for text containing ISO (Æ) characters
Posted by Thomas DeWeese <th...@gmail.com>.
Hi Charles,
On Feb 20, 2012, at 6:37 PM, Andrew Rowlands <a....@uq.edu.au> wrote:
> FWIW, I thought timing was a problem too with bbox(),
I don't think so. If you are using the canvas you need to be very careful about threading since changing the document during rendering is going to cause problems.
The bbox and other APIs in Batik should always return the right value as long as you don't have multiple threads manipulating the tree at the same time.
> but when I was modifying text nodes (on a path) using UpdateManager and subsequently calling bbox it would fail (reproducibly and in the same way as not using UM)
This probably indicates some misunderstanding in how the update manager works. If you care to explain things a bit more I might be able to help you understand the issue.
Thomas DeWeese
> On 21/02/2012, at 11:04 AM, Martin J wrote:
>
>> Charles,
>>
>> bbox() is indeed tricky! Try doing it on rotated text, or worse, text
>> on a path! However, your problem may only be a timing issue -- Batik
>> only knows the bbox once the text has been rendered, and in your
>> example there's probably not time for the renderer to have done its
>> work when you interrogate the properties.
>>
>> HTH
>> Martin
>>
>> On 20 February 2012 22:16, Charles Seelig <ch...@gmail.com> wrote:
>>> Hello, all.
>>>
>>> I'm wondering if anyone could point me in the right direction re: coaxing
>>> an SVGTextElement to return a correct bounding box when the text contains
>>> ISO encoded characters.
>>>
>>> SVGDocument doc = makeSvgDocument(svgString);
>>>
>>> SVGTextElement svgTextElement = (SVGTextElement)
>>> doc.getElementById("textID");
>>>
>>> svgTextElement.getFirstChild().setNodeValue("ΑΩ");
>>>
>>> float width = svgTextElement.getBBox().getWidth();
>>>
>>>
>>> My document is created as follows -
>>>
>>> protected SVGDocument makeSvgDocument(String svgString) {
>>>
>>> SVGDocument svgDoc = null;
>>>
>>> @SuppressWarnings("unused")
>>>
>>> GraphicsNode rootGN;
>>>
>>> UserAgent userAgent = new UserAgentAdapter();
>>>
>>> DocumentLoader loader = new DocumentLoader(userAgent);
>>>
>>> BridgeContext ctx = new BridgeContext(userAgent, loader);
>>>
>>> GVTBuilder builder = new GVTBuilder();
>>>
>>> SAXSVGDocumentFactory factory = new
>>> SAXSVGDocumentFactory(SAXParser.class.getCanonicalName(), true);
>>>
>>> try {
>>>
>>> svgDoc = (SVGDocument)
>>> factory.createDocument("file:///dummy/dummy/file.svg", new
>>> StringReader(svgString));
>>>
>>> ctx.setDynamicState(BridgeContext.DYNAMIC);
>>>
>>> rootGN = builder.build(ctx, svgDoc);
>>>
>>> } catch (IOException e) {
>>>
>>> e.printStackTrace();
>>>
>>> }
>>>
>>> return svgDoc;
>>>
>>> }
>>>
>>>
>>> It appears to me that the result (especially evident for width) is
>>> calculated as if the 1 character is actually 6 characters.
>>>
>>> Thank you.
>>>
>>> Best regards,
>>>
>>> Charles Seelig
>>>
>>
>>
>>
>> --
>> From my MacBook Pro
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Bounding Box accuracy for text containing ISO (Æ)
characters
Posted by Andrew Rowlands <a....@uq.edu.au>.
Martin/Charles,
FWIW, I thought timing was a problem too with bbox(), but when I was modifying text nodes (on a path) using UpdateManager and subsequently calling bbox it would fail (reproducibly and in the same way as not using UM) for certain strings.. would be interested to know though Martin if you found an approach that resulted in bbox working reliably?
Cheers,
Andrew
On 21/02/2012, at 11:04 AM, Martin J wrote:
> Charles,
>
> bbox() is indeed tricky! Try doing it on rotated text, or worse, text
> on a path! However, your problem may only be a timing issue -- Batik
> only knows the bbox once the text has been rendered, and in your
> example there's probably not time for the renderer to have done its
> work when you interrogate the properties.
>
> HTH
> Martin
>
> On 20 February 2012 22:16, Charles Seelig <ch...@gmail.com> wrote:
>> Hello, all.
>>
>> I'm wondering if anyone could point me in the right direction re: coaxing
>> an SVGTextElement to return a correct bounding box when the text contains
>> ISO encoded characters.
>>
>> SVGDocument doc = makeSvgDocument(svgString);
>>
>> SVGTextElement svgTextElement = (SVGTextElement)
>> doc.getElementById("textID");
>>
>> svgTextElement.getFirstChild().setNodeValue("ΑΩ");
>>
>> float width = svgTextElement.getBBox().getWidth();
>>
>>
>> My document is created as follows -
>>
>> protected SVGDocument makeSvgDocument(String svgString) {
>>
>> SVGDocument svgDoc = null;
>>
>> @SuppressWarnings("unused")
>>
>> GraphicsNode rootGN;
>>
>> UserAgent userAgent = new UserAgentAdapter();
>>
>> DocumentLoader loader = new DocumentLoader(userAgent);
>>
>> BridgeContext ctx = new BridgeContext(userAgent, loader);
>>
>> GVTBuilder builder = new GVTBuilder();
>>
>> SAXSVGDocumentFactory factory = new
>> SAXSVGDocumentFactory(SAXParser.class.getCanonicalName(), true);
>>
>> try {
>>
>> svgDoc = (SVGDocument)
>> factory.createDocument("file:///dummy/dummy/file.svg", new
>> StringReader(svgString));
>>
>> ctx.setDynamicState(BridgeContext.DYNAMIC);
>>
>> rootGN = builder.build(ctx, svgDoc);
>>
>> } catch (IOException e) {
>>
>> e.printStackTrace();
>>
>> }
>>
>> return svgDoc;
>>
>> }
>>
>>
>> It appears to me that the result (especially evident for width) is
>> calculated as if the 1 character is actually 6 characters.
>>
>> Thank you.
>>
>> Best regards,
>>
>> Charles Seelig
>>
>
>
>
> --
> From my MacBook Pro
>
> ---------------------------------------------------------------------
> 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: Bounding Box accuracy for text containing ISO (Æ) characters
Posted by Martin J <ja...@gmail.com>.
Charles,
bbox() is indeed tricky! Try doing it on rotated text, or worse, text
on a path! However, your problem may only be a timing issue -- Batik
only knows the bbox once the text has been rendered, and in your
example there's probably not time for the renderer to have done its
work when you interrogate the properties.
HTH
Martin
On 20 February 2012 22:16, Charles Seelig <ch...@gmail.com> wrote:
> Hello, all.
>
> I'm wondering if anyone could point me in the right direction re: coaxing
> an SVGTextElement to return a correct bounding box when the text contains
> ISO encoded characters.
>
> SVGDocument doc = makeSvgDocument(svgString);
>
> SVGTextElement svgTextElement = (SVGTextElement)
> doc.getElementById("textID");
>
> svgTextElement.getFirstChild().setNodeValue("ΑΩ");
>
> float width = svgTextElement.getBBox().getWidth();
>
>
> My document is created as follows -
>
> protected SVGDocument makeSvgDocument(String svgString) {
>
> SVGDocument svgDoc = null;
>
> @SuppressWarnings("unused")
>
> GraphicsNode rootGN;
>
> UserAgent userAgent = new UserAgentAdapter();
>
> DocumentLoader loader = new DocumentLoader(userAgent);
>
> BridgeContext ctx = new BridgeContext(userAgent, loader);
>
> GVTBuilder builder = new GVTBuilder();
>
> SAXSVGDocumentFactory factory = new
> SAXSVGDocumentFactory(SAXParser.class.getCanonicalName(), true);
>
> try {
>
> svgDoc = (SVGDocument)
> factory.createDocument("file:///dummy/dummy/file.svg", new
> StringReader(svgString));
>
> ctx.setDynamicState(BridgeContext.DYNAMIC);
>
> rootGN = builder.build(ctx, svgDoc);
>
> } catch (IOException e) {
>
> e.printStackTrace();
>
> }
>
> return svgDoc;
>
> }
>
>
> It appears to me that the result (especially evident for width) is
> calculated as if the 1 character is actually 6 characters.
>
> Thank you.
>
> Best regards,
>
> Charles Seelig
>
--
>From my MacBook Pro
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org