Re: Content spanning multiple pages issue

2011-08-05 Thread Fernando Israel
Hi Andreas and Rob,

Just to let you know that relaxing the FOP structure by removing the block
containers position=absolute and replacing the top/left by
space-after/start-indent did the trick and the pages produced by FOP look as
expected.

Thank you very much for your help and suggestions !

Kind Regards,
Fernando


On Mon, Aug 1, 2011 at 10:18 AM, Fernando Israel  wrote:

> Hi Andreas and Rob,
>
> Thank you very much both for your suggestions.
>
> The idea of using space-before and start-indent attributes instead of top
> and left respectively, and dropping the absolute position looks promising,
> I'll try that. In fact there are 2 tables in the document, the main one
> which we have discussed so far, and another one I did not mentioned so far
> to keep things simple, that always follows the main one and it is
> conceptually a summary of it. In the summary table I have actually used
> space-before and start-indent and that works fine. So now I think I should
> try to translate the top and left values to space-before and start-indent
> and thereby relax the whole structure and let it flow more naturally.
>
> Let me perhaps give you a more detailed picture of what I am trying to
> acomplish with FOP. This work is part of an application that deals with
> billing out of a system. Part of the application let users design their own
> invoice template that we then use, along with the actual data for each
> invoice, to produce an invoice PDF document. So the WSIWYG editor let users
> drop text, pictures and a table with the items sold which are part of the
> invoice. Some of the text and the invoice items table are generated from
> live data. So for instance, a typical invoice would include the company logo
> (a pic) static text with the company address, dynamic text with the invoice
> number, invoice date, client name and address, etc. Generally an invoice is
> arranged with all these bits on the top of the page followed by a table with
> the items invoiced; the table includes the name of the product, quantity,
> price, etc.
>
> This is why we need to the PDF to reproduce what the users have designed.
> In the template editor since we don't know upfront the height of the table
> (we know the width and the columns headers) we drop a table with 3 rows as a
> sample, but in practice the table's height varied depending on the number of
> invoiced items. Underneath the table there is the other table with the
> summary with things such as subtotal, VAT, total, etc. We made that summary
> table follow the main one using space-before and start-indent.
>
> This design has the limitation that anything underneath the main table and
> the following summary table might get hidden by the content of the tables if
> they are too long. Having said that, in most of the cases that will not be
> so. We just need to tell users to take this into account during design. Put
> it in a different way, the tool does the job and covers most needs but it
> does not cover 100% of the cases.
>
> We did use absolute positioning because it was the easiest thing to do.
> However I now see that perhaps that wasn't the best choice and doing all the
> positioning with space-before and start-indent will provide a more flexible
> tool. For once, it will remove the limitation that anything under the tables
> might get hidden by the tables content. It will also span multiple pages if
> needed.
>
> Going forward we also plan to support header/footer, which will allow users
> to have a finer control on what should appear in each page when it spans
> over a single page.
>
> One last question. I think that the main issue we are having with the
> current design is the constarins along the block propagation direction. So
> the first thin we need to do is to relax the structure and replace the top
> attribute by the space-before one. We don't have an issue in the inline
> direction, so, can I keep using the left attribute there ?. So it will be a
> mix of start-before and left attributes.
>
> Thanks again for you input. It is very much appreciated.
>
> Regards,
> Fernando
>
>
>
> On Sun, Jul 31, 2011 at 12:11 AM, Rob Sargent wrote:
>
>> OP might also be interested in calculating the required offset on the
>> second page (end of the table) at which to place (absolutely??) the
>> follow-on text. If so follow the (ill-named) thread "breakpoint suggestions
>> please".
>>
>> One is tempted to ask why the WYSIWYG editor doesn't open a second page...
>>
>>
>>
>>
>> Andreas L. Delmelle wrote:
>>
>>> On 30 Jul 2011, at 21:13, Fernando Israel wrote:
>>>
>>> Hi Fernando,
>>>
>>>
>>>
 
 So I now have to rephrase the question. Can I have a table within an
 absolute postioned block container go over to a second page it its length
 requires so ?. I guess that the answer is no, but I better ask.


>>>
>>> You guess correct.
>>>
>>> BTW, it just occurred to me, while re-examining the FO you sent, that the
>>> 'position' property does not apply to fo:

Re: Content spanning multiple pages issue

2011-08-01 Thread Fernando Israel
Hi Andreas and Rob,

Thank you very much both for your suggestions.

The idea of using space-before and start-indent attributes instead of top
and left respectively, and dropping the absolute position looks promising,
I'll try that. In fact there are 2 tables in the document, the main one
which we have discussed so far, and another one I did not mentioned so far
to keep things simple, that always follows the main one and it is
conceptually a summary of it. In the summary table I have actually used
space-before and start-indent and that works fine. So now I think I should
try to translate the top and left values to space-before and start-indent
and thereby relax the whole structure and let it flow more naturally.

