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 Nathan Carter <na...@gmx.net> on 2002/04/25 09:03:41 UTC
support for PS printer-specific options using PPDs
I currently use PJ for PDF output from a homegrown customer/member
management system, built on JBoss/Postgresql/etc. There are two basic
uses for the PDF output:
1) "letters" that use standard fonts to produce a "mail merged" PDF
form letter - starting with a blank PDF document and text grabbed from
client database
2) "forms" that fill in PDF "form template" with fields from client
database - this was accomplished using jakarta-ORO and string
substitution - we use several fonts, including a barcode font, on the
"writable" areas of these forms.
I'm thinking of moving to iText or FOP for #1, but there's one
particular problem that I can't seem to solve. When the client prints
"letters", they always want the first page to print on letterhead paper
and the second and following pages to print on plain paper. With PS,
you have the ability to set printer-specific options like
paper-tray/type, but PDF doesn't have this capability as far as I know
(I've read both specs pretty carefully). Unfortunately, it's not a
clean "switch trays every page" situation, because some letters end up 3
pages rather than 2 (longer address, extra paragraph, etc.). So there's
no way to render PDF ---ghostscript----->PS, adding "change trays every
page" to the PS at the end. In other words, I have to add the "use tray
x" flag at the time of rendering, which means I must render to PS rather
than PDF.
Ideally, I would be able to use FOP and grab the proper "use tray x"
flag from the PPD for the HP printer I'm using - I've even looked at a
Canon machine called the imageRunner 5000 that allows you to set flags
for switching trays, stapling, and folding (which would be nice for
1000+ person mailings). From checking the main fop page and the fop-dev
archive, it seems that PS output in general, and any PPD capability
specifically, is pretty far off.
From what I can tell, renderX doesn't have PPD features either.
Does anyone have any other ideas?
Nathan
Re: support for PS printer-specific options using PPDs
Posted by Jeremias Maerki <je...@outline.ch>.
Hi Nathan
On 25.04.2002 15:00:29 Nathan Carter wrote:
> Jeremias,
>
> Thanks for your thoughtful response.
>
> Jeremias Maerki wrote:
>
> >Being the one who wrote the PS renderer in the first place, I can
> >comment on a few things:
> >
> >- The PS renderer, as it is now, is more of a proof of concept, than
> > anything else. Some people are using it productively, though.
> >- As you gathered, there are a few things that still need to be done.
> > Here's the todo list from the PSRenderer's javadocs: Character
> > size/spacing, configuration, move to PrintRenderer, maybe improve
> > filters (I'm not very proud of them), add a RunLengthEncode filter
> > (useful for Level 2 Postscript), Improve DocumentProcessColors stuff
> > (probably needs to be configurable, then maybe add a color to
> > grayscale conversion for bitmaps to make output smaller (See
> > PCLRenderer), font embedding, support different character encodings,
> > try to implement image transparency, positioning of images is wrong
> > etc. And of course, there's the missing PPD functionality.
> >
> I'll spend some time looking at the code today or tomorrow - I'm
> assuming that I should look in CVS, and that there is not any wholesale
> rewrite of at least the PS renderer portion going on outside of CVS (I
> saw some confusion about "outside of CVS" rewrites on the fop-dev list).
Not sure what you mean. Anyway, you should just keep in mind that we're
working on two branches in CVS: main branch for redesign and the
maintenance branch where current releases come from. If you want to have
quick results it's probably best to work on the maintenance branch and
we move the code over to the main branch later.
> >- There's also another problem: XSL:FO does not provide any means to
> > specify things like tray selection. These will have to be proprietary
> > solutions. And that means some work as well. What's important here is
> > to have mechanisms that can be reused for PCL later.
> >
> Hmm. I was thinking this morning that it would be ideal to make it
> fully configurable by the client, so that I'm not changing code every
> time they buy a new printer. What would be ideal is to have some sort of
> web-based strict equivalent to GPR
> (http://www.compumetric.com/linux.html ) or XPP (
> http://cups.sourceforge.net/xpp/ ) that would allow me to set paper
> tray, stapling, and folding on a "per-document" ("per-letter") level.
"per-document" is probably not fine-grained enough. It should be
"per-page", at least for tray selection and folding, for example. There
are already quite a few XML standards for job tickets (JDF as an example).
Most of them are huge constructs which means a lot of work. It's
probably easier if we just implemented what we need in a proprietary way,
for now. That means we'll have an extension that enables us to specify
some parameters on fo:root, fo:simple-page-master and probably
fo:page-sequence. I don't know yet how this would look in detail.
> Is there a PCL equivalent of PPD, or would this have to be built
> separately for PS and PCL? (Uggh - this is beginning to sound like a
> big project).
I think PCL can use PPDs, too. I seem to have a PCL-specific PPD for my
Brother HL-1250 on my machine.
And you're right, this will be a rather big project depending on how
much you need.
> At present, we're using PJ to concatenate PDF documents (so that the
> client can print out hundreds of letters in one print job, a critical
> usability feature). With the system from the preceding paragraph in
> place, I could just concatenate PostScript letter that had already been
> generated with the proper tray/staple/fold settings (which may or may
> not work very well given our experience below).
> [[Side Note: At present, we're having plenty of problems using PJ to
> concatenate PDF document. In addition to the "letters" and "forms" PDF
> documents mentioned in my original posting, there are two "sources" of
> PDF documents that we sometimes integrate into the "print stream" -
> 1) a document scanning system that produces TIFF, that we then
> convert to PDF using ImageMagick/Ghostscript
> 2) Word documents that we convert to PDF using Abiword (
> http://www.abiword.org ) and Ghostscript.
> We've determined that the concatenation problems are from poor
> conversion of Word-->PDF, so we're hoping to move to OpenOffice or
> activePDF for this conversion in the not-too-distanct future ]]
We decided to concatenate the PostScript files, not the PDF's, because
we've found this not easier but more reliable, especially when all
PostScript files have been generated by the same converter (Acrobat
Reader). Like this, the PS files all have a similiar structure and are
(relatively) easy to patch. The most difficult thing was rebuilding a
unified font directory and rewriting all font lookups.
> >- Conclusion: Any help is welcome! (Because I haven't got the time yet,
> > to do it. At least, it's on my todo list, because we're currently
> > working with the PDF renderer, then using Acrobat Reader to produce
> > PostScript, which is finally patched with code for tray selection and
> > OMR marks. And this is a suboptimal solution especially since the
> > Acrobat Reader takes between 20 to 50 percent of processing time for a
> > job.)
> >
> >
> This is something you're doing for a client/production system? Is there
> any way I could look at the "code for tray selection and OMR marks" that
> you mention? I'm in New York, not a "competitor" next door in Germany
> :) ( the gmx email is probably confusing).
What we do is creating a system for mass-digital-printing which does
composition and job control over the whole document life-cycle from XML
to the finished envelope that is delivered to the post-office. Well,
that's only the short story...
I don't think management will approve giving this kind of code away.
They have drawn clear lines in that regard. Sorry.
> Many thanks for your thoughts - feel free to move this discussion to
> fop-dev if needed (copying me since I'm not currently subscribed there).
I'll leave it here for the moment. But I'd appreciate if you subscribed
fop-dev if you decide to participate in development.
Cheers,
Jeremias Maerki
Re: support for PS printer-specific options using PPDs
Posted by Nathan Carter <na...@gmx.net>.
Jeremias,
Thanks for your thoughtful response.
Jeremias Maerki wrote:
>Being the one who wrote the PS renderer in the first place, I can
>comment on a few things:
>
>- The PS renderer, as it is now, is more of a proof of concept, than
> anything else. Some people are using it productively, though.
>- As you gathered, there are a few things that still need to be done.
> Here's the todo list from the PSRenderer's javadocs: Character
> size/spacing, configuration, move to PrintRenderer, maybe improve
> filters (I'm not very proud of them), add a RunLengthEncode filter
> (useful for Level 2 Postscript), Improve DocumentProcessColors stuff
> (probably needs to be configurable, then maybe add a color to
> grayscale conversion for bitmaps to make output smaller (See
> PCLRenderer), font embedding, support different character encodings,
> try to implement image transparency, positioning of images is wrong
> etc. And of course, there's the missing PPD functionality.
>
I'll spend some time looking at the code today or tomorrow - I'm
assuming that I should look in CVS, and that there is not any wholesale
rewrite of at least the PS renderer portion going on outside of CVS (I
saw some confusion about "outside of CVS" rewrites on the fop-dev list).
>- There's also another problem: XSL:FO does not provide any means to
> specify things like tray selection. These will have to be proprietary
> solutions. And that means some work as well. What's important here is
> to have mechanisms that can be reused for PCL later.
>
Hmm. I was thinking this morning that it would be ideal to make it
fully configurable by the client, so that I'm not changing code every
time they buy a new printer. What would be ideal is to have some sort of
web-based strict equivalent to GPR
(http://www.compumetric.com/linux.html ) or XPP (
http://cups.sourceforge.net/xpp/ ) that would allow me to set paper
tray, stapling, and folding on a "per-document" ("per-letter") level.
Is there a PCL equivalent of PPD, or would this have to be built
separately for PS and PCL? (Uggh - this is beginning to sound like a
big project).
At present, we're using PJ to concatenate PDF documents (so that the
client can print out hundreds of letters in one print job, a critical
usability feature). With the system from the preceding paragraph in
place, I could just concatenate PostScript letter that had already been
generated with the proper tray/staple/fold settings (which may or may
not work very well given our experience below).
[[Side Note: At present, we're having plenty of problems using PJ to
concatenate PDF document. In addition to the "letters" and "forms" PDF
documents mentioned in my original posting, there are two "sources" of
PDF documents that we sometimes integrate into the "print stream" -
1) a document scanning system that produces TIFF, that we then
convert to PDF using ImageMagick/Ghostscript
2) Word documents that we convert to PDF using Abiword (
http://www.abiword.org ) and Ghostscript.
We've determined that the concatenation problems are from poor
conversion of Word-->PDF, so we're hoping to move to OpenOffice or
activePDF for this conversion in the not-too-distanct future ]]
>- Conclusion: Any help is welcome! (Because I haven't got the time yet,
> to do it. At least, it's on my todo list, because we're currently
> working with the PDF renderer, then using Acrobat Reader to produce
> PostScript, which is finally patched with code for tray selection and
> OMR marks. And this is a suboptimal solution especially since the
> Acrobat Reader takes between 20 to 50 percent of processing time for a
> job.)
>
>
This is something you're doing for a client/production system? Is there
any way I could look at the "code for tray selection and OMR marks" that
you mention? I'm in New York, not a "competitor" next door in Germany
:) ( the gmx email is probably confusing).
Many thanks for your thoughts - feel free to move this discussion to
fop-dev if needed (copying me since I'm not currently subscribed there).
Nathan
>On 25.04.2002 09:03:41 Nathan Carter wrote:
>
>
>>I currently use PJ for PDF output from a homegrown customer/member
>>management system, built on JBoss/Postgresql/etc. There are two basic
>>uses for the PDF output:
>> 1) "letters" that use standard fonts to produce a "mail merged" PDF
>>form letter - starting with a blank PDF document and text grabbed from
>>client database
>> 2) "forms" that fill in PDF "form template" with fields from client
>>database - this was accomplished using jakarta-ORO and string
>>substitution - we use several fonts, including a barcode font, on the
>>"writable" areas of these forms.
>>
>>I'm thinking of moving to iText or FOP for #1, but there's one
>>particular problem that I can't seem to solve. When the client prints
>>"letters", they always want the first page to print on letterhead paper
>>and the second and following pages to print on plain paper. With PS,
>>you have the ability to set printer-specific options like
>>paper-tray/type, but PDF doesn't have this capability as far as I know
>>(I've read both specs pretty carefully). Unfortunately, it's not a
>>clean "switch trays every page" situation, because some letters end up 3
>>pages rather than 2 (longer address, extra paragraph, etc.). So there's
>>no way to render PDF ---ghostscript----->PS, adding "change trays every
>>page" to the PS at the end. In other words, I have to add the "use tray
>>x" flag at the time of rendering, which means I must render to PS rather
>>than PDF.
>>
>>Ideally, I would be able to use FOP and grab the proper "use tray x"
>>flag from the PPD for the HP printer I'm using - I've even looked at a
>>Canon machine called the imageRunner 5000 that allows you to set flags
>>for switching trays, stapling, and folding (which would be nice for
>>1000+ person mailings). From checking the main fop page and the fop-dev
>>archive, it seems that PS output in general, and any PPD capability
>>specifically, is pretty far off.
>>
>> From what I can tell, renderX doesn't have PPD features either.
>>
>>Does anyone have any other ideas?
>>
>>Nathan
>>
>>
>>
>
>
>Cheers,
>Jeremias Maerki
>
>
>
>
Re: support for PS printer-specific options using PPDs
Posted by Jeremias Maerki <je...@outline.ch>.
Being the one who wrote the PS renderer in the first place, I can
comment on a few things:
- The PS renderer, as it is now, is more of a proof of concept, than
anything else. Some people are using it productively, though.
- As you gathered, there are a few things that still need to be done.
Here's the todo list from the PSRenderer's javadocs: Character
size/spacing, configuration, move to PrintRenderer, maybe improve
filters (I'm not very proud of them), add a RunLengthEncode filter
(useful for Level 2 Postscript), Improve DocumentProcessColors stuff
(probably needs to be configurable, then maybe add a color to
grayscale conversion for bitmaps to make output smaller (See
PCLRenderer), font embedding, support different character encodings,
try to implement image transparency, positioning of images is wrong
etc. And of course, there's the missing PPD functionality.
- There's also another problem: XSL:FO does not provide any means to
specify things like tray selection. These will have to be proprietary
solutions. And that means some work as well. What's important here is
to have mechanisms that can be reused for PCL later.
- Conclusion: Any help is welcome! (Because I haven't got the time yet,
to do it. At least, it's on my todo list, because we're currently
working with the PDF renderer, then using Acrobat Reader to produce
PostScript, which is finally patched with code for tray selection and
OMR marks. And this is a suboptimal solution especially since the
Acrobat Reader takes between 20 to 50 percent of processing time for a
job.)
On 25.04.2002 09:03:41 Nathan Carter wrote:
> I currently use PJ for PDF output from a homegrown customer/member
> management system, built on JBoss/Postgresql/etc. There are two basic
> uses for the PDF output:
> 1) "letters" that use standard fonts to produce a "mail merged" PDF
> form letter - starting with a blank PDF document and text grabbed from
> client database
> 2) "forms" that fill in PDF "form template" with fields from client
> database - this was accomplished using jakarta-ORO and string
> substitution - we use several fonts, including a barcode font, on the
> "writable" areas of these forms.
>
> I'm thinking of moving to iText or FOP for #1, but there's one
> particular problem that I can't seem to solve. When the client prints
> "letters", they always want the first page to print on letterhead paper
> and the second and following pages to print on plain paper. With PS,
> you have the ability to set printer-specific options like
> paper-tray/type, but PDF doesn't have this capability as far as I know
> (I've read both specs pretty carefully). Unfortunately, it's not a
> clean "switch trays every page" situation, because some letters end up 3
> pages rather than 2 (longer address, extra paragraph, etc.). So there's
> no way to render PDF ---ghostscript----->PS, adding "change trays every
> page" to the PS at the end. In other words, I have to add the "use tray
> x" flag at the time of rendering, which means I must render to PS rather
> than PDF.
>
> Ideally, I would be able to use FOP and grab the proper "use tray x"
> flag from the PPD for the HP printer I'm using - I've even looked at a
> Canon machine called the imageRunner 5000 that allows you to set flags
> for switching trays, stapling, and folding (which would be nice for
> 1000+ person mailings). From checking the main fop page and the fop-dev
> archive, it seems that PS output in general, and any PPD capability
> specifically, is pretty far off.
>
> From what I can tell, renderX doesn't have PPD features either.
>
> Does anyone have any other ideas?
>
> Nathan
>
Cheers,
Jeremias Maerki