I'm trying to generate a PDF that can be viewed interactively in Adobe Reader, but also, upon printing, selects different paper trays based on the page. (Some pages are supposed to use stationery, whereas other must not.)
PDF itself apparently doesn't support this form of metadata by design (as discussed e.g. here), but apparently, JDF is an appropriate format, and can be embedded as XML in the PDF.
What's less clear to me is if Adobe Reader does anything useful with that metadata: if a PDF with embedded JDF information is printed, does it parse the JDF and choose paper trays? Can I use PDF portfolios for this purpose instead?
My goal is to both let the user view the PDF in Adobe Reader interactively, and, upon printing, automatically selecting different paper trays.
(The far less convenient alternative would be to write a custom app to do the printing.)
You are right, PDF describes the artwork while the JDF describes the metadata about print. However, JDF is targeted to industrial printing systems rather than for desktop printers. As far as I know does Adobe Acrobat Reader not support this kind of feature based on a JDF.
In order to control the different paper trays of your printer, you may setup your printer several times - one for each tray and switch the flag "default printer" in the background programmatically.
Another idea could be to use the Acrobat Reader only for viewing purposes and using the command line for printing.
There are concepts of how to put metadata into the PDF directly (see: https://confluence.cip4.org/display/PUB/PDF+Intent), but it could take a while until this specification is gonna to be implemented.
Related
I'm working on a web-based KIOSK for in-house print jobs. We're a non-profit making small print publications. I've got a prototype created of portal that allows us to manage our publications (mainly PDFs), our print queues (mainly windows printers). I've been able to write C# code to use the FoxIt Reader to silently print PDFs from a RESTFUL API web service. It works. But in testing, I found serious limitations with the FoxIT Reader. Primarily, you can't specify how many copies to print, along with other basic settings. While it works, we often print in volume (50 or a hundred copies of multi-page PDFs. I could put in a loop to print the PDF N-times, but that's just ridiculous as it sends an ungodly amount of data and print jobs to the printer.
Anyways, I'm having difficulties locating a library (preferably open source) that gives me options for printing PDFs, specifiying things like # of copies, color / B&W, PRINTER MANAGES Color, etc.
I've been googling for a couple of days. I'm coming up empty. Those libraries I do come across are meant to work as WinForms foreground applications. What I need is an API that can Print PDFs as a background process (think windows service).
And just to be clear, by "Print PDF" I do not mean create a PDF. I mean take an existing PDF and sent it to a printer with options (# of copies, color/B&W, printer manages color, paper size, actual size vs. fit to paper size, orientation, etc.)
I really need some help. I'm coming up empty. Can anyone recommend an API that would help in this situation? The whole key I'm trying to avoid is FOREGROUND printing. I need to be able to spawn a print job as a background process, not interactive-user.
(My RESTFUL API web service takes an ID of a publication along with the quantity, page size, color mode (BW/Color)) and presently spawns a background print using FoxIt Reader. It does work. But without the options to specify quantity, page size, color/bw, PRINTER MANAGES Color, it's really useless for production.)
thanks in advance.
Please check out CLPrint. You have to either call the EXE directly or just place the PDF into a directory, but you can also specify the print options like you need. You should be able to run the process as any user.
http://www.terminalworks.com/command-line-printing
http://www.terminalworks.com/command-line-printing/downloads/documentation/CLPrintGuide.pdf (Page 6 are the command line options that I believe are relevant for you)
Is there any way in C# to get the documents sent to the printer from another program and use those documents again for something else?
I want to build an application which can get invoice sent to the printer by some point of sale system and gives opportunity to send that invoice to customer's email.
Well, you could print to the XPS printer and have it create a file. Then, let the system print the XPS file using the standard application. This may or may not work depending on some factors:
Is there XPS support on the system?
Did the user change the default application that handles XPS files? Maybe printing is no longer possible...
Is XPS a file format you want to send to the users?
etc.
That said, of course you could do the same thing with PDF, but you'd have to have access to an application that can actually print PDF. It has been asked multiple times here how to "send PDF bytes" to a printer - you can't. There are solutions, but in the end you have to answer this question for yourself:
Is it really worth the hassle or isn't it just easier to print the document and then create it again as PDF (for examples) to send to the user?
We are generating PDFS from a web app a couple different ways, ItextASharp, Html->Rotativa, and RDLC...
Is there any way in anyof those tools to modify the ViewerPreferences dictionary inside the PDF so as to disable the "shrink to fit" option..
The PDF format supports this option, I've found documentation for that...
I'm aware that not all viewers honor the request not to shrink to fit, but we're using stock adobe readers across the board so it's ok.
I was able to find this in ITextSharp to read one, modify it and save, it, so I have to believe there is a way to set it before generation...but I can't find it..
Determine properties such as if PDF is Simplex or Duplex in iTextSharp
It'd be awesome if Rotativa had a way too...since we use that for some reports
We also have some done in RDLC style, if there is a way to do it there...
The reason we have to do it, is one of our apps prints labels and the amount of data leave no room for fudging it. Printing them from a web app is problematic, even when we control the ecosystem.
Unfortunately, our IT group will not use the reg settings to change the default on the machines.. we have to do it through code.
I have a set of PDF files that were created in Acrobat Professional with fillable, savable forms. I can modify the values of the fields in the forms, and save those changes with ABCpdf, which works great. The problem is that users with Adobe Reader can no longer save any data they put in the form. They can still fill out the form and print it, just not save it.
This might be licensing related (on Adobe's end), but I have not been able to find a solid answer one way or another.
The answer is apparently "no". In order for a PDF form to be savable in Adobe Reader, it has to be signed by an approved product. I'm not sure if there are any third party PDF libraries that would allow this feature, but ABCpdf definitely does not.
Things have changed a little bit with Adobe Reader XI. If the user uses Adobe Reader XI (or newer), the form can be saved. For earlier versions of Reader, so-called Extended Rights are necessary. Extended Rights can be applied using Adobe Acrobat (Pro), or LiveCycle Reader Extensions server. Note that there are (legal) limitations for the use of the form when Acrobat is used to assign the Extended Rights, and that Acrobat can assign only a limited set of rights.
I'm looking for an asp.NET control that will allow for viewing and printing of a pdf and TIFF within a web form. I'm willing to use more than 1 control if needed (1 control for pdf, 1 for Tiff, show and hide based on file extension), but I have not been able to find a good Tiff viewer.
Files are stored on our LAN in a shared folder, and this application is an intranet site.
Open source / free licensing preferred, but I'm willing to look at paid options as well.
http://www.alternatiff.com/ is one of the viewers that I've seen used for this type of viewing of tiffs.
You can get a free licence of ABCPDF (provided you link back to their site) which will do the conversion from TIFF to PDF for you as per #Chris Lively 's suggestion.
It'll also do conversion from PDF to TIFF if you decide to do things backwards.
It makes sense to present the content in a common format. If you wanted to you can embed the PDF in the browser to create the 'seamless' experience you're looking for using something like PDFObject.
As #BenCr says though, PDF is a really common format and the tools already exist to open and work with them, so introducing new ways to perform existing tasks could actually end up complicating matters unnecessarily.
I'm in total agreement with #BenCr on this.
Viewing PDFs is an extremely common thing to do. This isn't a "technical" issue by any stretch.
It sounds like you have some type of faxing solution in place that is creating these documents. Most likely multi-page TIFF and PDFs.
If this is the case you might want to just convert the TIFFs to PDFs to begin with and run everything through Adobe's pdf reader. Every online fax solution does this.
You could try http://issuu.com/ and they appear to have a API too if you want to go that deep.
We used the the Seadragon control to do this. I think it was an overkill and we should have just rolled our own -- would have been cheaper than integrating it. TIFFs and PDFs are converted to PNG on the server side. I don't think you can do better than that, especially with PDFs (assuming you don't want to use Acrobat Reader to display them). Convert PDFs to PNG using Xpdf/Poppler.
How about using Google Docs Viewer?
EDIT: Probably not working, since the viewer has to read the document from your URL; when it's on the Intranet, this won't work.
If you can mess about with mime types -- mainly by making the .tiff files expose an application/pdf mimetype -- you should be able to get acrobat to open TIFF files directly by effectively fooling the browser to open TIFF files with acrobat. Then all you need is a trusty old iframe to get you familiar UI with print buttons.