Let me perhaps give you a more detailed picture of what I am trying to
acomplish with FOP. This work is part of an application that deals with
billing out of a system. Part of the application let users design their own
invoice template that we then use, along with the actual data for each
invoice, to produce an invoice PDF document. So the WSIWYG editor let users
drop text, pictures and a table with the items sold which are part of the
invoice. Some of the text and the invoice items table are generated from
live data. So for instance, a typical invoice would include the company logo
(a pic) static text with the company address, dynamic text with the invoice
number, invoice date, client name and address, etc. Generally an invoice is
arranged with all these bits on the top of the page followed by a table with
the items invoiced; the table includes the name of the product, quantity,
price, etc.

This is why we need to the PDF to reproduce what the users have designed. In
the template editor since we don't know upfront the height of the table (we
know the width and the columns headers) we drop a table with 3 rows as a
sample, but in practice the table's height varied depending on the number of
invoiced items. Underneath the table there is the other table with the
summary with things such as subtotal, VAT, total, etc. We made that summary
table follow the main one using space-before and start-indent.

This design has the limitation that anything underneath the main table and
the following summary table might get hidden by the content of the tables if
they are too long. Having said that, in most of the cases that will not be
so. We just need to tell users to take this into account during design. Put
it in a different way, the tool does the job and covers most needs but it
does not cover 100% of the cases.

We did use absolute positioning because it was the easiest thing to do.
However I now see that perhaps that wasn't the best choice and doing all the
positioning with space-before and start-indent will provide a more flexible
tool. For once, it will remove the limitation that anything under the tables
might get hidden by the tables content. It will also span multiple pages if
needed.

Going forward we also plan to support header/footer, which will allow users
to have a finer control on what should appear in each page when it spans
over a single page.

One last question. I think that the main issue we are having with the
current design is the constarins along the block propagation direction. So
the first thin we need to do is to relax the structure and replace the top
attribute by the space-before one. We don't have an issue in the inline
direction, so, can I keep using the left attribute there ?. So it will be a
mix of start-before and left attributes.

Thanks again for you input. It is very much appreciated.

Regards,
Fernando


On Sun, Jul 31, 2011 at 12:11 AM, Rob Sargent  wrote:

> OP might also be interested in calculating the required offset on the
> second page (end of the table) at which to place (absolutely??) the
> follow-on text. If so follow the (ill-named) thread "breakpoint suggestions
> please".
>
> One is tempted to ask why the WYSIWYG editor doesn't open a second page...
>
>
>
>
> Andreas L. Delmelle wrote:
>
>> On 30 Jul 2011, at 21:13, Fernando Israel wrote:
>>
>> Hi Fernando,
>>
>>
>>
>>> 
>>> So I now have to rephrase the question. Can I have a table within an
>>> absolute postioned block container go over to a second page it its length
>>> requires so ?. I guess that the answer is no, but I better ask.
>>>
>>>
>>
>> You guess correct.
>>
>> BTW, it just occurred to me, while re-examining the FO you sent, that the
>> 'position' property does not apply to fo:block, so it actually serves no
>> purpose there.
>> Specifying the property can almost be seen as wasteful, because it
>> 'overburdens' the property parser. Big word, because it does not matter
>> _that_ much, but "less is more". :-)
>>
>>
>>
>>> If the answer is no, given my description of the objective, can you think
>>> of a different way of trying to achieve the objective ?.
>>>
>>>
>>
>> Let's see...
>>
>> The block-container will only be broken if its top/left positioning is
>> relative, which FOP does not support. Never 

Re: Content spanning multiple pages issue

2011-07-30 Thread Rob Sargent
OP might also be interested in calculating the required offset on the 
second page (end of the table) at which to place (absolutely??) the 
follow-on text. If so follow the (ill-named) thread "breakpoint 
suggestions please".


One is tempted to ask why the WYSIWYG editor doesn't open a second page...



Andreas L. Delmelle wrote:

On 30 Jul 2011, at 21:13, Fernando Israel wrote:

Hi Fernando,

  


So I now have to rephrase the question. Can I have a table within an absolute 
postioned block container go over to a second page it its length requires so ?. 
I guess that the answer is no, but I better ask.



You guess correct.

BTW, it just occurred to me, while re-examining the FO you sent, that the 
'position' property does not apply to fo:block, so it actually serves no 
purpose there.
Specifying the property can almost be seen as wasteful, because it 'overburdens' the 
property parser. Big word, because it does not matter _that_ much, but "less is 
more". :-)

  

If the answer is no, given my description of the objective, can you think of a 
different way of trying to achieve the objective ?.



