In my project I generate PDFs from HTML. The problem is these PDFs can't be printed though I they are opened and displayed correctly. Files are generated by ConvertAPI, I also tried wkhtmltopdf but it gave me the same result.
In Windows Adobe Reader 9 gave me error messages "Print is impossible" and then "No pages were selected for print" (this is translation as there isn't English localization in my Reader). After I upgraded to Adobe Reader X it started printing but only part of document and giving error message "Drawing error occurred".
Using print as images doesn't help, i just got empty sheet.
I managed to print document from Linux but it's not an option for me.
Any ideas what could be a problem here? Or at least how can i find what's actually a problem?
UPD. Most likely problems are caused by SVG in my HTML.
Related
I've just upgraded from iTextSharp v5.5.6 to v5.5.9 and now one of my PDF documents report an error in Adobe Reader v11.0.17:
"An error exists on this page. Acrobat may not display the page correctly. Please contact the person who created the PDF document to correct the problem."
How can I see what the error is? Visually the document looks fine and I don't get the error when I open the PDF file in Google Chrome.
I tried looking at the changelog but can't see what has changed that is causing this error to appear.
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 a WPF application which can perform either a report preview or a report print.
Both requests use the same code.
Call the report service which gets the report from Microsoft Report Services.
Convert the report into the desired format (in this case PDF).
Then return the report as a byte array.
The result is then written to a temporary file as a binary stream, and either popped into a window to preview or start a Process to print.
In both cases the temporary file is passed.
Print Preview works flawlessly! But Print Report will print with all occurances of 'ti' disappearing. I see there is a printer escape sequence of ESC t NUL/SOH and I assume that if, for some reason, an escape character gets into that stream that ti will result in an ignored print sequence. Thus the missing characters.
My first question is if anyone has ever experienced this with generated PDF reports?
My second question (obviously) is if anyone knows of a utility I can use to view the binary data in the file being printed, to see what is in the file just before every 'ti' sequence?
After a great deal of searching I came across a post on the Adobe forum that states that version 8 had a bug where it was not printing character combinations. Once I dug deeper it seems that it has returned and the suggested workaround fixed our issue.
Workaround: Do a print as image.
Adobe seems to be unable to do the most basic of what their software must do, print the exact content!
Answer for your second question:
First, do one of the following two things:
Set the Windows print spooler properties to not delete printed jobs.
Pause the target print queue.
Then, grab the spool file from the Windows printspool directory (which location that is you can find out by looking at the (right-click) 'Properties...' dialog of the 'Printers and Faxes' folder).
I realize this is an old post but I wanted to add some updated info from the above comment stating that it's a problem with Acrobat 8. We are using Acrobat 10.1.6 and still have the same problem. From what I've read, it's a problem with the adobe product itself. The only real fix I've seen (actually work around) is to print as an image. LAME
Surprisingly this bug is still there in 2021. Adobe cannot be relied upon printing documents properly. This takes away all the allure of features it had if it cannot do the most basic stuff it is required for.
Printing as image reduces the quality and blur the document.
Simply open the document with Safari or Chrome and print from there. E
I had a similar problem while printing directly from the firefox (acrobat reader within). I downloaded the file and then printed. The problem was solved.
UPDATE: I wrote to Wolfram support about this and will update the post if they can resolve the problem. Sorry for spamming SO with a technical support question, but here it remains in case anyone else is having the same issue.
Is anyone else having this problem with Mathematica 8? I recently upgraded and noticed that when I export Graphics to a PDF file, although the file appears fine on my computer, it prints as a blank page. For example, try
Rectangle[{1,1}]//
Graphics//
Export["~/test.pdf",#]&
which creates a PDF file containing a black square. This file opens fine, but if I send it to my department printer I just get a blank page. If I don't export the graphics but print the notebook from MM, no problem, the graphics print as expected. If I use MM 7 to do exactly the same thing, the PDF file prints as expected. Exporting to PNG in MM8 seems to work fine. And, using the context menu Save Graphics As ... or File > Save Selection As ... to create a PDF containing just the graphic also works. However, these graphics eventually get included in a TeX document, and it would be far better if I could continue using the script I've got that doesn't require any button clicking to generate them.
I'm running MM 8.0.0.0 on Mac OS 10.6.7. I have not been able to test this on another printer yet, but this printer has never given me problems before and prints other PDF documents fine. Any ideas why this is happening?
Wolfram Research responds:
...
This issue has been reported by other users as
well and our developers are currently looking into it. I have added your
details to the report so you can be notified when this is resolved.
In the meantime, the alternatives that you could try are:
Try a different printer.
Rasterize the image with the function 'Rasterize' before exporting. If
the rasterized image loses some resolution, you could use the option
'ImageResolution' to edit this.
Rasterize[image, ImageResolution -> xxx]
Surely this is a bug (please report it to support#wolfram.com), but you can work around the problem by selecting the graphic and choosing File > Save Selection As... from the menu (or Save Graphic As... from the contextual menu). This produces a slightly different file that doesn't appear to exhibit the undesirable behavior we observe from Export[].
These problematic files, and LaTeX PDFs that include them, can be properly printed by Adobe Reader 10.1.2. That's if you're okay with installing and using a 450MB PDF reader.
I reproduced the problem (leading me to this question) with Mathematica 8.0.4.0 on Mac OS X 10.7.2. Wolfram suggested lame workarounds like Rasterize and told me
This issue has been addressed by our developers, and a fix will be included in a future version of Mathematica.
I am programmatically creating PDFs, and a recent change to my generator is creating documents that crash both Mac Preview and Adobe Reader on my Mac. Before Adobe Reader crashes, it reports:
There was an error processing a page.
There was a problem reading this document (18).
I suspect that that "18" might give me some information on what is wrong with the PDF I've created. Is there a document explaining the meaning of these status codes?
Hold down the Ctrl key while pressing OK and you should be able to load past this point in the document and possibly get more details.
What tool are you using to create the PDF (Aspose)?
I wasn't able to locate any info on the Adobe error code, so I ended up installing xpdf via Darwinports. Loading my PDF with xpdf spit out much more useful error information and I was able to track down the problem. (I was creating a circular reference in a form when I copied content from one document to another.)