Hello, Thomas.
That does the trick.
Thank you.
Charles
On Mon, Feb 20, 2012 at 7:40 PM, Thomas DeWeese <thomas.dewe...@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 <charles.see...@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 <jacobson.mar...@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 <charles.see...@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-unsubscr...@xmlgraphics.apache.org
>> For additional commands, e-mail: batik-users-h...@xmlgraphics.apache.org
>>
>>
>
