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-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: batik-users-h...@xmlgraphics.apache.org
