Community
Participate
Working Groups
Build ID: M20070212-1330 Steps To Reproduce: FormText on some machines has problems when it's set with combination of bolded and non-bolded text. a small portion of bolded text seems to be cut off by the non-bolded text right after it. We are using the FormText inside the FormToolkit like the following: FormText engine = new FormText(parent, SWT.WRAP | Window.getDefaultOrientation()); engine.marginWidth = 1; engine.marginHeight = 0; StringBuffer formStr = new StringBuffer("<form><p>"); formStr.append(" xxx ''<b>testing</b>'' yyy"); formStr.append("</p></form>"); rtext.setText(formStr.toString(), true, false); I have compared the areaRectangles (pixel starting point and width) in TextSegment.paint() for each text segment on a working and failing machine. And their numbers are the same. Not sure if this problem goes down to the OS level or not. More information:
Created attachment 72487 [details] Without bolded text looks fine
Created attachment 72488 [details] With bolded text, as it can be seenl, the bolded text is cut off
Moving to UI since that is where forms come from. If it turns out to be an swt issue that is still present in 3.3 then please move the report back, thanks.
I think this may have been reported before, if so will close as a duplicate. It would be good to address this for Eclipse 3.4.
Has the underlying cause of this bug been determined yet? The issue is still apparent in 3.3 under Vista. This issue looks similar to the problems observed with the StyledText in bug 99298.
*** Bug 206037 has been marked as a duplicate of this bug. ***
Created attachment 84571 [details] SWT test case I believe this is an SWT bug. Attached is a simple Java class with a main method. It creates a shell and registers a paint listener on it. In the listener it paints four bolded strings, each on their own line. After the first string, an apostrophe is painted (in a regular font) using the x coordinate of the test string's extent for the x position. You can see that the end of the bolded string is truncated significantly in this case. After the second string, an apostrophe is painted (in bold font this time) using the same logic to position it. The string is still truncated but not as badly. After the third string, nothing is painted and the string is not truncated. After the fourth string, a rectangle is painted using the same positioning logic and the string is not truncated.
Moving back to SWT for investigation. See comment 7 for testcase and details.
Created attachment 86851 [details] screenshot Works for me, see the attachment. I suggested you to change the test case to hardcode the name of the font. It is unlikely, but maybe my system default font is not the same as yours. In my system the bold font is: 1|Tahoma|8.25|1|WINDOWS|1|-11|0|0|0|700|0|0|0|1|0|0|0|0|Tahoma The default system font is: 1|Tahoma|8.25|0|WINDOWS|1|-11|0|0|0|400|0|0|0|1|0|0|0|0|Tahoma
Created attachment 87885 [details] screenshot of failing testcase Strange. My fonts are identical, yet I see the attached screenshot without fail when I run. 1|Tahoma|8.25|0|WINDOWS|1|-11|0|0|0|400|0|0|0|1|0|0|0|0|Tahoma 1|Tahoma|8.25|1|WINDOWS|1|-11|0|0|0|700|0|0|0|1|0|0|0|0|Tahoma
Created attachment 87889 [details] screenshot of failing testcase Oops. I told it my png was a patch.
I have the same issue. I just had a look at bug 175760, and tried to turn off "Cleartype" effect in my Windows' properties : hurrah, it solves the problem! Adam, or others, can you please test that you can also solve the problem disabling ClearType? If so, this bug should be marked as dupe of 175760.
Turning off cleartype does, in fact, solve the problem. Thanks for finding this Benjamin! Closing as duplicate. *** This bug has been marked as a duplicate of bug 175760 ***
Silenio provided a workaround in bug 175760 comment 8. I tried it out in both the testcase I create here (comment 7) and in forms itself and it appears to correct the problem. I plan to fix this for 3.4 after quite a bit more testing.
Created attachment 101367 [details] patch Always drawing strings with transparent backgrounds caused problems with the active/inactive hyperlink colors. After mouseover/mouseout of links they do not paint correctly with transparent backgrounds. To address this, I altered the fix to only use transparent backgrounds for regular TextSegments. TextHyperlinkSegments will still use opaque backgrounds. Since FormText does not allow <a> tags inside <b> tags or vice versa, this should fix the bug in all cases. The only way I can think of to recreate the bug after this fix would be to set the font on a FormText to a bold font and then put inline links. After some preliminary testing of that case, however, I found that the problem did not occur. Either way, the situation should be greatly improved by this fix.
Requesting review for RC2.
Patch applied to HEAD.
