You don't say if this is for Blueprint (corporate solution) or Uniprint (University/Print-for-Pay solution), but it does not really matter. In Blueprint, you have to ensure that a Collector server (or a print server running Print Scout in "print server" mode) has the Microsoft LPD role service running. In Blueprint, you have to ensure that your Uniprint print server has the Pharos LPD service installed (it should if you have installed the Pharos Uniprint Print Server). From there, client access is pretty much the same:
1. Establish your connection on the client as lpr://<servername or ip address>:<shared printer name>. I have provided the Linux/MacOS URI here. If you are using a Microsoft Windows client, the "shared printer name" is the "LPR Queue Name" in the Standard TCP/IP port configuration. Please note that some LPR implementations do not support the use of spaces, extended characters (non alphanumeric), or long names (8-12 characters or less, please) so ensure that the shared name you provide your queue corresponds to any client-imposed limitations.
2. Set up your application to print to the created connection on the client.
1. The LPR user name will be the "owner" of the process running the application used for print.
2. There is a strong tendency for Windows' LPD implementation to end up recording every job received over that protocol with the document name "Remote Downlevel Document" so ensure that your workflow is not document name-dependent.
3. There is much "flow control" with LPR/LPD. This means that when sending the print job you can be assured that if the job says "Sent" it is truly "Sent" 100% to the queue. It also means that the printer must receive the entire print file before it can start printing the job. So please be aware that your destination (which is most likely your Windows server) must have sufficient hard disk space. If you are, in turn, relaying your print job via LPR to the printing device, the same warning applies. Many printers that support LPD use special queue names in their configuration to allow job spooling to the hard disk of the printer instead of memory. Consult your printer's documentation or its Technical Support service for more information on this.
There is no inherent API that I am aware of.
What is the goal of the ability to automate sending a print job? I am primarily asking because I have had people ask me this in the past only to find that what they were really after was getting the automatic updater to fire. This is more easily accomplished just by executing uniupdater.exe located in the Pharos\Bin folder.
Thanks for all the replies guys.
We are a university using Uniprint.
My goal is to create a website for the students so that they can upload files to the site and it will show up in print queues in Pharos. I'm currently testing with PDF files and having some road bumps. I've managed to have a job show up in the print queues but with some set back.
1) It shows up in Print Queue but without a password
2) Once I release a pdf it prints "128MB of memory is required to enable direct PDF printing.". It doesn't print anything else.
P.S. - I'm using a C# library I found online
I'm sorry, that will not work. It is best if you use our MobilePrint and Print Center applications to accomplish this task. Pharos MobilePrint allows users to upload PDF, DOC/DOCX, PPT/PPTX, XLS, XLSX, JPG, TXT and other file formats (like OpenOffice format) via a web page upload or email submission. After upload, the student can change job attributes like color/black-and-white, single or double-sided, and then submit it to a printer found in a drop-down list (or they can search) in the same interface.
I suggest contacting your Pharos representative or reseller for more information.
Whether you could get it working or not, managing the project to keep up with changes in future versions would require ongoing maintenance and so forth. As Scott said, Pharos already has a solution for this goal. The Print Center included with Pharos 9.0 and 9.0 R2 displays jobs and allows for print release, and MobilePrint does a great job of allowing users to email or upload jobs. With the updates that came out in the last month, users can also easily upload jobs natively from Android devices now. The iOS app has been out a while now, and I believe an Android app is getting closer to release - perhaps even as early as the 1st quarter or so of next year.
I concur with Scott's recommendation to contact your rep and get more info and a demo. I think you'll like it.
Thank you Scott and Steven.
Currently our University has no plans of implementing MobilePrint, that I know of. My goal was to create a solution until we get there. How ever I greatly appreciate your feedback on this question.
This isn't Pharos specific, but something to consider when creating a "solution" and dealing with proprietary software is this: As a general rule, most of the applications that are created to work within a software manufacturers platform are proprietary by nature and are copy-written\patented. It isn't always possible to create something on your own that will work and not be an infringement (and I've seen many an IT department try). There are usually a limited number of options in terms of engine design, so "getting there" a new way is not always possible. When a company already has an established product that contains the functionality that you desire, but you instead try to create something to provide that functionality vs. buying the additional software, you risk at best putting yourself in a position where you no longer are going to get technical support due to a "rogue" customization, to at worst, a full blown law suit over copy-write\patent infringement. Just sayin......... .
As Steven pointed out, even if it were possible, it's going to add to your workload, and puts you in the position of doing your own R&D in order to keep up with new versions of the UP product. Assuming you could do this legally, in the end you'd spend more money on manpower, support, and time wasted reinventing the wheel (since what you are trying to do is essentially create your own version of Pharos Print Center) , than you would by just updating\upgrading your system.
If your organization wants this type of capability, then I also would suggest teaming up with your rep/salesperson and lobbying for them to demo the software. Then a decision can be made to buy it or not based on it's merits, while avoiding the possible legal\product support ramifications of doing otherwise.
FYI - I also agree that you'll like the product, especially the Mobileprint capability. We were one of the first locations to adopt Mobileprint when it first was available and it is by far the most popular capability the UP system offers as far as our user population is concerned.
I appreciate your input John