One good feature of TikZ is that the canvas size is automatically provided. But it is visually not as smart as I think (see question Bounding box is larger than expected when drawing a curved path). In PSTricks, the canvas must be calculated manually to let TeX provide the required space (because TeX has no knowledge about PostScript).
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
On page 35
On page 37
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.
gridlabelcolor that is a good naming convention. But the following names broke the convention.
gridlabels, it should be
gridfont, it should be
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
PointNameMode with options either
PosAngle, it should be
PSTricks' core again:
For placing object to a certain position, we have (among others)
\uput. However, their abbreviation seems not to be intuitive. According to Herbert,
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:
\parametricplot has an alias
\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
\newpsstyle that should be
\addtopsstyle that should be
\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
\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
\curvepnodes should be named as
\fnpnodes should be named as
\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
\getnodelist, there are 2 macros available internally,
\PST@root. Do you notice the capitalization?
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.
- all closed curves have
dimen=outer by default except for
\psccurve that have
- all open curves have
dimen=middle by default except for
\psellipticarc that has
- all closed curves move the current points to their starting points except for
\pscircle that do not move the current points.