We have a very large collection of PDFs and TIFs and need to generate
hardcopy for distribution.  Each document has pre-defined requirements
for number of copies at each size and target network printer, e.g.
print 30 copies of a.pdf to fit 11X17 on printerB, 20 copies to fit
ANSI E on printerC, and 10 copies to fit 8 1/2 X 11 on printer B.  We
want to programmatically accomplish the task from VB, VBScript,
JavaScript, VBA, WSH, or another application.  Our environment is all
Win2K (servers and workstations), IE 5.5, and currently Acrobat and
Reader 5.

We've looked at the Acrobat IAC docs, but none of the commandline,
DDE, or OLE commands seem to give us the control we need.  Nor does
InvokeVerb to launch the associated print command based on Windows
Explorer file associations.

We've looked at some third-party tools, but it's difficult to tell
from online documentation whether these meet our needs completely. 
And, most seem like overkill, since we don't need to create the PDFs.

Any recommendations, code examples, or hints would be greatly
appreciated.

Thanks,
Bruce

Bruce Hensley wrote:

> We have a very large collection of PDFs and TIFs and need to generate
> hardcopy for distribution.  Each document has pre-defined requirements
> for number of copies at each size and target network printer, e.g.
> print 30 copies of a.pdf to fit 11X17 on printerB, 20 copies to fit
> ANSI E on printerC, and 10 copies to fit 8 1/2 X 11 on printer B.  We
> want to programmatically accomplish the task from VB, VBScript,
> JavaScript, VBA, WSH, or another application.  Our environment is all
> Win2K (servers and workstations), IE 5.5, and currently Acrobat and
> Reader 5.
> 
> We've looked at the Acrobat IAC docs, but none of the commandline,
> DDE, or OLE commands seem to give us the control we need.  Nor does
> InvokeVerb to launch the associated print command based on Windows
> Explorer file associations.
> 
> We've looked at some third-party tools, but it's difficult to tell
> from online documentation whether these meet our needs completely.
> And, most seem like overkill, since we don't need to create the PDFs.
> 
> Any recommendations, code examples, or hints would be greatly
> appreciated.
> 
> Thanks,
> Bruce

