| From | Sent On | Attachments |
|---|---|---|
| Chris Borg | Mar 7, 2007 10:27 am | |
| Mauritz Jeanson | Mar 8, 2007 9:05 am | |
| Chris Borg | Mar 12, 2007 6:18 am | |
| Bob Stayton | Mar 22, 2007 11:28 pm |
| Subject: | Re: [docbook-apps] InputHandler error - generating PDF | |
|---|---|---|
| From: | Bob Stayton (bo...@sagehill.net) | |
| Date: | Mar 22, 2007 11:28:04 pm | |
| List: | org.oasis-open.lists.docbook-apps | |
That short sample produces a page-sequence whose fo:flow contains a single fo:wrapper element. I think fo:flow requires at least one fo:block element.
The fo:wrapper is used for indexterms to provide a zero-size anchor in the FO file for references to that point from the index. The fo:wrapper takes an id attribute for that purpose.
There is no better element to use as the holder of the id. A block would have space consequences, even if empty because it affects a block that follows. An fo:inline is not legal outside of blocks.
The "PDF destinations" he is referring to is a cross reference from another PDF file. Such references have a PDF filename followed by a "#fragment" identifier to link into the PDF file. The id can be used for such references, but in this case, the reference is internal from the index.
The fop1.extensions is a DocBook XSL stylesheet parameter that should be used when processing with fop 0.93 and above (anticipating fop 1.0 when it arrives). When that parameter is set, the stylesheet makes some adjustments for processor differences.
I recommend you put your indexterms inside an element that generates a block, which is just about anything inside chapter.
Bob Stayton Sagehill Enterprises DocBook Consulting bo...@sagehill.net
----- Original Message ----- From: "Chris Borg" <Chri...@AssetHouse.com> To: "'Mauritz Jeanson'" <mj...@johanneberg.com>; <docb...@lists.oasis-open.org> Sent: Monday, March 12, 2007 5:19 AM Subject: RE: [docbook-apps] InputHandler error - generating PDF
Hi,
The problem is with the source file, although it is valid. It seems that <chapter> <indexterm></indexterm> </chapter>
causes FOP to fail with the error stated despite being valid. Putting the indexterm inside <para> tags stops FOP failing.
I found the following thread on the fop-dev site (http://www.mail-archive.com/fop-dev@xmlgra...@). This indicates that FOP has had the ClassCastException fixed. However, I am not sure - if there were modifications required in Docbook and if they have been made. - what PDF destination means - what fop1.extensions are used for and how this relates to this issue.
Regards Chris
-----Original Message----- From: Mauritz Jeanson [mailto:mj...@johanneberg.com] Sent: 08 March 2007 17:06 To: 'Chris Borg'; docb...@lists.oasis-open.org Subject: RE: [docbook-apps] InputHandler error - generating PDF
-----Original Message----- From: Chris Borg
07-Mar-2007 17:55:45 org.apache.fop.cli.InputHandler error SEVERE: javax.xml.transform.TransformerException: org.apache.fop.layoutmgr.inline.WrapperLayoutManager
Prior to the error I marked up my source XML with some index tags. I am not sure if this could be related but thought I would mention it just in case. Also, a .fo is being generated successfully.
Can anyone guide me as to how I start troubleshooting this kind of error?
Here are a few suggestions:
* Make sure that the input document is valid. * Create output both with and without your customization layer (if you have one) to see if there is any difference. * Narrow down the problem by making the troublesome source file as small as possible. * Google for "org.apache.fop.cli.InputHandler error" (and other relevant messages). That might give you some clues. * Try another FO processor, for example XEP.
If this gets you nowhere, post a small sample source file to the list for others to try. If you do that, please also specify the version of the stylesheets and the version of FOP that you use.
/MJ





