What do you mean by "postscript parser"? A PostScript interpreter or a DSC parser like this one? http://xmlgraphics.apache.org/commons/postscript.html#dsc
On 22.09.2010 00:56:49 Martin Edge wrote: > 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 Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org