¿Cuáles son las ventajas de TikZ / PGF sobre PSTricks?

Solución:

TikZ es el único paquete de gráficos completo para TeX que he usado, por lo que realmente no puedo hacer una buena comparación. Sin embargo, aquí hay algunas cosas que creo que vale la pena mencionar:

• Lo que más me gusta de TikZ es su sintaxis. Los autores claramente pensaron mucho en definir una sintaxis que sea flexible y fácil de leer (a expensas de cierta verbosidad).
• El manual está lleno de ejemplos y, en general, de una calidad extremadamente alta.
• TikZ funciona con LaTeX, plain TeX y ConTeXt. Se puede compilar con todos los motores modernos (pdfTeX, LuaTeX, XeTeX), aunque algunas cosas (sombreados) actualmente solo funcionan con pdftex.
• Integración con gnuplot.

• Algunas funciones de programación útiles, como foreach o un motor matemático extensible.

• Por otro lado, PSTricks existe desde hace más tiempo. En particular, hay muchas bibliotecas construidas a su alrededor. Entonces, si desea usar una de las bibliotecas que (todavía) no tiene un equivalente de TikZ, debe usar PSTricks. También supongo que hay un mejor soporte en sistemas más antiguos, si la actualización no es posible.

TikZ: características

• Tamaño del lienzo: Tamaño del lienzo en TikZ se proporciona automáticamente. Pero visualmente no es tan inteligente como creo (consulte la pregunta El cuadro delimitador es más grande de lo esperado cuando se dibuja una trayectoria curva). En PSTricks, el lienzo debe calcularse manualmente para permitir que TeX proporcione el espacio requerido (porque TeX no tiene conocimiento sobre PostScript).
• Puntos de intersección: Con intersection biblioteca, los puntos de intersección de dos curvas arbitrarias se pueden determinar fácilmente en TikZ pero no en PSTricks porque dicho paquete aún no se ha implementado en PSTricks.

TikZ: documentación detallada

La documentación de TikZ es extremadamente detallada. En la parte tutorial, incluso llegó a hablar de cosas (por ejemplo, los alumnos de Karl) que son innecesarias (al menos para mí). Por ejemplo:

• En la página 23

  

• En la página 28

  

• En la página 33

  

  y

  

• En la página 35

  

• En la página 37

  

PGF / TikZ: claves inconsistentes

Aparentemente, aparecen inconsistencias no solo en PSTricks sino también en PGF / TikZ. La verbosidad, que es la gran característica de PGF / TikZ, junto con la inconsistencia proporcionada, cargará a los usuarios para recordar cosas innecesarias.

Si PGF / TikZ adopta palabras separadas por espacios para sus palabras múltiples keys como sigue

• line width
• legend style
• legend cell align
• etc, etc, etc (no puedo enumerar todos aquí)

Se debe evitar la siguiente convención de nomenclatura inconsistente.

• xlabel (eso debería ser x label para hacerlo consistente)
• xmin (eso debería ser x min para hacerlo consistente)
• xtick (eso debería ser x tick para hacerlo consistente)
• xticklabel (eso debería ser x tick label para hacerlo consistente)
• etc, etc, etc (no puedo enumerar todos aquí)

PSTricks: documentación demasiado corta

A diferencia de la documentación de TikZ, algunas de las documentaciones de PSTricks son bastante confusas debido a su brevedad. Podemos ver uno de ellos en mi pregunta.

PSTricks: Contra intuitivo macro nombres

Una de las malas características de PSTricks es su convención de nomenclatura adoptada. Los PSTricks podrían diseñarse sin adoptar el concepto de taxonomía. La convención de nomenclatura inconsistente hace que los usuarios sean difíciles de recordar los PSTricks disponibles. key-Opciones de valor.

Enumeraré las inconsistentes key-valuar opciones aquí y agregar progresivamente otras en el futuro.

• Núcleo de PSTricks:

  Tenemos gridlabelcolor esa es una buena convención de nomenclatura. Pero los siguientes nombres rompieron la convención.

  • gridlabels, debería ser gridlabelsize.
  • gridfont, debería ser gridlabelfont.

• pst-eucl paquete:

  PointName representa el nombre impreso de un punto definido. PointNameSep representa la distancia radial del nombre impreso desde el punto definido. Ambos keys parece ser bueno, pero el siguiente nombre rompió la convención.

  • PtNameMath, debería ser PointNameMath. O PointNameMode con opciones ya sea math o text.
  • PosAngle, debería ser PointNameAngle o PointNameDirection.

