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/20 13:49:54 UTC
Postscript and Intermediate Format Post processing
Hey Guys,
Possibly a rhetorical question - but thought I might ask regardless.
Playing with postscript and implementing printer specific functions within
the Intermediate format.
To-date - I have been implementing a certain amount of commands within the
intermediate file to achieve my goals, things like;
<ps:ps-setup-code name=""
xmlns:ps="apache:fop:extensions:postscript"><< /OutputType (FINISHER
TRAY) >> setpagedevice</ps:ps-setup-code>
<ps:ps-setup-code name="media-selection"
xmlns:ps="apache:fop:extensions:postscript"><< /MediaPosition 0
>> setpagedevice</ps:ps-setup-code>
<ps:ps-setup-code name="output-tray"
xmlns:ps="apache:fop:extensions:postscript"><< /Duplex true >>
setpagedevice</ps:ps-setup-code>
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.
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
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
Re: Postscript and Intermediate Format Post processing
Posted by Chris Bowditch <bo...@hotmail.com>.
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