Let's see...

The block-container will only be broken if its top/left positioning is relative, which FOP does not support. Never mind, because that is not what you want anyway. You would get a page-break, sure enough, but it would still cause _some_ of the content to be clipped. In fact, what would happen if FOP were to implement it, is that the block-container would be broken using the full available page-height, as it does not interact with the absolute-positioned ones. Then, the generated areas on each page are offset by the specified amount. Hardly surprising that nobody has ever even asked questions about this on the user-list (at least AFAIK). 
It doesn't look useful --but I'm straying...


Given the above, and assuming that, in the example you sent, you would only need to see that one 
block flowing to the next page, you could try using space-before (instead of "top") and 
start-indent (instead of "left") to create the displacement effect.

Something like:


  
TEXT 9
 Here is some sample code 
 Here is some sample code 
...

That way, at least that block-container will be split over multiple pages, if necessary. 
Any absolute-positioned content following it, will have its single area on the last page spanned by the preceding, relative-positioned content. Since it is likely not known in advance how many lines will end up on that last page, figuring out the right value for 'top' in such cases would be quite a challenge. Using 'bottom' displacement may offer a way out, here, but still... If there is then yet more following relative-positioned content, it becomes increasingly difficult to manage, since there is no clue as to what the initial offset should be. You would have to resort to using forced breaks to make it a bit easier.


It all really depends on how complex the eventual result can become. If it's 
only a single block that should flow to the next page, and it is not itself 
interrupted/followed by absolute-positioned content, the above would suffice: 
use a regular block-container with space-before for the initial displacement on 
the first page, or even leave that block-container out entirely, and just 
insert the block.

Not sure if this will help, but it's very difficult to say, generically, how 
best to address this, without actually having seen some of the more complex 
cases.



Regards,

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: Content spanning multiple pages issue

2011-07-30 Thread Andreas L. Delmelle
On 30 Jul 2011, at 21:13, Fernando Israel wrote:

Hi Fernando,

> 
> So I now have to rephrase the question. Can I have a table within an absolute 
> postioned block container go over to a second page it its length requires so 
> ?. I guess that the answer is no, but I better ask.

You guess correct.

BTW, it just occurred to me, while re-examining the FO you sent, that the 
'position' property does not apply to fo:block, so it actually serves no 
purpose there.
Specifying the property can almost be seen as wasteful, because it 
'overburdens' the property parser. Big word, because it does not matter _that_ 
much, but "less is more". :-)

> If the answer is no, given my description of the objective, can you think of 
> a different way of trying to achieve the objective ?.

Let's see...

The block-container will only be broken if its top/left positioning is 
relative, which FOP does not support. Never mind, because that is not what you 
want anyway. You would get a page-break, sure enough, but it would still cause 
_some_ of the content to be clipped. In fact, what would happen if FOP were to 
implement it, is that the block-container would be broken using the full 
available page-height, as it does not interact with the absolute-positioned 
ones. Then, the generated areas on each page are offset by the specified 
amount. Hardly surprising that nobody has ever even asked questions about this 
on the user-list (at least AFAIK). 
It doesn't look useful --but I'm straying...

Given the above, and assuming that, in the example you sent, you would only 
need to see that one block flowing to the next page, you could try using 
space-before (instead of "top") and start-indent (instead of "left") to create 
the displacement effect.

Something like:


  
TEXT 9
 Here is some sample code 
 Here is some sample code 
...

That way, at least that block-container will be split over multiple pages, if 
necessary. 
Any absolute-positioned content following it, will have its single area on the 
last page spanned by the preceding, relative-positioned content. Since it is 
likely not known in advance how many lines will end up on that last page, 
figuring out the right value for 'top' in such cases would be quite a 
challenge. Using 'bottom' displacement may offer a way out, here, but still... 
If there is then yet more following relative-positioned content, it becomes 
increasingly difficult to manage, since there is no clue as to what the initial 
offset should be. You would have to resort to using forced breaks to make it a 
bit easier.

It all really depends on how complex the eventual result can become. If it's 
only a single block that should flow to the next page, and it is not itself 
interrupted/followed by absolute-positioned content, the above would suffice: 
use a regular block-container with space-before for the initial displacement on 
the first page, or even leave that block-container out entirely, and just 
insert the block.

Not sure if this will help, but it's very difficult to say, generically, how 
best to address this, without actually having seen some of the more complex 
cases.



Regards,

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



Re: Content spanning multiple pages issue

2011-07-30 Thread Fernando Israel
Hi Andreas,

Thank you for your prompt response. If you hadn't tell me the why I would
have not got to that in a million years. I am glad I have asked and that you
shed the necessary light.

On the basis of your input it is quite clear that I cannot achieve the
objective with the current XSL-FO I am using, so I need to re-design it.

