TikZ: Features
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 widthlegend stylelegend 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,
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>}
