Re: Content spanning multiple pages issue

[Fernando Israel <fe...@kognoz.com>]

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 <rs...@xmission.com> 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,
>>
>>
>>
>>> <snip />
>>> 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:
>>
>> <fo:block-container space-before="8.3cm" start-indent="1cm" width="auto"
>> height="auto">
>>  <fo:block start-indent="0" font-family="Comic Sans MS,cursive"
>> font-size="16px" font-weight="700" font-style="normal" text-align="left"
>> color="rgb(0,0,0)" padding="4px">
>>    <fo:block>TEXT 9</fo:block>
>>    <fo:block> Here is some sample code </fo:block>
>>    <fo:block> Here is some sample code </fo:block>
>> ...
>>
>> 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-unsubscribe@**xmlgraphics.apache.org<fo...@xmlgraphics.apache.org>
>> For additional commands, e-mail: fop-users-help@xmlgraphics.**apache.org<fo...@xmlgraphics.apache.org>
>>
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: fop-users-unsubscribe@**xmlgraphics.apache.org<fo...@xmlgraphics.apache.org>
> For additional commands, e-mail: fop-users-help@xmlgraphics.**apache.org<fo...@xmlgraphics.apache.org>
>
>

Re: Content spanning multiple pages issue

[Fernando Israel <fe...@kognoz.com>]

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 <fernando.israel@kognoz.com
> 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 <rs...@xmission.com>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,
>>>
>>>
>>>
>>>> <snip />
>>>> 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:
>>>
>>> <fo:block-container space-before="8.3cm" start-indent="1cm" width="auto"
>>> height="auto">
>>>  <fo:block start-indent="0" font-family="Comic Sans MS,cursive"
>>> font-size="16px" font-weight="700" font-style="normal" text-align="left"
>>> color="rgb(0,0,0)" padding="4px">
>>>    <fo:block>TEXT 9</fo:block>
>>>    <fo:block> Here is some sample code </fo:block>
>>>    <fo:block> Here is some sample code </fo:block>
>>> ...
>>>
>>> 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-unsubscribe@**xmlgraphics.apache.org<fo...@xmlgraphics.apache.org>
>>> For additional commands, e-mail: fop-users-help@xmlgraphics.**apache.org<fo...@xmlgraphics.apache.org>
>>>
>>>
>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: fop-users-unsubscribe@**xmlgraphics.apache.org<fo...@xmlgraphics.apache.org>
>> For additional commands, e-mail: fop-users-help@xmlgraphics.**apache.org<fo...@xmlgraphics.apache.org>
>>
>>
>