wrap-option property

[Jeremias Maerki <de...@jeremias-maerki.ch>]

wrap-option is one of those few properties which work in 0.20.5 but are
not yet available in FOP Trunk. Luca, what do you think how difficult it
would be to implement it at least for, let's say, fo:block? I imagine it
would suffice to trick the breaker into not choosing any break
possibilities except at the end of the sequence.

I think we will need something similar in the StaticContentLM and the
BlockContainerLM so overflow can be handled better. At the moment, only
the first part until the first break point found by the breaker is
properly painted. Afterwards, the BCLM simply adds the additional parts
but this can lead to unexpected results as I have seen in one document
already.

Eager to hear your thoughts.

Jeremias Maerki

Re: wrap-option property

[Jeremias Maerki <de...@jeremias-maerki.ch>]

On 16.09.2005 13:09:05 Luca Furini wrote:
> Jeremias Maerki wrote:
> 
> > wrap-option is one of those few properties which work in 0.20.5 but are 
> > not yet available in FOP Trunk. Luca, what do you think how difficult it 
> > would be to implement it at least for, let's say, fo:block? I imagine it 
> > would suffice to trick the breaker into not choosing any break 
> > possibilities except at the end of the sequence.
> 
> Yes, it seems a very good idea: just an additional boolean parameter for 
> findBreakingPoints(), similar to hyphenationAllowed. Or we could use just 
> a single int instead of two booleans: a parameter whose value could be set 
> using three constants, for example ALL_BREAKS, NO_HYPHENATION, NO_WRAP.
> 
> Maybe it could be even easier: a LineBreakPosition could be created 
> without even performing the line breaking algorithm, as we alredy know we 
> will create just a line, an which will be the indexes of the first and 
> last element. But maybe this would prevent us from knowing useful 
> information created by the algorithm (difference, indent, ...).
> 
> I'm going to work on this immediately.

Cool!

I also thought about wrap-option on fo:inline etc. But I'm unsure about
how to interpret. At first, I thought this could be done by handling it
like a keep-together, but the spec text seems to imply that the content
would not be broken in this case but will simply overlap beyond the
boundaries. Shrug.

> > I think we will need something similar in the StaticContentLM and the 
> > BlockContainerLM so overflow can be handled better. At the moment, only 
> > the first part until the first break point found by the breaker is 
> > properly painted. Afterwards, the BCLM simply adds the additional parts 
> > but this can lead to unexpected results as I have seen in one document 
> > already.
> 
> Sorry, I don't quit get what you mean ... what are these unexpected results?

The problem was with a table of which the first cell had a smaller font.
The break point ended up inside a row which was split so that part of it landed
in the second part (the one that actually causes the overflow). With
page breaks that's ok, but in this case it looked like the second cell
was on a different row. Instead of:

|cell1   |CELL2|

I got:

|cell1   |     |
----------------
|        |CELL2|


Jeremias Maerki