What gives you the impression that the header is allowed multiple times? fop-intermediate-format-ng.xsd says:
<xs:element name="document"> <xs:complexType> <xs:sequence> <xs:element ref="mf:header"/> <xs:element ref="mf:page-sequence" minOccurs="1" maxOccurs="unbounded"/> <xs:element ref="mf:trailer"/> </xs:sequence> </xs:complexType> </xs:element> I'm not surprised there are side-effects if there are multiple headers. Maybe I should have added guards against that. But I've written org.apache.fop.render.intermediate.util.IFConcatenator exactly for the purpose of concatenating IF files. IMO, you've got a bug in the code that concatenates IF files. It's not a FOP problem. On 15.03.2011 09:49:21 mehdi houshmand wrote: > Hi Guys, > > I've been looking into the PS rendering, with an eye to reduce the > size of PS documents. I noticed that when PS documents are created > from concatenated IFs, FOP prints the procsets in a "%%BeginResource: > procset" every time it encounters a <header> tag in the IF. This > doesn't produce invalid PS docs or break any thing else for that > matter, but appears to be completely unnecessary. I checked the DSC > spec (v3 p67), and though this behaviour is allowed, it is intended so > that one can print (to the document) subsets of a large procedure-set > for complex graphical uses. Considering FOP is printing the same > procsets every time, that intended behaviour isn't applicable in FOPs > behaviour. I hacked a quick test to find out if removing these made > any difference what-so-ever to documents, especially with tables with > borders and embedded fonts to utilize a variety of the procedures > defined in the procset. As expected, removing these superfluous > proc-sets makes no difference. > > So, my question is thus; is that FOPs problem? This behaviour only > appears to happen when someone concatenates several IFs without any > intelligence to remove the <header> element from the IF (of which, > arguably, there should only be one anyway). I checked the IF schema, > and this suggests there can be zero to unbounded number of <header> > elements, is there any real need for this? Why would you need more > than one header? Is that a bug in the schema? > > I appreciate much of this is much over muchness but this behaviour > seems counter-intuitive. > > Thanks for the help > > Mehdi > > P.S. If anyone wishes me to produce an example of this behaviour, I'd > be more than happy to. Jeremias Maerki