• El núcleo de PSTricks de nuevo:

  Para colocar un objeto en una determinada posición, tenemos (entre otros) rput, nput y uput. Sin embargo, su abreviatura no parece ser intuitiva. Según Herbert,

  • nput significa poner nodo

  • rput significa ref put

  • uput significa usuario puesto

  No entiendo por qué los autores eligieron “nodo”, “ref” y “usuario” como prefix ya que estos nombres no enfatizan algo que pueda usarse para identificar de forma única a cada uno de ellos.

• El núcleo de PSTricks de nuevo:

  (Entre otros) parametricplot tiene un alias psparametricplot, scalebox tiene un alias psscalebox. La razón subyacente es hacer un nombre coherente y evitar el conflicto de nombres.

  Sin embargo, ¿por qué siguen existiendo los siguientes?

  • newpsobject eso debería ser psnewobject
  • newpsstyle eso debería ser psnewstyle
  • addtopsstyle eso debería ser psaddtostyle

• pst-node paquete:

  curvepnode y curvepnodes se utilizan para crear un nodo y una lista de nodos, respectivamente, según la expresión paramétrica dada | o . Sin embargo, sus complementarios son fnpnode y fnpnodes basado en la expresión en o .

  En mi opinión, la denominación de ambos grupos debería basarse en la representación de la expresión. Por lo tanto curvepnode y curvepnodes debe ser nombrado como parametricpnode y parametricpnodes y fnpnode y fnpnodes debe ser nombrado como functionpnode y functionpnodes. los prefix curve no se puede utilizar para identificar unívocamente el primer grupo del segundo grupo porque ambos grupos están relacionados con curvas. Las curvas se pueden representar en cualquier forma paramétrica (x(t),y(t)) o función (x,f(x)).

• pst-node de nuevo:

  Cuando usas getnodelist, hay 2 macros disponibles internamente, [email protected] y [email protected]. ¿Notas las mayúsculas? pst versus PST? ¿Por qué?

PSTricks: comportamiento excepcional

Encontré algunas excepciones en PSTricks que pueden sobrecargar a los usuarios. Los patrones deben ser intuitivos para que los usuarios no recuerden cosas innecesarias de la siguiente manera. Creo que te sientes incómodo al recordar las siguientes notas, ya que están definidas de manera ilógica y desperdician tu memoria (en tu cerebro).

• curvas cerradas psframe, pscircle, psellipse, pswedge, psellipticwedge tener cambiable dimen=outer por defecto excepto por polygon y psccurve que tienen cambiable dimen=middle. Los lados radiales de pswedge y psellipticwedge tener inmutable dimen=middle.
• curvas abiertas psline, pscurve, psbezier, psarc tener inmutable dimen=middle excepto por psellipticarc que ha cambiado dimen=outer.

• todas las curvas cerradas mueven los puntos actuales a sus puntos de partida excepto para psellipse y pscircle que no mueven los puntos actuales.

• (0,0) ya que el primer punto puede ignorarse para psframe, pscircle, psellipse, pswedge, psellipticwedge, pspolygon, psline, psbezier y psellipticarc pero debe especificarse explícitamente para psccurve, pscurve y psarc.

• En pst-eucl las etiquetas se pueden habilitar y deshabilitar con PointName=default y PointName=none, respectivamente. Sin embargo, para pstInterCC (probablemente otras macros, así como no las he marcado todas) deben estar deshabilitadas con PointNameA= o PointNameB= en vez de PointNameA=none o PointNameB=none, respectivamente. Es un problema conocido, vea esta discusión pero se deja como está como una característica (tal vez).

• Para crear un nuevo sistema de coordenadas (especialmente para los no ortogonales), pst-eucl proporciona pstOIJGeonode dónde O, I y J son los puntos en los que se basa el nuevo sistema de coordenadas. Desafortunadamente, el primer punto de este sistema de coordenadas debe especificarse como el primer argumento en lugar del cuarto, que es más común intuitivamente. Aquí está la sintaxis anormal,

  pstOIJGeonodeOIJ...
  

  Debería ser

  pstOIJGeonodeOIJ...
  

El responsable de PSTricks (Herbert) responde incansablemente a preguntas aquí y en otros lugares. Está publicando libros sobre PSTricks. Si tuviera que elegir uno, este sería un fuerte argumento para PSTricks.

Al final de la web puedes encontrar las explicaciones de otros administradores, tú además puedes insertar el tuyo si dominas el tema.

---

---

Utiliza Nuestro Buscador