Bug 160050

Summary: [Text] There should be simple API support for setting intraline spacing in Draw2D text
Product: [Tools] GEF Reporter: Eric Wasserman <ewasserman>
Component: GEF-Legacy Draw2dAssignee: gef-inbox <gef-inbox>
Status: NEW --- QA Contact:
Severity: enhancement    
Priority: P3 CC: nyssen
Version: 3.2.1   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:

Description Eric Wasserman CLA 2006-10-06 12:32:25 EDT
Currently there is no way to set the line spacing for a block of text short of a somewhat elaborate construction that involves subclassing AbstractFlowBorder, TextLayout and TextFragmentBox.
Comment 1 Randy Hudson CLA 2006-10-06 13:52:45 EDT
It seems like FlowBorders are simply broken in the vertical direction (they work horizontally). One solution which is supposed to work, is to simply create an AbstractFlowBorder that implements either getInsets(), or getTop/BottomMargin.

If FlowBorders worked properly, would that make you happy? If so, please change summary of the bug.
Comment 2 Eric Wasserman CLA 2006-10-06 14:16:19 EDT
For my particular needs I would be satisfied if the top and bottom insets returned by FIowBorder.getInsets() affected the interline spacing. However, I was told by Pratik that the current border behavior was by design to mimic the behavior of HTML borders (see news://news.eclipse.org:119/eg3703$3so$1@utils.eclipse.org). I don't particularly like the HTML-like behavior because it is internally inconsistent in that the border only adds horizontal space and not vertical. Further, it leads to rather ugly behavior in practice: borders above the bordered text overwrite the previous line but borders below the bordered line are overwritten by subsequent lines. Finally, and perhaps most troubling, is it does not work like borders on Figures.

I made the linespacing API request because it would make a workaround for me for the odd FlowBorder behavior. However, it does seem like an odd omission for a text-handling API that deals with multi-line blocks of text to not have more direct support for line spacing.

 I am assuming the HTML behavior Pratik followed was something like that demostrated by the following:

<style type="text/css">
<!--
span.bordr { border: 10px solid red; }
-->
</style>
blah babads fasd fasdf asdf asdf asdf sadf asdf asd fasdf asdf asdf asdf asd fasd fasd 
f blah babads fasd fasdf asdf asdf asdf sadf asdf asd fasdf asdf asdf asdf asd fasd fasd 
<span class="bordr">
Border this!
</span>
blah babads fasd fasdf asdf asdf asdf sadf asdf asd fasdf asdf asdf asdf asd fasd fasd 
blah babads fasd fasdf asdf asdf asdf sadf asdf asd fasdf asdf asdf asdf asd fasd fasd 
blah babads fasd fasdf asdf asdf asdf sadf asdf asd fasdf asdf asdf asdf asd fasd fasd 
blah babads fasd fasdf asdf asdf asdf sadf asdf asd fasdf asdf asdf asdf asd fasd fasd 
Comment 3 Randy Hudson CLA 2006-10-06 15:01:50 EDT
Right, I forgot about that part :-). But that doesn't mean we can't support more cases than HTML. We have getTopMargin, and getInsets().top. Do both of these currently have a use? I'm guessing insets.top is where outer, nested borders nest to, and topmargin is some separate value only used for block spacing?

So, do we need to add ascent and descent to FlowBorder?

The other route is to support line spacing in a way that it could be either a fixed amount, or a multiple of the current line's height.

Maybe something like BlockFlow.setLineSpacing(LineSpacing), and the spacer gets the current and previous LineBox to determine the extra pixels needed.
Comment 4 Eclipse Webmaster CLA 2007-07-29 09:20:59 EDT
Changing OS from Mac OS to Mac OS X as per bug 185991
Comment 5 Alexander Nyßen CLA 2010-12-16 15:37:56 EST
This is no os specific issue, thus setting platform to ALL-ALL.