pstoedit [ -v -help ]
pstoedit [ -adt ] [ -df fontname ] [ -dis ] [ -dt ] [ -flat number ] [ -fontmap file ] [ -include includefile ] [ -merge ] [ -nb ] [ -nfr ] [ -nomaptoisolatin1 ] [ -nq ] [ -page number ] [ -pagesize string ] [ -psarg string ] [ -pti or -pta ] [ -rgb ] [ -rotate angle (0-360) ] [ -scale factor ] [ -sclip ] [ -ssp ] [ -split ] [ -t2fontsast1 ] [ -uchar character ] [ -v ] -f "format[:options]" [inputfile [ outputfile ]]
pstoedit [ -scale factor ] -f "format[:options]" -bo input-file [ output-file ]
From within gsview pstoedit can be called via "Edit | Convert to vector format"
pstoedit can also be used as PostScript and PDF graphic import filter for several programs including MS-Office 95/97,2000, PaintShop-Pro and PhotoLine. See http://www.pstoedit.net/importps/ for more details.
This manpage documents release 3.31 of pstoedit.
pstoedit converts PostScript and PDF files to various vector graphic formats. The resulting files can be edited or imported into various drawing packages. Type
pstoedit -help
to get a list of supported output formats. Pstoedit comes with a large set of format drivers integrated in the binary. Additional drivers can be installed as plugins and are available via http://www.pstoedit.net/plugins/. Just copy the plugins to the same directory where the pstoedit binary is installed. However, unless you also get a license key for the plugins, the additional drivers will slightly distort the resulting graphics. See the documentation provided with the plugins for further details.
pstoedit works by redefining the two basic painting operators of PostScript, stroke and show (bitmaps drawn by the image operator are not supported by all backends.) After redefining these operators, the PostScript or PDF file that needs to be converted is processed by a PostScript interpreter, e.g., Ghostscript (gs(1)). You normally need to have a PostScript interpreter installed in order to use this program. However, you can perform some "back end" processing of prepared files by specifying the -bo option for debugging or limited filtering. See "BACK END-SPECIFIC OPTIONS" below.
The output that is written by the interpreter due to the redefinition of the drawing operators is a sort of 'flat' PostScript file that contains only simple operations like moveto, lineto, show, etc. You can look at this file using the -f debug option.
This output is read by end-processing functions of pstoedit and triggers the drawing functions in the selected back end driver, or backend.
If you want to process PDF files directly, your PostScript interpreter must provide this feature, as does Ghostscript. Aladdin Ghostscript 4.03 or later is recommended for processing PDF (and PostScript Level 2) files.
You can switch Ghostscript into PostScript Level 1 only mode by -psarg "level1.ps". This can be useful for example if the PostScript file to be converted uses some Level 2 specific custom color models that are not supported by pstoedit. However, this requires that the PostScript program checks for the PostScript level supported by the interpreter and "acts" accordingly.
If you want to pass multiple options to Ghostscript you must can use multiple -psarg options -psarg opt1 -psarg opt2 -psarg opt2. See the GhostScript manual for other possible options.
document_font_name target_font_name
% lines beginning with % are comments
% if a font name contains spaces, use
% the "font name with spaces" notation.
Each font name found in the document is checked agains this mapping and if there is a corresponding entry, the new name is used for the output.
If the -fontmap option is not specified, pstoedit automatically looks for the file drivername.fmp in the installation directory and uses that file as a default fontmap file if available. The installation directory is:
The mpost.fmp in the misc directory of the pstoedit distibution is a sample map file with mappings from over 5000 PostScript font names to their TeX equivalents. This is useful because MetaPost is frequently used with TeX/LaTeX and those programs don't use standard font names. This file and the MetaPost backend are provided by Scott Pakin (pakin@cs.uiuc.edu).
Another example is wemf.fmp to be used under Windows. See the misc directory of the pstoedit distribution.
If neither an input nor an output file is given as argument, pstoedit works as filter reading from standard input and writing to standard output.
pstoedit allows you to pass individual options to a backend. This is done by appending all options to the format specified after the -f option. The format specifier and its options must be separated by a colon (:). If more than one option needs to be passed to the backend, the whole argument to -f must be enclosed within double-quote characters, thus:
-f "format[:option option ...]"
To see which options are supported by a specific format, type: pstoedit -f format:-help
The following description is it not up to date at the moment. Sorry! Please use the above command to get a current list of options supported by the specific format.
Currently met, java, dxf, pic, fig, metapost, LaTeX2e, mif, emf, and wmf are the only drivers accepting specific options. Other options may be asserted through environment variables. See "ENVIRONMENT VARIABLES" below.
The wmf and the emf driver supports the following backend specific options:
The java backend allows to specify the class name of the class that is generated by pstoedit. The default is PSJava. You can change this using
The dxf backend accepts the option -lines which forces all polygons and lines to be represented as LINEs in the generated DXF file. The default is to use POLYLINEs.
Example: -f "dxf:-lines"
The met backend allows the following single character options (without a leading -)
Example: -f "met:lc"
The pic backend accepts the options:
BUG: these options really does not belong in a backend
Example: -f "pic:-troff -text -landscape"
The fig driver accepts the following options:
The ps2ai driver provides an option to select to old AI-88 format instead of the default AI-3
Example: -f ps2ai:-88
The tgif driver provides option to control the conversion of text strings into hyperlink attributes.
The tk driver supports the following backend specific options:
The mif backend allows the following options:
The GNU libplot driver (gmfa, gmfb, plot) provides a huge set of options. All these are described in the header of the drvlplot.cpp file.
pstoedit cooperates with autotrace. Autotrace can now produce a dump file for further processing by pstoedit using the -bo (backend only) option. Autotrace is a program written by a group around Martin Weber and can be found at http://sourceforge.net/projects/autotrace/.
The ps2ai backend is not a native pstoedit backend. It does not use the pstoedit postcript flattener, instead it uses the PostScript program ps2ai.ps which is installed in the GhostScript distribution directory. It is included to provide the same "look-and-feel" for the conversion to AI. The additional benefit is that this conversion is now available also via the "convert-to-vector" menu of Gsview. However, lot's of files don't convert nicely or at all using ps2ai.ps. So a native pstoedit driver would be much better. Anyone out there to take this ? The AI format is usable for example by Mayura Draw (http://www.mayura.com). Also a driver to the Mayura native format would be nice.
If you have a version of GhostScript older than 5.60, then you have to apply the following simple patch to the ps2ai.ps file in order to make this driver work. This patch is already included in newer versions of GhostScript.
After the line "/vers {2.13} def" insert:
/cdef { 1 index where { pop pop pop } { def } ifelse } def
Replace the lines:
"/jout false def"
with
"/jout false cdef"
(notice the cdef instead of def)
"/joutput (ps2ai.out.aips) def"
with
"/joutput (ps2ai.out.aips) cdef"
"/joutln false def"
with
"/joutln false cdef"
and the line
"/jtxt3 true def"
with
"/jtxt3 true cdef"
Note: If you already patched ps2ai for pstoedit version 3.02. you have to change to the patch above. This version is different but it better fits the ideas of Peter L. Deutsch. Sorry for the confusion, but this way chances are better that this version will go into the GhostScript distribution.
Note that, as far as Scott knows, MetaPost does not support PostScript's eofill. My backend just converts eofill to fill, and issues a warning if verbose is set. Fortunately, very few PostScript programs rely on the even-odd fill rule, even though many specify it.
For more on MetaPost see:
http://cm.bell-labs.com/who/hobby/MetaPost.html
To implement a new backend you can start from drvsampl.cpp and drvsampl.h. See also comments in drvbase.h and drvfuncs.h for an explanation of methods that should be implemented for a new backend.
A default PostScript interpreter to be called by pstoedit is specified at compile time. You can overwrite the default by setting the GS environment variable to the name of a suitable PostScript interpreter.
You can check which name of a PostScript interpreter was compiled into pstoedit using: pstoedit -help -v.
See the GhostScript manual for descriptions of environment variables used by Ghostscript most importantly GS_FONTPATH and GS_LIB; other environment variables also affect output to display, print, and additional filtering and processing. See the related documentation.
pstoedit allocates temporary files using the function tempnam(3). Thus the location for temporary files might be controllable by other environment variables used by this function. See the tempnam(3) manpage for descriptions of environment variables used. On UNIX like system this is probably the TMPDIR variable, on DOS/WINDOWS either TMP or TEMP.
pstoedit compiled with MS-Visual C++ or Borland C++ runs under 32-bit only. It might run under WIN32s, but certainly does not run under plain 16-bit DOS.
pstoedit works best if you installed at least version 5.50 of GhostScript and version 2.72 of gsview. Using older version of GhostScript is possible but requires the setting of some environment variables.
If you have problems with pstoedit first try whether Ghostscript successfully displays your file. If yes try pstoedit -f ps infile.ps testfile.ps and check whether testfile.ps still displays correctly using Ghostscript. If this file doesn't look correctly then there seems to be a problem with pstoedit's PostScript frontend. If this file looks good but the output for a specific format is wrong, the problem is probably in the backend for the specific format. In either case send bug fixes and reports to the author.
A common problem with PostScript files is that the PostScript file redefines one of the standard PostScript operators inconsistently. There is no effect of this if you just print the file since the original PostScript "program" uses these new operator in the new meaning and does not use the original ones anymoew. However, when run under the control of pstoedit, these operators are expected to work with the original semantics.
So far I've seen redefinitions for:
I've included work-arounds for the ones mentioned above, but some others could show up in addition to those.
Non-standard fonts (e.g. TeXbitmap fonts) are mapped to a default font which can be changed using the -df option. pstoedit chooses the size of the replacement font such that the width of the string in the original font is the same as in the replacement font. This is done for each text fragment displayed. Special character encoding support is limited in this case. If a character cannot be mapped into the target format, pstoedit displays a '#' instead. See also the -uchar option.
pstoedit supports bitmap graphics only for some backends.
The Gnuplot backend and the 3D backends (rpl, lwo, rib) do not support text.
Generally, pstoedit does not support clipping. You can try to use the -sclip option to simulate clipping. However, this doesn't work in all cases as expected.
Special note about the Java backends (java1 and java2)
The java backends generate a java source file that needs other files in order to be compiled and usable. These other files are Java classes (one applet and support classes) that allow to step through the individual pages of a converted PostScript document. This applet can easily be activated from a html-document. See the java/java1/readme_java1.txt or java/java2/readme_java2.htm file for more details.
Why do letters like O or B get strange if converted to tgif/xfig using the -dt option?
This is because most backends don't support composite paths with intermediate gaps (moveto's) and second don't support very well the (eo)fill operators of PostScript (winding rule). For such objects pstoedit breaks them into smaller objects whenever such a gap is found. This results in the "hole" beeing filled with black color instead of beeing transparent. Since version 3.11 you can try the -ssp option in combination with the xfig backend.
Why does pstoedit produce ugly results from PostScript files generated by dvips?
TeX documents usually use bitmap fonts. Such fonts cannot be used as native font in other format. So pstoedit replaces the TeX font with another native font. Of course, the replacement font will in most cases produce another look, especially if mathematical symbols are used.
Wolfgang Glunz, wglunz@pstoedit.net
http://www.pstoedit.net/pstoedit/
At this site you also find more information about pstoedit and related programs and hints how to subscribe to a mailing list in order to get informed about new releases and bug-fixes.
Trademarks mentioned are the property of their respective owners.
Some code incorporated in the pstoedit package is subject to copyright or other intellectual property rights or restrictions including attribution rights. See the notes in individual files.
pstoedit is controlled under the Free Software Foundation GNU Public License (GPL). However, this does not apply to importps and the additional plugins.
Aladdin Ghostscript is a redistributable software package with copyright restrictions controlled by Aladdin Software.
pstoedit has no other relation to Ghostscript besides calling it in a subprocess.
The authors, contributors, and distributors of pstoedit are not responsible for its use for any purpose, or for the results generated thereby.
Restrictions such as the foregoing may apply in other countries according to international conventions and agreements.