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}
Related
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.
I can easily convert a pdf to an odt file using:
soffice --infilter="writer_pdf_import" --convert-to odt a.pdf
But when I try to do:
soffice --infilter="writer_pdf_import" --convert-to odg a.pdf
I get an error:
no export filter
TL;DR the answer is at the bottom but do read the following as to why there can be issues
ODG is a multi-part graphics file usually a blank template, often similar to an ORA, however there are many ways they can be structured and converted TO a set of PDF page printouts, as they contain thumbnails, plus one or more high resolution images or scalable vector graphics. Common variants can be used with Inkscape, Krita possibly Scribus / OODraw and other more GRAPHIC apps.
PDF is a page document output format thus not a suitable candidate for converting to professional images with scalar graphics. *Except see the last comment
ODG or ORA may be done well in image conversion but the reverse is not usually true.
Open Office Graphic is like a DocX, a zip wrapper around a core object, here it is a Jpeg but could be PNG SVG etc.
However the contents of the zip are not simple potentially running to thousands of lines of coding. Thus you need to use a more appropriate method to hand build an ODG not simple command line conversion from cruder PDF.
The real strength of a EXPORT from draw as PDF is the hybrid use of embedding ODFG content thus opening such a PDF you can edit it in Draw.
And it will look just as good in any PDF viewer. However it is too specialist to be simply translated without the app settings. In reality the PDF is the chimera/polyglot ODG.
But if you wish to try with simple files the command line is for a.pdf to a.odg
soffice --infilter="draw_pdf_import" --convert-to odg a.pdf
I've got a silly problem which is literally driving me mad:
When I try to print a file using lpr file.pdf depending on the file I obtain one of the following issues:
the printer does not recognise the A4 format
the file is printed but together with a countless number of pages of programming code ( the 'real' face of a PDF file I guess), characters and numbers.
The same happens also for PNG files.
I'm using MAC OS X El capitan and a Xerox colorQube printer.
Clearly if I open the file with Acrobat or Preview and just make the printing manually I have no problem at all.
I hope you can give me some clues because I couldn't find anything useful on the web.
PS: If I use the option -l the printer prints a sheet saying that the printer is not configured to print pdf files directly.
lpr sends file directly to printer, it may not understand pdf as-is, but since pdf is a successor to postscript - it can contain familiar commands so something gets printed, but the rest, probably the embedded preview and so on - gets printed as raw text
Try using ghostscript to convert to postscript before sending to printer:
gs -dSAFER -dNOPAUSE -sDEVICE=(your printer name) -sOutputFile=\|lpr file.pdf
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 :)
When I print a PDF-file with a PS-driver and then convert the PS-file to a searchable PDF with ghostscript (pdfwrite device) something is wrong with the final pdf file. It becomes corrupt.
In some cases, the space character disappears, and in other cases the text width becomes too large so text overlap text.
The settings for gs is -dNOPAUSE -dBatch -sDEVICE=pdfwrite -dEmbedAllFonts=true -dSubsetFonts=false -sOutputFile=output.pdf input.ps
I am wondering if it is ghostscript that just cant produce a good output when the input file is a pdf.
If I print a word-document everything works fine!
Are there any other solutions like using a xps-driver and convert the xps file to a searchable pdf instead? are there any solutions out there that can do this?
I use gs 9.07.
Best regards
Joe
Why are you going through the step of printing the PDF file to a PostScript file? Ghostscript is already capable of accepting a PDF file as input.
This simply adds more confusion, it certainly won't add anything useful.
Its not possible to say what the problem 'might' be without seeing the original PDF file and the PostScript file produced by your driver. My guess would be that whatever application is processing the PDF hasn't embedded the font, or that the PostScript driver hasn't been able to convert the font into something suitable for PostScript, resulting in the font being missing in the output, and the pdfwrite device having to substitute 'something else' for the missing font.
Ghostscript (more accurately the pdfwrite device) is perfectly capable of producing a decent PDF file when the input is PDF, but your input isn't PDF, its PostScript!
To be perfectly honest, if your original PDF file isn't 'searchable' its very unlikely that the PDF file produced by pdfwrite will be either, no matter whether you use the original PDF or mangle it into PostScript instead.
The usual reasons why a PDF file are not 'searchable' are because there is no ToUnicode information and the font is encoded with a custom encoding and deos not use standard glyph names. If this is the case there is nothing you can do with the PDF file except OCR it.