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.dewe...@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.
>
>