You may have noticed my posting on "printer control", which specifies a
similar requirement.  I am coming to the conclusion that PDF was not such a
great format to have chosen because this stuff seems so hard to do, but
OTOH what else is there?  Word is useless at printer control - & windows
will let you change the tray of the 1st page but little else, and anyway we
need to do this programatically, as yourselves. So if you do find a way
(preferably which doesn't rely on windows) I'd love to hear it.

Am I missing the point though, and PDF is simly the wrong format to have
chosen for this.  There must be big print houses that do this stuff -
presumably they don't require operator intervention?

Thanks
Graham Nicholls
-- 
Rock Computer Consultancy:
The answer's always "yes"!

Graham Nicholls wrote:

> Bruce Hensley wrote:
> 
> 
>>We have a very large collection of PDFs and TIFs and need to generate
>>hardcopy for distribution.  Each document has pre-defined requirements
>>for number of copies at each size and target network printer, e.g.
>>print 30 copies of a.pdf to fit 11X17 on printerB, 20 copies to fit
>>ANSI E on printerC, and 10 copies to fit 8 1/2 X 11 on printer B.  We
>>want to programmatically accomplish the task from VB, VBScript,
>>JavaScript, VBA, WSH, or another application.  Our environment is all
>>Win2K (servers and workstations), IE 5.5, and currently Acrobat and
>>Reader 5.
>>
>>We've looked at the Acrobat IAC docs, but none of the commandline,
>>DDE, or OLE commands seem to give us the control we need.  Nor does
>>InvokeVerb to launch the associated print command based on Windows
>>Explorer file associations.
>>
>>We've looked at some third-party tools, but it's difficult to tell
>>from online documentation whether these meet our needs completely.
>>And, most seem like overkill, since we don't need to create the PDFs.
>>
>>Any recommendations, code examples, or hints would be greatly
>>appreciated.
>>
>>Thanks,
>>Bruce
> 
> 
> You may have noticed my posting on "printer control", which specifies a
> similar requirement.  I am coming to the conclusion that PDF was not such a
> great format to have chosen because this stuff seems so hard to do, but
> OTOH what else is there?  Word is useless at printer control - & windows
> will let you change the tray of the 1st page but little else, and anyway we
> need to do this programatically, as yourselves. So if you do find a way
> (preferably which doesn't rely on windows) I'd love to hear it.
> 
> Am I missing the point though, and PDF is simly the wrong format to have
> chosen for this.  There must be big print houses that do this stuff -
> presumably they don't require operator intervention?
> 
> Thanks
> Graham Nicholls

Graham,

I'm sure you will get definitive answers to your questions from the 
experts here, but if the definitive answer is No, let me offer a 
somewhat different approach. This describes the way a similar problem 
was solved a decade ago (long ago, far away) and thus may not be 
relevant; but the logic of it may appeal to you.

We converted all documents to some language the RIP understood (it was a 
fairly sophisticated RIP that accepted PS, TIFF, CCITT, and a couple of 
other formats IIRC, in addition to its native PCL) and stored them on 
the network in our own working directories. We then prepared a job 
ticket, using a piece of Kodak software called Lionheart, I think (or 
something like that) on which we listed each file in the job and the 
paper size and type for that file and whether it was duplex. (There was 
also the usual header info about number of copies, ownership, customer, 
accounting info, etc.; but that's not relevant here.) I don't think we 
had to specify the number of pages in the file, but perhaps we did.

On submitting the job ticket, the system put it in a queue in which a 
human print manager could assign printing sequence (based on priorities) 
and select which job to send to which printer. Once the manager released 
the job, it sat in a queue for the selected RIP, and the Lionheart 
system managed the details of sending the individual print files 
interspersed with the required PCL commands to get the sheets to come 
out of the right trays, etc.

On this particular system, an entire job (any number of files) would be 
RIP'd before page 1 printed; but I don't see any particular reason that 
should be a requirement for your solution.

Maybe something in that description will trigger a thought as to how to 
solve your current problem.

HTH,

Dick

I have written a plugin for Acrobat on Windows that does just what you 
are asking. I know that a plugin will not work for your purposes but the 
methods behind it would. Here is what we do.
1. Embed "finishing tags" for each page into the PDF based on user 
selections for drawer location, plex and exit location.
2. User also selects staple, fold, trim, body paper location etc. and we 
embed that into the PDF as a job ticket.
3. At print time we have the user print using our plugin.
4. The plugin generates postscript and adds the appropriate print 
commands into the postscript for the particular printer from the 
embedded info in the PDF.
5. The plugin then sends the completed postscript to the printer selected.
This method allows a printing job ticket to embedded into the PDF and 
allows it to be printer independent. This works well for us and I hope 
it may lead you somewhere.

Dick Margulis wrote:
> 
> 
> Graham Nicholls wrote:
> 
>> Bruce Hensley wrote:
>>
>>
>>> We have a very large collection of PDFs and TIFs and need to generate
>>> hardcopy for distribution.  Each document has pre-defined requirements
>>> for number of copies at each size and target network printer, e.g.
>>> print 30 copies of a.pdf to fit 11X17 on printerB, 20 copies to fit
>>> ANSI E on printerC, and 10 copies to fit 8 1/2 X 11 on printer B.  We
>>> want to programmatically accomplish the task from VB, VBScript,
>>> JavaScript, VBA, WSH, or another application.  Our environment is all
>>> Win2K (servers and workstations), IE 5.5, and currently Acrobat and
>>> Reader 5.
>>>
>>> We've looked at the Acrobat IAC docs, but none of the commandline,
>>> DDE, or OLE commands seem to give us the control we need.  Nor does
>>> InvokeVerb to launch the associated print command based on Windows
>>> Explorer file associations.
>>>
>>> We've looked at some third-party tools, but it's difficult to tell
>>> from online documentation whether these meet our needs completely.
>>> And, most seem like overkill, since we don't need to create the PDFs.
>>>
>>> Any recommendations, code examples, or hints would be greatly
>>> appreciated.
>>>
>>> Thanks,
>>> Bruce
>>
>>
>>
>> You may have noticed my posting on "printer control", which specifies a
>> similar requirement.  I am coming to the conclusion that PDF was not 
>> such a
>> great format to have chosen because this stuff seems so hard to do, but
>> OTOH what else is there?  Word is useless at printer control - & windows
>> will let you change the tray of the 1st page but little else, and 
>> anyway we
>> need to do this programatically, as yourselves. So if you do find a way
>> (preferably which doesn't rely on windows) I'd love to hear it.
>>
>> Am I missing the point though, and PDF is simly the wrong format to have
>> chosen for this.  There must be big print houses that do this stuff -
>> presumably they don't require operator intervention?
>>
>> Thanks
>> Graham Nicholls
> 
> 
> Graham,
> 
> I'm sure you will get definitive answers to your questions from the 
> experts here, but if the definitive answer is No, let me offer a 
> somewhat different approach. This describes the way a similar problem 
> was solved a decade ago (long ago, far away) and thus may not be 
> relevant; but the logic of it may appeal to you.
> 
> We converted all documents to some language the RIP understood (it was a 
> fairly sophisticated RIP that accepted PS, TIFF, CCITT, and a couple of 
> other formats IIRC, in addition to its native PCL) and stored them on 
> the network in our own working directories. We then prepared a job 
> ticket, using a piece of Kodak software called Lionheart, I think (or 
> something like that) on which we listed each file in the job and the 
> paper size and type for that file and whether it was duplex. (There was 
> also the usual header info about number of copies, ownership, customer, 
> accounting info, etc.; but that's not relevant here.) I don't think we 
> had to specify the number of pages in the file, but perhaps we did.
> 
> On submitting the job ticket, the system put it in a queue in which a 
> human print manager could assign printing sequence (based on priorities) 
> and select which job to send to which printer. Once the manager released 
> the job, it sat in a queue for the selected RIP, and the Lionheart 
> system managed the details of sending the individual print files 
> interspersed with the required PCL commands to get the sheets to come 
> out of the right trays, etc.
> 
> On this particular system, an entire job (any number of files) would be 
> RIP'd before page 1 printed; but I don't see any particular reason that 
> should be a requirement for your solution.
> 
> Maybe something in that description will trigger a thought as to how to 
> solve your current problem.
> 
> HTH,
> 
> Dick
> 


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 100,000 Newsgroups - 19 Different Servers! =-----

"Dick Margulis" <margulisd@comcast.net> wrote in message
news:10cb6dppbvqah71@news.supernews.com...
>
>
> Graham Nicholls wrote:
>
> > Bruce Hensley wrote:
> >
> >
> >>We have a very large collection of PDFs and TIFs and need to generate
> >>hardcopy for distribution.  Each document has pre-defined requirements
> >>for number of copies at each size and target network printer, e.g.
> >>print 30 copies of a.pdf to fit 11X17 on printerB, 20 copies to fit
> >>ANSI E on printerC, and 10 copies to fit 8 1/2 X 11 on printer B.  We
> >>want to programmatically accomplish the task from VB, VBScript,
> >>JavaScript, VBA, WSH, or another application.  Our environment is all
> >>Win2K (servers and workstations), IE 5.5, and currently Acrobat and
> >>Reader 5.
> >>
> >>We've looked at the Acrobat IAC docs, but none of the commandline,
> >>DDE, or OLE commands seem to give us the control we need.  Nor does
> >>InvokeVerb to launch the associated print command based on Windows
> >>Explorer file associations.
> >>
> >>We've looked at some third-party tools, but it's difficult to tell
> >>from online documentation whether these meet our needs completely.
> >>And, most seem like overkill, since we don't need to create the PDFs.
> >>
> >>Any recommendations, code examples, or hints would be greatly
> >>appreciated.
> >>
> >>Thanks,
> >>Bruce
> >
> >
> > You may have noticed my posting on "printer control", which specifies a
> > similar requirement.  I am coming to the conclusion that PDF was not
such a
> > great format to have chosen because this stuff seems so hard to do, but
> > OTOH what else is there?  Word is useless at printer control - & windows
> > will let you change the tray of the 1st page but little else, and anyway
we
> > need to do this programatically, as yourselves. So if you do find a way
> > (preferably which doesn't rely on windows) I'd love to hear it.
> >
> > Am I missing the point though, and PDF is simly the wrong format to have
> > chosen for this.  There must be big print houses that do this stuff -
> > presumably they don't require operator intervention?
> >
> > Thanks
> > Graham Nicholls
>
> Graham,
>
> I'm sure you will get definitive answers to your questions from the
> experts here, but if the definitive answer is No, let me offer a
> somewhat different approach. This describes the way a similar problem
> was solved a decade ago (long ago, far away) and thus may not be
> relevant; but the logic of it may appeal to you.
>
> We converted all documents to some language the RIP understood (it was a
> fairly sophisticated RIP that accepted PS, TIFF, CCITT, and a couple of
> other formats IIRC, in addition to its native PCL) and stored them on
> the network in our own working directories. We then prepared a job
> ticket, using a piece of Kodak software called Lionheart, I think (or
> something like that) on which we listed each file in the job and the
> paper size and type for that file and whether it was duplex. (There was
> also the usual header info about number of copies, ownership, customer,
> accounting info, etc.; but that's not relevant here.) I don't think we
> had to specify the number of pages in the file, but perhaps we did.
>
> On submitting the job ticket, the system put it in a queue in which a
> human print manager could assign printing sequence (based on priorities)
> and select which job to send to which printer. Once the manager released
> the job, it sat in a queue for the selected RIP, and the Lionheart
> system managed the details of sending the individual print files
> interspersed with the required PCL commands to get the sheets to come
> out of the right trays, etc.
>
> On this particular system, an entire job (any number of files) would be
> RIP'd before page 1 printed; but I don't see any particular reason that
> should be a requirement for your solution.
>
> Maybe something in that description will trigger a thought as to how to
> solve your current problem.
>
> HTH,
>
> Dick
>

Lionheart lets you add the codes yourself, I think they are called KDK's.
I've implemented this sort of thing a couple of times but it is very printer
dependent.

-- 
Tony Edgecombe
www.frogmorecs.com/ng
Software for printing

Thanks all!  I'll look at Lionheart and the other ideas.

Here is what I was originally considering (sorry, it's a Windows and
HP printer solution, which fits our environment):

- Preinstall a printer that prints to a file

At print time --

- Use the Windows shell InvokeVerb method with the "printto" verb,
specifying the print-to-file printer, to create a printfile for the
document.

- Append the needed PJL commands to the print file to specify printer
settings like copy count, page size and orientation, and separator
info.

- Copy the print file to the target printer.

Thanks again,
Bruce

Hi,
We are also working on a similar problem.
The point is to enable the user to select the tray for printing.

How do we edit the print to file ".prn" files.
The tray options have been specified as escape sequence code in PCL-XL language.
How do we edit them?

Isn't there any other option to specify the printer tray programatically?

Thanks in advance,
Mangala.

bhensley@bechtel.com (Bruce Hensley) wrote in message news:<6d2b2c2.0406081011.7a094c60@posting.google.com>...
> Thanks all!  I'll look at Lionheart and the other ideas.
> 
> Here is what I was originally considering (sorry, it's a Windows and
> HP printer solution, which fits our environment):
> 
> - Preinstall a printer that prints to a file
> 
> At print time --
> 
> - Use the Windows shell InvokeVerb method with the "printto" verb,
> specifying the print-to-file printer, to create a printfile for the
> document.
> 
> - Append the needed PJL commands to the print file to specify printer
> settings like copy count, page size and orientation, and separator
> info.
> 
> - Copy the print file to the target printer.
> 
> Thanks again,
> Bruce

There are many, many applications that do just that. Some call it data
driven publishing, versioning, variable data printing etc. The best
take advantage of postscript, using it as a programming language.
In its basic form all you need is a simple ascii text editor and a
postscript printer.

I would like to do a similar thing with PDF however do not have the knowledge with PDF and PDF is a bit of a cow, I want to send say 100 imposed PDFs to a RIP / Marking Engine with different copy counts, odd numbers PDF files have a copy count > 1 and even numbers PDF files have a copy count of 1.  I need something like a print stream to maintain each PDF's copy count but finally be printed as hardcopy as one job, uhm, be so much easier if this RIP accepted PostScript ...