Re: Table troubles
On 13.02.2007 13:40:53 Andreas L Delmelle wrote: On Feb 12, 2007, at 23:34, Jeremias Maerki wrote: snip / I'd very much like to agree with your solution/interpretation, but the nit in me feels compelled to ask: 100% of what? XSL 1.1 says for percentages in block-progression-dimension: The percentage is calculated with respect to the corresponding dimension of the closest area ancestor that was generated by a block-level formatting object. If that dimension is not specified explicitly (i.e., it depends on content's block-progression-dimension), the value is interpreted as auto. But that's a weird statement IMO. If the table's parent is a block, the block's height depends on the content's size. Circular dependency. It would make more sense to say: ...of the closest anscestor that is a reference area... Shrug. The Rec in all its glory! :) I wonder what this means for tables that don't have a block-container parent. Note that, since a block's b-p-d can't be specified, that leaves only block-container as a possible and reliable base 'block- level FO that generates the closest area ancestor'. If there is no such block-container, the behavior of percentages would again be undefined. If there's only a parent block, then this would create a circular dependency, as you point out... Besides that, mind that the native XSL property 'block-progression- dimension' does not directly apply to table or table-row. That is, specifying block-progression-dimension=100% on a table or table-row would (and should) not have any effect. Only the CSS-XSL hybrids 'height/min-height/max-height' apply to them. My first reaction was: That's simply not true. b-p-d does apply to table and table-row. The CSS properties are mapped to the XSL equivalents as specified in http://www.w3.org/TR/xsl11/#d0e4413 Our code exclusively works with b-p-d and i-p-d, not height, max-height etc. But as you noticed 7.3 refers to the CSS properties explicitely. IMO that's another point in the spec that is really not helpful. Rather the opposite. I wish the CSS dependency were never introduced Anyway, b-p-d does apply to table and table-row. :-) Now, these being CSS properties in origin, I think that either: a) the first rule in 7.3 applies 1. For properties defined in CSS2 referring to the containing block, the content-rectangle of the closest ancestor block-area that is not a line-area is used. or b), the height property being mapped to XSL's block-progression- dimension (or inline-progression-dimension), the fourth rule applies 4. If the formatting object generating the identified area generates a sequence of such areas, the first area is used for the conversion. I'd put my money on a). Moreover, this is most likely why XSL explicitly refers to CSS in its definition of height, since percentage heights for tables and table-rows in CSS are /not/ defined in terms of a containing block --they are undefined altogether :( I prefer to ignore the CSS stuff and work with the XSL stuff entirely, i.e. map everything to XSL and go from there. Makes my brain hurt a little less. :-) b) seems to make matters even worse. It would again lead to a circular dependency for some tables that are direct descendants of the flow, since that 'first area' could correspond to the first area generated by the table itself... If not, then it could also be an area generated by a completely unrelated block (=first block in the flow) preceding the table...? Big Shrug indeed! Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Table troubles
Vincent Hennebert wrote:
Chris Bowditch a écrit :
Andreas L Delmelle wrote:
snip/
The Rec in all its glory! :)
I wonder what this means for tables that don't have a block-container
parent. Note that, since a block's b-p-d can't be specified, that
leaves only block-container as a possible and reliable base 'block-
level FO that generates the closest area ancestor'. If there is no
such block-container, the behavior of percentages would again be
undefined. If there's only a parent block, then this would create a
circular dependency, as you point out...
I don't think there is a circular dependency:
XSL 1.1 says for percentages in block-progression-dimension:
The percentage is calculated with respect to the corresponding dimension
of the closest area ancestor that was generated by a block-level
formatting object. If that dimension is not specified explicitly i.e.,
it depends on content's block-progression-dimension), the value is
interpreted as auto.
Which I understand as changing the n% value of b-p-d for the current
object to auto. So on Andrea's example:
fo:table-row
fo:table-cell number-columns-spanned={all}
fo:block-container block-progression-dimension.optimum=100%
block-progression-dimension.minimum=0pt
fo:block#xA0;/fo:block
/fo:block-container
/fo:table-cell
/fo:table-row
The height of the fo:block-container is 100% of the height of the
fo:table (the closest ancestor generating a block-area). As for fo:table
the only sensible value is auto, then the height of this very
block-container is changed to auto.
I agree with Vincent's interpretation here. When the spec is unclear,
common sense should prevail. Just saying percentage heights are not
supported unless inside a block-container is not good enough IMHO. And
if a common sense approach can't be agreed upon then an e-mail should be
sent to the editors list requesting clarification.
In the case where fo:table is a child of fo:block or fo:flow isn't the
nearest ancestor reference area the fo:region-body? Whose bpd will be
known.
To be precise, the nearest ancestor is the normal-flow-reference-area in
which the table relies, which has the size of its parent
span-reference-area, whose size generally is the size of the
main-reference-area (unless there are several spans) which generally has
the size of the region-body (unless there are before-floats or
footnotes) (see 6.4.14 fo:region-body). Follow me? ;-)
Yes and I agree.
So yes the bpd should be known, unless there are several spans in which
case we can surely imagine a whole bunch of tricky situations with a mix
of auto and percentages, leaving the bpd undefined...
Thats right, so the only case thats not supported then is percentage
heights on FOs on a page with multiple span areas. I think that is an
acceptable limitation from a user perspective.
snip/
Does anyone else think this discussion should be moved to fop-dev?
Chris
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Table troubles
On Feb 12, 2007, at 23:34, Jeremias Maerki wrote: snip / I'd very much like to agree with your solution/interpretation, but the nit in me feels compelled to ask: 100% of what? XSL 1.1 says for percentages in block-progression-dimension: The percentage is calculated with respect to the corresponding dimension of the closest area ancestor that was generated by a block-level formatting object. If that dimension is not specified explicitly (i.e., it depends on content's block-progression-dimension), the value is interpreted as auto. But that's a weird statement IMO. If the table's parent is a block, the block's height depends on the content's size. Circular dependency. It would make more sense to say: ...of the closest anscestor that is a reference area... Shrug. The Rec in all its glory! :) I wonder what this means for tables that don't have a block-container parent. Note that, since a block's b-p-d can't be specified, that leaves only block-container as a possible and reliable base 'block- level FO that generates the closest area ancestor'. If there is no such block-container, the behavior of percentages would again be undefined. If there's only a parent block, then this would create a circular dependency, as you point out... Besides that, mind that the native XSL property 'block-progression- dimension' does not directly apply to table or table-row. That is, specifying block-progression-dimension=100% on a table or table-row would (and should) not have any effect. Only the CSS-XSL hybrids 'height/min-height/max-height' apply to them. Now, these being CSS properties in origin, I think that either: a) the first rule in 7.3 applies 1. For properties defined in CSS2 referring to the containing block, the content-rectangle of the closest ancestor block-area that is not a line-area is used. or b), the height property being mapped to XSL's block-progression- dimension (or inline-progression-dimension), the fourth rule applies 4. If the formatting object generating the identified area generates a sequence of such areas, the first area is used for the conversion. I'd put my money on a). Moreover, this is most likely why XSL explicitly refers to CSS in its definition of height, since percentage heights for tables and table-rows in CSS are /not/ defined in terms of a containing block --they are undefined altogether :( b) seems to make matters even worse. It would again lead to a circular dependency for some tables that are direct descendants of the flow, since that 'first area' could correspond to the first area generated by the table itself... If not, then it could also be an area generated by a completely unrelated block (=first block in the flow) preceding the table...? Big Shrug indeed! Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Table troubles
Andreas L Delmelle wrote: snip/ The Rec in all its glory! :) I wonder what this means for tables that don't have a block-container parent. Note that, since a block's b-p-d can't be specified, that leaves only block-container as a possible and reliable base 'block- level FO that generates the closest area ancestor'. If there is no such block-container, the behavior of percentages would again be undefined. If there's only a parent block, then this would create a circular dependency, as you point out... In the case where fo:table is a child of fo:block or fo:flow isn't the nearest ancestor reference area the fo:region-body? Whose bpd will be known. Besides that, mind that the native XSL property 'block-progression- dimension' does not directly apply to table or table-row. That is, specifying block-progression-dimension=100% on a table or table-row would (and should) not have any effect. Only the CSS-XSL hybrids 'height/min-height/max-height' apply to them. Now, these being CSS properties in origin, I think that either: a) the first rule in 7.3 applies 1. For properties defined in CSS2 referring to the containing block, the content-rectangle of the closest ancestor block-area that is not a line-area is used. or b), the height property being mapped to XSL's block-progression- dimension (or inline-progression-dimension), the fourth rule applies 4. If the formatting object generating the identified area generates a sequence of such areas, the first area is used for the conversion. I'd put my money on a). Moreover, this is most likely why XSL explicitly refers to CSS in its definition of height, since percentage heights for tables and table-rows in CSS are /not/ defined in terms of a containing block --they are undefined altogether :( b) seems to make matters even worse. It would again lead to a circular dependency for some tables that are direct descendants of the flow, since that 'first area' could correspond to the first area generated by the table itself... If not, then it could also be an area generated by a completely unrelated block (=first block in the flow) preceding the table...? Big Shrug indeed! Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Table troubles
On Feb 13, 2007, at 15:06, Chris Bowditch wrote: Andreas L Delmelle wrote: snip/ The Rec in all its glory! :) I wonder what this means for tables that don't have a block- container parent. Note that, since a block's b-p-d can't be specified, that leaves only block-container as a possible and reliable base 'block- level FO that generates the closest area ancestor'. If there is no such block-container, the behavior of percentages would again be undefined. If there's only a parent block, then this would create a circular dependency, as you point out... In the case where fo:table is a child of fo:block or fo:flow isn't the nearest ancestor reference area the fo:region-body? Whose bpd will be known. Yes, but that's precisely what makes it all so fuzzy... The Recommendation does not refer to the 'nearest ancestor reference area'. Why? I have no idea. In any case, there's only stuff like: - the closest area ancestor generated by a block-level FO - the closest ancestor block-area - the first area in the sequence of areas generated by... All in all, I'd say it boils down to: don't use percentages for table or table-row height (or table-cell, for that matter). Peculiar is that the behavior for percentages on fixed-positioned block-containers is explicitly defined in terms of references to the nearest ancestor viewport area. OTOH, if I remember correctly, block- containers aren't supposed to appear broken over multiple pages (if the content is too large to fit, treat the excess content according to the overflow property). Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Table troubles
Chris Bowditch a écrit :
Andreas L Delmelle wrote:
snip/
The Rec in all its glory! :)
I wonder what this means for tables that don't have a block-container
parent. Note that, since a block's b-p-d can't be specified, that
leaves only block-container as a possible and reliable base 'block-
level FO that generates the closest area ancestor'. If there is no
such block-container, the behavior of percentages would again be
undefined. If there's only a parent block, then this would create a
circular dependency, as you point out...
I don't think there is a circular dependency:
XSL 1.1 says for percentages in block-progression-dimension:
The percentage is calculated with respect to the corresponding dimension
of the closest area ancestor that was generated by a block-level
formatting object. If that dimension is not specified explicitly i.e.,
it depends on content's block-progression-dimension), the value is
interpreted as auto.
Which I understand as changing the n% value of b-p-d for the current
object to auto. So on Andrea's example:
fo:table-row
fo:table-cell number-columns-spanned={all}
fo:block-container block-progression-dimension.optimum=100%
block-progression-dimension.minimum=0pt
fo:block#xA0;/fo:block
/fo:block-container
/fo:table-cell
/fo:table-row
The height of the fo:block-container is 100% of the height of the
fo:table (the closest ancestor generating a block-area). As for fo:table
the only sensible value is auto, then the height of this very
block-container is changed to auto.
In the case where fo:table is a child of fo:block or fo:flow isn't the
nearest ancestor reference area the fo:region-body? Whose bpd will be
known.
To be precise, the nearest ancestor is the normal-flow-reference-area in
which the table relies, which has the size of its parent
span-reference-area, whose size generally is the size of the
main-reference-area (unless there are several spans) which generally has
the size of the region-body (unless there are before-floats or
footnotes) (see 6.4.14 fo:region-body). Follow me? ;-)
So yes the bpd should be known, unless there are several spans in which
case we can surely imagine a whole bunch of tricky situations with a mix
of auto and percentages, leaving the bpd undefined...
Besides that, mind that the native XSL property 'block-progression-
dimension' does not directly apply to table or table-row. That is,
specifying block-progression-dimension=100% on a table or table-row
would (and should) not have any effect. Only the CSS-XSL hybrids
'height/min-height/max-height' apply to them. Now, these being CSS
properties in origin, I think that either:
a) the first rule in 7.3 applies
1. For properties defined in CSS2 referring to the containing
block, the content-rectangle of the closest ancestor block-area that
is not a line-area is used.
or b), the height property being mapped to XSL's block-progression-
dimension (or inline-progression-dimension), the fourth rule applies
4. If the formatting object generating the identified area generates
a sequence of such areas, the first area is used for the conversion.
I'd put my money on a). Moreover, this is most likely why XSL
So would I.
explicitly refers to CSS in its definition of height, since
percentage heights for tables and table-rows in CSS are /not/ defined
in terms of a containing block --they are undefined altogether :(
b) seems to make matters even worse. It would again lead to a
circular dependency for some tables that are direct descendants of
the flow, since that 'first area' could correspond to the first area
generated by the table itself... If not, then it could also be an
area generated by a completely unrelated block (=first block in the
flow) preceding the table...? Big Shrug indeed!
No, the block area in question would be the normal-flow-reference-area
above. Anyway I don't think there is a circular dependency in any case.
As I understand it, at least.
Vincent
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Table troubles
Moreover I have some cells with the 'display-align' attribute set to 'after'. Because of I can't use the 'keep-together' attribute on rows, it happens that if a row is shared on two pages the 'display-align' doesn't work and the value appears on the former page instead of the latter. This seems like a bug. Can you please post the FO, or even better, open an entry in Bugzilla and store the FO as an attachment there? Hi Andreas. I don't know if it's a bug or a my mistake. Here is the FO. As you can see the last row of the first page continues on the second page, but the values of the cells 3, 4, 6 and 7 are displayed on the first page even if I set the attribute display-align to after. I expected that they were displayed on the second page. What do you think? Regards Vincenzo HTH! Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ?xml version=1.0 encoding=UTF-8?fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:XWC=http://www.netbureau.it/XWC/1.0/spec.htm;fo:layout-master-setfo:simple-page-master margin-right=5mm margin-left=5mm margin-bottom=10mm margin-top=6mm page-width=210mm page-height=297mm master-name=main-destinatariofo:region-body margin-bottom=55mm margin-top=120mm/fo:region-before extent=120mm/fo:region-after extent=55mm//fo:simple-page-masterfo:simple-page-master margin-right=5mm margin-left=5mm margin-bottom=10mm margin-top=6mm page-width=210mm page-height=297mm master-name=main-mittentefo:region-body margin-bottom=55mm margin-top=120mm/fo:region-before extent=120mm/fo:region-after extent=55mm//fo:simple-page-masterfo:simple-page-master margin-right=5mm margin-left=5mm margin-bottom=10mm margin-top=6mm page-width=210mm page-height=297mm master-name=main-archiviofo:region-body margin-bottom=55mm margin-top=120mm/fo:region-before extent=120mm/fo:region-after extent=55mm//fo:simple-page-master/fo:layout-master-setfo:page-sequence force-page-count=no-force initial-page-number=1 master-reference=main-destinatariofo:static-content flow-name=xsl-region-beforefo:table table-layout=fixed width=200mmfo:table-column column-width=42mm/fo:table-column column-width=158mm/fo:table-bodyfo:table-rowfo:table-cellfo:block//fo:table-cellfo:table-cellfo:block height=5pt /fo:blockfo:block margin-left=5mm text-align=left font-weight=bold font-size=14pt font-family=Times /fo:block/fo:table-cell/fo:table-row/fo:table-body/fo:tablefo:block text-align=left font-size=10pt font-family=Timesxx/fo:blockfo:block text-align=left font-weight=bold font-size=10pt font-family=Timesxx/fo:blockfo:block text-align=left font-size=10pt font-family=Timesxx/fo:blockfo:block text-align=left font-size=10pt font-family=Timesxx/fo:blockfo:block text-align=left font-size=10pt font-family=Times /fo:blockfo:block text-align=left font-size=10pt font-family=Times#160;/fo:blockfo:block text-align=left font-size=10pt font-family=Times#160;/fo:blockfo:block text-align=left font-size=10pt font-family=Times#160;/fo:blockfo:table table-layout=fixed width=200mmfo:table-column column-width=89.5mm/fo:table-column column-width=10.6mm/fo:table-column column-width=98.9mm/fo:table-headerfo:table-rowfo:table-cellfo:block text-align=center font-size=8pt font-family=CourierRagione sociale/fo:block/fo:table-cellfo:table-cellfo:block text-align=left font-size=8pt font-family=Times#160;/fo:block/fo:table-cellfo:table-cellfo:block text-align=center font-size=8pt font-family=CourierRagione sociale / Indirizzo spedizione/fo:block/fo:table-cell/fo:table-row/fo:table-headerfo:table-bodyfo:table-row height=38mmfo:table-cellfo:block text-align=left font-size=8pt font-family=Times#160;/fo:blockfo:block font-weight=bold margin-left=2mm text-align=left font-size=10pt font-family=CourierSpett.le/fo:blockfo:block text-align=left font-size=8pt font-family=Times#160;/fo:blockfo:block margin-left=10mm text-align=left font-size=12pt font-family=Times/fo:blockfo:block margin-left=10mm text-align=left font-size=12pt font-family=Times/fo:blockfo:block margin-left=10mm text-align=left font-size=12pt font-family=Times/fo:blockfo:block margin-left=10mm text-align=left font-size=12pt font-family=Times/fo:blockfo:block margin-left=10mm text-align=left font-size=12pt font-family=Times/fo:blockfo:block margin-left=10mm text-align=left font-size=12pt font-family=Times/fo:block/fo:table-cellfo:table-cellfo:block text-align=left font-size=8pt font-family=Times#160;/fo:block/fo:table-cellfo:table-cell border-left-color=blackfo:block text-align=left font-size=8pt font-family=Times#160;/fo:blockfo:block font-weight=bold margin-left=2mm text-align=left font-size=10pt font-family=CourierSpett.le/fo:blockfo:block text-align=left font-size=8pt font-family=Times#160;/fo:blockfo:block margin-left=10mm
Re: Table troubles
Hi Vincenzo, Vincenzo Mazzeo a écrit : Moreover I have some cells with the 'display-align' attribute set to 'after'. Because of I can't use the 'keep-together' attribute on rows, it happens that if a row is shared on two pages the 'display-align' doesn't work and the value appears on the former page instead of the latter. This seems like a bug. Can you please post the FO, or even better, open an entry in Bugzilla and store the FO as an attachment there? Hi Andreas. I don't know if it's a bug or a my mistake. Here is the FO. As you can see the last row of the first page continues on the second page, but the values of the cells 3, 4, 6 and 7 are displayed on the first page even if I set the attribute display-align to after. I expected that they were displayed on the second page. What do you think? This is a bug. display-align currently doesn't work well when breaking cells over two pages. I'm not sure there is a workaround ATM. However, in your particular case, you may put the date ranges (-00-00-2007 / 00-00-2007) in a separate row, along with content of cells 3, 4, 6, 7. You should get the same result as currently, but with the price/quantities etc. infos aligned with the date. HTH, Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Table troubles
It seems there is no bug open on bugzilla. I put a new entry (41592). Regards Vincenzo Vincent Hennebert ha scritto: Hi Vincenzo, Vincenzo Mazzeo a écrit : Moreover I have some cells with the 'display-align' attribute set to 'after'. Because of I can't use the 'keep-together' attribute on rows, it happens that if a row is shared on two pages the 'display-align' doesn't work and the value appears on the former page instead of the latter. This seems like a bug. Can you please post the FO, or even better, open an entry in Bugzilla and store the FO as an attachment there? Hi Andreas. I don't know if it's a bug or a my mistake. Here is the FO. As you can see the last row of the first page continues on the second page, but the values of the cells 3, 4, 6 and 7 are displayed on the first page even if I set the attribute display-align to after. I expected that they were displayed on the second page. What do you think? This is a bug. display-align currently doesn't work well when breaking cells over two pages. I'm not sure there is a workaround ATM. However, in your particular case, you may put the date ranges (-00-00-2007 / 00-00-2007) in a separate row, along with content of cells 3, 4, 6, 7. You should get the same result as currently, but with the price/quantities etc. infos aligned with the date. HTH, Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Table troubles
On 09.02.2007 18:43:40 Andreas L Delmelle wrote: On Feb 9, 2007, at 18:22, Jeremias Maerki wrote: An extension isn't necessary. This can be expressed with normal FO means: Specify block-progression-dimension.optimum=100% and block-progression-dimension.minimum=0pt on the last table-row. Hmm... but that property is not directly applicable to a table-row, IIRC. Only 'height' is applicable to tables or table-rows. The fun then truly begins when you read the Rec's definition of the 'height' property... 8) For a discussion of the height property in tables see: http:// www.w3.org/TR/REC-CSS2/tables.html OK, and so we browse through the CSS Rec(*), and there it says: CSS2 does not define what percentage values of 'height' refer to when specified for table rows and row groups. (*) http://www.w3.org/TR/REC-CSS2/tables.html#height-layout That's what CSS2 says, not XSL. I'd very much like to agree with your solution/interpretation, but the nit in me feels compelled to ask: 100% of what? XSL 1.1 says for percentages in block-progression-dimension: The percentage is calculated with respect to the corresponding dimension of the closest area ancestor that was generated by a block-level formatting object. If that dimension is not specified explicitly (i.e., it depends on content's block-progression-dimension), the value is interpreted as auto. But that's a weird statement IMO. If the table's parent is a block, the block's height depends on the content's size. Circular dependency. It would make more sense to say: ...of the closest anscestor that is a reference area... Shrug. See also: http://www.w3.org/TR/xsl11/#percrule What do other processors do in that case? Haven't checked. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Table troubles
Hi all, I have upgraded fop from 0.25 to 0.93 and I have some troubles with tables. 1. On page break table doesn't have the bottom border even if I set it. 2. On the last page, if there isn't enough data, table doesn't fill all available space even if I set the 'height' attribute to 100%. Moreover I have some cells with the 'display-align' attribute set to 'after'. Because of I can't use the 'keep-together' attribute on rows, it happens that if a row is shared on two pages the 'display-align' doesn't work and the value appears on the former page instead of the latter. Does anyone have idea about these troubles? Regards Vincenzo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Table troubles
Hi, Could you send the XSL:FO file, it's quite hard to answer you without. Thanks Miro -Original Message- From: Vincenzo Mazzeo [mailto:[EMAIL PROTECTED] Sent: Friday, February 09, 2007 4:09 PM To: fop-users@xmlgraphics.apache.org Subject: Table troubles Hi all, I have upgraded fop from 0.25 to 0.93 and I have some troubles with tables. 1. On page break table doesn't have the bottom border even if I set it. 2. On the last page, if there isn't enough data, table doesn't fill all available space even if I set the 'height' attribute to 100%. Moreover I have some cells with the 'display-align' attribute set to 'after'. Because of I can't use the 'keep-together' attribute on rows, it happens that if a row is shared on two pages the 'display-align' doesn't work and the value appears on the former page instead of the latter. Does anyone have idea about these troubles? Regards Vincenzo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Table troubles
Thanks for your reply. Here is the XSL:FO file Regards Vincenzo Gregan, Miroslav ha scritto: Hi, Could you send the XSL:FO file, it's quite hard to answer you without. Thanks Miro -Original Message- From: Vincenzo Mazzeo [mailto:[EMAIL PROTECTED] Sent: Friday, February 09, 2007 4:09 PM To: fop-users@xmlgraphics.apache.org Subject: Table troubles Hi all, I have upgraded fop from 0.25 to 0.93 and I have some troubles with tables. 1. On page break table doesn't have the bottom border even if I set it. 2. On the last page, if there isn't enough data, table doesn't fill all available space even if I set the 'height' attribute to 100%. Moreover I have some cells with the 'display-align' attribute set to 'after'. Because of I can't use the 'keep-together' attribute on rows, it happens that if a row is shared on two pages the 'display-align' doesn't work and the value appears on the former page instead of the latter. Does anyone have idea about these troubles? Regards Vincenzo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ?xml version=1.0 encoding=UTF-8?fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:XWC=http://www.netbureau.it/XWC/1.0/spec.htm;fo:layout-master-setfo:simple-page-master margin-right=5mm margin-left=5mm margin-bottom=10mm margin-top=6mm page-width=210mm page-height=297mm master-name=main-destinatariofo:region-body margin-bottom=55mm margin-top=120mm/fo:region-before extent=120mm/fo:region-after extent=55mm//fo:simple-page-masterfo:simple-page-master margin-right=5mm margin-left=5mm margin-bottom=10mm margin-top=6mm page-width=210mm page-height=297mm master-name=main-mittentefo:region-body margin-bottom=55mm margin-top=120mm/fo:region-before extent=120mm/fo:region-after extent=55mm//fo:simple-page-masterfo:simple-page-master margin-right=5mm margin-left=5mm margin-bottom=10mm margin-top=6mm page-width=210mm page-height=297mm master-name=main-archiviofo:region-body margin-bottom=55mm margin-top=120mm/fo:region-before extent=120mm/fo:region-after extent=55mm//fo:simple-page-master/fo:layout-master-setfo:page-sequence force-page-count=no-force initial-page-number=1 master-reference=main-destinatariofo:static-content flow-name=xsl-region-beforefo:table table-layout=fixed width=200mmfo:table-column column-width=42mm/fo:table-column column-width=158mm/fo:table-bodyfo:table-rowfo:table-cellfo:block//fo:table-cellfo:table-cellfo:block height=5pt /fo:blockfo:block margin-left=5mm text-align=left font-weight=bold font-size=14pt font-family=Times /fo:block/fo:table-cell/fo:table-row/fo:table-body/fo:tablefo:block text-align=left font-size=10pt font-family=Timesxx/fo:blockfo:block text-align=left font-weight=bold font-size=10pt font-family=Timesxx/fo:blockfo:block text-align=left font-size=10pt font-family=Timesxx/fo:blockfo:block text-align=left font-size=10pt font-family=Timesxx/fo:blockfo:block text-align=left font-size=10pt font-family=Times /fo:blockfo:block text-align=left font-size=10pt font-family=Times#160;/fo:blockfo:block text-align=left font-size=10pt font-family=Times#160;/fo:blockfo:block text-align=left font-size=10pt font-family=Times#160;/fo:blockfo:table table-layout=fixed width=200mmfo:table-column column-width=89.5mm/fo:table-column column-width=10.6mm/fo:table-column column-width=98.9mm/fo:table-headerfo:table-rowfo:table-cellfo:block text-align=center font-size=8pt font-family=CourierRagione sociale/fo:block/fo:table-cellfo:table-cellfo:block text-align=left font-size=8pt font-family=Times#160;/fo:block/fo:table-cellfo:table-cellfo:block text-align=center font-size=8pt font-family=CourierRagione sociale / Indirizzo spedizione/fo:block/fo:table-cell/fo:table-row/fo:table-headerfo:table-bodyfo:table-row height=38mmfo:table-cellfo:block text-align=left font-size=8pt font-family=Times#160;/fo:blockfo:block font-weight=bold margin-left=2mm text-align=left font-size=10pt font-family=CourierSpett.le/fo:blockfo:block text-align=left font-size=8pt font-family=Times#160;/fo:blockfo:block margin-left=10mm text-align=left font-size=12pt font-family=Times/fo:blockfo:block margin-left=10mm text-align=left font-size=12pt font-family=Times/fo:blockfo:block margin-left=10mm text-align=left font-size=12pt font-family=Times/fo:blockfo:block margin-left=10mm text-align=left font-size=12pt font-family=Times/fo:blockfo:block margin-left=10mm text-align=left font-size=12pt font-family=Times/fo:blockfo:block margin-left=10mm text-align=left font-size=12pt font-family=Times/fo:block/fo:table-cellfo:table-cellfo:block text-align=left font-size=8pt font-family
Re: Table troubles
Chris Bowditch ha scritto: Vincenzo Mazzeo wrote: Hi all, I have upgraded fop from 0.25 to 0.93 and I have some troubles with tables. 1. On page break table doesn't have the bottom border even if I set it. This is because of border conditionality. Table borders are not painted at the start/end of a reference area by default. You have to add property table-border.conditionality=retain Hi Chris, I added the table-border.conditionality=retain property to the fo:table but it says Error(4/2343): fo:table, Invalid property name 'table-border.conditionality. How can I use this property? 2. On the last page, if there isn't enough data, table doesn't fill all available space even if I set the 'height' attribute to 100%. height attribute has no affect on a table. IIUC, then there is no way to stretch a table so that it fills an entire page using XSL-FO 1.1. Moreover I have some cells with the 'display-align' attribute set to 'after'. Because of I can't use the 'keep-together' attribute on rows, it happens that if a row is shared on two pages the 'display-align' doesn't work and the value appears on the former page instead of the latter. I don't follow this bit. What do you mean by a table-row being shared between 2 pages. Do you mean you have some cells spanning 2 rows, whilst other cells are not? I mean that a cell can contain more than one line. As I don't use the 'keep-together' attribute some lines are put on a page and the others on the other page. snip/ Chris Vincenzo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Table troubles
Vincenzo Mazzeo wrote: Chris Bowditch ha scritto: Vincenzo Mazzeo wrote: Hi all, I have upgraded fop from 0.25 to 0.93 and I have some troubles with tables. 1. On page break table doesn't have the bottom border even if I set it. This is because of border conditionality. Table borders are not painted at the start/end of a reference area by default. You have to add property table-border.conditionality=retain Hi Chris, I added the table-border.conditionality=retain property to the fo:table but it says Error(4/2343): fo:table, Invalid property name 'table-border.conditionality. How can I use this property? Oops I made a typo in my original e-mail! The correct property name is just border.conditionality on the table element, e.g. fo:table border-color=black border-width=1pt border-style=solid border.conditionality=retain snip/ Moreover I have some cells with the 'display-align' attribute set to 'after'. Because of I can't use the 'keep-together' attribute on rows, it happens that if a row is shared on two pages the 'display-align' doesn't work and the value appears on the former page instead of the latter. I don't follow this bit. What do you mean by a table-row being shared between 2 pages. Do you mean you have some cells spanning 2 rows, whilst other cells are not? I mean that a cell can contain more than one line. As I don't use the 'keep-together' attribute some lines are put on a page and the others on the other page. and you are saying that you can't use keep-together on the table-row because it messes up display-align? Well that sounds like a bug... snip/ Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Table troubles
On Feb 9, 2007, at 18:43, Andreas L Delmelle wrote:
On Feb 9, 2007, at 18:22, Jeremias Maerki wrote:
An extension isn't necessary. This can be expressed with normal FO
means: Specify block-progression-dimension.optimum=100% and
block-progression-dimension.minimum=0pt on the last table-row.
snip /
Or, to avoid the CSS 'height' pitfall, how about:
fo:table-row
fo:table-cell number-columns-spanned={all}
fo:block-container block-progression-dimension.optimum=100%
block-progression-dimension.minimum=0pt
fo:block#xA0;/fo:block
/fo:block-container
/fo:table-cell
/fo:table-row
What does the percentage refer to in this case?
Is space-before/-after needed to complete the picture?
Cheers,
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
