Re: wrap-option property

2005-09-16 Thread Luca Furini

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.

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?

Regards
Luca





Re: wrap-option property

2005-09-16 Thread Jeremias Maerki

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