Home » Eclipse Projects » GEF » draw2d.text indent strategy
|
| Re: draw2d.text indent strategy [message #159587 is a reply to message #159572] |
Mon, 29 November 2004 17:09   |
Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
(It's great when someone posts a question and has looked at the code!)
Do you want a border/margin around a TextFlow or some other InlineFlow? We
would like to support inline borders maybe in the 3.1 release. Or, do you
want to process TAB characters and advance the LineBox's current X position
to the next "tab stop"?
If you just want a nested block with a border, you should be able to handle
this at the BlockFigure or its layout. Perhaps in setupBlock, the
recommended width should substract insets.getWidth()
"Rob Grzywinski" <rgrzywinski@realityinteractive.com> wrote in message
news:cofdq2$tgq$1@www.eclipse.org...
> It is my desire to add various indenting strategies to a FlowFigure. I
> started off with the standard techniques (i.e. MarginBorder) but it seems
> that IFigure.getInsets() is only accounted for in FlowPage (and not in
> BlockFlow, InlineFlow or TextFlow).
>
> After a bit of research it seems that there are two points during which
> "layout" (as it is needed for indenting) for a TextFlow occurs:
> ParagraphTextLayout.layout (where a line is split into multiple lines as
> necessary) and LineBox.commit (where a line's children are positioned).
> Shrinking the available space that a line has based on getInsets() seems
to
> be trivial in ParagraphTextLayout. The problem comes in when laying out
the
> children fragments (FlowBoxes) in LineBox; LineBox knows nothing about
the
> FlowFigure from which it is derived so it cannot know about any indenting
> strategy (e.g. getInsets()).
>
> I am interested in the following:
> o Is there already work going on for indenting strategies?
> o Am I on the right track (i.e. do the locations that I've identified
> represent the whole of the problem that I am attempting to solve)?
>
> Thanks!
>
> --
> Rob Grzywinski
>
>
|
|
| |
| Re: draw2d.text indent strategy [message #159626 is a reply to message #159595] |
Mon, 29 November 2004 17:56 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
> At this point I am only interested in the presentation (and not any
> interaction).
>
> The goal is to have a programmable strategy for indenting. At this point
we
> certainly can see situations where the first line of a "paragraph"
> (TextFlow) is indented and the remaining are not (which does not lend
itself
> to only a MarginBorder for example). We're also envisioning other
> strategies such as the first line of a flow being left justified and any
new
> lines being indented.
Out of curiousity, what type of editor is this for?
>
> > If you just want a nested block with a border, you should be able to
> > handle
> > this at the BlockFigure or its layout. Perhaps in setupBlock, the
> > recommended width should substract insets.getWidth()
>
> I've poked around a bit at the BlockFlowLayout level and I have gotten
> indenting to work mininally (such as in BlockFlowLayout.layoutLine()
setting
> currentLine.x to Insets.left to start and doing the necessary shrinking of
> the recommended width). But this is only step one.
> I keep running into a wall whenever I attempt to modify setupLine() to
> change the initial 'x' position of a line. It seems that LineBox.commit()
> and contiguousCommit() just aren't designed to do anything but start at
the
> parent's 'x'. Things are just screaming to have a reference to the
> FlowFigure in LineBox so that I can determine any indent offset.
Thoughts?
I think that LineBox and boxes in general need to support "padding" and
"insets". For first line indentation, the LineBox would have left insets >
0. The BlockFlow is creating the LineBoxes, so I don't see why
back-pointers are needed or for LineBox to become anything more than a
struct (ok, with convenience methods). Padding would be space outside of
the content. Sometimes padding will not be additive. For example, if a
block requires 10 pixels below, and the next block requires 20 above, then
just 20 pixels will separate the blocks content areas.
Inline Borders would be special borders with 6 types of "sides": TLBR, and
right-continued, and left-continued.
|
|
| |
| Re: draw2d.text indent strategy [message #159795 is a reply to message #159634] |
Tue, 30 November 2004 16:31 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
> Code. (No, I haven't gone loco =D)
Funny, if you look at our text example in CVS, you'll see that we've modeled
import statements and javadoc regions. I'm just making up test cases, but I
believe code should be edited wysiwyg-style. Instead of typing "{", then
indenting a bunch of lines, then typing "}", why not just select the code
and invoke "block" command. I don't think I should ever have to type or
delete a single TAB. And of course, JavaDoc should be edited as HTML.
Another benefit of using figures would be that "code-folding" could be more
flexible. You could reformat other peoples code as you are viewing it, or
change sorting of members, etc.
>
> > I think that LineBox and boxes in general need to support "padding" and
> > "insets". For first line indentation, the LineBox would have left
insets
> > >
> > 0.
>
> We're on the same page here. I'll tinker and see what develops.
If you would like to contribute to GEF, our goals would be to conform to
CSS2 definitions of boxes, padding, insets, borders, etc.
>
> Are you blue-skying at this point or is this something in the works? I
only
> ask to determine my own level of effort. I'm more than happy to help with
> this but I don't want to noodle through something that's already been
> noodled through.
If you want to track these items and/or contribute, open bugzillas to avoid
both of us working on the same thing. For now there is not a bugzilla open
for inline borders, nor for padding.
>
>
> --
> Rob Grzywinski
>
>
|
|
|
| Re: draw2d.text indent strategy [message #160018 is a reply to message #159626] |
Wed, 01 December 2004 16:28 |
 Rob Grzywinski
Messages: 29
Registered: July 2009 |
Junior Member |
|
|
> I think that LineBox and boxes in general need to support "padding" and
> "insets". For first line indentation, the LineBox would have left insets
> >
> 0. The BlockFlow is creating the LineBoxes, so I don't see why
> back-pointers are needed or for LineBox to become anything more than a
> struct (ok, with convenience methods). Padding would be space outside of
> the content. Sometimes padding will not be additive. For example, if a
> block requires 10 pixels below, and the next block requires 20 above, then
> just 20 pixels will separate the blocks content areas.
I've been trying to noodle my through through what I want and what might
happen with those wants.
What I -really- want is the ability to place a border on a element in a
FlowPage. I want to be able to either place a LineBorder around a word or
series of words or place image decorations on a piece of text via a Border
(this one only makes sense to do on a single word).
This want leads to some interesting implications. If TextFlow supported
borders then what happens when a single TextFlow is broken into two lines?
How is the border split between the two lines? Are there just two borders
(the same Border's paint() is called twice)? This can lead to some
interesting and unexpected results.
So what we really want is some "indivisible unit" that can be added inline
to the flow that supports borders. (This implies that InlineFlow would
throw UnsupportedThingy on setBorder().) BlockFlow seems to fit the
requirements but it would need to be enhanced so that it is less like a
<div> and more like a <span>. To be more precise, a BlockFlow needs to be
enhanced to be either inline or block (ala the CSS "display"). (Yes, I know
your goal is to support CSS2-like functionality. I'm just putting in my bid
for the order of functionality implementation.)
There is already an InlineFlow but this seems to just be a container rather
than a "block flow that is inlined". (If it is decided that BlockFlow won't
be modified to add the inline functionality then there might be an
InlineBlockFlow.)
Having this inlined BlockFlow would allow me to do:
+--------+
Before text | Inline | After text
| Block |
| Flow |
| Text |
+--------+
(please excuse the ASCII art -- you will need fixed width fonts to view
correctly but hopefully the idea is evident regardless)
This is something else that I really -really- want to be able to do. This
obviously brings up questions of alignment and flow issues (i.e. where does
text added after "After text" go? To the left of the box? Below the box?
All of these are already defined by CSS2 so I would follow that.) but that
can wait.
While I was determining the LOE on this inline BlockFlow I cam to a
screeching halt when it comes to supporting Borders on BlockFlows. It seems
that someone was a bit too liberal with the package local "width" and
"height" on FlowBox =D. If TextFlows aren't going to have borders (which I
don't think they should for the reasons pointed out above) then the insets
only need to be incorporated up at the BlockBox level (I don't think that it
makes sense anywhere below that). You would just want to override
BlockBox's getWidth() and getHeight() to include the insets but everyone
pokes their grubby fingers directly into FlowBox's width and height.
I'd like the following:
o Some validation on what I've been rambling about above (specifically
inlined BlockFlow, no borders on TextFlow, and borders on BlockFlow)
o A feel for where implementing this is on the queue so that I know if I
should just wait or dig in. I hesitate to dig in to the whole border thing
given FlowBox's width and height nastiness.
Thanks!
--
Rob Grzywinski
|
|
| |
| Re: draw2d.text indent strategy [message #160049 is a reply to message #160018] |
Wed, 01 December 2004 17:58 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
> What I -really- want is the ability to place a border on a element in a
> FlowPage. I want to be able to either place a LineBorder around a word or
> series of words or place image decorations on a piece of text via a Border
> (this one only makes sense to do on a single word).
>
> This want leads to some interesting implications. If TextFlow supported
> borders then what happens when a single TextFlow is broken into two lines?
> How is the border split between the two lines? Are there just two borders
> (the same Border's paint() is called twice)? This can lead to some
> interesting and unexpected results.
Yes, the border would paint for every one of the figure's fragment. The
modified paint method would contain two booleans indicating whether the left
and right sides are to be closed or open.
> So what we really want is some "indivisible unit" that can be added inline
> to the flow that supports borders. (This implies that InlineFlow would
> throw UnsupportedThingy on setBorder().) BlockFlow seems to fit the
> requirements but it would need to be enhanced so that it is less like a
> <div> and more like a <span>. To be more precise, a BlockFlow needs to be
> enhanced to be either inline or block (ala the CSS "display"). (Yes, I
know
> your goal is to support CSS2-like functionality. I'm just putting in my
bid
> for the order of functionality implementation.)
> There is already an InlineFlow but this seems to just be a container
rather
> than a "block flow that is inlined". (If it is decided that BlockFlow
won't
> be modified to add the inline functionality then there might be an
> InlineBlockFlow.)
>
> Having this inlined BlockFlow would allow me to do:
>
> +--------+
> Before text | Inline | After text
> | Block |
> | Flow |
> | Text |
> +--------+
>
> (please excuse the ASCII art -- you will need fixed width fonts to view
> correctly but hopefully the idea is evident regardless)
That's an interesting idea but how does the inline-block know how wide it is
going to be? Is it based on its content, or is it's width hard-coded, or a
percentage of the line width. This would be easy to implement, if the
requirements were well described,
> This is something else that I really -really- want to be able to do. This
> obviously brings up questions of alignment and flow issues (i.e. where
does
> text added after "After text" go? To the left of the box? Below the box?
> All of these are already defined by CSS2 so I would follow that.) but that
> can wait.
Wrapping around boxes is not going to be addressed any time soon :-)
> While I was determining the LOE on this inline BlockFlow I cam to a
> screeching halt when it comes to supporting Borders on BlockFlows. It
seems
> that someone was a bit too liberal with the package local "width" and
> "height" on FlowBox =D. If TextFlows aren't going to have borders (which
I
> don't think they should for the reasons pointed out above) then the insets
> only need to be incorporated up at the BlockBox level (I don't think that
it
> makes sense anywhere below that). You would just want to override
> BlockBox's getWidth() and getHeight() to include the insets but everyone
> pokes their grubby fingers directly into FlowBox's width and height.
>
> I'd like the following:
> o Some validation on what I've been rambling about above (specifically
> inlined BlockFlow, no borders on TextFlow, and borders on BlockFlow)
> o A feel for where implementing this is on the queue so that I know if I
> should just wait or dig in. I hesitate to dig in to the whole border
thing
> given FlowBox's width and height nastiness.
I don't see any difficulties with the box stuff. I'll start looking into
it.
> Thanks!
>
>
> --
> Rob Grzywinski
>
>
|
|
|
| Re: draw2d.text indent strategy [message #160057 is a reply to message #160049] |
Wed, 01 December 2004 18:46 |
Rob Grzywinski
Messages: 29
Registered: July 2009 |
Junior Member |
|
|
> Yes, the border would paint for every one of the figure's fragment. The
> modified paint method would contain two booleans indicating whether the
> left
> and right sides are to be closed or open.
By the way, with an "underline" border (a Border that only draws along the
bottom), you get "free" underline support for text. So I can certainly say
that borders on TextFlows are a good thing. (This is something that I
didn't consider before.) I have my reservations about the boolean approach
that you've outlined but if it's easy to implement then run with it.
> That's an interesting idea but how does the inline-block know how wide it
> is
> going to be? Is it based on its content, or is it's width hard-coded, or
> a
> percentage of the line width. This would be easy to implement, if the
> requirements were well described,
I outlined this slighly in my other posting but what I envision is using
Figure's getMaximumSize(), getMinimumSize() and getPreferredSize() to
specify the max, min and preferred sizes accordingly. By default the
preferred width is remaining line size (make sure that there is easy access
to this value in the code as it will help with implementing a sane
getMaximumSize() (or maybe you could just use the old override and called
super.getMaximumSize() trick to determine what the max allowed is)). I have
no thoughts on the default preferred height -- just follow the paradigm used
in Figure I suppose. By default the max and min are the preferred. If
someone makes the max larger than the remaining line then they're just SOL
(i.e. it gets cut off) -- this is true both horizontally and vertically.
As I mentioned in my other posting, if one makes the "context.endLine()"
calls in BlockFlowLayout variable based on if the BlockFlow is inline or not
(i.e. call context.endLine() if non-inline otherwise do not). I haven't
seen any other changes that are necessary.
One other requirement that seems to be a must with all of this is making
InlineFlow and by extension TextFlow have the ability to be set to
"non-break" (i.e. any TextFlows in an InlineFlow or the TextFlow itself will
never be broken into fragments). It seems that if ParagraphTextLayout (at
least in the TextFlow case) had a WORD_WRAP_NONE and
FlowUtilities.getTextForSpace() was enhanced to simply return the total
width, then the requirement would be satisfied. (I don't have any thoughts
on how to do with with InlineFlow unfortunately.) It would certainly be
possible for a string to be cut off if it was larger than the allowed width
but this is to be expected. Combining InlineFlows and TextFlows with this
"no wrapping" would provide great flexibility on how lines are wrapped.
> I don't see any difficulties with the box stuff. I'll start looking into
> it.
One concern I have is with getAscent() and getBaseline(). In order to
ensure that text lines up vertically, all baselines (which does not include
any insets) must match. I know this is obvious when you're working on it,
but currently FlowBox's getAscent() returns getHeight(). This is one of the
few places that it should have been "height" =D
As for vertically aligning the inline BlockFlows, (I'm assuming that if text
is aligned on its baseline) the baseline of a BlockFlow will be changed
based on its vertical alignment. One could extend this idea further by
allowing a subclass to override this and allow arbitrary vertical alignment.
--
Rob Grzywinski
|
|
| |
Goto Forum:
Current Time: Fri Dec 27 10:35:46 GMT 2024
Powered by FUDForum. Page generated in 0.04492 seconds |
] 
Search
Help
Register
Login
Home
