AW: W: AW: Keep-together.within-page in FOP 0.95

2009-01-25 Thread Georg Datterl
Hi Vincent,

Thanks for the answer. Luckily this problem solved itself, because the breaking 
rules I need to implement are simpler than they seemed at first.

Regards,
 
Georg Datterl
 
-- Kontakt --
 
Georg Datterl
 
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
 
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert 

Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
 
www.geneon.de
 
Weitere Mitglieder der Willmy MediaGroup:
 
IRS Integrated Realization Services GmbH:www.irs-nbg.de 
Willmy PrintMedia GmbH:www.willmy.de
Willmy Consult  Content GmbH: www.willmycc.de 
-Ursprüngliche Nachricht-
Von: Vincent Hennebert [mailto:vhenneb...@gmail.com] 
Gesendet: Freitag, 23. Januar 2009 17:16
An: fop-users@xmlgraphics.apache.org
Betreff: Re: W: AW: Keep-together.within-page in FOP 0.95

Hi Georg,


Georg Datterl wrote:
 Hi Jeremias,
 
 I finally came around to testing your keep-together with numbers and it did 
 not quite work as I did not expect anyway.
 
 Let's assume I have one block with five child blocks. If all five blocks fit 
 on one page, keep them on one page. Otherwise break between block 3 and 4. If 
 any block alone is too big for one page, break it where necessary.
 
 block keep-together.within-page=1 
   block keep-together.within-page=3 (block 1 content)/block
   block keep-together.within-page=3 (block 2 content)/block
   block keep-together.within-page=2 (block 3 content)/block
   block keep-together.within-page=3 (block 4 content)/block
   block keep-together.within-page=3 (block 5 content)/block 
 /block
 
 should that work? do I need more wrapping blocks like maybe one block around 
 blocks 1-3 and one around 4 and 5? 

I think so. Something like this:
block keep-together.within-page=1
  block keep-together.within-page=2
block keep-together.within-page=3(block 1 content)/block
block keep-together.within-page=3(block 2 content)/block
block keep-together.within-page=3(block 3 content)/block
  /block
  block keep-together.within-page=2
block keep-together.within-page=3(block 4 content)/block
block keep-together.within-page=3(block 5 content)/block
  /block
/block

However this is all theoretical, since FOP currently handles all integer values 
the same way; that is, set a very high penalty for breaking inside the block, 
but not forbid it completely. The idea is to encourage the algorithm to favour 
layouts without breaks over those with breaks.
While this might not always be the case, the hope is that this is what will 
happen for most real-life documents.

To achieve what you need integer keeps would have to be fully implemented. I 
don't think there is any solution other than that, unfortunately.


 Regards,
  
 Georg Datterl

HTH,
Vincent

-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org


-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org



AW: AW: W: AW: Keep-together.within-page in FOP 0.95

2009-01-21 Thread Georg Datterl
Hi Jeremias,

I finally came around to testing your keep-together with numbers and it did not 
quite work as I did not expect anyway.

Let's assume I have one block with five child blocks. If all five blocks fit on 
one page, keep them on one page. Otherwise break between block 3 and 4. If any 
block alone is too big for one page, break it where necessary.

block keep-together.within-page=1 
block keep-together.within-page=3 (block 1 content)/block
block keep-together.within-page=3 (block 2 content)/block
block keep-together.within-page=2 (block 3 content)/block
block keep-together.within-page=3 (block 4 content)/block
block keep-together.within-page=3 (block 5 content)/block
/block

should that work? do I need more wrapping blocks like maybe one block around 
blocks 1-3 and one around 4 and 5? 

Regards,
 
Georg Datterl
 
-- Kontakt --
 
Georg Datterl
 
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
 
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert 

Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
 
www.geneon.de
 
Weitere Mitglieder der Willmy MediaGroup:
 
IRS Integrated Realization Services GmbH:www.irs-nbg.de 
Willmy PrintMedia GmbH:www.willmy.de
Willmy Consult  Content GmbH: www.willmycc.de 

-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org



AW: W: AW: Keep-together.within-page in FOP 0.95

2008-12-18 Thread Georg Datterl
Hi Jeremias,  

I'll try that next year. I have quite a complicated table who should be kept 
together except if it spans more than a page. Speaking of tables:
Given a table with two rows, two columns, cell in first column spans both rows, 
is there a way to tell FOP: If there's a break between this two rows, repeat 
the content of the split cell on next pages? 