Let me give you the background as to why I am using absolute positioning for
all blocks.

This project is part of an application that has a web client where users
design the document. The web client is a kind of WYSIWYG type of app that
shows the presents the user with a blank canvas, which is the size of the
page they selected -e.g. A4, Legal, etc., along with the margins selected,
and there is a series of tools that allow the user to drop text, images and
tables. In the canvas the user can re-size the blocks and images. We then
take all this sizing, position, and content information in XML format, and
pass it through an XSL-FO stylesheet to produce the input to FOP.  Obviously
the size and position of the content is important because we basically
translate what the user designs in the web app into a PDF that looks the
same as his/her design.

In practice the web app only shows one page in the canvas so it is
implicitly assumed that the output will always be one page. However, as I
mentioned there is one table always and the table length depends on the
number of rows, which in turn depends on dynamic data that we (the server)
does not know upfront. In most cases the table will fit within one page so
there would not be a problem. But I want to deal with the more rare case
when the table length is such that it should go over the first page and into
the second page.

I haven't reflected this variable table in the XSL-FO I posted because I
didn't know that the issue I am facing has to do with absolute positioning.
But essentially the table also lives within an absolute positioned block.

So I now have to rephrase the question. Can I have a table within an
absolute postioned block container go over to a second page it its length
requires so ?. I guess that the answer is no, but I better ask. If the
answer is no, given my description of the objective, can you think of a
different way of trying to achieve the objective ?.

Thank you very much again for your help. It is very much appreciated.

Regards,
Fernando


On Sat, Jul 30, 2011 at 3:45 PM, Andreas L. Delmelle <
andreas.delme...@telenet.be> wrote:

> On 30 Jul 2011, at 17:55, Fernando Israel wrote:
>
> Hi Fernando
>
> > I use FOP 1.0 to produce PDFs.  The issue I am facing is that the content
> of the page is such that it should span over multiple pages but I only get
> one single page PDF file. I believe I am missing something very obvious.
>
> The reason is that *all* the content is wrapped inside absolute-positioned
> block-containers. Those will never, ever trigger a page-break. At worst,
> there will be an overflow condition if the content does not fit, but it will
> never flow to the next page, like a 'regular' block-container. (In XSL-FO
> terminology, regular block-containers will potentially yield multiple
> viewport/reference pairs, whereas absolute-positioned ones will always have
> only one such pair.)
>
> To give advice on how to resolve this (in case it is still necessary), we
> would also need a hint of the intended result.
>
> Let us know if we can be of further assistance.
>
>
> HTH!
>
> Regards
>
> Andreas
>
> -
> To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
>
>


Re: Content spanning multiple pages issue

2011-07-30 Thread Andreas L. Delmelle
On 30 Jul 2011, at 17:55, Fernando Israel wrote:

Hi Fernando

> I use FOP 1.0 to produce PDFs.  The issue I am facing is that the content of 
> the page is such that it should span over multiple pages but I only get one 
> single page PDF file. I believe I am missing something very obvious.

The reason is that *all* the content is wrapped inside absolute-positioned 
block-containers. Those will never, ever trigger a page-break. At worst, there 
will be an overflow condition if the content does not fit, but it will never 
flow to the next page, like a 'regular' block-container. (In XSL-FO 
terminology, regular block-containers will potentially yield multiple 
viewport/reference pairs, whereas absolute-positioned ones will always have 
only one such pair.)

To give advice on how to resolve this (in case it is still necessary), we would 
also need a hint of the intended result.

Let us know if we can be of further assistance.


HTH!

Regards

Andreas

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



Content spanning multiple pages issue

2011-07-30 Thread Fernando Israel
Hi All,

I use FOP 1.0 to produce PDFs.  The issue I am facing is that the content of
the page is such that it should span over multiple pages but I only get one
single page PDF file. I believe I am missing something very obvious.

Here is a sample of the XSL-FO I feed FOP and I am attaching the PDF that
this produces too. As you can see one of the blocks in the flow (TEXT 9) has
over 30 children blocks and, based on their positions on the page, this
would lead to part of the content to spill over a second page.However, as
can be seen in the PDF output attached, the content gets truncated and the
PDF contains just one page.

Is this something to do with my XSL-FO or is it something I am missing of
FOP ?.

Thank you very much in advance.

Regards,
Fernando

http://www.w3.org/1999/XSL/Format";>
  

  
  
  
  
  

  
  

  

  TEXT 1

  
  

  TEXT 2
  TEXT 3

  
  

  TEXT 4

  
  

  TEXT 5
  TEXT 6
  TEXT 7
  TEXT 8

  
  

  TEXT 9
   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code

   Here is some sample code


  

  



FopTest.pdf
Description: Adobe PDF document

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