xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TomWilcox <wil...@hp.com>
Subject Re: AW: AW: AW: AW: Area Tree Handling
Date Tue, 14 Jul 2009 14:43:11 GMT

Cheers Georg,

I look forward to getting into the IF however I was under the impression it
is still very much in the development phase..


Geord Datterl wrote:
> 
> What I did and what might help you too: I need to build a FO file (no
> transformation), so I built wrappers around the different FO constructs,
> set the attributes through getter and setter methods and build the FO file
> in memory. Then I can change any attribute by a simple method call, as
> long as I still have a reference to the interesting Block object. When I'm
> satisfied, a toString call to the root element generates the complete FO
> file.  
> 

I do have something similar to that which I think can be modified to do the
job.

Thanks,
Tom


Georg Datterl wrote:
> 
> Hi Tom, 
> 
> First, AT ist going out of style, as far as I understood. The new
> IntermediateFormat will replace it. Second, I don't see how an API would
> help you. Of course, you can modify the AT objects and for example, add
> text. But to get a meaningfull result, the whole breaking/layouting, which
> results in the AT, would have to be redone, so Fop would have to accept
> your changes, revert them to FO, then layout again. It's by far easier and
> safer, if you make your changes in the FO file and then layout again. Or
> Fop would need an AT-to-AT converter, which doesn't sound quite possible
> to me. 
> 
> What I did and what might help you too: I need to build a FO file (no
> transformation), so I built wrappers around the different FO constructs,
> set the attributes through getter and setter methods and build the FO file
> in memory. Then I can change any attribute by a simple method call, as
> long as I still have a reference to the interesting Block object. When I'm
> satisfied, a toString call to the root element generates the complete FO
> file.  
> 
> Mit freundlichen Grüßen
>  
> Georg Datterl
>  
> ------ Kontakt ------
>  
> Georg Datterl
>  
> Geneon media solutions gmbh
> Gutenstetter Straße 8a
> 90449 Nürnberg
>  
> HRB Nürnberg: 17193
> Geschäftsführer: Yong-Harry Steiert 
> 
> Tel.: 0911/36 78 88 - 26
> Fax: 0911/36 78 88 - 20
>  
> www.geneon.de
>  
> Weitere Mitglieder der Willmy MediaGroup:
>  
> IRS Integrated Realization Services GmbH:    www.irs-nbg.de 
> Willmy PrintMedia GmbH:                            www.willmy.de
> Willmy Consult & Content GmbH:                 www.willmycc.de 
> -----Ursprüngliche Nachricht-----
> Von: TomWilcox [mailto:wilcox@hp.com] 
> Gesendet: Dienstag, 14. Juli 2009 15:16
> An: fop-users@xmlgraphics.apache.org
> Betreff: Re: AW: AW: AW: Area Tree Handling
> 
> 
> Thanks Georg,
> 
> That seems like the approach for me :). 
> 
> However, I would like to propose a potentially useful future feature of
> FOP would be the ability to do this using Java objects with a view for
> optimising modifications of document fragments such as a subtree of the AT
> through an API (as I think either yourself or Andreas mentioned earlier).
> Any ideas where I post suggestions for FOP features?
> 
> Cheers,
> Tom
> 
> 
> Georg Datterl wrote:
>> 
>> Hi Tom,
>> 
>> In that case I'd take the interesting fo block, wrap it with a default 
>> page and render it. Of course the page is overhead, but other than 
>> that you only render the interesting block. When you are satisfied 
>> with it, continue with the next block. Only when all blocks are 
>> finished, combine them to a document. Of course, this does not work, 
>> when you have to think about page breaks. I have a similar problem 
>> with tables and cell content which has to be duplicated on the next 
>> page, if there's a break. In the end, I generate the whole stuff over 
>> and over again, because each table has to know exactly where on the 
>> page it starts. Horrible. But customer wants it that way, so what can I
>> do?
>> 
>> Regards,
>>  
>> Georg Datterl
>>  
>> ------ Kontakt ------
>>  
>> Georg Datterl
>>  
>> Geneon media solutions gmbh
>> Gutenstetter Straße 8a
>> 90449 Nürnberg
>>  
>> HRB Nürnberg: 17193
>> Geschäftsführer: Yong-Harry Steiert
>> 
>> Tel.: 0911/36 78 88 - 26
>> Fax: 0911/36 78 88 - 20
>>  
>> www.geneon.de
>>  
>> Weitere Mitglieder der Willmy MediaGroup:
>>  
>> IRS Integrated Realization Services GmbH:    www.irs-nbg.de 
>> Willmy PrintMedia GmbH:                            www.willmy.de
>> Willmy Consult & Content GmbH:                 www.willmycc.de 
>> -----Ursprüngliche Nachricht-----
>> Von: TomWilcox [mailto:wilcox@hp.com]
>> Gesendet: Montag, 13. Juli 2009 16:30
>> An: fop-users@xmlgraphics.apache.org
>> Betreff: Re: AW: AW: Area Tree Handling
>> 
>> 
>> Georg,
>> 
>> Sorry I think I have explained this badly (or completely wrong)...
>> 
>> I am trying to take some FO, render the AT, then look at 
>> fragments/nodes of the AT, then modify the FO related to that fragment 
>> and regenerate the AT for that fragment. Then reevaluate the AT and if 
>> my criterion are satisfied, I will render a PDF from the AT.
>> 
>> What I am trying to do is take some text/image content and fill blocks 
>> of set size and position. At the moment I have a guess at how much 
>> space the text and images take up in the block and then output FO 
>> which is converted into a PDF. This produces page layouts with heavy
>> over/underflow..
>> 
>> I am constrained to use blocks of a set size and position, there I 
>> would like to know if I can access an intermediate format that gives 
>> me the amount of space left in the block and would allow me to add 
>> more text/images in order to fill the block.
>> 
>> Cheers,
>> Tom
>> 
>> 
>> Georg Datterl wrote:
>>> 
>>> Hi Tom,
>>> 
>>> I'm not quite sure I understand what you want to do. You are 
>>> rendering FO to AT, manipulate the AT and then generate a PDF. I 
>>> don't think you can render the PDF, then manipulate the AT and 
>>> rerender the changed nodes into the previously generated PDF. You can 
>>> of course generate the AT, then manipulate it, then generate the PDF 
>>> based on the manipulated AT.
>>> 
>>> Regards,
>>>  
>>> Georg Datterl
>>>  
>>> ------ Kontakt ------
>>>  
>>> Georg Datterl
>>>  
>>> Geneon media solutions gmbh
>>> Gutenstetter Straße 8a
>>> 90449 Nürnberg
>>>  
>>> HRB Nürnberg: 17193
>>> Geschäftsführer: Yong-Harry Steiert
>>> 
>>> Tel.: 0911/36 78 88 - 26
>>> Fax: 0911/36 78 88 - 20
>>>  
>>> www.geneon.de
>>>  
>>> Weitere Mitglieder der Willmy MediaGroup:
>>>  
>>> IRS Integrated Realization Services GmbH:    www.irs-nbg.de 
>>> Willmy PrintMedia GmbH:                            www.willmy.de
>>> Willmy Consult & Content GmbH:                 www.willmycc.de 
>>> -----Ursprüngliche Nachricht-----
>>> Von: TomWilcox [mailto:wilcox@hp.com]
>>> Gesendet: Montag, 13. Juli 2009 12:06
>>> An: fop-users@xmlgraphics.apache.org
>>> Betreff: Re: AW: Area Tree Handling
>>> 
>>> 
>>> Thanks Georg,
>>> 
>>> That's great. I was doing something a bit similar however I did not 
>>> use the sax result to get a node of the DOM tree and traverse using 
>>> XPath.
>>> 
>>> I am not sure this will be efficient enough for me as I need to 
>>> traverse, modify and then render various nodes repeatedly in a very 
>>> short space of time. I was keen to find a method that would allow me 
>>> to alter and reevaluate a fragment of the area tree (rerendering that 
>>> part of the AT using FOP without wasting time, rendering the rest).
>>> 
>>> So I don't suppose anyone knows a way to handle, manipulate and 
>>> re-render a fragment of the area tree using FOP?
>>> 
>>> I will keep experimenting in the meantime!
>>> 
>>> Cheers,
>>> Tom
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Georg Datterl wrote:
>>>> 
>>>> Hi Tom,
>>>> 
>>>> I get the area tree using
>>>> 
>>>>             FOUserAgent foUserAgent = getFopFactory().newFOUserAgent();
>>>>             Transformer transformer = 
>>>> getMultipassFactory().newTransformer();
>>>>             TransformerHandler handler = 
>>>> getMultipassFactory().newTransformerHandler();
>>>>             DOMResult domResult = new DOMResult();
>>>>             handler.setResult(domResult);
>>>> 
>>>>             org.apache.fop.render.Renderer targetRenderer =
>>>>             foUserAgent.getRendererFactory().createRenderer(
>>>>                             foUserAgent, MimeConstants.MIME_PDF);
>>>> 
>>>>             XMLRenderer renderer = new XMLRenderer();
>>>>             renderer.mimicRenderer(targetRenderer);
>>>>             renderer.setContentHandler(handler);
>>>>             renderer.setUserAgent(foUserAgent);
>>>> 
>>>>             foUserAgent.setRendererOverride(renderer);
>>>>             
>>>>             Fop fop =
>>>> getFopFactory().newFop(MimeConstants.MIME_FOP_AREA_TREE, foUserAgent);
>>>>             Result res = new SAXResult(fop.getDefaultHandler());
>>>>             transformer.transform(source, res);
>>>>             org.w3c.dom.Document doc = domResult.getNode();
>>>> 
>>>> Then I get values from the tree through Xpath
>>>> 
>>>> 		XPathFactory factory=XPathFactory.newInstance();
>>>> 		XPath xPath=factory.newXPath(); 
>>>> 		NodeList nl =
>>>> (NodeList)xPath.evaluate("//block[@prod-id='"+DT_TAG+id+"']", doc, 
>>>> XPathConstants.NODESET);
>>>> 		xPath.evaluate(".//block[@prod-id='"+L1_TAG+id+"']/@bpd",
>>>> nl.item(i),
>>>> XPathConstants.NUMBER)
>>>> 
>>>> The blocks I'm interested in have well-known ids and I'm interested 
>>>> in more than one information below the node with id DT_TAGxx, that's 
>>>> why I use a nodelist. When you find a smarter way to get the 
>>>> information, please tell me, cause this xpath solution is not very 
>>>> fast in large documents...
>>>> 
>>>> Regards,
>>>>  
>>>> Georg Datterl
>>>>  
>>>> ------ Kontakt ------
>>>>  
>>>> Georg Datterl
>>>>  
>>>> Geneon media solutions gmbh
>>>> Gutenstetter Straße 8a
>>>> 90449 Nürnberg
>>>>  
>>>> HRB Nürnberg: 17193
>>>> Geschäftsführer: Yong-Harry Steiert
>>>> 
>>>> Tel.: 0911/36 78 88 - 26
>>>> Fax: 0911/36 78 88 - 20
>>>>  
>>>> www.geneon.de
>>>>  
>>>> Weitere Mitglieder der Willmy MediaGroup:
>>>>  
>>>> IRS Integrated Realization Services GmbH:    www.irs-nbg.de 
>>>> Willmy PrintMedia GmbH:                            www.willmy.de
>>>> Willmy Consult & Content GmbH:                 www.willmycc.de 
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: TomWilcox [mailto:wilcox@hp.com]
>>>> Gesendet: Freitag, 10. Juli 2009 18:52
>>>> An: fop-users@xmlgraphics.apache.org
>>>> Betreff: Area Tree Handling
>>>> 
>>>> 
>>>> Hi,
>>>> 
>>>> First of all, I am a FOP dummy. I can make PDFs from FO but I don't 
>>>> know about the inner workings.
>>>> 
>>>> I have FOP 0.95 embedded in my Java application. I would like to 
>>>> construct an FO document and modify/examine the AreaTree for it on 
>>>> the fly.
>>>> 
>>>> This is in an attempt to fill blocks (of set size and position) on a 
>>>> page with text/graphics and until the areatree info shows that block 
>>>> is full.
>>>> 
>>>> I would like to do this as fast as possible and I thought this would 
>>>> imply the best route is to get hold of the areatree object in my 
>>>> application and modify/access the objects of interest. (Or, failing 
>>>> that, to get hold area tree xml fragments maybe)..
>>>> 
>>>> Can anyone tell me how I might go about achieving this?
>>>> 
>>>> Or even better, can anyone point me in the direction of any good 
>>>> tutorials/examples that show Java code using embedded FOP to 
>>>> generate an area tree object for an FO stream/file and then modify 
>>>> it with code..?
>>>> 
>>>> That would be awesome :)
>>>> 
>>>> Thanks in advance,
>>>> Tom
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Area-Tree-Handling-tp24431098p24431098.html
>>>> Sent from the FOP - Users mailing list archive at Nabble.com.
>>>> 
>>>> 
>>>> --------------------------------------------------------------------
>>>> - To unsubscribe, e-mail: 
>>>> fop-users-unsubscribe@xmlgraphics.apache.org
>>>> For additional commands, e-mail: 
>>>> fop-users-help@xmlgraphics.apache.org
>>>> 
>>>> 
>>>> --------------------------------------------------------------------
>>>> - To unsubscribe, e-mail: 
>>>> fop-users-unsubscribe@xmlgraphics.apache.org
>>>> For additional commands, e-mail: 
>>>> fop-users-help@xmlgraphics.apache.org
>>>> 
>>>> 
>>>> 
>>> 
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Area-Tree-Handling-tp24431098p24458974.html
>>> Sent from the FOP - Users mailing list archive at Nabble.com.
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>>> For additional commands, e-mail: 
>>> fop-users-help@xmlgraphics.apache.org
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>>> For additional commands, e-mail: 
>>> fop-users-help@xmlgraphics.apache.org
>>> 
>>> 
>>> 
>> 
>> --
>> View this message in context:
>> http://www.nabble.com/Area-Tree-Handling-tp24431098p24462824.html
>> Sent from the FOP - Users mailing list archive at Nabble.com.
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>> 
>> 
>> 
> 
> --
> View this message in context:
> http://www.nabble.com/Area-Tree-Handling-tp24431098p24479220.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Area-Tree-Handling-tp24431098p24481019.html
Sent from the FOP - Users mailing list archive at Nabble.com.


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


Mime
View raw message