Jeremias,

This topic is very interesting me. I am also stuck with the tray selection.
Can I have the "code for tray selection and OMR marks" for patching
PostScript file please?

Thanks
Mark


-----Original Message-----
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Sent: Thursday, 25 April 2002 22:32
To: [EMAIL PROTECTED]
Subject: Re: support for PS printer-specific options using PPDs


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

Reply via email to