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 <[email protected] > 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 <[email protected]>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<[email protected]> >>> For additional commands, e-mail: >>> fop-users-help@xmlgraphics.**apache.org<[email protected]> >>> >>> >>> >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> fop-users-unsubscribe@**xmlgraphics.apache.org<[email protected]> >> For additional commands, e-mail: >> fop-users-help@xmlgraphics.**apache.org<[email protected]> >> >> >
