Bug 160050 - [Text] There should be simple API support for setting intraline spacing in Draw2D text
Summary: [Text] There should be simple API support for setting intraline spacing in Dr...
Status: NEW
Alias: None
Product: GEF
Classification: Tools
Component: GEF-Legacy Draw2d (show other bugs)
Version: 3.2.1   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: gef-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-06 12:32 EDT by Eric Wasserman CLA
Modified: 2015-01-22 02:38 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.