I built a quite large PDF using LaTeX with the lualatex compiler (I need that one because of specific fonts) and now want to shrink the PDF with ps2pdf, following this instruction (the answer with the second-most votes, since gs is not recognized as a command line tool on my computer). My command looks like this:
ps2pdf -dPDFSETTINGS=/ebook -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -q -sOutputFile=output.pdf input.pdf
I get this error message:
MiKTeX GPL Ghostscript 9.25: Device 'pdfwrite' requires an output file but no file was specified.
**** Unable to open the initial device, quitting.
I definitely made sure that the file exists, I tried it using as *.ps file as input, gave the full path, once with and without double-quotes (Windows system), yet nothing worked. Strangely enough, just running ps2pdf ouput.pdf input.ps works, but produces an even larger PDF. What am I missing?
The file that can't be opened is the output file, so if it exists, that would be a potential problem. If 'something else' has the output file open then it won't be possible to write to it.
You appear to be running a non-standard version of Ghostscript, judging by the startup banner, if I were you I would install and use a standard version of Ghostscript, even if you have to build it yourself.
It's odd that 'ps2pdf' which is just a script to run Ghostscript would work, whereas a simple 'gs' would not. I personally would not use the script. Try and find the Ghostscript executable and run that directly.
I'd drop the -q (quiet) switch as well, at least while trying to solve a problem, suppressing messages could be hiding something useful.
Oh I see, you are actually using Windows. Well, the executable on Windows isn't called 'gs', it's called gswin followed by either 32 or 64 for the word size and then c if it's the command line (as opposed to windowed) version. So you want one of gswin32, gswin32c, gswin64 or gswin64c. Note that the Ghostscript installer doesn't add the installation directory to the $PATH environment variable so if you just open a Windows command shell and type 'gswin32c' it won't be found. You need to either add the isntall directory to the $PATH or supply a full path to the executable.
I'd personally use the vanilla Windows binary rather than a modified version supplied under MingW or whatever Linux shell you are using. It's also conceivable that this is causing your problem writing to the output file, if the directory is unavailable, or read-only, to the shell.
Related
I have a .cmm file which helps in debugging of Qcomm chipsets.
This file has a line : cd ../../../../../modem_proc
When I run this same cmm file using T32 GUI, it runs fine and does the work. But when I am trying to run the same file using windows command line using,
C:\T32\bin\windows64>t32mqdsp6.exe -c C:\T32\config.t32 -s D:\path\to\xxx.cmm
Following error is thrown in T32: syntax error in B::cd ../../../../../modem_proc
What am I missing here? I have no hands-on experience with T32 what-so-ever.
The problem probably results from different working directories. Type
PRINT OS.PWD()
in the GUI and add it to the top of the script. I'd suspect they are different.
Don't use working directory relative paths, instead use paths relative to the script, e.g.
CD ~~~~/../../../../modem_proc
The four tilde (~) symbols mean "directory of the currently executed script". There's still a possible issue with this solution when using multiple GUIs and the intercom, but for most use-cases this should be OK.
When starting TRACE32 (up to build 99518) without option "-s", it starts a default script t32.cmm form your TRACE32 installation directory. But t32.cmm is not executed, when "-s" is used.
So probably your t32.cmm is changing your working directory. If so you can fix the issue by adding the line
DO ~~/t32.cmm
to the top of your script xxx.cmm.
See also https://www.lauterbach.com/frames.html?help_autostart.html
The default working path is also set by the TRACE32 configuration file. That is the file passed with "-c". So if your are using a different configuration file than C:\T32\config.t32 when starting your TRACE32 GUI the normal way, then you should use that configuration file also when starting TRACE32 from the command line.
To get the path of the configuration file usually used, start TRACE32, execute command AREAand then command PRINT OS.PCF()
Furthermore dev15 is probably right here https://stackoverflow.com/a/53671657/4727717:
Use paths relative to the PRACTICE script (cmm-file) by starting each path with four tildes.
I am currently trying to add some TrueType Fonts to my current Ghostscript setup.
(Windows 10, Ghostscript 9.25, 64bit)
I am editing the Fontmap.GS file found in the folder C:\Program Files\gs\gs9.25\Resource\Init but somehow that doesn't change the behavior. Ghostscript is still substituting Arial-BoldMT with Helvetiva-BoldMT even though I have specified a font to use in that case:
/ArialMT (arial.ttf) ;
/Arial-BoldMT (arialbd.ttf) ;
/Arial-ItalicMT (ariali.ttf) ;
/Arial-BoldItalicMT (arialbi.ttf) ;
Do you know if there is a way to update the Fontmap?
(Or maybe there is another Fontmap file that is being used and I'm editing the wrong one?)
This is the shell answer I get when converting a document that uses Arial-BoldMT (not embedded):
gswin64c -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -dAutoRotatePages=/None -sOutputFile=bt_c.pdf bt.pdf
GPL Ghostscript 9.25 (2018-09-13)
Copyright (C) 2018 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 1.
Page 1
Querying operating system for font files...
Substituting font Helvetica-Bold for Arial-BoldMT.
Loading NimbusSans-Bold font from %rom%Resource/Font/NimbusSans-Bold... 4854008 3414088 2431224 1058145 3 done.
The font files themselves are placed in C:\Program Files\gs\gs9.25\Resource\Font
Thank you so much in advance!
In older versions of Ghostscript we did not even ship the support files for Windows, 9.25 is the first (Windows) version where these files are actually installed without extra effort from the user.
The Windows version (and in fact all versions now) defaults to using a ROM file system. That is, the support files are compiled into the executable. What that means is that Ghostscript doesn't look at the disk files, unless you tell it to.
You need to add a -I (Include) directive to tell Ghostscript to look at the modified files on disk. In your case that would be :
-IC:/Program Files/gs/gs9.25/Resource/Init
I'd suggest that you don't put the TrueType files in the Fonts folder, leave them in the Windows/Fonts folder and modify the contents of fontmap.GS so that you include the path:
/ArialMT (c:/Windows/Fonts/arial.ttf) ;
/Arial-BoldMT (c:/Windows/Fonts/arialbd.ttf) ;
/Arial-ItalicMT (c:/Windows/Fonts/ariali.ttf) ;
/Arial-BoldItalicMT (c:/Windows/Fonts/arialbi.ttf) ;
As a couple of extra notes; many font names in PDF files don't follow the names of the original TrueType font. Its not uncommon to see Arial,Bold as a font name. You can add an alias in the fontmap.GS file for that if you've already defined Arial-BoldMT:
/Arial,Bold /Arial-BoldMT ;
I'd recommend using forward slash (/) rather then backslash characters whenever specifying paths for Ghostscript. It happily uses both, converts as required to the OS version and you don't have to worry about whether you need a double backslash or not.
Not all fonts are Fonts, sometimes they are CIDFonts, you need to edit cidfmap to add those. The format of the content is different because more information is needed to construct a replacement for a missing CIDFont.
Update: I was now able to solve the problem myself by passing the custom fontmap as well as the location of the font files in the command line:
-sFONTMAP='/home/MyFonts/MyFontmap.GS' -I'/home/MyFonts/'
Like this Ghostscript loads the correct FontMap file and also knows where to search for the actual font files.
I hope this is helpful for someone!
You have to declare "rom" in the local variable of windows and put
rom = "C: \ Program Files \ gs \ gs9.50 \"
% Rom% Resource / Font / NimbusSans-Regular
equals
C: \ Program Files \ gs \ gs9.50 \ Resource / Font / NimbusSans-Regular
I'm using ptxdist to build uclinux for an EFM32GG DK3750. It provides a small unix shell, with busybox. When I then try to compile io.js for the distribution, and copy it to the target bin folder and run the program on the target, I get the error
iojs: applet not found
This is the same result I get from typing busybox iojs. Typing a random string in the shell, I get that there's no such file on the system.
Using ls -l in /bin shows that iojs is a binary, unlike the other commands provided through busybox, which are symlinks. Executing the binary directly with ./bin/iojs results in the same error. What way can I tell busybox to not try to execute the applet, but that I want to use the binary in bin?
Check that the binary for io.js is really correct (right size and md5sum), and not a copy of the busybox binary. Perhaps there's a packaging problem.
We're developing an app that needs to run on a removable device (e.g. USB stick). On Linux, we're using Gnome launchers to place a shortcut to the app on the root of the device. However, we need to use relative paths for the executable and icon since we don't know in advance where the device will mount. In the .desktop file I have something like:
Exec=../myapp/myexecutable
Icon=../myapp/myicon.png
Neither the executable or icon is found. I read the spec on icon lookup in .desktop files (http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#icon_lookup) but it didn't enlighten me.
Is there a way to get launchers to use a relative path? If not, is there another approach to achieve what I want (i.e. a shortcut with an icon and an executable, specified using relative paths)?
Relative paths are not supported*.
One solution is to have an installer. This script updates the desktop file according to the location the script is run from. Make the script executable, and the user can click it to install. The script requires the desktop file to be writable.
This was done with Linux in mind. The file is named autorun.sh; but that is just a convention, it usually won't run automatically. If you deploy this on something other than Linux, then name the file something else(autorun.linux), or adapt it to do different things according to the platform.
#! /bin/sh
#### Fixup $APPNAME.desktop.
APPNAME=xvscatter
ICONNAME=xv_logo.png
cd $(dirname "$0")
APPDIR="$PWD/$APPNAME"
EXEC="$APPDIR/$APPNAME"
ICON="$APPDIR/$ICONNAME"
sed -i -e "s#^Icon=.*#Icon=$ICON#" \
-e "s#^Exec.*#Exec=$EXEC#" "$APPNAME.desktop"
*The convention for the freedesktop is to have the icons in $HOME/.icons, /usr/share/icons or /usr/share/pixmaps. Under those directories are subdirectories for different icon sizes and types. When using one of those directories to store the icon, only the icon name(without the directory) is listed in the desktop file; otherwise record the full path to the file.
The executable, if in the path, can be listed with no pathname(unsafe). It's best to list the full path. Imagine the wrong program getting launched because the full path isn't specified.
Another possibility is to copy the desktop file to the user's desktop or to /usr/share/applications, and edit it there. Do this when the program is on read-only media.
Because none of the above results in a true install, if possible, use the platform's native installer and packaging tools(rpm,dep,portage, etc.). Those tools provide a framework for complete installation including the proper file permissions(think selinux), and desktop menus. They also provide for easy uninstall.
If the program has to run from the removable media, consider using the system install for just installing symlinks, maybe to /opt/vendor/progname.
What I did and worked perfectly was:
Exec=sh -e -c "exec \\"\\$(dirname \\"\\$0\\")/.sh/server.sh\\";$SHELL" %k
Explaining the command:
The snippet below will get the dir name of who is executing that, therefore the launcher dir name
$(dirname \\"\\$0\\")
So appending the desired path, will make this execute relative path.
Ref: https://askubuntu.com/questions/1144341/execute-shell-on-a-relative-path-on-ubuntu-launcher
Is there a way to use ghostscript to convert PDF to PDF/A or PDF/X? I know it can be used to convert PDF to images, but I don't know if it can be used to convert PDF/A. What parameters should I use?
This is to convert a pdf document (not pdf/a) into pdf/a:
gs -dPDFA -dBATCH -dNOPAUSE -dUseCIEColor -sProcessColorModel=DeviceCMYK -sDEVICE=pdfwrite -sPDFACompatibilityPolicy=1 -sOutputFile=output_filename.pdf input_filename.pdf
Hope this will help some one!
Hope this answer helps others coming from Google with the same problem:
To convert from PDF to PDFA-1b or PDFA-2b, you can use Ghostscript. I suggest you use the latest version (9.19 today).
Install it
**In Mac OS**, you may prefer to use [Homebrew][1]:
brew install ghostscript
(UPDATE: 2023-01-23. This no longer works in mac with homebrew, as versions newer than 9.19 will adamantly refuse to do the conversion, no matter what I've tried)
In Linux, some distros bring a much older version (rhel7 sports 9.07). To download a fully independent modern one-file-only ghostscript, download it directly from the site:
wget https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/download/gs919/ghostscript-9.19-linux-x86_64.tgz
(UPDATE: 2023-01-23: stick to that version, newer versions won't work with the method presented below.
If the link above is broken when you try it 20 years from now, please refer to ghostscript.com and search for download section. Download the binary version, don't go for the source, unless you know what you are doing.
In Windows, I cannot help you, but if you manage to install it, the following commands will also work, if you substitute the location of files and gs executable.
Command line
(note to future editors, please don't remove formatting, as this is more readable, yet working command line)
gs-919-linux_x86_64 \
-dPDFA=1
-dNOOUTERSAVE \
-sProcessColorModel=DeviceRGB \
-sDEVICE=pdfwrite \
-dPDFACompatibilityPolicy=1 \
-o output_file.pdf \
/path/to/PDFA_def.ps \
input_file.pdf
In Mac gs-919-linux_x86_64 will be simply gs.
Please note that output_file.pdf and input_file.pdf must be changed to the names of the output file (the converted file) and the input file (the file to be converted). /path/to/PDFA_def.ps is your copy of the file PDFA_def.ps.
-dPDFA=1 is for PDFA-1b.
-dPDFA=2 if you want PDFA-2b.
What is PDFA_def.ps?
PDFA_def.ps is some sort of template ghostscript uses to create a PDFA file. The tricky part is that, for some reason, ghostcript comes with a non-working file.
You'll need to edit PDFA_def.ps and include the path to a valid ICC (color profile) file. Download a good color profile from Adobe:
wget https://tutankhamon.acc.umu.se/mirror/archive/ftp.sunet.se/pub/vendor/adobe/adobe/iccprofiles/win/AdobeICCProfilesWin_end-user.zip
Inside that zip, find a file called AdobeRGB1998.icc, put it somewhere and put the path to that file INSIDE you PDFA_def.ps file. Note that the path should be absolute, with no quotes. Like:
/ICCProfile (/full/path/to/file/AdobeRG1998.icc) % Customize.
Here is a version of PDFA_def.ps, change PATH_TO_YOUR_ICC_FILE to the path of you AdobeRGB1998.icc.
https://gist.githubusercontent.com/weltonrodrigo/19df77833f023fbe1572168982e4b515/raw/ea86e87379d14120d7ff26f6f235ac7eeb5f5dd5/PDFA_def.ps
#danio, #imgen: Even recently released documentation pages on PDF/X (standardized Prepress requirements) and PDF/A (standardized Archiving requirments) generation were quite misleading. (Your link pointed to a v8.63 release.) In the end, it suggested that running the example commandlines using the sample PDF*_def.ps would already generated valid PDF/A and PDF/X files.
But, they do not!
Here is one of the sample commands, which by itself is correct:
gs \
-dPDFA \
-dBATCH \
-dNOPAUSE \
-dNOOUTERSAVE \
-dUseCIEColor \
-sDEVICE=pdfwrite \
-sOutputFile=out-a.pdf \
PDFA_def.ps \
input.ps
The output file will declare itself to be PDF/A (and most PDF viewers would happily go along with this), but the output file fails all real compliance tests.
The fix is easy: you need to edit your sample PDFA_def.ps (for PDF/X: your PDFX_def.ps) files to match your environments. These required edits were not clearly spelled out in older documentation versions, and the provided command suggested it would work out of the box.
Especially in case of PDF/X you MUST specifiy a valid ICC profile to use.
See also the updated documentation (current SVN trunk version) about this:
http://svn.ghostscript.com/ghostscript/trunk/gs/doc/Ps2pdf.htm#PDFA
Please note that current answers are not completely correct. You can define which level of PDF/A you want, resulting in different behaviors of the program. This one is correct:
gs -dPDFA -dBATCH -dNOPAUSE -sColorConversionStrategy=UseDeviceIndependentColor -sDEVICE=pdfwrite -dPDFACompatibilityPolicy=2 -sOutputFile=output_filename.pdf input_filename.pdf
Please note my change from sdPDFACompatibilityPolicy to dPDFACompatibilityPolicy.
Change it to a higher number to get other versions. 1 is good if you don't need DOCINFO.
Furthermore we use the option UseDeviceIndependentColor to avoid validating issues.
If you change options here, you will most likely get a non compliant PDF/A (even if it stated differently).
You can check your pdf/a here:
https://www.pdf-online.com/osa/validate.aspx
If you're using Windows and want to create PDF/A-1b documents explicitely (PDFCreator has an output option for PDF/A-2b but not for PDF/A-1b), you just can enter the parameters Artur described above into the ui settings of PDFCreator without the ones for the document names. Start PDFCreator, choose the printer menu, then go to settings. Now, choose 'Ghostscript' from the settings list on the left side. Under 'additional ghostscript settings', enter as follows :
-dPDFA|-dBATCH|-dNOPAUSE|-dUseCIEColor|-sProcessColorModel=DeviceCMYK|-sDEVICE=pdfwrite|-sPDFACompatibilityPolicy=1
Click on 'Save', then print something from MS Word or any other application you want using the PDFCreator - it will be created in PDF/A-1b.
Greetings,
Fritz