Re: WordML continuous section break
Thaks for your quick reply Andreas, I have created a reduced version of the original WordML document with the same continous section break, and obtained the same results (it breaks it in two different pages). Here you have the FO I'm currently using. It's long. ready? == ?xml version=1.0 encoding=utf-8? fo:root font-family=TimesNewRoman fo:layout-master-set fo:simple-page-master master-name=section1-first- page page-width=595.3pt page-height=841.9pt margin-top=42.55pt margin-bottom=42.55pt margin-right=70.9pt margin-left=70.9pt fo:region-body margin-top=62.75pt margin-bottom=38.63636363636363pt/ fo:region-before extent=11in region-name=first-page-header/ fo:region-after display-align=after extent=11in region-name=first-page-footer/ /fo:simple-page-master fo:simple-page-master master-name=section1-odd-page page-width=595.3pt page-height=841.9pt margin-top=42.55pt margin-bottom=42.55pt margin-right=70.9pt margin-left=70.9pt fo:region-body margin-top=62.75pt margin-bottom=38.63636363636363pt/ fo:region-before extent=11in region-name=odd-page-header/ fo:region-after display-align=after extent=11in region-name=odd-page-footer/ /fo:simple-page-master fo:simple-page-master master-name=section1-even-page page-width=595.3pt page-height=841.9pt margin-top=42.55pt margin-bottom=42.55pt margin-right=70.9pt margin-left=70.9pt fo:region-body margin-top=62.75pt margin-bottom=38.63636363636363pt/ fo:region-before extent=11in region-name=even-page-header/ fo:region-after display-align=after extent=11in region-name=even-page-footer/ /fo:simple-page-master fo:page-sequence-master master-name=section1-page-sequence-master fo:single-page-master-reference master-reference=section1-first-page/ fo:repeatable-page-master-alternatives fo:conditional-page-master-reference master-reference=section1-odd-page odd-or-even=odd/ fo:conditional-page-master-reference master-reference=section1-even-page odd-or-even=even/ /fo:repeatable-page-master-alternatives /fo:page-sequence-master fo:simple-page-master master-name=section2-first-page page-width=595.3pt page-height=841.9pt margin-top=42.55pt margin-bottom=42.55pt margin-right=70.9pt margin-left=70.9pt fo:region-body margin-top=62.75pt margin-bottom=38.63636363636363pt column-count=2 column-gap=35.4pt/ fo:region-before extent=11in region-name=first-page-header/ fo:region-after display-align=after extent=11in region-name=first-page-footer/ /fo:simple-page-master fo:simple-page-master master-name=section2-odd-page page-width=595.3pt page-height=841.9pt margin-top=42.55pt margin-bottom=42.55pt margin-right=70.9pt margin-left=70.9pt fo:region-body margin-top=62.75pt margin-bottom=38.63636363636363pt column-count=2 column-gap=35.4pt/ fo:region-before extent=11in region-name=odd-page-header/ fo:region-after display-align=after extent=11in region-name=odd-page-footer/ /fo:simple-page-master fo:simple-page-master master-name=section2-even-page page-width=595.3pt page-height=841.9pt margin-top=42.55pt margin-bottom=42.55pt margin-right=70.9pt margin-left=70.9pt fo:region-body margin-top=62.75pt margin-bottom=38.63636363636363pt column-count=2 column-gap=35.4pt/ fo:region-before extent=11in region-name=even-page-header/ fo:region-after display-align=after extent=11in region-name=even-page-footer/ /fo:simple-page-master fo:page-sequence-master master-name=section2-page-sequence-master fo:single-page-master-reference master-reference=section2-first-page/ fo:repeatable-page-master-alternatives fo:conditional-page-master-reference master-reference=section2-odd-page odd-or-even=odd/ fo:conditional-page-master-reference master-reference=section2-even-page odd-or-even=even/ /fo:repeatable-page-master-alternatives /fo:page-sequence-master /fo:layout-master-set fo:declarations ... /fo:declarations fo:bookmark-tree/ fo:page-sequence master-reference=section1-page-sequence-master format=1 fo:static-content flow-name=first-page-header fo:retrieve-marker retrieve-boundary=page retrieve-position=first-including-carryover retrieve-class-name=first-page-header/ /fo:static-content fo:static-content flow-name=first-page-footer fo:retrieve-marker retrieve-boundary=page retrieve-position=first-including-carryover retrieve-class-name=first-page-footer/ /fo:static-content fo:static-content flow-name=odd-page-header fo:retrieve-marker retrieve-boundary=page retrieve-position=first-including-carryover retrieve-class-name=odd-page-header/ /fo:static-content fo:static-content flow-name=odd-page-footer fo:retrieve-marker retrieve-boundary=page retrieve-position=first-including-carryover retrieve-class-name=odd-page-footer/ /fo:static-content
Re: Mysterious left truncation of table in region-before: version 1.0 only
Drats. I played with the fo after attaching it and before sending. The commented-out region-before lines are the ones which cause the problem. On 07/14/2011 09:51 PM, Rob Sargent wrote: Call off the hounds, I've found the root cause. I still think it's quite interesting how the two version deal with the situation so differently. As I said there are two flows (or more correctly? page-sequences). The definition of the region-before in the first sequence is more specific in it's dimensions. Here a left-hand page definition for this sequence: fo:simple-page-master margin-bottom=0.6in margin-top=0in page-height=11in page-width=8.5in master-name=rest-even fo:region-body margin-left=0.0in margin-right=0.833in margin-bottom=0.7in margin-top=0.66in column-gap=0.25in column-count=2 / fo:region-before margin-top=5mm margin-left=0.75in margin-right=0.833in extent=0.66in region-name=header-rest / fo:region-start extent=0.75in region-name=sidebar-left / /fo:simple-page-master where as the second sequence used region-before definitions like this: fo:simple-page-master page-width=8.5in page-height=11in margin=0in 0.833in 0in 0in master-name=leftimages fo:region-body margin-left=0.75in margin-top=0.66in margin-bottom=0.6in column-gap=0.25in column-count=2 / fo:region-before margin-left=0.0in overflow=hidden region-name=header-images extent=0.66in / fo:region-after region-name=footer-images extent=0.7in / fo:region-start extent=0.75in region-name=sidebar-left / /fo:simple-page-master I suspect the main culprit is the 'margin-left=0.0'. This made 0.83 inches of the LEFT side of the single celled table simply disappear. One could cover the region-before with a background colour and see the background where there should have been the title cell. Running v-1.0 with-d produces nicer information than 0.95 and that helped but 0.95 was more lenient (and that helped ;) ) Rob Sargent wrote: Understood. It'll take some work to trim the fo, since our documents are so heavily populated with medical images. Hence I wanted to be sure this wasn't a known issue. I'll be on vacation next week so don't wait up for me. :) Cheers, rjs Andreas L. Delmelle wrote: On 14 Jul 2011, at 05:58, Rob Sargent wrote: Hi Rob Is this by any chance a know bug in version 1.0? Searching for open issues in Bugzilla that contain both table and region-before yielded no results. So, I would assume that, if it is a bug, it is not a known one (or already fixed in trunk --didn't search the closed bugs). At any rate, sorry to keep repeating this, but... it is difficult --not to say: virtually impossible- to say more without the actual FO file. Preferably, if not too time-consuming, trimmed down to the smallest FO that shows the issue. Is it possible to post something like that here? If you can't because it contains confidential info, you can send it to me off-list if that works for you. I place a single row table, single cell table in the region before. In version 0.95 the table, which has background set to silver renders perfectly, spanning the entire region-before. Using versions 1.0, the left ~0.83 inches of the table are obliterated. The text is centered properly as if the cell spanned the region width. .83in is almost 60pt, 'roughly' .83in could be exactly that. Perhaps this gives a clue? Is there some margin/indent specified as 60pt? If you specify a border on the table, does that disappear on the left as well? I've tried placing the entire table in a block-container to no avail. Weirder still is that only in one flow, (the second of two) does the truncation appear. Both flows use the same template to define the table. The two fo files are identical (according to emacs's ediff). Is that believable? While that seems strange, I would not rule it out without having taken a closer look. KR Andreas --- - 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: org.apache.fop.fo.ValidationException: fo:list-block is missing child elements
On 12/07/2011 12:11, Glenn Adams wrote: this is not a bug, as pointed out by Pascal By debug I meant debug the XSLT/XSL-FO rather than the Java code. On Tue, Jul 12, 2011 at 5:08 AM, Chris Bowditch bowditch_ch...@hotmail.com mailto:bowditch_ch...@hotmail.com wrote: On 12/07/2011 09:52, tecshine wrote: Hi, Thanks for the reply Pascal I have tried using fopFactory.setStrictValidation(false); but it doesnt solve the problem. Our entire application was based on FOP 0.20.5 and rewriting all XSLTs would mean a lot of work. Is there any other way we can resolve the issue. Can you generate the XSL-FO and post it to the list (if its not too big) Since you are submitting XSLT+XML to fop you will need to use -foout option when running FOP from the command line to generate the intermediate XSL-FO. We can debug the issue by looking at the XSL-FO. Thanks, Chris Pascal Sancho wrote: Hi Swetha, FOP 1.0 is more strict than FOP 0.2x regarding the XSL-FO REC 1.1. Probably you will experiment further ValidationExceptions against FO elements or attributes (missing %block% in fo:table-cell is the most popular). The best way is to rewrite your XSL-T to produce strict XSL-FO. But FOP team offered a configuration tip to help in FOP 0.2x to Latest migration: see [strict-validation] element at [1]. [1] http://xmlgraphics.apache.org/fop/1.0/configuration.html#general-available Le 12/07/2011 08:14, tecshine a écrit : I have migrated from fop 0.20.5 to FOP 1.0. I get the following exception javax.xml.transform.TransformerException: org.apache.fop.fo http://org.apache.fop.fo.ValidationException: fo:list-block is missing child elements. Required content model: marker* (list-item)+ (See position 369:112) I am aware that this kind of errors occur when the parent is empty or doesnt have child elements, so check the xsl file .All fo:list-block elements in the xsl file contain at least one fo:list-item child element. Even then I stumble upon this exception. Can someone help me get out of this please. Thanks in advance Swetha -- Pascal - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org mailto:fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org mailto:fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org mailto:fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org mailto: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: org.apache.fop.fo.ValidationException: fo:list-block is missing child elements
I get this error intermittently while generating PDF report using FOP 1.0.
null:5511:928: {http://www.w3.org/1999/XSL/Format}block; is not a valid
child of fo:table-row! (See position 5511:928). In most cases this issue
is resolved on resubmitting the report. Can any one pin point what is the
actual cause of this issue and why it is happening occasionally for the same
input?
org.apache.fop.fo.ValidationException: {
http://www.w3.org/1999/XSL/Format}block; is not a valid child of
fo:table-row! (See position 1143:945)
On Fri, Jul 15, 2011 at 9:42 AM, Chris Bowditch
bowditch_ch...@hotmail.comwrote:
On 12/07/2011 12:11, Glenn Adams wrote:
this is not a bug, as pointed out by Pascal
By debug I meant debug the XSLT/XSL-FO rather than the Java code.
On Tue, Jul 12, 2011 at 5:08 AM, Chris Bowditch
bowditch_ch...@hotmail.com
mailto:bowditch_chris@**hotmail.combowditch_ch...@hotmail.com
wrote:
On 12/07/2011 09:52, tecshine wrote:
Hi,
Thanks for the reply Pascal
I have tried using fopFactory.**setStrictValidation(false); but
it doesnt
solve the problem.
Our entire application was based on FOP 0.20.5 and rewriting
all XSLTs would
mean a lot of work.
Is there any other way we can resolve the issue.
Can you generate the XSL-FO and post it to the list (if its not
too big)
Since you are submitting XSLT+XML to fop you will need to use
-foout option when running FOP from the command line to generate
the intermediate XSL-FO. We can debug the issue by looking at the
XSL-FO.
Thanks,
Chris
Pascal Sancho wrote:
Hi Swetha,
FOP 1.0 is more strict than FOP 0.2x regarding the XSL-FO
REC 1.1.
Probably you will experiment further ValidationExceptions
against FO
elements or attributes (missing %block% in fo:table-cell
is the most
popular).
The best way is to rewrite your XSL-T to produce strict
XSL-FO.
But FOP team offered a configuration tip to help in FOP
0.2x to Latest
migration: see [strict-validation] element at [1].
[1]
http://xmlgraphics.apache.org/**fop/1.0/configuration.html#**
general-availablehttp://xmlgraphics.apache.org/fop/1.0/configuration.html#general-available
Le 12/07/2011 08:14, tecshine a écrit :
I have migrated from fop 0.20.5 to FOP 1.0. I get the
following exception
javax.xml.transform.**TransformerException:
org.apache.fop.fo
http://org.apache.fop.fo.**ValidationException:
fo:list-block is missing child
elements. Required content model: marker* (list-item)+
(See position
369:112)
I am aware that this kind of errors occur when the
parent is empty or
doesnt
have child elements, so check the xsl file .All
fo:list-block elements
in
the xsl file contain at least one fo:list-item
child element. Even
then I
stumble upon this exception.
Can someone help me get out of this please.
Thanks in advance
Swetha
-- Pascal
--**--
**-
To unsubscribe, e-mail:
fop-users-unsubscribe@**xmlgraphics.apache.orgfop-users-unsubscr...@xmlgraphics.apache.org
mailto:fop-users-unsubscribe@**xmlgraphics.apache.orgfop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail:
fop-users-help@xmlgraphics.**apache.orgfop-users-h...@xmlgraphics.apache.org
mailto:fop-users-help@**xmlgraphics.apache.orgfop-users-h...@xmlgraphics.apache.org
--**--**
-
To unsubscribe, e-mail:
fop-users-unsubscribe@**xmlgraphics.apache.orgfop-users-unsubscr...@xmlgraphics.apache.org
mailto:fop-users-unsubscribe@**xmlgraphics.apache.orgfop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail:
fop-users-help@xmlgraphics.**apache.orgfop-users-h...@xmlgraphics.apache.org
mailto:fop-users-help@**xmlgraphics.apache.orgfop-users-h...@xmlgraphics.apache.org
--**--**-
To unsubscribe, e-mail:
fop-users-unsubscribe@**xmlgraphics.apache.orgfop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail:
fop-users-help@xmlgraphics.**apache.orgfop-users-h...@xmlgraphics.apache.org
--
Thanks,
Hamed Mohammed,
Email: mohdhamedms...@gmail.com.
Re: WordML continuous section break
On 15 Jul 2011, at 09:26, Marcos García wrote: Hi Marcos I have created a reduced version of the original WordML document with the same continous section break, and obtained the same results (it breaks it in two different pages). Here you have the FO I'm currently using. It's long. ready? OK, thanks. That makes it a whole lot clearer. So, you want Paragraph 1 and Paragraph 2 to be shown on the same page, right? In that case, the fact that they appear in different fo:page-sequences does not help --quite on the contrary: that forces an unconditional page-break in between the two page-sequences. The two blocks/paragraphs should end up in the same page-sequence, using the same 2-column page-master, and the fo:flow should look something like (stripped to show the most relevant parts): fo:flow flow-name=xsl-region-body fo:block span=all role=Div widows=2 orphans=2 font-size=10pt line-height=1.147 white-space-collapse=true ... fo:block font-family=TimesNewRoman font-size=12pt language=ES fo:inlineParagraph1/fo:inline /fo:block /fo:block fo:block role=Div widows=2 orphans=2 font-size=10pt line-height=1.147 white-space-collapse=true fo:block font-family=TimesNewRoman font-size=12pt language=ES fo:inlineParagraph2/fo:inline /fo:block /fo:block fo:block id=last-block/ /fo:flow Note the span=all spec on the first block to make sure it spans both columns. The second block then, will flow in two columns (implicit span=none). Obviously, this will mean --likely significant-- changes to your stylesheet code. Hope this helps! Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: org.apache.fop.fo.ValidationException: fo:list-block is missing child elements
On 15 Jul 2011, at 17:54, Hamed Mohammed wrote:
Hi
Just to get it out of the way: please refrain from hijacking existing threads
in the future, unless it really is the same issue. The OP was about
fo:list-blocks, your issue concerns fo:table-rows. The OP was about missing
child elements, your issue is about a wrong child element. Apart from the fact
that a ValidationException is thrown, the cases have nothing in common...
I get this error intermittently while generating PDF report using FOP 1.0.
null:5511:928: {http://www.w3.org/1999/XSL/Format}block; is not a valid
child of fo:table-row! (See position 5511:928).
snip /
In most cases this issue is resolved on resubmitting the report. Can any one
pin point what is the actual cause of this issue and why it is happening
occasionally for the same input?
This means that, at line 5511, column 928 in the FO source, there is a fo:block
that ends up as a direct child of a fo:table-row, and that is not allowed by
XSL-FO (see: http://www.w3.org/TR/xsl/#fo_table-row - only fo:table-cells are
allowed as child nodes)
I would suspect it is actually NOT the same input. Have you verified that the
FO is really identical in both cases? If so, can you post a sample?
Regards,
Andreas
---
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: org.apache.fop.fo.ValidationException: fo:list-block is missing child elements
See [1]. Valid children of table-row are table-cell+.
[1] http://www.w3.org/TR/2006/REC-xsl11-20061205/#fo_table-row
On Fri, Jul 15, 2011 at 11:54 AM, Hamed Mohammed
mohdhamedms...@gmail.comwrote:
I get this error intermittently while generating PDF report using FOP 1.0.
null:5511:928: {http://www.w3.org/1999/XSL/Format}block; is not a valid
child of fo:table-row! (See position 5511:928). In most cases this issue
is resolved on resubmitting the report. Can any one pin point what is the
actual cause of this issue and why it is happening occasionally for the same
input?
org.apache.fop.fo.ValidationException: {
http://www.w3.org/1999/XSL/Format}block; is not a valid child of
fo:table-row! (See position 1143:945)
On Fri, Jul 15, 2011 at 9:42 AM, Chris Bowditch
bowditch_ch...@hotmail.com wrote:
On 12/07/2011 12:11, Glenn Adams wrote:
this is not a bug, as pointed out by Pascal
By debug I meant debug the XSLT/XSL-FO rather than the Java code.
On Tue, Jul 12, 2011 at 5:08 AM, Chris Bowditch
bowditch_ch...@hotmail.com
mailto:bowditch_chris@**hotmail.combowditch_ch...@hotmail.com
wrote:
On 12/07/2011 09:52, tecshine wrote:
Hi,
Thanks for the reply Pascal
I have tried using fopFactory.**setStrictValidation(false); but
it doesnt
solve the problem.
Our entire application was based on FOP 0.20.5 and rewriting
all XSLTs would
mean a lot of work.
Is there any other way we can resolve the issue.
Can you generate the XSL-FO and post it to the list (if its not
too big)
Since you are submitting XSLT+XML to fop you will need to use
-foout option when running FOP from the command line to generate
the intermediate XSL-FO. We can debug the issue by looking at the
XSL-FO.
Thanks,
Chris
Pascal Sancho wrote:
Hi Swetha,
FOP 1.0 is more strict than FOP 0.2x regarding the XSL-FO
REC 1.1.
Probably you will experiment further ValidationExceptions
against FO
elements or attributes (missing %block% in fo:table-cell
is the most
popular).
The best way is to rewrite your XSL-T to produce strict
XSL-FO.
But FOP team offered a configuration tip to help in FOP
0.2x to Latest
migration: see [strict-validation] element at [1].
[1]
http://xmlgraphics.apache.org/**fop/1.0/configuration.html#**
general-availablehttp://xmlgraphics.apache.org/fop/1.0/configuration.html#general-available
Le 12/07/2011 08:14, tecshine a écrit :
I have migrated from fop 0.20.5 to FOP 1.0. I get the
following exception
javax.xml.transform.**TransformerException:
org.apache.fop.fo
http://org.apache.fop.fo.**ValidationException:
fo:list-block is missing child
elements. Required content model: marker* (list-item)+
(See position
369:112)
I am aware that this kind of errors occur when the
parent is empty or
doesnt
have child elements, so check the xsl file .All
fo:list-block elements
in
the xsl file contain at least one fo:list-item
child element. Even
then I
stumble upon this exception.
Can someone help me get out of this please.
Thanks in advance
Swetha
-- Pascal
--**
--**-
To unsubscribe, e-mail:
fop-users-unsubscribe@**xmlgraphics.apache.orgfop-users-unsubscr...@xmlgraphics.apache.org
mailto:fop-users-unsubscribe@**xmlgraphics.apache.orgfop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail:
fop-users-help@xmlgraphics.**apache.orgfop-users-h...@xmlgraphics.apache.org
mailto:fop-users-help@**xmlgraphics.apache.orgfop-users-h...@xmlgraphics.apache.org
--**--**
-
To unsubscribe, e-mail:
fop-users-unsubscribe@**xmlgraphics.apache.orgfop-users-unsubscr...@xmlgraphics.apache.org
mailto:fop-users-unsubscribe@**xmlgraphics.apache.orgfop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail:
fop-users-help@xmlgraphics.**apache.orgfop-users-h...@xmlgraphics.apache.org
mailto:fop-users-help@**xmlgraphics.apache.orgfop-users-h...@xmlgraphics.apache.org
--**--**-
To unsubscribe, e-mail:
fop-users-unsubscribe@**xmlgraphics.apache.orgfop-users-unsubscr...@xmlgraphics.apache.org
For
Re: Mysterious left truncation of table in region-before: version 1.0 only
On 15 Jul 2011, at 15:57, Rob Sargent wrote: Hi Rob Drats. I played with the fo after attaching it and before sending. The commented-out region-before lines are the ones which cause the problem. Sorry, but which commented lines are you referring to? I do not see any in the posted fragment... Am I missing something? Do you mean the issue is still unresolved? ... Here a left-hand page definition for this sequence: fo:simple-page-master margin-bottom=0.6in margin-top=0in page-height=11in page-width=8.5in master-name=rest-even fo:region-body margin-left=0.0in margin-right=0.833in margin-bottom=0.7in margin-top=0.66in column-gap=0.25in column-count=2 / fo:region-before margin-top=5mm margin-left=0.75in margin-right=0.833in extent=0.66in region-name=header-rest / OK, I see. Just so you know, margin-* properties do not apply to region-before, nor to any of the other side-regions for that matter. Apparently, given your description, this would be handled incorrectly in FOP 1.0. That said, however, I cannot reproduce such an issue with FOP trunk. Admittedly, I am trying to piece together a sample using the simple-page-master you posted, and FOP, as I half expected, just seems to ignore the margin. As the spec states, literally: Every formatting property may be specified on every formatting object. So, it is not an error. It should not have side-effects either, though... KR Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Mysterious left truncation of table in region-before: version 1.0 only
No the commented lines are in the fo I attached to message previous to the drats. The issue is resolved though I think the difference in the behaviour between the two revs is ,um, er, spectacular. ;) On 07/15/2011 01:44 PM, Andreas L. Delmelle wrote: On 15 Jul 2011, at 15:57, Rob Sargent wrote: Hi Rob Drats. I played with the fo after attaching it and before sending. The commented-out region-before lines are the ones which cause the problem. Sorry, but which commented lines are you referring to? I do not see any in the posted fragment... Am I missing something? Do you mean the issue is still unresolved? ... Here a left-hand page definition for this sequence: fo:simple-page-master margin-bottom=0.6in margin-top=0in page-height=11in page-width=8.5in master-name=rest-even fo:region-body margin-left=0.0in margin-right=0.833in margin-bottom=0.7in margin-top=0.66in column-gap=0.25in column-count=2 / fo:region-before margin-top=5mm margin-left=0.75in margin-right=0.833in extent=0.66in region-name=header-rest / OK, I see. Just so you know, margin-* properties do not apply to region-before, nor to any of the other side-regions for that matter. Apparently, given your description, this would be handled incorrectly in FOP 1.0. That said, however, I cannot reproduce such an issue with FOP trunk. Admittedly, I am trying to piece together a sample using the simple-page-master you posted, and FOP, as I half expected, just seems to ignore the margin. As the spec states, literally: Every formatting property may be specified on every formatting object. So, it is not an error. It should not have side-effects either, though... KR Andreas --- - 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: Mysterious left truncation of table in region-before: version 1.0 only
I don't know if this is the case, but I had similar problem (a region with left side of the content hidden on the left side only on FOP 1.0 while FOP 0.95 worked correctly) and I discovered that was related to a bug in hidden property of regions in FOP 1.0. https://issues.apache.org/bugzilla/show_bug.cgi?id=49910 -- Giuseppe Briotti g.brio...@gmail.com Alme Sol, curru nitido diem qui promis et celas aliusque et idem nasceris, possis nihil urbe Roma visere maius. (Orazio) - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Mysterious left truncation of table in region-before: version 1.0 only
BTW, my XML editor show that the attached fo is not valid, due to the margin- properties (as stated by Rob) and due to the cell content (table-cell cannot have text content, only element allowed)... -- Giuseppe Briotti g.brio...@gmail.com Alme Sol, curru nitido diem qui promis et celas aliusque et idem nasceris, possis nihil urbe Roma visere maius. (Orazio) - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
