Ah beautiful! Have already written a postscript parser, but will try this and pull it out :-)
Thanks Chris :-) --------------- On 22/09/2010, at 12:33 AM, Chris Bowditch <bowditch_ch...@hotmail.com> wrote: > > Martin Edge wrote: >> Hey Guys, > > Hi Martin, > > <snip/> > >> Up till now, this has served me well, and larger commercial printers have no >> quams in dealing with the output. However, today, whilst trying to print on >> our FujiXerox ApeosPort 650I (I'd say a SME sized printer) - the duplex >> functions were not working correctly. >> >> This turned out to be because the printer is finicky enough to have a >> problem if on the reverse side of a duplex set, the PageSize is defined, it >> ignores the request completely. I found if I remove the offending Page Size >> (and other codes I may have added), the process works. > > Actually this problem is not only limited to the Printer model you mention. I > have encountered this behaviour on about 50% of all PS Printers. To solve > this problem we added an option to FOP to only put entries into the > pagedevice dictionary, such as the /PageSize entry, when they change. This > option is rather cryptically named dsc-compliant. If you add the following > element to the PS Renderer section of fop.xconf you should find that duplex > starts working again! > > <dsc-compliant>false</dsc-compliant> > > Thanks, > > Chris > >> >> This is the offending section: >> %FOPBeginSetPageDevice >> << >> /PageSize [595 842] >> /ImagingBBox null >>>> setpagedevice >> %FOPEndSetPageDevice >> >> So; if I attempt to remove the width/height attributes from the page >> definition within the page sequence, as per below; >> <page index="0" name="1" page-master-name="basicPage" width="595275" >> height="841889"> >> >> The FOP parser gets narky with me and talks about a number format exception >> ( I assume translating the lack of width/height to output ): >> >> javax.xml.transform.TransformerException: java.lang.NumberFormatException: >> null >> at >> org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:302) >> at >> org.apache.fop.cli.IFInputHandler.renderTo(IFInputHandler.java:77) >> at org.apache.fop.cli.Main.startFOP(Main.java:174) >> at org.apache.fop.cli.Main.main(Main.java:205) >> Caused by: javax.xml.transform.TransformerException: >> java.lang.NumberFormatException >> >> So, the rhetorical part of the question is - is it worth trying to modify >> FOP (and would I have my fingers removed) to deal with the lack of a >> width/height in the transformer to Postscript, or am I forced to write a >> secondary post processor on the PostScript file to look for a duplex, and >> then remove those lines for the following page? >> >> Hopefully, this makes sense. >> >> Thanks >> Martin >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org >> For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org >> >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org > For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
