You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Martin Edge <Ma...@intellimail.com.au> on 2010/09/22 00:56:49 UTC
Re:
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 <bo...@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-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
RE: Postscript parser
Posted by Martin Edge <Ma...@intellimail.com.au>.
Something to repair the unnecessary page dimensions on the duplex side of a
page.
Apparently the DSC setting will fix what I have manually fixed now.
Thanks
Martin
-----Original Message-----
From: Jeremias Maerki [mailto:dev@jeremias-maerki.ch]
Sent: Wednesday, 29 September 2010 5:44 PM
To: fop-users@xmlgraphics.apache.org
Subject: Re: Postscript parser
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 <bo...@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-unsubscribe@xmlgraphics.apache.org
> >> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> >>
> >>
> >>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Postscript parser
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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 <bo...@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-unsubscribe@xmlgraphics.apache.org
> >> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> >>
> >>
> >>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org