Bugzilla – Full Text Bug Listing
| Summary: | Truncation problem in diagrams | ||
|---|---|---|---|
| Product: | [Modeling] GMF-Runtime | Reporter: | Ed Merks <Ed.Merks> |
| Component: | General | Assignee: | Mariot Chauvin <mariot.chauvin> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | blocker | ||
| Priority: | P3 | CC: | aboyko, ahunter.eclipse, andreas.schuster, crevells, dag.rende, dsciamma, eclipse-bugzilla, github, jlescot, laurent.redor, mariot.chauvin, mgobeil, orgler |
| Version: | 2.2 | Flags: | mariot.chauvin:
pmc_approved?
(richard.gronback) mariot.chauvin: review? (ahunter.eclipse) |
| Target Milestone: | 2.3 | ||
| Hardware: | PC | ||
| OS: | Windows All | ||
| Whiteboard: | |||
| Attachments: | |||
|
Description
Ed Merks
Anthony, My suspicion is that this is a GMF runtime or GEF problem. Is it a known issue? Hi, I see this problem on many diagrams since GMF 2.1, so I am pretty sure it comes from GMF Runtime, and I suspect that it is a regression linked to WrappingLabel. Some users on the newsgroup have the same problem. http://dev.eclipse.org/newslists/news.eclipse.modeling.gmf/msg17792.html The bug is only reproducible on windows platform. Created attachment 138147 [details]
Screenshot 1 showing the problem
Created attachment 138148 [details]
Screenshot 2 showing the problem
I figured it was more basic. I picked up the latest from CVS and the problem has gone away, so it must be a duplicate of something. And only one of my Ecore diagrams is messed up now, so that makes me happier too. Well I was positive that this was a known issue that we fixed but I cannot find the Bugzilla. The know issue was with italic fonts. Are you using RC2 drivers? I suspect also a GMF or GEF bug since it can be easily reproduced with the GMF example Ecore editor. Truncation also depends on the Font which is used (I noticed that "Tahoma" produce better results than "Microsoft Sans Serif" one). Also, the longer the text, the worse the truncation. I have tested with the latest RC3 versions (Eclipse + EMF + GEF) (except for GMF, still with RC2 one) I think the fixed one is the bug 111830. The reason comes from SWT bug 5190. I will have a look. Created attachment 138781 [details] patch for head I confirm the bug with the Galileo RC3 modeling package. I reproduced it with at least the following fonts and zoom combination : - Tahoma-10-bold-175% - Sylfaen-10-200% - Roman-10-bold-100% Remarks that its appears depending on the displayed text. I reproduced it quite often with '3' as trailing char. as said in bug bug 5190, the right thing to do is to add a margin around the text. With the provided patch, I was not able to reproduce anymore. (In reply to comment #7) > I suspect also a GMF or GEF bug since it can be easily reproduced with the GMF > example Ecore editor. Cannot be reproduced so easily. I have GMF RC4 on windows and cannot reproduce the issue at 100% zoom. If I zoom to 200% I can see some clipping with some fonts and at 400% I can definitely see some clipping. I tried playing around with one of my product diagrams and could reproduce the issue at 100% CourierNew Bold. The patch does fix this issue and the problem did not occur with GMF 2.1.3. Marc needs to review the patch, but I think I am convinced enough that a regression from GMF 2.1.3 does exist. By the way, is this Windows XP or Windows Vista? It can be reproduced with XP and Vista. I did not test with other Windows version. (In reply to comment #6) > Well I was positive that this was a known issue that we fixed but I cannot find > the Bugzilla. > The know issue was with italic fonts. Anthony might have also been thinking of bug 235549. I did dumped a bunch of analysis into this bug in there. To fix this perfectly, it may be necessary to introduce a new text extents method that takes advanced mode as a parameter. Mariot's patch does fix more cases than the existing code, but blindly adding one character worth of padding to every string we ever measure doesn't address the core issue and may cause problems of its own. 1. there are surely cases where the miscalculation is larger than one character, and it would truncate again 2. all the estimates that were previously correct to the pixel would be unnecessarily padded, causing layout issues. e.g. I would expect centered text to get skewed to the left, right aligned text not to align with other right aligned elements, and auto-fit containers to have unbalanced padding on the right. The core problem appears to be syncing advanced graphics mode to the offscreen GC used to simulate rendering to measure text extents, which Alex and I discussed in 235549 - Prior to 235549, the code assumed non-advanced graphics which truncated frequently - After 235549, the code assumed advanced graphics which truncated less frequently (and was exactly correct for text that was rendered in advanced mode) - passing in advanced mode to measure correctly would probably require a new function signature, and code sweep to use it (any other ideas?) - using TrueType fonts is a good workaround I guess the bottom line here is whether we want to make this change of adding one character worth of padding to every block of text we ever measure. Some clients may already be adding their own padding. TextUtilities in GEF, and TextUtilitiesEx in GMF each have their own "offline" GC to measure a string's extents in pixels, outside of the paint method where the "real" GC actually used to render the text would be available. Methods such as Label.getMinimumSize() use it before the paint method is called, preventing us from caching the information ahead of time when we have the real GC. To produce an accurate measurement, all parameters that affect text size need to be synchronized between the offline and real GC's. The offline GC was originally set up under the assumption font was the only such parameter, and conveniently enough it's stored in the root Figure class, so it can always be passed into the measurement function from getFont(). My investigation of the first truncation bugzilla 235549 revealed that the advanced mode of the GC was also a major factor, and investigating it again for this bug I see that antialias mode would affect it as well when in advanced mode. Syncing these parameters between the real and offline GC's is not simple because they aren't stored in Figure, they are usually inherited from the call chain of paintFigure() methods. To complicate things further, the same figure is often drawn in multiple modes simultaneously (antialiasing on for the canvas, and off for the outline view). The patch to bugzilla 235549 changed GMF diagrams' offline GC assumption from a non-advanced mode to advanced mode, which made it more likely to match the real GC's state. True synchronization is the ultimate solution, but appears virtually impossible to implement. Note: After that patch, the probability of error is minimal for TrueType fonts. Solutions I've considered and thrown out: - flip the order of getMinimumSize() and paintFigure() by returning a default minimum size the first time, calculating and caching the proper values in paintFigure(), then re-running layout (huge job, probably cause visual glitches, and a big performance hit) - change measurement functions to accept additional GC state parameters (callers don't have the data to pass in, and would have a hard time getting their hands on it, if at all, since they'd have to search up the ownership chain they shouldn't have any knowledge of) So, I'm resolving this one as a WONTFIX with the suggestion clients stick to TrueType fonts. *** Bug 284718 has been marked as a duplicate of this bug. *** The problem is still there, even when using true type fonts on windows xp systems. (https://bugs.eclipse.org/bugs/show_bug.cgi?id=284718). I've installed the current GMF version 2.2 *** Bug 291029 has been marked as a duplicate of this bug. *** I reopen this bug because Andreas said that the proposed workaround does not work. Andreas could you provide more information such as the true type font you use, the font size, the zoom level, and a screenshot. Thanks. Created attachment 148530 [details]
GMF diagram screenshot - editing label
Created attachment 148531 [details]
GMF diagram screenshot - truncated label
Font type: Tahoma, Font size: 9, Zoom: 100%
By the way. I'm not the only one in my company that can reproduce this bug. My colleagues are working on different windows systems, and most of them can reproduce this behavior. I'm normally working on linux. Linux doesn't have this problem. (In reply to comment #23) > By the way. I'm not the only one in my company that can reproduce this bug. My > colleagues are working on different windows systems, and most of them can > reproduce this behavior. I'm normally working on linux. Linux doesn't have this > problem. Andreas, Thanks for providing such infos. May I asked you to test the provided patch. If it works, it might be a temporary solution for you, but read carefully comment 14 to see patch drawbacks and why it was not applied. You should have install GMF SDK. Then select "File" -> "Import" -> "Plug-ins and Fragments" -> In "Import as" select "Project with source folder" -> Choose "org.eclipse.gmf.runtime.draw2d.ui". In the created project, patch TextUtilitiesEx class. After that, just do a right-click and select "Run as eclipse application". (In reply to comment #24) > Thanks for providing such infos. May I asked you to test the provided patch. > If it works, it might be a temporary solution for you, but read carefully > comment 14 to see patch drawbacks and why it was not applied. I've already tried this patch, with the impact described in comment 14. So this is not a solution for me. The only possibility I've found to avoid truncation is to get a non-advanced GC Object, in TextUtilitiesEx#getStringExtents(). I can't reproduce this problem and it seems odd to me that I have been fixing bugs the last couple weeks with font cut-off issues and I didn't come across this. However, I am not using a generated GMF diagram, so maybe that is the issue. Has anyone reproduced this issue in a non-generated GMF diagram? Andreas, can you reproduce this problem in a GMF Example ECore Diagram (I tried using this diagram, but couldn't) or any other GMF Example diagrams? We need reproducible steps in a GMF Example diagram. Created attachment 148614 [details]
gmf diagram screenshots with truncated labels
Here is another collection of screenshots, made from different diagram types.
It's really hard to find out reproducible steps, because there is just no scheme to get truncated labels. The labels are suddenly truncated when I work with GMF diagrams.
I made the following to get these screenshots:
1. start the workbench with a clean workspace
2. create an empty project
3. create an *.ecorediag diagram containing EClasses, EAttributes and EOperations -> everthing looks fine
4. create an *.ecore_diagram from the *.ecore model -> everything looks fine
5. create a self-made gmf diagram and create shapes and nodes -> everything looks fine.
6. close the diagram an open it -> everything looks fine
7. restart the workbench with the created diagrams -> everything looks fine
8. create a new node in the self-made gmf diagram -> the new label is truncated, the other labels are ok
9. reopen the *.ecorediag and *.ecore_diagram -> all labels are truncated
10. create a new UML2 tools class diagram containing a new class -> the label is truncated
...
*** Bug 288745 has been marked as a duplicate of this bug. *** I have this problem in a pure GEF application. It happens when I: - use a TextFlow to draw text - use font calibri 10 - use many characters that are wide in a proportional font , like w - use zoom to more than 100% - like 150% or more If I dont set the font at all, then there is no problem. Maybe the TextFlow just calculates widths for another font than the font I have set. (In reply to comment #15) > I guess the bottom line here is whether we want to make this change of adding > one character worth of padding to every block of text we ever measure. > > Some clients may already be adding their own padding. We have enough complaints to proceed with this fix. Mariot and Alex, I think we should try to apply Mariot's patch and test. Agree? (In reply to comment #30) > (In reply to comment #15) > > I guess the bottom line here is whether we want to make this change of adding > > one character worth of padding to every block of text we ever measure. > > > > Some clients may already be adding their own padding. > > We have enough complaints to proceed with this fix. > > Mariot and Alex, I think we should try to apply Mariot's patch and test. > > Agree? I read all comments again and related bug and I think we should apply the patch : - As said in bug 5190, if we want to measure text size with GC.textExtent or GC.stringExtent we MUST add a margin. It explains why one could reproduce the problem without GMF, or in prior version of GMF (2.0 and even on other system than win, see attached files). - Since GMF 2.1, this issue is increased due to synchronization problem between the offline and real GC (See bug 235549 and comment 14). Resolving cleany this problem seems quite difficult. - Layout issues for alignement does not seems to a me a real problem. I think that adding a demi-character margin will be almost invisible for the end user. On the other side a truncated label is highly noteworthy. - There is no clear workaround for adopters. Created attachment 168745 [details]
Screenshot showing truncated label on GMF 2.0 on windows
Created attachment 168747 [details]
Screenshot showing truncated label on GMF 2.0 on linux
This is already fixed with bug 235549. I enabled the GDI+ for the off-screen GC. Problems faced in GMF 2.1 with that fix were related to Text cell editors, SWT Txt widget paints the text with GDI. SWT had an issue with the sie of the string and text with GDI an GDI+, namely a large difference in size. SWT team has addressed these poblems in 3.5. and 3.6: https://bugs.eclipse.org/bugs/show_bug.cgi?id=95410 https://bugs.eclipse.org/bugs/show_bug.cgi?id=289244 Now if I enable advanced graphics for the off-screen GC in GMF TextUtilitiesEx, the cell editor behaves much better and of course the labels on the diagrams are all showing correctly. I can only see a problem with the text cell editor when a font cannot be rendered with GDIP and a system default font is used instead, like with "Modern" font. In this case however, the string in the cell editor is shorter than the displayed string, so it shows up entirely. There are 2 options: 1) Enable advanced graphics in GMF's TextUtilitiesEx - will satisfy almost all the fonts with the current SWT 2) Draw text always with GDI (i.e. advanced graphics is off). This will probably work with almost all fonts if not all. The penalty, though, is that shape's preferred size may change, like for "Modern" font, which may screw up clients diagram layout. Option 1) was the fix to Bug 235549. The fix for 235549 isessentially the fix for this one. [target cleanup] 2.3 RC was the original target milestone for this bug [GMF Restructure] Bug 319140 : product GMF and component Runtime was the original product and component for this bug (In reply to comment #34) > This is already fixed with bug 235549. > > [snip] Marking this resolved then. Hi, I reproduce the problem with a zoom at 400%. Is it a known limitation (as Mark Gobeil says in comment #14)? Or is it a new problem? Regards, Laurent Environment : * Eclipse 3.7 (eclipse-modeling-indigo-SR2-win32) * Graphical Modeling Framework (GMF) Runtime SDK - 1.5.0.v20110607-1200-67N09E9QnChoWswz-3wf_rz0kQ8Y. * Geoshape diagram * Default font of Windows XP (Tahoma - 9) Created attachment 211582 [details]
Diagram shape without problem (zoom 100%)
Created attachment 211583 [details]
Diagram shape with problem (zoom 400%)
|