Question:
It is possible to convert SVG to PDF using GhostPCL, like this:
gsvg.exe -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile=my.pdf t1.svg
The difficulty is getting gsvg.exe...
I managed to find the source from:
http://svn.ghostscript.com/ghostscript/trunk/
and it built and compiled and it works fine.
However, when I go to http://svn.ghostscript.com, then it states:
SVN is decprecated, Ghostscript and associated projects are now hosted
only in git repositories, see: http://git.ghostscript.com
So I tried to get the latest version by downloading from the git repository
git clone http://git.ghostscript.com/ghostpdl.git
It built fine, but it looks like gsvg is gone.
Unfortunately, it lacks a bit in the documentation department.
Does anybody know if this functionality has been integrated, deleted, or otherwise moved ?
If it has been integrated, how can I convert a svg to a pdf in the new version (using ghost*) ?
PS:
Yes, I know I can do it with inkscape or rsvg-convert, but they don't work fine for my SVGs (rsvg-convert removes all text), inkscape delivers poor quality svg conversion. CairoSVG seems to be the same as rsvg-convert.
Only ghostsvg works as required.
SVG input (gsvg) has been deprecated and removed from Ghostscript. It never worked well and there was not sufficient interest to bring it up to date and maintain it.
If you're really desperate you can probably take the gsvg sources and glue them together with the current graphics library and output devices, nothing has changed in the Ghostscript API so this 'should' all still work, but the directory structure has been reworked and the makefiles modified to match, so its not going to be simple.
Related
We use libreoffice to generate pdf-figures from odg files (automatically via makefile) and include these in documentation generated by sphinx that via LaTeX ultimately produces a pdf file. This works nicely. However, starting with libreoffice 7, libreoffice generates pdfs with version 1.6. And pdflatex as used by sphinx (4.1.2) only accepts PDFs up to 1.5. producing warning messages such as
PDF inclusion: found PDF version <1.6>, but at most version <1.5> allowed
That would easily be fixable by including \pdfminorversion=6 early in the generated LaTeX file. However, putting it (first) in the preamble via conf.py is too late
! pdfTeX error (setup): PDF version cannot be changed after data is written to the PDF file.
Are there any other legal means to just insert raw LaTeX early (without resorting to scripted file manipulation)? Or do you have any other hints on how to specifiy the pdf version that gets produced by LaTeX/sphinx and thus get rid of the warnings. I know, just warnings, but these things tend to become errors sooner than one might think...
First of all, some of the answers to this question might be useful if you definitely want to upgrade to PDF version 1.6.
On the opposite, if the actual PDF version of your figures is not an issue, you can also manually force the PDF's to insert to be of version 1.5, using Ghostscript in the following command taken from here:
gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.5 -o output.pdf input.pdf
That way, you make sure avoiding inserting any instability issue, messing up with LaTeX configuration. (even though setting up \pdfminorversion=6 should be fine by now)
I have a requirement to append one PDF file to another.
I felt that Ghostscript was the way forward, and installed the 64 bit Windows version (9.53.0), but if I attempt to do anything with pdfwrite where the input is a PDF, e.g.
gswin64c -DNOSAFER -sDEVICE=pdfwrite -o output.pdf input.pdf
I get zero length output (with no error messages at all). This happens whether the PDF is one of Ghostscript's shipped examples, one generated using tcpdf, or one saved from a Windows application. It happens whether I try to read from a single PDF or from multiple ones (the latter being my use case).
If I convert the input PDFs to Postscript and then use pdfwrite on those, it works like a dream, e.g.
call pdf2ps input.pdf temp.ps
gswin64c -DNOSAFER -sDEVICE=pdfwrite -o output.pdf temp.ps
EPS inputs work fine also - the only problem seems to be with PDF ones. But Ghostscript can read and display any PDF (and indeed convert any PDF to Postscript), it just can't cope with PDFs as input to pdfwrite, as far as I can see.
I can find no reference anywhere to this particular issue.
This turned out to not be limited to PDF input, it's just easier to trigger it that way. The problem was that an internal data type was changed from a build-dependent size to always be 64-bits, but a #define'd value wasn't correctly updated so the 64-bit Windows build was still using a value intended for 32-bit builds.
There's a commit to fix the problem here. However this seems serious enough that a new build 9.53.1 (so that's patch level 1 already...) will be forthcoming shortly (if it's not already there).
It would help a lot if people could report bugs when they find this kind of problem, and even better if there are any volunteers to try out the release candidates, we would really prefer not to make releases with serious problems.....
---EDIT---
As discussed below and in the comments, my ISP took a default policy.xml on June 25 for Imagemagick which turns off convert for pdf files, which is what I need. I am getting crickets from my requests to modify it and I don't consider that a good solution as it could revert back on the next upgrade. I have found that Ghostscript will convert pdf files. I would appreciate any input if I am on the right track but so far this is very promising.
My existing call is this
convert -density 300 -quality 100 \"" . Aqualarm.pdf . "\" -resize 800 -sharpen 0x1.0 -flatten \"" . Aqualarm.png . "\"
The proposed Ghostscript version is this
gs -dNOPAUSE -dBATCH -r300 -dDownScaleFactor=3 -sDEVICE=png16m -sOutputFile="Aqualarm_%03d.png" Aqualarm.pdf
In this case Aqualarm is a test file.
---EDIT 2---
Using Ghostscript as described above worked with one modification. convert numbers files starting with 0 and gs numbers files starting with 1. I had to put a test in and if file 0 was missing, I changed the index to 1. Other than that I am happy with the result. This is apparently a common problem even on non shared host systems. The issue is that updates to ImageMagick will overwrite edits to the policy.xml so what you do there to make things work, might stop working on the next update. Since ImageMagick uses Ghostscript to do this anyway, I don't see any reason not to bypass the middleman.
From other reading I found that the reason ImageMagick disabled pdf by default is because of an error in Ghostscript that was fixed a few version back.
---END EDIT---
My website is on a shared hosting server. For years I have used ImageMagick "convert" to turn pdf documents into png. Now I get an error message as described here
ImageMagick security policy 'PDF' blocking conversion
The message is: convert-im6.q16: attempt to perform an operation not allowed by the security policy `PDF' # error/constitute.c/IsCoderAuthorized/408.
The suggested solution is to modify policy.xml but of course on a shared host I do not have access to that file.
I have also seen the suggestion to install pdftoppm but even after hours of searching I cannot find out how to do that locally, without root access.
Is there a way that will work on a shared host server?
Thank you for reading.
I decided that getting policy.xml changed to allow pdf was not a good solution because it might just be overwritten at the next release and put me right back where I am. Research uncovered that ImageMagick uses Ghostscript to do the pdf conversions so why put up with an unreliable middleman. More research found some command line batch instructions to do the conversion. However, the resolution was terrible. Only when I got up to close to the resolution of 300 did I get good results but the file was huge. Ghostscript has a command that allows high internal resolution and then a downscale factor to bring the file to a smaller size. Why this is better than just directly converting to the file size I want is a mystery but this is the recommended solution and experimentation showed it to be of high quality. The final solution is as follows:
$gscommand = "gs -dNOPAUSE -dBATCH -r300 -dDownScaleFactor=3 -sDEVICE=png16m -sOutputFile=\"" .$file . "_%d.png\" " . $file . ".pdf";
$returnedvalue = exec($gscommand);
In closing, this seems to be a pretty common problem without a solution other than use a different program. One recommended is pdftoppm which I did not find how to install on a shared host system and with Ghostscript doing the job there is no need to figure that out.
I hope this post helps others faced with this problem.
I use Ghostscript 9.14, the last one compiled for HP-Unix.
I need to create PDF/A-1b files from existing pdf files from different sources.
It is preferred that this happens on a HP-Unix server because that is the server that puts them in a DMS.
The command:
gs -q -dPDFA -dBATCH -dNOPAUSE -dNOOUTERSAVE \
-dCCFONTDEBUG -dCFFDEBUG -dCMAPDEBUG -dDOCIEDEBUG -dEPSDEBUG \
-dFAPIDEBUG -dINITDEBUG -dPDFDEBUG -dPDFOPTDEBUG -dPDFWRDEBUG \
-dSETPDDEBUG -dSTRESDEBUG -dTTFDEBUG -dVGIFDEBUG -dVJPGDEBUG \
-dColorConversionStrategy=/sRGB -dProcessColorModel=/DeviceRGB \
-sDEVICE=pdfwrite -sPDFACompatibilityPolicy=2 \
-sOutputFile=debug_0901ece380001a00.pdf /usr/../PDFA_def.ps \
/0901ece380001a00.pdf
The source pdf is filled with just non-OCRed images.
I have this working on a newer version on a Windows server (Ghostscript 9.19) without problems and with the same command but can't seem to get it working on HP-Unix.
On the Windows server there is a MS Office installed.
The HP-Unix command generates 9mb file for a 300kb source file and it takes ages to generate.
Ghostscript seems single threaded but 9 mins for 35 pages is a bit much.
When I check through Preflight in Acrobat Pro 9 Extended, the 9mb file is truly PDF-A 1b.
Do I need to install a kind of Office software on Unix to get this working?
Or an image editing tool?
Also, how do I check the debug lines? They aren't in a readable format and I can't find any info on that.
Maybe it is something that only can be checked by the Ghostscript developers?
Almost certainly the input file contains transparency. PDF/A-1 does not support transparency, and so when creating PDF/A-1 files any page which does contain transparency is rendered to an image, and then that image is embedded in the output.
Clearly this will take time (rendering a page at 720 dpi, full colour, and transparency processing is slow) and will result in a large file. However, its the only way to preserve the appearance of the input file and still create a PDF/A-1 file.
Of course, in the absence of an example input file to examine its not possible to be certain of this.
The DEBUG lines switches are useless except to Ghostscript developers, don't bother to set them. You would never set so many anyway, you'll be swamped with extraneous detail. I'm doubtful all the ones you have listed are even valid.
You say you have this 'working' with Ghostscript 9.19 on Windows, what do you mean by 'working' ? It seems to me that the 9.14 output 'works' as well.....
As far as I know we have never compiled a Ghostscript release for HP/UX, but the current version (9.22) is known to compile and run on HP/UX.
Finally Ghostscript does not rely on (and indeed cannot make use of) Microsoft Office. Nor does it rely on the operating system for anything except memory and file access.
I'm just trying to achieve what this thread tittle says. I have found several examples in Google but none of them works. Some of them return short errors while others return large ones. I think that the problem is the Ghostscript version. Is there any proven command that I can use in Ghostscript 9.10 version in order to convert a PDF file to a JPEG file???
This works perfectly well for me:
gs -sDEVICE=jpeg -o out.jpg input.pdf
Without seeing your errors its impossible to know what your problem is. I really doubt you are using 1.10 (I'm not even sure that was a real version number)....