# What are the advantages of TikZ/PGF over PSTricks?

The first time I saw the PSTricks' 3D Galleries, I immediately fell in love with it. I have spent much time to learn and use it.

In this forum, I see many people using TikZ. I have not used TikZ yet. But now I am confused why there are so many people discussing TikZ rather than PSTricks. Probably there might be special things, in TikZ, that surpass features offered by PSTricks.

Learning new thing really takes time and need hard effort.

1. So is it worth investing time in learning TikZ even though I already know PSTricks?
2. Or should I leave PSTricks and migrate to TikZ?
• I'm not sure that this is a question that is answerable! Perhaps you could identify those aspects of PSTricks that you like so much and ask if they are feasible in TikZ/PGF. Also, pick something that PSTricks doesn't do (or doesn't do easily) and ask if that is possible in TikZ/PGF. – Loop Space Dec 7 '10 at 11:01
• The question may be better phrased as "What are the advantages of TikZ/PGF over PSTricks?" – Matthew Leingang Dec 7 '10 at 13:55
• See also this question: How do PStricks and TikZ compare for ease of learning and for quality of API design? on StackOverflow. – Matthew Leingang Dec 7 '10 at 17:03
• @Jake: Done. Done. – xport Aug 15 '11 at 7:18
• – user10274 Feb 10 '13 at 13:43

TikZ is the only full graphics package for TeX I have ever used, so I can't really do a good comparison. However here are some things that I think are worth mentioning:

• What I like most about TikZ is its syntax. The authors clearly put a lot of thought into defining a syntax that is both flexible and easy to read (at the expense of some verbosity).
• The manual is full of examples and generally of extremely high quality.
• TikZ works with LaTeX, plain TeX and ConTeXt. It can be compiled with all modern engines (pdfTeX, LuaTeX, XeTeX), though a few things (shadings) currently only work with pdftex.
• Integration with gnuplot.
• Some useful programming features, like \foreach or an extensible mathematics engine.

• On the other hand, PSTricks has been around for a longer time. In particular, there are lots of libraries built around it. So if you want to use one of the libraries that doesn't (yet) have a TikZ equivalent, you have to use PSTricks. Also I suppose there is better support on older systems, if updating is not possible.

• @xport: Yes, see chapter 20 ”Transparency” in the (v2.10) manual for examples. Or see texample.net/tikz/examples/venn-diagram – Caramdir Dec 7 '10 at 16:58
• @xport: Both are possible. By default (1,1) would get interpreted as (1cm,1cm), but you can change that both globally and locally (see 22.2 ”The XY- and XYZ-Coordinate Systems”). You can also do silly things like (1cm+1pt,3.4in). You could even have the the coordinate axes pointing in arbitrary directions. – Caramdir Dec 7 '10 at 17:31
• what about the opacity key in pstricks? \documentclass[fleqn,10pt]{book}\usepackage{pstricks}\begin{document}\begin{figure}[!ht]\begin{pspicture}(0,0)(6,5)\psframe[fillstyle=solid,fillcolor=blue,linestyle=none,opacity=1](1,1)(4,4)\psframe[fillstyle=solid,fillcolor=red,linestyle=none,opacity=0.9](2,2)(6,5)\end{pspicture}\end{figure}\end{document} – pluton Dec 7 '10 at 17:31
• There is also a Tikz export in Inkscape and Blender, to be improved probably but still very nice features. – pluton Dec 7 '10 at 17:33
• You can add to your list the greater feature of TikZ/pgf: pgfkeys! – Paul Gaborit Jul 29 '12 at 19:41

## TikZ: Over detailed documentations

The TikZ documentation is extremely detailed. In the tutorial part, it even came to talk about things (e.g., Karl's students) that are unnecessary (at least for me). For example:

• On page 23

• On page 28

• On page 33

and

• On page 35

• On page 37

## PGF/TikZ: Inconsistent Keys

Apparently inconsistencies appear not only in PSTricks but also in PGF/TikZ. Verbosity, which is the great feature in PGF/TikZ, together with provided inconsistency will burden the users to remember unnecessary things.

If PGF/TikZ adopts space separated words for its multi-words keys as follows

• line width
• legend style
• legend cell align
• etc, etc, etc (I cannot list all here)

the following inconsistent naming convention must be avoided.

• xlabel (that should be x label to make it consistent)
• xmin (that should be x min to make it consistent)
• xtick (that should be x tick to make it consistent)
• xticklabel (that should be x tick label to make it consistent)
• etc, etc, etc (I cannot list all here)

## PSTricks: Too short documentation

Unlike the TikZ documentation, some of PSTricks' documentations are rather confusing because of their brevity. We can see one of them in my question.

## PSTricks: Counter intuitive macro names

One of the bad features of PSTricks is its adopted naming convention. PSTricks might be designed without adopting the concept of taxonomy. Inconsistent naming convention makes the users difficult to remember the available PSTricks' key-value options.

I will list the inconsistent key-value options here and progressively add others in the future.

• PSTricks' core:

We have gridlabelcolor that is a good naming convention. But the following names broke the convention.

• gridlabels, it should be gridlabelsize.
• gridfont, it should be gridlabelfont.
• pst-eucl package:

PointName represents the printed name of a defined point. PointNameSep represents the radial distance of the printed name from the defined point. Both keys seem to be good, but the following naming broke the convention.

• PtNameMath, it should be PointNameMath. Or PointNameMode with options either math or text.
• PosAngle, it should be PointNameAngle or PointNameDirection.
• PSTricks' core again:

For placing object to a certain position, we have (among others) \rput, \nput and \uput. However, their abbreviation seems not to be intuitive. According to Herbert,

• \nput stands for node put

• \rput stands for ref put

• \uput stands for user put

I cannot understand why the authors chose "node", "ref" and "user" as the prefix as these names don't emphasize something that can be used to uniquely identify each of them.

• PSTricks' core again:

(Among others) \parametricplot has an alias \psparametricplot, \scalebox has an alias \psscalebox. The underlying reason is to make consistent name as well as to avoid name clash.

However, why are there still the following?

• \newpsobject that should be \psnewobject
• \newpsstyle that should be \psnewstyle
• \addtopsstyle that should be \psaddtostyle
• pst-node package:

\curvepnode and \curvepnodes are used to create a node and a list of nodes, respectively, based on the given parametric expression <abscissa algebraic expression in t>|<ordinate algebraic expression in t> or <abscissa RPN expression in t> <ordinate RPN expression in t>. However, its complementers are \fnpnode and \fnpnodes based on the expression in <ordinate as the algebraic function of x> or <ordinate as the RPN function of x>.

In my opinion, the naming for the both groups should be based on the expression representation. Thus \curvepnode and \curvepnodes should be named as \parametricpnode and \parametricpnodes and \fnpnode and \fnpnodes should be named as \functionpnode and \functionpnodes. The prefix curve cannot be used to uniquely identify the first group from the second group because both groups are related to curves. Curves can be represented in either parametric (x(t),y(t)) or function (x,f(x)).

• pst-node again:

When using \getnodelist, there are 2 macros available internally, \pst@args and \PST@root. Do you notice the capitalization? pst versus PST? Why?

## PSTricks: Exceptional behavior

I found some exceptions in PSTricks that might burden users. The patterns should be intuitive to free users from remembering unnecessary things as follows. I believe that you feel uncomfortable to remember the following notes as they are illogically defined so they waste your memory (in your brain).

• closed curves psframe, pscircle, psellipse, pswedge, psellipticwedge have changeable dimen=outer by default except for \polygon and \psccurve that have changeable dimen=middle. The radial sides of pswedge and psellipticwedge have unchangeable dimen=middle.
• open curves psline, pscurve, psbezier, psarc have unchangeable dimen=middle except for \psellipticarc that has changeable dimen=outer.
• all closed curves move the current points to their starting points except for \psellipse and \pscircle that do not move the current points.

• (0,0) as the first point may be ignored for psframe, pscircle, psellipse, pswedge, psellipticwedge, pspolygon, psline, psbezier and psellipticarc but it must be explicitly specified for psccurve, pscurve and psarc.

• In pst-eucl the labels can be enabled and disabled with PointName=default and PointName=none, respectively. However, for \pstInterCC (probably other macros as well as I haven't checked all) must be disabled with PointNameA= or PointNameB= rather than PointNameA=none or PointNameB=none, respectively. It is a known issue, see this discussion but it is left as is as a feature (maybe).

• To create a new coordinate system (specially for non-orthogonal ones), pst-eucl provides \pstOIJGeonode where O, I and J are the points on which the new coordinate system is based. Unfortunately, the first point on this coordinate system must be specified as the first argument rather than the fourth one which is more common intuitively. Here is the abnormal syntax,

\pstOIJGeonode{<first point>}{O}{I}{J}{<second point>}...{<n point>}


It should be

\pstOIJGeonode{O}{I}{J}{<first point>}{<second point>}...{<n point>}

• Re: Inconsistent keys. All keys you listed except line width are PGFPlots keys and have nothing to do with PGF/TikZ. This is a disadvantage of PGFPlots (with which I agree). Though, there are even worse examples: minor xtick vs minor x tick style. Maybe PGFPlots just has too many keys … – Qrrbrbirlbel Dec 3 '13 at 22:48
• @Qrrbrbirlbel: I intentionally categorized them as a single unit PGF/TikZ as what I did for PSTricks cases where some inconsistencies come from other PSTricks packages. – kiss my armpit Dec 3 '13 at 22:56

The maintainer of PSTricks (Herbert) is tirelessly answering questions here and elsewhere. He is publishing books on PSTricks. If I had to choose one, this was a strong argument towards PSTricks.

• Although Till Tantau may not be a TeX.SE user, Christian Feuersänger wrote pgfplots and often answers pgfplots and tikz questions. – wchargin Dec 11 '14 at 18:35

This should really go in the comments thread on the original post, but I can't do that yet, so I'll put it as an answer instead:

A similar site to the gallery for PSTricks is http://www.texample.net/. As Andrew suggested, this might help you in deciding a more specific question since you'll be able to see a little bit of what TikZ is capable of.

• This should indeed have been a comment. I thought about flagging it, but then decided it was useful and upvoted. – 0xC0000022L Feb 27 '18 at 7:53

1. Yes. It is worth investing time in learning many things in life unless the time and memory restrict you not to do so.
2. No. There is no a good reason to migrate. The maturity of PSTricks provides us with many easy-to-use libraries (even though some naming conventions are confusing and difficult to remember if you are not using them so often). The only 2 things PSTricks' drawbacks are
• PSTricks cannot run on pdflatex without -enable-write18.
• With -enable-write18 and auto-pst-pdf, pdflatex can make use of PSTricks code in the input file. It is done by invoking an external program silently to produce a PDF output that corresponds to PSTricks code. Later this PDf output will be imported as images. Unfortunately, this mechanism make animation with animate package no longer work. Overlaying PSTricks objects on non-EPS images is totally impossible. Cross referencing in PSTricks code will be broken.

Thus TikZ wins only because it was designed to be compiler agnostic.

• (1) i don't understand how auto-pst-pdf breaks animate (unless you're coding a moving image in pstricks, which seems extreme). (2) i don't understand the assertion about overlaying, either; most overlay packages are agnostic about the formats used, except (of course) for psfrag... – wasteofspace Feb 17 '12 at 10:50

The package pgfplots which depends on pgf can call and use gnuplot to compute coordinates from within itself, while the packages pst-plot and pst-3dplot which depend on pstricks have no such feature, though one can use pst-math and pst-func for computing functions in the latter case.

I've used PSTricks a lot in the past, and even contributed some code. One of the main reasons to change to TikZ was probably presentations, i.e. using beamer. And there, in particular the relative ease of creating evolving pictures with nodes in overlays. This used to be quite a hassle in PSTricks since the node names would get confused from one overlay to the next.

I have only used pgf-tikz for TeX graphics and I am very happy with it. At first I also got impressed by some pstricks galleries but however I decided to learn pgf instead. Most of my graphics appear in beamer presentations, so the harmony between pgf and pdftex made me opt for pgf.

What I miss most in pgf is a strong 3D graphics support. Although it is possible to create 3D graphics, it is really a cumbersome task. I hope the promising package tikz-3dplot keep improving.

• tikz-3dplot sounds like a nice package but real 3D perspective is not implemented. It may require too many calculations: should we use Luatex instead? Instead of spending time on such package, wouldn't it be more useful to improve export from Blender? probably not. – pluton Dec 7 '10 at 20:25
• The pgfplots package provides support for 3D data visualization on top of pgf/tikz (compare its manual). Perhaps its orthogonal projections can be extended to also support perspective. I'd say that the difficulty of 3D plots is the amount of data -- not necessarily the perspective transformation. You can post feature requests on the pgfplots sourceforge page. – Christian Feuersänger Mar 6 '11 at 19:20

I prefer to use tikz rather than pstricks because when using pstricks for a web-based pdf generator, it needs 3 compilation steps that consume more processor time.

For me what completely seals the deal towards TikZ is the matlab2tikz package.

As an assiduous Matlab user, the possibility to export my graphs and plots to LaTeX (which I use to write papers) is invaluable.

• assiduous as in rich and unfortunate, eh? – percusse Oct 30 '13 at 16:22
• @percusse as in Student and Pirates of the Caribeean :P – Mario S. E. Oct 30 '13 at 16:58

In my rough or at a glance investigation, TikZ consumes more keystrokes than PSTricks does. So for those who can only type with 2 fingers slowly, i.e., one index on the left hand, the other index on the right hand, you will get tired quickly when using TikZ. It is not a joke!

• Do you spend more time writing code, or reading and debugging it? – Federico Poloni Mar 23 '13 at 12:59