I have a pdf with form fields on it. I want to "flatten" this into a pdf without form fields but when i run the original pdf through ghostscript, the resulting pdf file has a banner at the top that says: "In order to submit this form, you should open it with Adobe Acrobat Reader"
If I tell ghostscript not to render the form fields the banner does not appear, but neither do the form fields.
Is there any way to print the pdf with the form fields using ghostscript without generating this banner.
Running on FBSD, Ghostscript v9.22
The command line is :
gs -dNOPAUSE -sDEVICE=pdfwrite "-sOutputFile=/tmp/flatened.pdf" -dBATCH "/tmp/Sample PDF w fillable fields.pdf"
A sample PDF file:
A sample results file
This seams to be related to how the PDF for generated, it was generated via jotform, and this is a known issue at jotform. Form generated via adobe acrobat work fine.
Related
I have a set of SVGs that have been converted into PDFs using inkscape.
These are then compiled with latex and attempted to be viewed in a reader.
Pdflatex completes successfully and is error free, yet when I print form either Preview or Adobe Reader, the result is identical to the left pane in the screen grab enclosed.
Adobe Reader also only sees the pdf in this way.
I am able to print the original pdfs, so the error must lie in latex or the viewers.
One working solution lies in converting SVG's to eps:
inkscape -z --export-area-drawing <input filename+ path>.svg -E <output filename + path>.eps --export-ps-level=3
... and then letting pdf latex convert them into a pdf during compiling to embed them in the original document.
\includegraphics[...]{filename.eps}
I am trying to print a section of an existing pdf to a new pdf. The original is searchable and selectable but the new pdf cannot do either. I am using "adobe acrobat reader DC" and print via "Microsoft Print to PDF". Unsure if there is any other relevant information.
After searching for a period of time I could not find an answer that allows for direct PDF to PDF print.
I did find a workaround however.
I downloaded a free software called PrimoPDF. Once installed, PrimoPDF becomes a printer option within Adobe acrobat reader. I then selected my desired pages and printed to PrimoPDf instead of Microsoft Print to PDF. This Generated a .ps file. I then imported the .ps file into PrimoPDF application and was able to generate a .pdf from that. The newly generated pdf was searchable and selectable and exactly what I needed.
Hopefully someone else finds this useful in the future.
Generally refrying (printing to PostScript then converting back to PDF) is a bad idea. The reason that Microsoft Print to PDF created a file that wasn't searchable is because when Adobe Reader detects that the printer it is targeting isn't capable of rendering the PDF correctly because of any number of reasons, like it doesn't have the right fonts for example, it will render the PDF itself and send an image to the printer. A simpler PDF probably would have worked just fine.
You are much better off getting a tool that will simply allow you to extract the pages you need to a new file rather than printing.
I'm having difficulties filling in a form using pdftk with text fields with true type fonts.
Font files (.ttf) are added to /Library/Fonts (OSX Mavericks)
The form is created with Adobe Acrobat Pro
The form includes normal (non form) text using these fonts
The form text fields also use these fonts
The form can successfully be filled and printed using Adobe Acrobat Pro and even Preview
However, pdftk throws an error when trying to fill it using the command:
pdftk ./my_form.pdf fill_form my_data.fdf output ./the_output.pdf
The output is:
Unhandled Java Exception in create_output():
java.lang.ArrayIndexOutOfBoundsException: 0
at pdftk.com.lowagie.text.pdf.DocumentFont.fillEncoding(pdftk)
at pdftk.com.lowagie.text.pdf.DocumentFont.doType1TT(pdftk)
at pdftk.com.lowagie.text.pdf.DocumentFont.<init>(pdftk)
at pdftk.com.lowagie.text.pdf.AcroFields.getAppearance(pdftk)
at pdftk.com.lowagie.text.pdf.AcroFields.setField(pdftk)
at pdftk.com.lowagie.text.pdf.AcroFields.setFields(pdftk)
If I change the font of the text inputs to Helvetica, Times Roman or Courier, pdftk will successfully create a PDF. Oddly though, Arial and Georgia also throw the same error.
I have tried to no avail to embed the fonts in the PDF using Ghostscript as suggested in this question How to repair a PDF file and embed missing fonts. gs may have embedded the fonts, but it removes the form fields so the resulting PDF can't feed back into pdftk.
A working resolution would be greatly appreciated.
I was getting the same java.lang.ArrayIndexOutOfBoundsException: 0 error using pdftk to fill forms on an Adobe Acrobat generated PDF. This question is super old, but I couldn't find a consistent answer on stackoverflow or elsewhere so I figured I'd post my fix.
What ended up working for me:
Opening the PDF in the OS X app Preview
Clicking into a form field, adding text then deleting that text (so nothing is actually changed)
Saving it
Running the PDF through pdftk again
I'm not that familiar with encoding or PDFs in general, but saving the PDF with Preview seems to fix the encoding or at least get it to a place where pdftk can work with it. Good luck.
This was causing a huge headache for me for 2 days. It turns out I was focusing on the wrong end of the problem.
A nice alternative that isn't as manual and only has to be done once is to enter some text in a field of the source PDF form, in your case ./my_form.pdf. I don't know EXACTLY why this works, but it does. that way if you want to create a new file at any time, you dont have to go through this trouble :)
We have ghostscript setup on our server to convert a PDF into separate TIFF images when it is uploaded. It's works perfectly most of the time, however sometimes it fails. I have managed to solve this on a per PDF basis by opening the problem PDF and saving it in Acrobat as an 'Optimized PDF' and specifically with JUST these two attributes checked:
'Discard unreferenced named destinations' (in Clean Up)
'Optimize page content' (in Clean Up)
(nothing else has been checked in any section, just these two)
My question is, is there a way to have ghostscript do what I am having to currently do?
The reason I need ghostscript to do this is because it has to be fully automated so users can upload a pdf and it gets converted into images.
If it helps, here are the ghostscript settings we are using:
-dQUIET
-dSAFER
-dBATCH
-dNOPAUSE
-dNOPROMPT
-sDEVICE=tiff24nc
-dUseCIEColor
-dTextAlphaBits=4
-dGraphicsAlphaBits=4
-dEPSCrop
Many thanks,
Pat
some times ghostscript fails in opening files due to XREF table corruption
try to repair problematic pdf with
pdftk
http://www.pdflabs.com/docs/install-pdftk/
pdftk file.pdf output fixed.pdf
if pdftk is able to repair pdf file, then a shellscript can be made with an
if...then..else statement (if pdf file causes ghostscript failing, then it will be automatically repaired by pdftk and then resubmitted to ghostscript)
apart all; you need to learn to READ ERROR OUTPUT, since in error output are almost the 99% of times contained the explanations of error
I'm trying to use Ghostscript 9.02 on Windows 7 to print a PDF to an Epson Workforce printer from the command line using the following command:
gswin32c -dPrinted -dBATCH -dNOPAUSE -dNOSAFER -q -dNumCopies=1 -sDEVICE=epson -sOutputFile=\\spool\EPSON C:\Document1.pdf
When executing this command, pages will print from my printer, but it is just garbled text instead of the PDF.
I have tried 3 different PDF files with similar results.
I doubt that the previous answer is the issue, but rather is a problem with getting the epson format data passed through correctly as binary. Particularly if the 'init_string' == "\f\033#" doesn't make it in,
the rest of the data will be interpreted by the printer as text instead of raster data.
Since you are on Windows, you may get better results by using the -sDEVICE=mswinpr2 device which sends the raster image for the page through GDI to the manufacturer's driver. See http://artifex.com/gs-current-release/Devices.htm#Win for documentation on printing from windows using Ghostscript.
BTW, you can easily check if the problem is with gswin32c being able to properly render the input PDF by
looking at it on the default 'display' device using:
gswin32c C:\Document1.pdf
your problem may be probably related with encoding used by pdf file
how this pdf has been produced?
I seen several times this problem arise with pdf produced by internal pdf exporter of OpenOffice
I have had a similar issue, and it looks like not all listed devices are capable of printing PDF files. I have used ljet4 option for Ricoh network printer and it prints fine. The only problem is it always prints immediately instead of "HoldPrint" queue.