Gliffy

oom1.xml - A small test case of the problem
oom.xml - The original diagram that was causing problems
oom - A version of the diagram that works when I replace all instances of the offending character

I'm the original user reported this problem. the character is actually Chinese and it basically means "no", so you can imagine it's used in practically every flow chart we have. Since not every one of them is causing the problem, it seems to me that it is this character combined with some other stuff that is causing the problem.

Moving these issues to Confluence Plugin release 1.4 since this is the next version being released.

Exact steps to reproduce:

Environment:
Confluence 2.8.0
GPFC 1.4-RC1

I'm pretty sure any version of Gliffy/Confluence will create this error

• Create a new confluence page
• To the new confluence page, add the attachment oom1.xml (attached to this issue)
• Edit the confluence page and add this gliffy macro:

{gliffy:name=oom1.xml}

• Save the confluence page.

Notice that:

• The Confluence log repeats the following debug line forever:

2008-06-10 19:06:19,099 DEBUG [http-8280-Processor8] [gliffy.core.svg.SVGTextWrapper] wrapText iteration:0

The out of memory error doesn't happen as quickly now because I added the debug code, but the problem is still the same. The counter is stuck at zero.

I tried these steps to reproduce on my Windows machine and still don't get the issue. It never reaches the Debug output and only loops once.
I'm probably not seeing the issue because of the slight difference in the JVM's value of FontMetrics to find character width. I'll continue to look into a fix with the assumption it fails.

I think the issue might not be the character itself, but that we are detecting the width of the text shape containing the character to be Less or exactly the same in width as the character. (This kind of makes sense since it is the "NO" character and its in its own text shape) This was similar to the issue when we saw this problem before. As a test, you could try increasing the width of the text shape in the UI holding all of the solo "No" characters to see if the problem goes away.

If you want, we can pair program this.

You might also consider running Confluence with JDK 1.4.2, as that's what I'm running and I'm able to reproduce the issue.

I tried reproducing the issue on gliffy02: no dice.

I'll contact the original reporter to see if he has more information.

-chris

Ya, pair programming might be a good plan. Let me do some more evaulation of the code first.

I am running Confluence on JDK 1.4.2_13. Also, the Fonts on Windows may be causing a discrepancy.

I've been able to recreate the issue by adding the character to a really thin text shape. Looking into a fix.

added a special check at beginning of loop if no progress is made to attempt to wrap a line of text after first try