I read the specification, but I did not quite understand it. Always means 
never break and auto means break, wenever you feel like it. But numbers 
would mean, a keep or break can influence other keeps or breaks. I can see a 
keep-with-next clash with a break-before or the other way round or a keep on a 
block clash with a break on a sub-block, but which strength does a break 
because end of page/column/line is reached have? Or a break because otherwise 
it would not fit the page?

Everything very complicated...

Regards,
 
Georg Datterl
 
-- Kontakt --
 
Georg Datterl
 
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
 
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert 

Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
 
www.geneon.de
 
Weitere Mitglieder der Willmy MediaGroup:
 
IRS Integrated Realization Services GmbH:www.irs-nbg.de 
Willmy PrintMedia GmbH:www.willmy.de
Willmy Consult  Content GmbH: www.willmycc.de 
-Ursprüngliche Nachricht-
Von: Jeremias Maerki [mailto:d...@jeremias-maerki.ch] 
Gesendet: Donnerstag, 18. Dezember 2008 12:43
An: fop-users@xmlgraphics.apache.org
Betreff: Re: W: AW: Keep-together.within-page in FOP 0.95

On 18.12.2008 12:10:27 Georg Datterl wrote:
 Hi Jeremias,
 
  block keep-together.within-column=1  blockI use 30% 
  height/block  blockI use 30% height/block  blockI use 50% 
  height/block /block In this case, the 50% block is moved to the 
  next page if the layout engine doesn't find a better solution, for 
  example by keeping the first block on the previous page and keeping 
  the latter two together. (all assuming those nested blocks are 
  unbreakable for example by carrying a
  keep-together.within-column=always)
 
 So, without a keep-together.within-column, the sequence would be:
 most preferable break: after third block. (impossible, since 110%) 
 less preferable: after second block. (possible, if blocks before take 
 = 40%) even less preferable: after first block. (possible, if blocks 
 before take 41% to 70%) even less preferable: before first block. 
 (possible, if blocks before take 71% )

It's difficult to say exactly that as this also depends on the surrounding 
content if any. A break before the first block will never happen if the content 
above is the only content in the document.

 = Meaning: fit as much as possible on the previous page

More or less, yes.

 So, with keep-together.within-column=1, the sequence would be (from your 
 description):
 most preferable break: after third block. (impossible, since 110%) 
 less preferable: after first block. (possible, if blocks before take 
 = 70%) even less preferable: after second block. ( would only happen 
 if block2+block3 would use more than 100% and blocks before block1 
 would take =40%) even less preferable: before first block. (possible, 
 if blocks before take 71% )

Hmmm. At least what you can say is that the most preferable break is after the 
third block. Whether then the break possibility after the first or second block 
is more preferable depends on the surrounding content.

 I don't understand why. 

I hope the above clears that up a bit. However, if you want an exact 
description of how this works I have to give you a pointer into the
spec:
http://www.w3.org/TR/xsl11/#keepbreak
That explains everything though maybe in a very technical way and without 
examples.

 Of course my example was buggy, I meant: keep-with-next, not keep-together. 

:-)

 What I was trying to say is: keep-with-next if in any way possible.
 Separate from next ONLY if both blocks together would never ever fit 
 on a page, since they take more than 100%.
 
 block I use 30% height/block
 block keep-with-next=1 I use 30% height /block

I don't really like the use of the shorthand. That can lead to nasty 
side-effects, especially with keep-together.

 blockI use 50% height/block
 
 would break before the second block, but

Yes.

 block I use 30% height/block
 block keep-with-next=1 I use 30% height /block blockI use 80% 
 height/block
 
 would break after the second block. 

Yes.

snip/



Jeremias Maerki


-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org


-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org



Re: AW: W: AW: Keep-together.within-page in FOP 0.95

2008-12-18 Thread Jeremias Maerki
On 18.12.2008 13:17:17 Georg Datterl wrote:
 Hi Jeremias,  
 
 I'll try that next year. I have quite a complicated table who should be
 kept together except if it spans more than a page. Speaking of tables:
 Given a table with two rows, two columns, cell in first column spans
 both rows, is there a way to tell FOP: If there's a break between this
 two rows, repeat the content of the split cell on next pages? 

