Inserting printer bin instructions or hints in a PDF ?

  • Does someone knows if there are *any* provisions in the PDF specification to insert printer bin selection codes or hints? Such instructions would only be significant for the exact printer it was designed for and probably ignored as invalid (silently) in most cases ?

    The goal is this: find a way to design the printer output of a software such that it is 100% PDF based (always printing to PDF) even though sometimes the user prints "directly" to the printer. In such case the PDF would be produced and stored ("behind the curtain") and printed immediately. It offers a very nice and easy way to archive each and every printout done (for some days or weeks). The one thing which seems without solution is that the software need to address multiple bins : for the first copy of the multi-page invoice, send page one to this bin A, send page 2 and others to that bin B. And for all other copies of that same document, send for instance all pages to bin C.

    These two requirements (wanting a PDF based solution and support for printer bins) seems contradictory and without solution. Is there some idea here?

    Another idea I have would be to structure the output such that each page is generated independently of others and each i printed immediately after buying finalized, to the right printer bin. The collection of individual pages can then be automatically be appended to save a single PDF file of the document even though the individuals pages where printed to various bins and papers.

    But this might pose some performance issues. Or PDF size issues. I am not sure it is worth some coding to test it. Any suggestion ?

  • Could I somehow setup my windows printing task such as to intercept it in EMF, get pdfControl or rtftopdf to convert the EMF to PDF, and then let windows continue on and print the EMF itself ?

    Maybe with such an organization I could still use printer bins (I guess those calls setting up the bins end up in some form in the EMF) and yet capture a PDF copy (I can loose bins assignments by then) of each of my prints without duplicating the effort ?

    I am considering pdfControl for licensing but I' ready to upgrade my goals to rtf2pdf if it helps fits that scheme.

    Any ideas ? (I apologize as these posts are not really product support oriented but go a little bit beyond).

  • Or maybe really inject some comments records/tags in the PDF with the printer bin selection (which would be ignored and invisible when displayed printed) but could be interpreted while printing the PDF. That would imply collaboration from both pdfControl (to let insert such arbitrary 'comments' before some pages ion the PDF) and pdfView (so that printing can optionally interpret those comments as printer bin assignments).

    My goal is not to be able to print the PDF file *later* and still follow the bins assignments. No, I just need to follow the bins assignments when the PDF is printed the first time when it is created.

  • I found a very simple way to solve the above needs and it works well, and does not require any special support of any kind in the libraries or capturing EMF output from the spooler.

    I just do the printing twice at the same time. When the application opens a printer, I silently also start a PDF. I re-use the device metrics of the printer device context to setup my pdf environment, so that all code calculating positions and sizes gives results valid for both print supports.

    When a new page start, I have a win32 StartPage and a wpdfStartPage, and so on... Every TextOut, and other calls are simply doubled, on the printer DC and on the pdf DC. Fonts can be shared (selected both in the print DC and in the pdf DC at the same time), as well as some other resources. This is very convenient as I already had some generic methods encapsulating the gdi primitives. Of course, I play with paper bins/trays as requested by the app on the real print and simply ignores these for the pdf side. When I'm done closing the print job, I'm done closing the pdf file and that PDF file is inherently built as a visual clone of the direct printout. This is exactly what I was looking for in this forum thread and it is really simple.

    This is actually a superb demonstration of how nicely the pdfControl acts as a gdi device context and how easy it is to migrate a common gdi printing source code to one doing pdf output.

    I will now cleanup all these experiments and within some days I will order the needed commercial licenses.