I tried this command:
gs -dPDFA -dBATCH -dNOPAUSE -sProcessColorModel=DeviceRGB -sDEVICE=pdfwrite -sPDFACompatibilityPolicy=1 -sOutputFile=/tmp/test/pdfa/pdftopdfa.pdf /tmp/test/pdftopdfa.pdf
But I got this error:
Artifex Ghostscript 9.14: Can't find initialization file gs_init.ps.
I tried another command:
gs -dPDFA -dBATCH -dNOPAUSE -dUseCIEColor -sProcessColorModel=DeviceCMYK -sDEVICE=pdfwrite -sPDFACompatibilityPolicy=1 -sOutputFile=/tmp/test/pdfa/23238input.xml_2.pdf 23238input.xml_2.pdf
But i got this error:
Artifex Ghostscript 9.14 (2014-03-26) Copyright (C) 2014 Artifex
Software, Inc. All rights reserved. This software comes with NO
WARRANTY: see the file PUBLIC for details. Can't find (or open)
initialization file (gs_std_e.ps) Unrecoverable error: undefined in
.uninstallpagedevice Operand stack: gs_std_e.ps gs_std_e.ps
gs_std_e.ps
Well firstly you are using an old version of Ghostscript, you should probably upgrade.
Secondly wherever you got it from, its non-standard because it has the PostScript resources stored on disk, the default is for them to be built into the binary as a ROM file system.
Finally it appears that the resources on disk are either missing or corrupted. You could search for them, they are usually in somewhere like /usr/local/bin/ghostpdl/Resource and then use the -I switch to present that path to Ghostscript so it knows where to look.
But since its an old version then I'd suggest you get the current version (9.21) instead. If you get a package, and that fails to work, then you should complain to the package maintainer. If you feel up to it you can simply clone the Ghostscript Git repository and build it yourself, its not hard if you have a working C compiler (gcc). Lastly, there are pre-built Linux binaries here which may work on your system, depending on what your setup is.
A couple of notes on your command line; you have not specified the PDFA_def.ps file which you will have to do in order to create a valid PDF/A file, see this documentation but note that's the current 9.21 docs. If you don't supply that file (properly modified from the supplied model) then you won't be able to create a conforming PDF/A file.
Do not use -dUseCIEColor unless you have a very good reason, if you don't know what it does (and I'm guessing you don't) then you don't have a good reason. If you use it without understanding you'll only adversely impact performance and possibly get poor colour reproduction.
Related
we recently upgraded ghostscript from 9.18.0 to 9.55.0. The pdf to tiff conversion is not working with ghostscript version 9.55.0 but it still works with 9.18.0.
We are trying to convert .pdf file to .tiff file using ghostscript. Recently we upgraded the version of ghostscript from 9.18.0 to 9.55.0. below is the arguments we are passing to the version 9.18.0 and it still works fine.tiff file is created
-q -sDEVICE=tiffg4 -r200x200 -dNOPAUSE -dBATCH -sOutputFile=E:\iCapture\mu\X25470003012022022440.tif E:\iCapture\mu\X25470003012022022440.pdf
But when we are passing same arguments to version 9.55.0 its not cretaing the tiff file. Please let me know if any changes to be done to the arguments or do we need to perform any printer setup action after upgradation of the ghostscript. Because we upgraded the ghostscript software and directly we were trying to convert. are we missing any steps after installation?. Thank you! It will be very helpful if we get any insights on this this issue.
I'm on Macos 10.14.5. I run Ghostscript via Macports, and recently upgraded to Ghostscript 9.27. Ever since I upgraded, most of what I use Ghostscript for (Imagemagick file conversions) doesn't work anymore. I made the silly mistake of deleting the old version of Ghostscript in Macports (yeah ...).
Essentially, Ghostscript crashes with an 'Abort trap: 6' error. Example? I try to convert a PDF to PNG. I get this:
[ghostscript library 9.27] -sstdout=%stderr -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 '-sDEVICE=pngalpha' -dTextAlphaBits=4 -dGraphicsAlphaBits=4 '-r600x600' '-sOutputFile=/var/folders/k0/m6mz3d055m75782ynnkt2k0w0000gn/T/magick-5910MkmWy1yIM0tx%d' '-f/var/folders/k0/m6mz3d055m75782ynnkt2k0w0000gn/T/magick-5910gs9cNcP8C7cU' '-f/var/folders/k0/m6mz3d055m75782ynnkt2k0w0000gn/T/magick-5910iJZ-CiPdfIWp'Abort trap: 6
I believe this has to to with '/usr/local/bin/gs-X11' being unable to find the correct directory for a dyld library. When I run gs-X11, I get this:
/usr/local/bin/gs-X11
dyld: Library not loaded: /opt/X11/lib/libXt.6.dylib
Referenced from: /usr/local/bin/gs-X11
Reason: image not found
Abort trap: 6
The 'libXt.6.dylib' library exists on my file system, but not in '/opt/X11/', but in '/opt/local/lib/'.
How do I get Ghostscript to use the correct directory?
Ghostscript doesn't build an executable called 'gs-X11', the executable should be called simply 'gs'.
It 'sounds like' you've picked up a pre-built binary from somewhere, which has been built to expect X-Windows support, and that support is supplied by a system shared library, and as you rightly say, not where you have it installed.
I don't think you can (easily) modify the binary to look elsewhere for the system library, but I'm not a Mac developer so I might be mistaken.
Given that you have the library already present you could try simply copying it to /opt/X11/lib.
Or you could try the source you got the binary from and look for a non-X-Windows version. (or ask them, presumably the Macports people hwo to fix the problem)
Or you could build Ghostscript yourself from source.
To build from source you'll need gcc and the autotools, you can pick up autoconf, automake and libtool from HomeBrew if you don't already have them. With that, get the source tarball from the www.ghostscript.com downloads page, untar it somewhere convenient and then, from that folder do "./autogen.sh" and then "make". That should build a version of Ghostscript compatible with your system.
To be honest, this isn't a Ghostscript question really, more of a Mac system question.
I am having a similar problem on a machine that had various versions of X11 installed (and uninstalled) through both MacPorts and XQuartz. I seem to have solved the problem by providing a symlink between the missing /opt/X11 and the existing /opt/local where the needed things exist:
sudo ln -s /opt/local /opt/X11
sudo ln -s /opt/local /opt/X11R6
Similar problems seem to sometimes occur when /usr/local/X11 and /usr/local/X11R6 are non-existing, but in my case the /usr/local/X11 already had a symlink to /opt/X11 (as does /usr/local/X11R6 )
Probably to really fix everything properly, I should completely uninstall MacPorts, and completely uninstall XQuartz, and remove all the symlinks, then restart the computer to make sure it is all clear. Then reinstall it all and hope that the installers get everything in the right places. Perhaps redoing my MacTeX LaTeX installation would also be wise.
I would like to run my unit test suite with -fsanitize=address,undefined and have all sanitizer errors be written to a report.txt file. By default all sanitizer errors get written to stdout, however the software also writes info to stdout so this makes it difficult to detect errors. I tried:
export ASAN_OPTIONS="log_path=asan.log"
./mytests
And I also tried calling the C API before running tests:
#include <sanitizer/asan_interface.h>
__sanitizer_set_report_path("/tmp/asan.log")
However neither seems to work, all errors just get written to stdout. I am using Debian testing:
root#94e239ad460a:~# gcc --version
gcc (Debian 6.1.1-11) 6.1.1 20160802
Copyright (C) 2016 Free Software Foundation, Inc.
Is there any alternative method that I can save the sanitizer error from my unit tests somewhere?
Hm, I've successfully used log_path numerous times. If it does not work for you, please report a bug to ASan github (preferably with a minimal repro).
I realize that my binaries were not having read permissions. A simple chmod 500 <exe_path> solved my problem.
What I always do is to make sure the directory exists.
You could use Qt:
QDir().mkpath("/tmp");
Asan will append a PID to your filename though, and I don't think you can disable that.
In my common_interface_defs.h there is only __sanitizer_set_report_path but I see that gcc's master has a more recent function where you pass on a file descriptor:
void __sanitizer_set_report_fd(void *fd);
You could check out if your platform's gcc/clang has the newer function to set a file descriptor.
I downloaded the WinFF source code in the hopes the new version would solve a segfault.
It's sitting, extracted, in its folder. But I see no ./configure, nothing make would know what to do with, no binaries, and no compilation instructions:
$ ls
AUTHORS COPYING README-Presets.txt unit2.lfm unit4.pas winff.1 winff.rc
changelog.txt docs README.txt unit2.pas unit5.lfm winff.ico
clean.bat languages RESOURCES.RC unit3.lfm unit5.pas winff-icons
clean.sh potranslator.pas unit1.lfm unit3.pas unit6.lfm winff.lpi
COMPILE.TXT presets.xml unit1.pas unit4.lfm unit6.pas winff.lpr
Does anyone know how I can try to actually compile the code?
All we get is a README.txt:
Winff - graphical video and audio batch converter using ffmpeg or
avconv Copyright © 2006-2012 Matthew Weatherford
http://www.winff.org
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or (at
your option) any later version.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see http://www.gnu.org/licenses/.
WinFF is a GUI for the command line video converter FFmpeg or avconv.
Get the latest ffmpeg builds and source from http://ffmpeg.org/
The answer is in COMPILE.TXT:
winff is compiled with lazbuild -B winff.lpr or manually in the
Lazarus IDE.
I'm rebuilding a flash loader utility for a TI chip and am facing a minor issue that's affecting my workflow. I'm using a 64-bit Win7 PC and rebuilding the utility using make on cygwin bash shell. make and cygwin version numbers below.
$ make -v
GNU Make 3.82.90
Built for i686-pc-cygwin
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ uname -a
CYGWIN_NT-6.1-WOW64 DEEDAA 1.7.15(0.260/5/3) 2012-05-09 10:25 i686 Cygwin
One step in the build process calls a previously generated utility (windows executable) to generate the bin file that is required for the TI processor.
../../AISUtils//HexAIS_OMAP-L138.exe -ini ../sft_hexais.ini -o ../sft_C6748_SPI_MEM.bin ../sft_C6748_SPI_MEM.out
After this command is called there is no progress seen on the cygwin command line. However, execution of the command does complete, generating the files specified in this step and proceeds with the steps that follow in the makefile. It's just that I can never regain control of this window. I always need to kill the window, start another instance of cygwin.
If I try to kill the cygwin window immediately I get the message below.
mintty
Processes are running in session
Close anyway?
If I wait a while (the time to complete the steps that follow), then I can kill the window without this message popping up.
The same command on the windows command line is executed without any stalls and I do regain my command line.
c:\ti\boot_tools\OMAP-L138_FlashAndBootUtils_2_40\OMAP-L138\GNU\AISUtils>HexAIS_OMAP-L138.exe -ini ..\sft\sft_hexais.ini
-o ..\sft\sft_C6748_SPI_MEM.bin ..\sft\sft_C6748_SPI_MEM.out
-----------------------------------------------------
TI AIS Hex File Generator for OMAP-L138
(C) 2012, Texas Instruments, Inc.
Ver. 1.27
-----------------------------------------------------
Begining the AIS file generation.
AIS file being generated for bootmode: UART.
Parsing the input object file, ..\sft\sft_C6748_SPI_MEM.out.
AIS file generation was successful.
Wrote 15464 bytes to file ..\sft\sft_C6748_SPI_MEM.bin.
Conversion is complete.
It seems to me that something about the way the command is constructed is pushing commands on to another shell or forcing it to run in the background. Any thoughts on what may be going on or steps I can try to debug the issue?
file format of the executable that stalls
$ file AISUtils/HexAIS_OMAP-L138.exe
AISUtils/HexAIS_OMAP-L138.exe: PE32 executable (console) Intel 80386 Mono/.Net assembly, for MS Windows
Link to TI wiki that explains the build process. The link provides general instructions on rebuilding the utility and is very unlikely to provide any specific information related to my question. I'm only including it in case someone needed more background about the tools or the process.
http://processors.wiki.ti.com/index.php/Rebuilding_the_Flash_and_Boot_Utils_Package
Thanks.
Running Windows console applications inside a Cygwin (MinTTY) terminal is usually a terrible idea.
Try running inside a Windows (cmd) console or using cygstart to launch in a new window (in a Makefile, -w would probably be useful too).