No.

 I read the specification, but I did not quite understand it. Always
 means never break and auto means break, wenever you feel like it.
 But numbers would mean, a keep or break can influence other keeps or
 breaks. I can see a keep-with-next clash with a break-before or the
 other way round or a keep on a block clash with a break on a sub-block,
 but which strength does a break because end of page/column/line is
 reached have?

A break is always stronger than any keep.

 Or a break because otherwise it would not fit the page?

That's basically what the integer values allow.

 Everything very complicated...

Yeah, there you see what we have to build here.

 Regards,
  
 Georg Datterl
  
 -- Kontakt --
  
 Georg Datterl
  
 Geneon media solutions gmbh
 Gutenstetter Straße 8a
 90449 Nürnberg
  
 HRB Nürnberg: 17193
 Geschäftsführer: Yong-Harry Steiert 
 
 Tel.: 0911/36 78 88 - 26
 Fax: 0911/36 78 88 - 20
  
 www.geneon.de
  
 Weitere Mitglieder der Willmy MediaGroup:
  
 IRS Integrated Realization Services GmbH:www.irs-nbg.de 
 Willmy PrintMedia GmbH:www.willmy.de
 Willmy Consult  Content GmbH: www.willmycc.de 
 -Ursprüngliche Nachricht-
 Von: Jeremias Maerki [mailto:d...@jeremias-maerki.ch] 
 Gesendet: Donnerstag, 18. Dezember 2008 12:43
 An: fop-users@xmlgraphics.apache.org
 Betreff: Re: W: AW: Keep-together.within-page in FOP 0.95
 
 On 18.12.2008 12:10:27 Georg Datterl wrote:
  Hi Jeremias,
  
   block keep-together.within-column=1  blockI use 30% 
   height/block  blockI use 30% height/block  blockI use 50% 
   height/block /block In this case, the 50% block is moved to the 
   next page if the layout engine doesn't find a better solution, for 
   example by keeping the first block on the previous page and keeping 
   the latter two together. (all assuming those nested blocks are 
   unbreakable for example by carrying a
   keep-together.within-column=always)
  
  So, without a keep-together.within-column, the sequence would be:
  most preferable break: after third block. (impossible, since 110%) 
  less preferable: after second block. (possible, if blocks before take 
  = 40%) even less preferable: after first block. (possible, if blocks 
  before take 41% to 70%) even less preferable: before first block. 
  (possible, if blocks before take 71% )
 
 It's difficult to say exactly that as this also depends on the surrounding 
 content if any. A break before the first block will never happen if the 
 content above is the only content in the document.
 
  = Meaning: fit as much as possible on the previous page
 
 More or less, yes.
 
  So, with keep-together.within-column=1, the sequence would be (from your 
  description):
  most preferable break: after third block. (impossible, since 110%) 
  less preferable: after first block. (possible, if blocks before take 
  = 70%) even less preferable: after second block. ( would only happen 
  if block2+block3 would use more than 100% and blocks before block1 
  would take =40%) even less preferable: before first block. (possible, 
  if blocks before take 71% )
 
 Hmmm. At least what you can say is that the most preferable break is after 
 the third block. Whether then the break possibility after the first or second 
 block is more preferable depends on the surrounding content.
 
  I don't understand why. 
 
 I hope the above clears that up a bit. However, if you want an exact 
 description of how this works I have to give you a pointer into the
 spec:
 http://www.w3.org/TR/xsl11/#keepbreak
 That explains everything though maybe in a very technical way and without 
 examples.
 
  Of course my example was buggy, I meant: keep-with-next, not keep-together. 
 
 :-)
 
  What I was trying to say is: keep-with-next if in any way possible.
  Separate from next ONLY if both blocks together would never ever fit 
  on a page, since they take more than 100%.
  
  block I use 30% height/block
  block keep-with-next=1 I use 30% height /block
 
 I don't really like the use of the shorthand. That can lead to nasty 
 side-effects, especially with keep-together.
 
  blockI use 50% height/block
  
  would break before the second block, but
 
 Yes.
 
  block I use 30% height/block
  block keep-with-next=1 I use 30% height /block blockI use 80% 
  height/block
  
  would break after the second block. 
 
 Yes.
 
 snip/
 




Jeremias Maerki


-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail