[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fop-dev
Subject:    Re: Repeated Procsets in PS
From:       Jeremias Maerki <dev () jeremias-maerki ! ch>
Date:       2011-03-18 16:01:07
Message-ID: 20110318170106.CA2B.60BA733C () jeremias-maerki ! ch
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]