Bug 99298

Comment 1 Florian Priester 2005-06-09 23:37:34 EDT

Created attachment 22777 [details]
Screenshot

(The fonts used in the screenshot are Tahoma, Comic Sans MS, Impact
and Microsoft Sans Serif.)

Comment 2 Felipe Heidrich 2005-06-10 17:34:49 EDT

This the classic problem when using Italic fonts. I suppose mostly editors 
solve this problem by setting a large left and right margin.

Comment 3 Steve Northover 2005-06-10 17:38:09 EDT

Should we set a larger margin in StyledText?

Comment 4 Florian Priester 2005-06-11 06:12:52 EDT

> Should we set a larger margin in StyledText?

There is already a request for providing a configurable margin (bug 56342)
but I would strongly suggest not to include a mandatory non-zero margin.

Apart from the aforementioned problem with italic characters and a few
caret positioning issues (bug 87774), StyledText neatly fits its contents
down to the pixel without any possibly unwanted fluff around them.
Personally, I would hate to see any changes that would make StyledText
visually bigger in general and therefore less suitable to be used as a
compact text editing area that can be embedded in other controls.

Also, you cannot just hardcode the margin to a certain pixel value
because the margin that would be required to produce an appropriate
"safety zone" for rendering italics would depend on the font size.
Right now, you know the font size because the StyledText only has one
but as soon as bug 83405 is fixed, there could be all kinds of different
fonts, set dynamically using StyleRange objects.

My idea on how to the fix the clipping problem would avoid introducing margins
and would instead involve trying to find out the real visual text extent.
If the StyledText widget could somehow calculate or otherwise determine the
actual bounds of the area affected by rendering each glyph (see illustration
in the next comment), it could base the calculation of the visual line length
-and therefore the decision on where to wrap each line- on this value.
Other mechanisms that depend on the position of the glyphs such as
caret positioning, background and selection painting need not be affected
by this and should continue to use the conventional bounds.

This approach seems like the natural solution for the clipped italics
although I'm not sure if it is technically possible. Perhaps Uniscribe,
Pango etc. don't allow for this.

Comment 5 Florian Priester 2005-06-11 06:15:12 EDT

Created attachment 22859 [details]
Illustration

Snippet:

import org.eclipse.swt.*;
import org.eclipse.swt.events.*;
import org.eclipse.swt.graphics.*;
import org.eclipse.swt.widgets.*;

public class ItalicsTest {
  public static void main(String[] args) {
    Display display = new Display();
    Shell shell = new Shell(display);
    
    Font font = new Font(display, "Tahoma", 128, SWT.ITALIC);
    
    final TextLayout textLayout = new TextLayout(display);
    textLayout.setText("?");
    textLayout.setStyle(
      new TextStyle(font, null, display.getSystemColor(SWT.COLOR_WHITE)),
      0,
      0);
    
    shell.addPaintListener(new PaintListener() {
      public void paintControl(PaintEvent e) {
	//e.gc.setClipping(textLayout.getBounds());
	  
	textLayout.draw(e.gc, 0, 0);
      }
    });
    
    shell.setSize(150, 275);
    shell.open();
    
    while (!shell.isDisposed()) {
      if (!display.readAndDispatch()) {
	display.sleep();
      }
    }
    
    textLayout.dispose();
    font      .dispose();
    display   .dispose();
  }
}

---

Related bug: bug 93447

Comment 6 Felipe Heidrich 2009-08-19 12:24:31 EDT

Your bug has been moved to triage, visit http://www.eclipse.org/swt/triage.php for more info.

Comment 7 Eclipse Genie 2019-07-23 17:12:41 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.