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: AW: page break in table cells
Date Fri, 13 Mar 2009 15:53:07 GMT
Hi Andreas,

Forget I said anything. The difference comes from the printer or acrobat adding 5mm margin
on the paper and then scaling everything down. If I take that into account, the numbers add
up.

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: Georg Datterl [mailto:georg.datterl@geneon.de] 
Gesendet: Freitag, 13. März 2009 15:33
An: fop-users@xmlgraphics.apache.org
Betreff: AW: AW: page break in table cells

Hi Andreas, 

> Assuming nothing exotic with writing-mode or reference-orientation, 
> this would be the "bpd" or "bpda". IIC, the difference between the two 
> is that one takes into account the borders and padding, while the 
> other only refers to the content. I'd have to check an example to say 
> for sure which is which.

Of course it's not as easy as I thought. Would you mind having a look at the attached fo-file?
It contains some stuff I don't think relevant for my problem (but I may be wrong), but the
interesting part are a few blocks labeled L15, L25, L35, R1a5 and R1b5. I gave them a background
color to find them again, but when I generated the area tree and the pdf, the area tree blocks'
bpd and bpda don't fit the mm size of the coloured areas in the pdf. For example, L15 gives
me 88104 millipoint, translated into 31.081133mm, but measuring results in no more than 30mm.
L25 gives 215808 millipoint, translated into 76.13226mm, measured 73mm. Why? 

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: Andreas Delmelle [mailto:andreas.delmelle@telenet.be]
Gesendet: Donnerstag, 12. März 2009 20:01
An: fop-users@xmlgraphics.apache.org
Betreff: Re: AW: page break in table cells

On 12 Mar 2009, at 09:44, Georg Datterl wrote:

> But your solution only makes the first column blocks 5cm longer. If 
> there's more space in the first column, it's not used. And if the 
> second column block + 5cm is longer than page height, the empty block 
> flows to the second page and the text block for the second page is 
> moved to the third page. I'm afraid, that's not dynamical enough for 
> me.

I thought as much...

> In my real live case, I have a table in the right column which can 
> spread over multiple pages. In the left column I have some images 
> which should pe printed on each page, no matter how many pages the 
> table spans. At the moment I generate the table and one set of images, 
> have a look at the area tree and find out, how many pages the table 
> spans. Then I go back to the fo-file and insert image blocks as 
> needed. I guess, I could ask the area tree for the size of the image 
> block and the sizes of the table blocks and then calculate a 
> space-after or padding-after for the  image blocks instead of the page 
> breaks. Does that sound possible and which area tree attribute should 
> I look at to get the realtime height of the blocks?

Definitely sounds possible. Assuming nothing exotic with writing-mode or reference-orientation,
this would be the "bpd" or "bpda". IIC, the difference between the two is that one takes into
account the borders and padding, while the other only refers to the content. I'd have to check
an example to say for sure which is which.

Since the block in the first cell will be broken, you will obviously need to combine the block-progression-dimension
of all three blocks, but that should not pose a problem, I think...

HTH!

Andreas

---------------------------------------------------------------------
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