xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fernando Israel <fernando.isr...@kognoz.com>
Subject Re: Content spanning multiple pages issue
Date Fri, 05 Aug 2011 14:28:18 GMT
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 <rsargent@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<fop-users-unsubscribe@xmlgraphics.apache.org>
>>> For additional commands, e-mail: fop-users-help@xmlgraphics.**apache.org<fop-users-help@xmlgraphics.apache.org>
>>>
>>>
>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: fop-users-unsubscribe@**xmlgraphics.apache.org<fop-users-unsubscribe@xmlgraphics.apache.org>
>> For additional commands, e-mail: fop-users-help@xmlgraphics.**apache.org<fop-users-help@xmlgraphics.apache.org>
>>
>>
>

Mime
View raw message