Re: Space-resolution doesn't work
On Tue, 13 Sep 2005 04:25 pm, Jeremias Maerki wrote: FYI, I'm going to try reimplementing the whole space-resolution part on the block-progression-dimension (to start with) using the inputs from both Luca and Simon and based on my findings I've documented in the Wiki: http://wiki.apache.org/xmlgraphics-fop/SpaceResolution I've started by creating a base class UnresolvedElement (holding a Position instance) from which SpaceElement (holding SpaceProperty) and BorderOrPaddingElement (holding a CondLengthProperty) are derived. We'll see how well this turns out. Looking forward to seeing the result of this as the same/similar problem needs to be solved for the inline-progression-direction. Side note: The LineLayoutManager currently doesn't add the the half-leading trait as space-before/space-after as required by the spec (4.5). This means you won't consider these as part of your space resolution in bpd although they probably should? OTOH, I would prefer no big changes to the whole line/inline layout stuff until my batch of changes accumulated here are in Subversion. snip/ Jeremias Maerki Manuel
Re: Space-resolution doesn't work
FYI, I'm going to try reimplementing the whole space-resolution part on the block-progression-dimension (to start with) using the inputs from both Luca and Simon and based on my findings I've documented in the Wiki: http://wiki.apache.org/xmlgraphics-fop/SpaceResolution I've started by creating a base class UnresolvedElement (holding a Position instance) from which SpaceElement (holding SpaceProperty) and BorderOrPaddingElement (holding a CondLengthProperty) are derived. We'll see how well this turns out. On 09.09.2005 11:07:56 Jeremias Maerki wrote: I think we need to revisit the whole space-resolution story. The current code is fine for only the simplest of cases. If you look at the 4.3.1 Space-resolution Rules in the spec the example given there shows quite clearly IMO that we probably can't just rely on the right combination of Knuth elements to resolved the spaces. Especially rule 3 is quite nasty. I'll start from scratch to come up with a better strategy of implementing these rules. I'll probably start by documenting a few cases in the Wiki and try to develop the right element list for them. After that I'll try to find out who exactly to implement everything. Help is welcome. Jeremias Maerki Jeremias Maerki
Re: Space-resolution doesn't work
On 10.09.2005 21:54:56 Simon Pepping wrote:
On Fri, Sep 09, 2005 at 02:04:08PM +0200, Luca Furini wrote:
Luca Furini wrote:
For example, if we have this LM tree
Outer BlockLM
|
+++
|||
BlockLM 1BlockLM 2BlockLM 3
|
+--+-+
||
BlockLM ABlockLM B
BlockLM1.getNextKnuthElements() would return to the outer BlockLM only the
elements representing its block content, without any space.
In order to decide which elements it has to create, the outer BlockLM
could have some lines like:
(currentChild = BlockLM 1
nextChild = BlockLM 2)
space1 = currentChild.getSpaceAfter();
space2 = nextChild.getSpaceBefore();
if (this.mustKeepTogether()
|| currentChild.mustKeepWithNext() !nextChild.hasBreakBefore()
|| !currentChild.hasBreakAfter() nextChild.mustKeepWithPrevious) {
// there cannot be a break between the two children,
createElementsForSpace(resolve(space1, space2, false, false));
} else {
// there can be a break between the children
createElementsForSpace(resolve(space1, null, false, true),
resolve(null, space2, true, false),
resolve(space1, space2, false, false));
}
This is a good idea.
I agree.
Each LM would invoke this whenever it steps from
one child to another. Only the top level LM would also invoke it for
its before and after edges.
I would think of a different treatment of the spaces (space specifiers):
List spaces = new List(currentChild.getSpacesAfter(),
nextChild.getSpacesBefore());
createElementsForSpaces(spaces);
Good idea, too. I actually wondered how to implement Luca's suggestion
and I ended up subclassing Knuth classes (in my mind for now) to hold
the additional space specifier info, but this is a much cleaner approach
even if a little more objects might be instantiated here. I'll try to
document this on the Wiki once I'm through playing through my examples
so I really understand every aspect of the topic.
createElementsForSpaces would create a single glue and a single
penalty, because all space specifiers in a single block stacking
constraint need to be considered together to calculate the space
value. Resolution and creating elements go together, as a penalty must
be created to reflect the influence of a page break.
I'm not sure about this part, yet. I have some doubts about the rule 1
whose effects are only seen after the page breaking. But I'll find out
while creating my examples.
Jeremias Maerki
Re: Space-resolution doesn't work
On Sun, Sep 11, 2005 at 11:19:38AM +0200, Jeremias Maerki wrote:
On 10.09.2005 21:54:56 Simon Pepping wrote:
On Fri, Sep 09, 2005 at 02:04:08PM +0200, Luca Furini wrote:
Luca Furini wrote:
For example, if we have this LM tree
Outer BlockLM
|
+++
|||
BlockLM 1BlockLM 2BlockLM 3
|
+--+-+
||
BlockLM ABlockLM B
BlockLM1.getNextKnuthElements() would return to the outer BlockLM only
the
elements representing its block content, without any space.
In order to decide which elements it has to create, the outer BlockLM
could have some lines like:
(currentChild = BlockLM 1
nextChild = BlockLM 2)
space1 = currentChild.getSpaceAfter();
space2 = nextChild.getSpaceBefore();
if (this.mustKeepTogether()
|| currentChild.mustKeepWithNext() !nextChild.hasBreakBefore()
|| !currentChild.hasBreakAfter() nextChild.mustKeepWithPrevious) {
// there cannot be a break between the two children,
createElementsForSpace(resolve(space1, space2, false, false));
} else {
// there can be a break between the children
createElementsForSpace(resolve(space1, null, false, true),
resolve(null, space2, true, false),
resolve(space1, space2, false, false));
}
This is a good idea.
I agree.
Each LM would invoke this whenever it steps from
one child to another. Only the top level LM would also invoke it for
its before and after edges.
I would think of a different treatment of the spaces (space specifiers):
List spaces = new List(currentChild.getSpacesAfter(),
nextChild.getSpacesBefore());
createElementsForSpaces(spaces);
Good idea, too. I actually wondered how to implement Luca's suggestion
and I ended up subclassing Knuth classes (in my mind for now) to hold
the additional space specifier info, but this is a much cleaner approach
even if a little more objects might be instantiated here. I'll try to
document this on the Wiki once I'm through playing through my examples
so I really understand every aspect of the topic.
An alternative procedure is this: Let each LM return spaces together
with the Knuth elements in getNextKnuthElements. At a higher level,
the returned list is scanned for consecutive lists of spaces, which
are then resolved. The advantage is that it fits in with the existing
getNextKnuthElements, and the LMs can calculate their spaces when they
are calculating their Knuth elements, like they do now.
Simon
--
Simon Pepping
home page: http://www.leverkruid.nl
Re: Space-resolution doesn't work
I like it! On 11.09.2005 12:10:14 Simon Pepping wrote: snip/ An alternative procedure is this: Let each LM return spaces together with the Knuth elements in getNextKnuthElements. At a higher level, the returned list is scanned for consecutive lists of spaces, which are then resolved. The advantage is that it fits in with the existing getNextKnuthElements, and the LMs can calculate their spaces when they are calculating their Knuth elements, like they do now. Jeremias Maerki
Re: Space-resolution doesn't work
On Fri, Sep 09, 2005 at 02:04:08PM +0200, Luca Furini wrote:
Luca Furini wrote:
For example, if we have this LM tree
Outer BlockLM
|
+++
|||
BlockLM 1BlockLM 2BlockLM 3
|
+--+-+
||
BlockLM ABlockLM B
BlockLM1.getNextKnuthElements() would return to the outer BlockLM only the
elements representing its block content, without any space.
In order to decide which elements it has to create, the outer BlockLM
could have some lines like:
(currentChild = BlockLM 1
nextChild = BlockLM 2)
space1 = currentChild.getSpaceAfter();
space2 = nextChild.getSpaceBefore();
if (this.mustKeepTogether()
|| currentChild.mustKeepWithNext() !nextChild.hasBreakBefore()
|| !currentChild.hasBreakAfter() nextChild.mustKeepWithPrevious) {
// there cannot be a break between the two children,
createElementsForSpace(resolve(space1, space2, false, false));
} else {
// there can be a break between the children
createElementsForSpace(resolve(space1, null, false, true),
resolve(null, space2, true, false),
resolve(space1, space2, false, false));
}
This is a good idea. Each LM would invoke this whenever it steps from
one child to another. Only the top level LM would also invoke it for
its before and after edges.
I would think of a different treatment of the spaces (space specifiers):
List spaces = new List(currentChild.getSpacesAfter(),
nextChild.getSpacesBefore());
createElementsForSpaces(spaces);
createElementsForSpaces would create a single glue and a single
penalty, because all space specifiers in a single block stacking
constraint need to be considered together to calculate the space
value. Resolution and creating elements go together, as a penalty must
be created to reflect the influence of a page break.
Regards, Simon
--
Simon Pepping
home page: http://www.leverkruid.nl
Space-resolution doesn't work
I think we need to revisit the whole space-resolution story. The current code is fine for only the simplest of cases. If you look at the 4.3.1 Space-resolution Rules in the spec the example given there shows quite clearly IMO that we probably can't just rely on the right combination of Knuth elements to resolved the spaces. Especially rule 3 is quite nasty. I'll start from scratch to come up with a better strategy of implementing these rules. I'll probably start by documenting a few cases in the Wiki and try to develop the right element list for them. After that I'll try to find out who exactly to implement everything. Help is welcome. Jeremias Maerki
Re: Space-resolution doesn't work
Jeremias Maerki wrote:
I'll start from scratch to come up with a better strategy of
implementing these rules. I'll probably start by documenting a few cases
in the Wiki and try to develop the right element list for them. After
that I'll try to find out who exactly to implement everything. Help is
welcome.
I think spaces and keeps are quite similar and very connected: in both
cases, the constraints can invole formatting objects that are not at the
same depth in the tree.
So, my idea for handling space resolution is tho have a LM ask its
children about their spaces, and create the necessary elements (while at
the moment each LM creates elements for its own spaces).
For example, if we have this LM tree
Outer BlockLM
|
+++
|||
BlockLM 1BlockLM 2BlockLM 3
|
+--+-+
||
BlockLM ABlockLM B
BlockLM1.getNextKnuthElements() would return to the outer BlockLM only the
elements representing its block content, without any space.
In order to decide which elements it has to create, the outer BlockLM
could have some lines like:
(currentChild = BlockLM 1
nextChild = BlockLM 2)
space1 = currentChild.getSpaceAfter();
space2 = nextChild.getSpaceBefore();
if (this.mustKeepTogether()
|| currentChild.mustKeepWithNext() !nextChild.hasBreakBefore()
|| !currentChild.hasBreakAfter() nextChild.mustKeepWithPrevious) {
// there cannot be a break between the two children,
createElementsForSpace(resolve(space1, space2, false, false));
} else {
// there can be a break between the children
createElementsForSpace(resolve(space1, null, false, true),
resolve(null, space2, true, false),
resolve(space1, space2, false, false));
}
where:
- the method createElementsForSpace() can have a single space parameter
(returning a sequence that has no feasible breaks [1]) or three
different spaces parameters (returing a sequence with a feasible break
[2]);
- resolve takes two spaces and two booleans, signalling if the space will
be at the beginning / end of a page (as this affects the resolved space)
- getSpaceAfter() would be something like
return resolve(this.spaceAfter, lastChild.getSpaceAfter(), false, false);
vice-versa, getSpaceBefore would be
return resolve(this.spaceBefore, firstChild.getSpaceBefore(), false, false);
(a similar mechanism could be used for keeps)
but I'm not sure that adding two spaces at a time would always give the
same result.
Otherwise, we could follow the implementation of keeps, using the
LayoutContext to keep track of the spaces met and not yet converted into
elements.
Regards
Luca
[1] this would be a simple glue element, preceded by a penalty with value
= inf
[2] maybe a sequence glue - penalty - glue - box - PENALTY - glue,
with
glue #1 is the resolved space after block 1 if a break occurs
glue #3 is the resolved space before block 2 if a break occurs
penalty is a feasible break
PENALTY forbids a break
glue #3 is the difference between glue #1 + glue #3 and the resolved
space if there is no break
