What gives you the impression that the header is allowed multiple times?

fop-intermediate-format-ng.xsd says:

  <xs:element name="document">
        <xs:element ref="mf:header"/>
        <xs:element ref="mf:page-sequence" minOccurs="1" maxOccurs="unbounded"/>
        <xs:element ref="mf:trailer"/>

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
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

Reply via email to