Wrapping JGoText issue

JGo
1

Hi,
In the case a JGoText belongs to JGoArea and let text wraps to a second line if text is too long ( setWrapping(true) ), there is a problem when I zoom in/out: the wrapping is not the same.
It has two consequences:

  • The text overlapps on the the next text bellow it (if I have a second text line)
  • The text goes outside the JGoArea and then when I move that JGoArea a trace is left behind.
    Have you fixed this issue in a recent releases ?
    Thank you,
    Ali Metref
2

Which versions of JGo and Java and what window system and platform are you using?
Could you give an example? Just the JGoText properties should be enough…

3

JGo 5.0, on JAVA 1.4.2, on Windows XP
I have a list of JGoText, for each one, I set the same properties
( (JGoText)obj ).setMultiline(true);
( (JGoText)obj ).setWrappingWidth(200);
( (JGoText)obj ).setWrapping(true);
Here is an example (I don’t know how to embed the image) with the zooming issue. It is a list where I was forced to put an empty line between the JGoText elements (otherwise it overlapps depending on the zoom).
zoom1:
First process Alpha

Second process Beta

zoom2:
First process
Alpha
Second process Beta

zoom3:
First process Alpha

Second process
Beta

4

I tried to reproduce your situation with JGo 5.03 with Java 1.4.2 on Windows XP SP2, but was unable to exhibit any problem at any scale.
I found that “Second process Beta” would not come anywhere near close to wrapping if the wrapping-width is 200. Could you tell what font family, font size, and alignment you are using?
There were some changes made to text drawing for 5.1, and one minor change for 5.2, so perhaps the case you have has already been addressed.

5

Here more Informations:
font: Tahoma, italic, 9 &nbsp ; ; alignement: JGoText.ALIGN_LEFT

public void zoomIn()
{
double newscale = Math.rint(view.getScale() / 0.9f * 100f) / 100f;
view.setScale(newscale);
}

public void zoomOut()
{
double newscale = Math.rint(view.getScale() * 0.9f * 100f) / 100f;
view.setScale(newscale);
}

6

I’m sorry, but I still can’t reproduce it, using all of the JGoText settings that we have talked about, including the same text strings, with JGo version 5.03 and JRE 1.4.2_12 on WinXP SP2.
I’m also still wondering why there would be any wrapping at all, since with those strings have a measured document width much less than the 200 you specified for the wrapping width.

7

Walter,
How upgrading to JGo 5.2 ?
I specified a 200 wrapping for those long text. Unfortunatelt, I don’t understand why it wraps under the mentionned 200.
Ali

8

I would try upgrading to JGo 5.1 first.
But before you try upgrading, you might want to just create a plain old JGoText object, set all of its properties to be what you are using, and see if you get the same results. Maybe your JGoArea/JGoNode class has overridden JGoArea.layoutChildren to resize the JGoText’s width or wrapping width to a smaller value that you didn’t expect or weren’t aware of. Or maybe there is some other property affecting painting that I didn’t think of.

9

Hi,
I verified the code, there is no overriding in the involved JGoArea.
I downloaded JGo 5.15 evaluation and then tried the JGo.jar, the zooming works perfectly with my list (A JGoArea that contains a list of JGoText. This JGoArea list belongs to a JGoArea node)
Infortunately With this new version 5.15, I encountered a back compatibility problem with an other issue and I must do a lot of testing to be sure that everything else is OK.
Is it possible to upgrade only the JGoText modification? That would solve my zooming problem.
Thank you,
Ali

10

I don’t know if you could just take the new version of JGoText. You might need JGoTextEdit too. I guess you could try it.
What was the compatibility problem you encountered? Alas, the eval kit doesn’t include the full release notes – just the abbreviated version. Here’s part of the full release notes:
If you are upgrading from version 5.03 to version 5.1*:
- CHANGED JGoDocument.isAvoidable to be true for nodes, not just any areas
- CHANGED JGoView.newLink and reLink to call JGoSubgraph.reparentToCommonSubGraph,
to make sure each new and each reconnected link belongs to a JGoSubGraph that may be
a common parent of both ports, or else is a top-level object in a layer.

- DEPRECATED JGoObject.isGrabChildSelection and setGrabChildSelection
- added JGoArea property PickableBackground
- CHANGED JGoArea: GrabChildSelection no longer used; assumed to be true regarding selection
- CHANGED JGoArea: Selectable for areas now really means selectable, as with other JGoObjects
- CHANGED JGoArea: old use of Selectable for JGoAreas now governed by new PickableBackground property
If you called:
setSelectable(false);
setGrabChildSelection(true);
on a JGoArea, do this instead:
setSelectable(true);
setPickableBackground(false);
If you called:
setSelectable(false);
setGrabChildSelection(false);
on a JGoArea, you can simply do:
setSelectable(false);
If you called:
setSelectable(true);
setGrabChildSelection( … either true or false …);
on a JGoArea, you can simply do:
setSelectable(true);
setPickableBackground(true);