xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Georg Datterl" <georg.datt...@geneon.de>
Subject AW: again strange keeps
Date Fri, 04 Dec 2009 16:08:27 GMT
Hi Vincent, 

I'll try your suggestion on Monday. Thanks a lot. 

I do try to simplify my fos, but usually I end up with a simple fo which doesn't show the
problem any longer. But I did not know this values make debugging harder. I'll keep it in
mind for the next problem. 

Regards and have a nice weekend,
 
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:vhennebert@gmail.com] 
Gesendet: Freitag, 4. Dezember 2009 17:03
An: fop-users@xmlgraphics.apache.org
Betreff: Re: again strange keeps

Hi Georg,

Georg Datterl wrote:
> Hi Vincent,
> 
> You explanations sounds quite good, but if I replace the keeps "5" with "always", the
whole block, images and everything, move to the next page. Is that, because that's more "desireable"?


That's because you use keep-with-next.within-page instead of .within-column, and that has
a side-effect on the table algorithm. In
short: .within-column forbids any block-level break whatsoever, whereas .within-page only
forbids page breaks. This is enough for the table algorithm to build a different sequence
of elements, and skip the preferable break after the 'TEST' block. Replace your keep.within-page
with keep.within-column and you get the expected output.


> The present solution with the headre and the final, empty line on the next page is in
any case least desireable, because it looks ugly. Do you see a way to force the images and
two tables on the first page, the third table and image on the second page?
> 
> Regards,
>  
> Georg Datterl

HTH,
Vincent

PS: please, next time, could you try and simplify your FO document to use more 'regular' dimensions?
For example, a padding of 1.5pt instead of 1.417pt, a space-after of 6pt instead of 5.669pt,
etc. That would ease the debugging a lot (provided you can still reproduce your problem, of
course). Thanks :-)


> ------ 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:vhennebert@gmail.com]
> Gesendet: Donnerstag, 3. Dezember 2009 13:24
> An: fop-users@xmlgraphics.apache.org
> Betreff: Re: again strange keeps
> 
> Hi Georg,
> 
> Georg Datterl wrote:
>> Hi everybody, hi Vincent,
>>
>> Attached fo file contains the already well known tables, now for A6 format. In this
case, the right column contains three short tables and one image. Since that's too much for
one page, fop inserts a break before the last line of the third table, overriding a keep-with-next.within-page="5".
Now I would have expected the keep at the red block with the "TEST"-Text, since this block
does not have any keeps, but obviously I'm missing something here. Can somebody help?
> 
> Support for integer keeps is very limited at the moment. A break 
> occurring within an integer keep will simply be given maximum penalty 
> in the hope that breaks at better places (i.e., where keep has been 
> left to
> auto) will be privileged. All integer values result into the same 
> break penalty. In fact, the current implementation supports only 3 
> keep
> values: auto, 'highly desirable', always.
> 
> A break where keep is highly desirable may still be privileged over a 
> break where keep is auto if that leads to a better overall layout; for 
> example, if breaking at auto places would lead to half-empty pages 
> whereas breaking at undesirable places would give full pages. (This is 
> not compliant with the Recommendation, for that matter.)
> 
> In the present case, however, there is something else that comes into
> play: since the two images in the first column must be kept together, they make a big
unbreakable block. Therefore, the table algorithm will put as much content from the second
column as possible to match the height of the first one (the heuristic being that full tables
are more desirable). By doing that, it will skip the acceptable breaks after the TEST blocks,
and will end up with the less acceptable ones inside the inner tables.
> 
> 
>> 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 
> 
> 
> Vincent

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


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


Mime
View raw message