texlive[65553] Master/texmf-dist: pgf (15jan23)
commits+karl at tug.org
commits+karl at tug.org
Sun Jan 15 21:58:28 CET 2023
Revision: 65553
http://tug.org/svn/texlive?view=revision&revision=65553
Author: karl
Date: 2023-01-15 21:58:27 +0100 (Sun, 15 Jan 2023)
Log Message:
-----------
pgf (15jan23)
Modified Paths:
--------------
trunk/Master/texmf-dist/doc/generic/pgf/README.md
trunk/Master/texmf-dist/doc/generic/pgf/RELEASE_NOTES.md
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual.pdf
trunk/Master/texmf-dist/tex/generic/pgf/basiclayer/pgfcore.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/basiclayer/pgfcoreimage.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/basiclayer/pgfcorepatterns.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/basiclayer/pgfcorescopes.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/basiclayer/pgfcoretransformations.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/circuits/tikzlibrarycircuits.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/datavisualization/tikzlibrarydatavisualization.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/graphs/tikzlibrarygraphs.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/tikzexternalshared.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryangles.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryanimations.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarychains.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarydecorations.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryfit.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryfolding.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarymath.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarymatrix.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryperspective.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryquotes.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryshapes.multipart.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryspy.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryturtle.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/frontendlayer/tikz/tikz.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/graphdrawing/lua/pgf/gd/trees/ChildSpec.lua
trunk/Master/texmf-dist/tex/generic/pgf/graphdrawing/tex/tikzlibrarygraphdrawing.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/libraries/decorations/pgflibrarydecorations.shapes.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/libraries/pgflibrarylindenmayersystems.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/libraries/pgflibraryplotmarks.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/libraries/shapes/circuits/pgflibraryshapes.gates.logic.IEC.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/libraries/shapes/pgflibraryshapes.arrows.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/libraries/shapes/pgflibraryshapes.geometric.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/libraries/shapes/pgflibraryshapes.misc.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/libraries/shapes/pgflibraryshapes.symbols.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/math/pgfmath.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/math/pgfmathcalc.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/math/pgfmathfloat.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.random.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/math/pgfmathparser.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/modules/pgfmoduleanimations.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/modules/pgfmoduledatavisualization.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/modules/pgfmoduledecorations.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/modules/pgfmodulematrix.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/modules/pgfmoduleshapes.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/pgf.revision.tex
trunk/Master/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-common-pdf.def
trunk/Master/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-dvipdfmx.def
trunk/Master/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-dvisvgm4ht.def
trunk/Master/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-luatex.def
trunk/Master/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-pdftex.def
trunk/Master/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-textures.def
trunk/Master/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-vtex.def
trunk/Master/texmf-dist/tex/generic/pgf/systemlayer/pgfsys.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/systemlayer/pgfsysanimations.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/utilities/pgfcalendar.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/utilities/pgffor.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/utilities/pgfkeys.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/utilities/pgfrcs.code.tex
trunk/Master/texmf-dist/tex/generic/pgf/utilities/pgfutil-common-lists.tex
trunk/Master/texmf-dist/tex/generic/pgf/utilities/pgfutil-common.tex
trunk/Master/texmf-dist/tex/generic/pgf/utilities/pgfutil-latex.def
trunk/Master/texmf-dist/tex/latex/pgf/basiclayer/pgfcore.sty
trunk/Master/texmf-dist/tex/latex/pgf/doc/pgfmanual-en-macros.tex
trunk/Master/texmf-dist/tex/latex/pgf/doc/pgfmanual.pdflinks.code.tex
Added Paths:
-----------
trunk/Master/texmf-dist/doc/generic/pgf/CHANGELOG.md
trunk/Master/texmf-dist/doc/generic/pgf/CTAN_NOTES.md
trunk/Master/texmf-dist/doc/generic/pgf/brave-gnu-world-logo-mask.jpg
trunk/Master/texmf-dist/doc/generic/pgf/brave-gnu-world-logo.25.jpg
trunk/Master/texmf-dist/doc/generic/pgf/brave-gnu-world-logo.jpg
trunk/Master/texmf-dist/doc/generic/pgf/color.cfg
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-actions.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-animations.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-arrows.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-decorations.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-design.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-external.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-images.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-internalregisters.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-layers.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-matrices.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-nodes.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-paths.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-patterns.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-plots.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-points.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-quick.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-scopes.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-shadings.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-transformations.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-transparency.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-drivers.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-axes.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-backend.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-examples.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-formats.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-introduction.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-main.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-polar.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-stylesheets.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-visualizers.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-gd-algorithm-layer.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-gd-algorithms-in-c.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-gd-binding-layer.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-gd-circular.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-gd-display-layer.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-gd-edge-routing.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-gd-examples.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-gd-force.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-gd-layered.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-gd-misc.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-gd-ogdf.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-gd-overview.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-gd-phylogenetics.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-gd-trees.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-gd-usage-pgf.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-gd-usage-tikz.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-guidelines.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-installation.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-introduction.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-3d.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-angles.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-arrows.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-automata.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-babel.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-backgrounds.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-calc.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-calendar.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-chains.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-circuits.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-decorations.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-edges.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-er.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-external.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-fadings.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-fit.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-fixedpoint.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-folding.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-fpu.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-lsystems.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-math.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-matrices.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-mindmaps.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-patterns.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-perspective.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-petri.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-plot-handlers.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-plot-marks.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-profiler.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-rdf.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-shadings.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-shadows.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-shapes.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-spy.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-svg-path.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-through.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-trees.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-turtle.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-library-views.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-license.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-main-body.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-main-preamble.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-main.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-math-algorithms.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-math-commands.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-math-design.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-math-numberprinting.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-math-parsing.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-module-parser.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-oo.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-pages.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-pgfcalendar.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-pgffor.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-pgfkeys.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-pgfkeysfiltered.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-pgfsys-animations.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-pgfsys-commands.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-pgfsys-overview.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-pgfsys-paths.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-pgfsys-protocol.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-tikz-actions.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-tikz-animations.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-tikz-arrows.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-tikz-coordinates.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-tikz-decorations.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-tikz-design.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-tikz-graphs.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-tikz-matrices.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-tikz-paths.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-tikz-pics.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-tikz-plots.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-tikz-scopes.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-tikz-shapes.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-tikz-transformations.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-tikz-transparency.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-tikz-trees.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-tutorial-Euclid.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-tutorial-chains.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-tutorial-map.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-tutorial-nodes.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-tutorial.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-xxcolor.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-test.tex
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual.cfg
trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual.tex
trunk/Master/texmf-dist/tex/generic/pgf/utilities/pgfkeyslibraryfiltered.code.tex
Removed Paths:
-------------
trunk/Master/texmf-dist/doc/generic/pgf/ChangeLog
trunk/Master/texmf-dist/doc/generic/pgf/FILES
trunk/Master/texmf-dist/doc/generic/pgf/INSTALL
trunk/Master/texmf-dist/doc/generic/pgf/extract.lua
trunk/Master/texmf-dist/doc/generic/pgf/images/
trunk/Master/texmf-dist/doc/generic/pgf/licenses/
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-base-actions.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-base-animations.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-base-arrows.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-base-decorations.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-base-design.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-base-external.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-base-images.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-base-internalregisters.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-base-layers.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-base-matrices.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-base-nodes.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-base-paths.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-base-patterns.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-base-plots.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-base-points.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-base-quick.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-base-scopes.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-base-shadings.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-base-transformations.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-base-transparency.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-drivers.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-dv-axes.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-dv-backend.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-dv-examples.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-dv-formats.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-dv-introduction.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-dv-main.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-dv-polar.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-dv-stylesheets.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-dv-visualizers.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-gd-algorithm-layer.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-gd-algorithms-in-c.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-gd-binding-layer.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-gd-circular.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-gd-display-layer.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-gd-edge-routing.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-gd-examples.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-gd-force.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-gd-layered.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-gd-misc.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-gd-ogdf.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-gd-overview.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-gd-phylogenetics.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-gd-trees.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-gd-usage-pgf.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-gd-usage-tikz.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-guidelines.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-installation.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-introduction.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-3d.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-angles.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-arrows.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-automata.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-babel.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-backgrounds.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-calc.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-calendar.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-chains.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-circuits.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-decorations.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-edges.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-er.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-external.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-fadings.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-fit.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-fixedpoint.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-folding.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-fpu.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-lsystems.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-math.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-matrices.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-mindmaps.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-patterns.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-perspective.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-petri.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-plot-handlers.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-plot-marks.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-profiler.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-rdf.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-shadings.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-shadows.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-shapes.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-spy.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-svg-path.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-through.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-trees.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-turtle.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-library-views.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-license.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-main-body.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-main-preamble.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-main.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-math-algorithms.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-math-commands.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-math-design.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-math-numberprinting.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-math-parsing.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-module-parser.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-oo.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-pages.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-pgfcalendar.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-pgffor.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-pgfkeys.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-pgfkeysfiltered.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-pgfsys-animations.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-pgfsys-commands.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-pgfsys-overview.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-pgfsys-paths.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-pgfsys-protocol.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tikz-actions.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tikz-animations.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tikz-arrows.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tikz-coordinates.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tikz-decorations.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tikz-design.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tikz-graphs.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tikz-matrices.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tikz-paths.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tikz-pics.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tikz-plots.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tikz-scopes.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tikz-shapes.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tikz-transformations.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tikz-transparency.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tikz-trees.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tutorial-Euclid.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tutorial-chains.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tutorial-map.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tutorial-nodes.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-tutorial.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/pgfmanual-en-xxcolor.tex
trunk/Master/texmf-dist/doc/generic/pgf/text-en/plots/
trunk/Master/texmf-dist/doc/generic/pgf/version-for-dvipdfm/en/Makefile
trunk/Master/texmf-dist/doc/generic/pgf/version-for-dvipdfm/en/pgfmanual.tex
trunk/Master/texmf-dist/doc/generic/pgf/version-for-dvipdfm/en/plots/
trunk/Master/texmf-dist/doc/generic/pgf/version-for-dvipdfm/pgfmanual-dvipdfm.cfg
trunk/Master/texmf-dist/doc/generic/pgf/version-for-dvipdfmx/en/Makefile
trunk/Master/texmf-dist/doc/generic/pgf/version-for-dvipdfmx/en/pgfmanual-test.tex
trunk/Master/texmf-dist/doc/generic/pgf/version-for-dvipdfmx/en/pgfmanual.tex
trunk/Master/texmf-dist/doc/generic/pgf/version-for-dvipdfmx/en/plots/
trunk/Master/texmf-dist/doc/generic/pgf/version-for-dvipdfmx/pgfmanual-dvipdfmx.cfg
trunk/Master/texmf-dist/doc/generic/pgf/version-for-dvips/en/Makefile
trunk/Master/texmf-dist/doc/generic/pgf/version-for-dvips/en/pgfmanual-test.tex
trunk/Master/texmf-dist/doc/generic/pgf/version-for-dvips/en/pgfmanual.tex
trunk/Master/texmf-dist/doc/generic/pgf/version-for-dvips/en/plots/
trunk/Master/texmf-dist/doc/generic/pgf/version-for-dvips/pgfmanual-dvips.cfg
trunk/Master/texmf-dist/doc/generic/pgf/version-for-dvisvgm/en/Makefile
trunk/Master/texmf-dist/doc/generic/pgf/version-for-dvisvgm/en/color.cfg
trunk/Master/texmf-dist/doc/generic/pgf/version-for-dvisvgm/en/pgfmanual-test.html
trunk/Master/texmf-dist/doc/generic/pgf/version-for-dvisvgm/en/pgfmanual-test.tex
trunk/Master/texmf-dist/doc/generic/pgf/version-for-dvisvgm/en/pgfmanual.html
trunk/Master/texmf-dist/doc/generic/pgf/version-for-dvisvgm/en/pgfmanual.tex
trunk/Master/texmf-dist/doc/generic/pgf/version-for-dvisvgm/en/plots/
trunk/Master/texmf-dist/doc/generic/pgf/version-for-dvisvgm/pgfmanual-dvisvgm.cfg
trunk/Master/texmf-dist/doc/generic/pgf/version-for-luatex/en/Makefile
trunk/Master/texmf-dist/doc/generic/pgf/version-for-luatex/en/pgfmanual-test.tex
trunk/Master/texmf-dist/doc/generic/pgf/version-for-luatex/en/pgfmanual.tex
trunk/Master/texmf-dist/doc/generic/pgf/version-for-luatex/en/plots/
trunk/Master/texmf-dist/doc/generic/pgf/version-for-luatex/pgfmanual-luatex.cfg
trunk/Master/texmf-dist/doc/generic/pgf/version-for-pdftex/en/Makefile
trunk/Master/texmf-dist/doc/generic/pgf/version-for-pdftex/en/pgfmanual.tex
trunk/Master/texmf-dist/doc/generic/pgf/version-for-pdftex/en/plots/
trunk/Master/texmf-dist/doc/generic/pgf/version-for-pdftex/pgfmanual-pdftex.cfg
trunk/Master/texmf-dist/doc/generic/pgf/version-for-tex4ht/en/Makefile
trunk/Master/texmf-dist/doc/generic/pgf/version-for-tex4ht/en/pgfmanual.tex
trunk/Master/texmf-dist/doc/generic/pgf/version-for-tex4ht/en/plots/
trunk/Master/texmf-dist/doc/generic/pgf/version-for-tex4ht/pgfmanual-tex4ht.cfg
trunk/Master/texmf-dist/doc/generic/pgf/version-for-vtex/en/Makefile
trunk/Master/texmf-dist/doc/generic/pgf/version-for-vtex/en/pgfmanual.tex
trunk/Master/texmf-dist/doc/generic/pgf/version-for-vtex/en/plots/
trunk/Master/texmf-dist/doc/generic/pgf/version-for-vtex/pgfmanual-vtex.cfg
trunk/Master/texmf-dist/doc/generic/pgf/version-for-xetex/en/Makefile
trunk/Master/texmf-dist/doc/generic/pgf/version-for-xetex/en/pgfmanual.tex
trunk/Master/texmf-dist/doc/generic/pgf/version-for-xetex/en/plots/
trunk/Master/texmf-dist/doc/generic/pgf/version-for-xetex/pgfmanual-xetex.cfg
trunk/Master/texmf-dist/scripts/pgf/
trunk/Master/texmf-dist/source/generic/pgf/c/INSTALL
trunk/Master/texmf-dist/source/generic/pgf/c/Makefile
trunk/Master/texmf-dist/source/generic/pgf/c/config/
trunk/Master/texmf-dist/source/generic/pgf/c/graphdrawing/pgf/gd/examples/c/
trunk/Master/texmf-dist/source/generic/pgf/c/graphdrawing/pgf/gd/interface/c/
trunk/Master/texmf-dist/source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/InterfaceFromOGDF.c++
trunk/Master/texmf-dist/source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/InterfaceFromOGDF.h
trunk/Master/texmf-dist/source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/Makefile
trunk/Master/texmf-dist/source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/SimpleDemoOGDF.c++
trunk/Master/texmf-dist/source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/FMMMLayout_script.h
trunk/Master/texmf-dist/source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/FastMultipoleEmbedder_script.h
trunk/Master/texmf-dist/source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/GEMLayout_script.h
trunk/Master/texmf-dist/source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/MultilevelLayout_script.h
trunk/Master/texmf-dist/source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/SpringEmbedderFRExact_script.h
trunk/Master/texmf-dist/source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/SpringEmbedderFR_script.h
trunk/Master/texmf-dist/source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/SpringEmbedderKK_script.h
trunk/Master/texmf-dist/source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/energybased_script.h
trunk/Master/texmf-dist/source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/multilevelmixer/
trunk/Master/texmf-dist/source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/layered/
trunk/Master/texmf-dist/source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/misclayout/
trunk/Master/texmf-dist/source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/module/
trunk/Master/texmf-dist/source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/ogdf_script.c++
trunk/Master/texmf-dist/source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/planarity/
trunk/Master/texmf-dist/source/generic/pgf/testsuite/external/
trunk/Master/texmf-dist/source/generic/pgf/testsuite/mathtest/
trunk/Master/texmf-dist/tex/generic/pgf/utilities/pgfkeysfiltered.code.tex
Added: trunk/Master/texmf-dist/doc/generic/pgf/CHANGELOG.md
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/CHANGELOG.md (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/CHANGELOG.md 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,3329 @@
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
+
+## [3.1.10] - 2023-01-13 Henri Menke
+
+Even though this release is not too heavy on user-facing additions it has seen a
+lot of contributed changes. Thanks to everyone who volunteered their time!
+
+### BREAKING CHANGES
+
+- `\pgfversiondatetime` and `\pgfrevisiondatetime` have been removed.
+ `\pgfversiondate` and `\pgfrevisiondate` now use the format `YYYY-MM-DD`.
+ `\pgfrevision{,date}` and `\pgfversion{,date}` are synonyms for now, but the
+ revision should eventually gain back its original meaning. However, as of now
+ this is not supported by l3build.
+- Many operations in `pgfkeys` used to use `\csname` directly which lets the
+ given csname become `\relax` in case it wasn't defined. This resulted in some
+ leakage of accidentally `\relax`ed keys into the global scope. This has been
+ cleaned up a little. To preserve compatibility macros that used to expand to a
+ `\relax`ed csname now expand to a primitive `\relax`. This affects the
+ user-level commands `\pgfkeysgetvalue` and `\pgfkeysgetvalueof`. For the
+ former the change should not be visible except for the number of expansions
+ required. For `\pgfkeysgetvalueof`, however, the behavior is manifestly
+ different in that it will now expand to an alias for the primitive `\relax` in
+ case the value is undefined instead of a `\relax`ed csname. It has always been
+ semantically wrong to assign to the result of `\pgfkeysgetvalueof`, but now it
+ will have undesired side-effects. Therefore this change is breaking.
+- The `textures` and `vtex` drivers have been deprecated. Both engines are no
+ longer in active development and lack eTeX features which are required for
+ quite some time in PGF.
+- The file `pgfutil-common-lists.tex` is deprecated and therefore no longer
+ `\input` by `pgfutil-common.tex`. The macros from this file are specifically
+ meant for pgfplots and are not used in PGF at all.
+
+### Added
+
+- l3build support for packaging PGF/TikZ
+- Add Matrix chat to README
+- Add rhombic polihedra #1022
+- Add Developer Certificate of Origin (DCO) to Pull Request template and enforce
+- Add test set for `graphdrawing` (gd)
+- pgfkeys gained support for loading libraries
+- Add dependabot to keep GitHub Actions up to date
+
+### Fixed
+
+- Wrap logic gate symbol in `\pgfinterruptpicture` for shapes in library
+ `shapes.gates.logic.IEC`
+- Remove superfluous `;` for shape `arrow box`
+- Remove superfluous `/utils/exec` in animations
+- Gobble `\pgf at stop` when parsing finishes in animations
+- Add missing `\pgf at sys@tonumber` before `<dimen>` in drivers and animations
+- Rewrite `dash expand off`
+- Better unknown key error msg in decorations
+- Fix `\let` in drivers for two csnames #1088
+- Protect against comma in pgfkeys arguments #389
+- Let active `"` expand to non-active `"` in pgfmath #1062
+- Protect against comma in `/tikz/rotate fit` argument and make it
+ eagerly evaluated #1071
+- Set pics/code in angle #1068
+- Fix for externalization and horizontal mode
+- Avoid spurious tokens in `\pgfcalendarifdate` expansion
+- Remove angle restriction #1048
+- Fix compatibility of `external` lib with `fadings` lib
+- Only clearpage and flush `\pgfutil at everybye` if non-empty #724
+- Fix foreach documentation #1039
+- Fix pgfmathless documentation #1040
+- Blend mode as array is deprecated #1037
+- One-step expansion for `\pgfmathrandomitem` in pgfmath #1033
+- Check whether expanded is a primitive in all engines
+- Reinsert the last token when giving up on a path #1025
+- Make `/tikz/local bounding box` aware of `name prefix` and `name suffix`
+- Add empty Pattern dictionary to Resources dictionary
+- Spelling and typo fixes in the manual
+- Update Debian installation instructions
+- Suppress white space at line end when `datavisualization` reads from a file
+ #1112
+- Form-only patterns have no specified color #1122
+- Make `graphdrawing` work with `name prefix` and `name suffix` options #1087
+- pgfkeys was a bit too relaxed around `\relax` #1132
+- Remove spurious spaces for `3d view` #1151
+- Fix incorrectly placed matrix delimiters for implicitly positioned nodes #1102
+- Use `/.append` to fix a wrong usage of `/.add` in pgfmanual #1201
+
+### Changed
+
+- Cleanup `\newif`s
+- Remove unused scripts
+- Remove experiments/ folder
+- Simplify loading by delegating to top-level files
+- Promote `Missing character` to errors in building manual
+- Flatten the doc tree
+- Ensure `\tracinglostchars<3` in `\pgf at picture`
+- Use descriptive workflow job ids
+- Ensure `doc` v2 is loaded for pgfmanual
+- Ensure active `^^M` is non-expandable in `codeexample`
+
+### Contributors
+
+- 3geek14
+- BeneIII
+- graue70
+- Gábor Braun
+- Joel Coffman
+- Jonathan Spratte
+- Joseph Wright
+- Mario Frasca
+- Michael Kuron
+- Michal Hoftich
+- muzimuzhi
+- PhelypeOleinik
+- QJLc
+- Stefan Pinnow
+
+## [3.1.9a] - 2021-05-15 Henri Menke
+
+Emergency release to fix pgfplots which depends on unreleased parts of PGF.
+
+### Changed
+
+- Merge pull request #1012 from TorbjornT/incontrol_doc
+- Specify that relative coord is to end point
+- Merge pull request #1005 from kechtel/patch-1
+- Fix typo in guidelines on graphics
+- CI: Expire the cache
+- Merge pull request #1004 from michal-h21/patch-1
+- Update pgfsys-dvisvgm4ht.def
+- Merge pull request #1003 from tknuth/patch-1
+- fixed typo
+- Merge pull request #977 from muzimuzhi/pgf-point-node-border
+- adjust comments
+- \pgfpointshapeborder: measure by distance < 0.02pt
+- \pgfpointshapeborder: more doc words
+- doc: use paired \`\` and ''
+- \pgfpointshapeborder: doc new behavior
+- pgf/shapes: add warning when \pgfpointshapeborder gives up
+- pgf/shapes: improve \pgfpointshapeborder, #908
+- Merge pull request #1002 from muzimuzhi/edef-keys
+- pgfkeys: enhance edef keys, #305
+- fixup! build: copy the README into the TDS archive
+- build: copy the README into the TDS archive
+
+### Contributors
+
+- Christoph Kecht
+- Dr. Tobias Knuth
+- Michal Hoftich
+- muzimuzhi
+- Torbjørn T
+
+## [3.1.9] - 2021-03-02 Henri Menke
+
+### Fixed
+
+This release introduces a fix for blend mode with the dvips driver and
+improvements for handling expandable material that appears on a path.
+
+### Changed
+
+- Merge pull request #996 from muzimuzhi/dvips-blend-mode
+- dvips: fix displacement after blend group, #995
+- Revert "syntax is similar to METAPOST not METAFONT"
+- Merge pull request #994 from itmm/master
+- syntax is similar to METAPOST not METAFONT
+- Merge pull request #992 from joel-coffman/dev/fix-code-2-args-documentation
+- Correct documentation for .code 2 args second arg
+- Merge pull request #987 from muzimuzhi/doc-typo
+- doc: fix typo #986
+- Merge pull request #981 from muzimuzhi/fix-tikz at handle
+- Apply suggestions from code review
+- tikz: fix uses of \pgfutil at switch
+- Merge pull request #979 from muzimuzhi/doc-install-only
+- doc/fpu: fpu: mark /pgf/fpu/install only as not experimental
+- Fix and document dim() #964
+- Merge pull request #976 from muzimuzhi/tikz-math
+- tikz/math: gobble spaces between for list and loop body
+- Merge pull request #970 from muzimuzhi/reset-tikz at expandcount
+- tikz: retry to handle \relax on path #966
+- tikz/calendar: switch over \pgf at let@token in \tikz at lib@cal at handle
+- Merge pull request #973 from schtandard/spurious_show
+- Remove a spurious \show
+- Merge pull request #972 from alisaaalehi/patch-1
+- doc: fix typo
+- tikz: switch over \pgf at let@token in \tikz at handle
+- tikz: improve \tikz at expandcount handling
+- tikz: reset \tikz at expandcount more frequent #969
+
+### Contributors
+
+- Ali Salehi
+- Joel Coffman
+- muzimuzhi
+- schtandard
+- Timm Knape
+
+## [3.1.8b] - 2020-12-27 Henri Menke
+
+Hotfix for handling of TeX conditionals on a path. We can't forward \relax and
+frozen \relax through the parser because there is existing code that relies on
+this.
+
+The recommendation is to use expandable conditionals where possible.
+
+## [3.1.8a] - 2020-12-27 Henri Menke
+
+Hotfix for the new topaths handling. One instance did not yet properly
+preserve relative coordinates.
+
+## [3.1.8] - 2020-12-25 Henri Menke
+
+### BREAKING CHANGES
+
+If a topath is bent by any of the in=, out=, bend=, etc. options, a Bezier
+curve is constructed in the background. To infer the positions of the control
+points the start and end coordinate are converted to absolute coordinates.
+However, this has the effect that subsequent points on the path think that the
+endpoint of the topath was absolute which can lead to counter-intuitive path
+construction, e.g.
+```latex
+\draw (2,0) to[out=0,in=180] +(1,0) -- ++(0,-1) -- +(1,0);
+```
+If old code relies on this behavior, this drawing will silently break! Please
+open an issue if you rely on this.
+
+### Fixed
+
+This release introduces a fix for path handling which concerns expansion of
+tokens on the path in particular with respect to conditional. Previously when
+the expansion of a conditonal resulted in a frozen \relax the parser would just
+give up. Now the parser will skip over the frozen \relax and continue to
+expand tokens. Whether this will result in a meaningful expansion is up to the
+user.
+
+This release also includes other bug fixes. On GitHub you can click the commit
+hashes and the issue numbers to get to the fix and the ticket, respectively.
+
+- a4c275704 #952
+- 8a997bbc1 #954
+- 8f37bca84 #962
+- 3cbe5a192 #844
+- 49e5f0a08 #654
+- 17a95e4c5 #966
+- ad06895a6 #966
+- 79e613ae1 #966
+
+### Changed
+
+- CI: Use GitHub Actions from pgf-tikz/actions
+- Remove empty or outdated files
+- Preserve coordinate relativity across ..
+- Merge pull request #967 from muzimuzhi/handle-relax
+- fixup! doc: Add note on expandsion of path operations #966
+- Remove spurious spaces, terminate \advance in time
+- tikz: handle \relax and frozen \relax on path #966
+- doc: Add note on expandsion of path operations #966
+- Merge pull request #961 from muzimuzhi/improve-doc
+- doc: relation of /.code & /.initial will remain
+- Only force signed releases #962
+- doc: clarify /.code keys don't respect /.initial #654
+- Added doc for \pgfpointtransformed #844
+- Merge pull request #959 from muzimuzhi/improve-doc
+- doc: clarify path or full key start with slash #904
+- Merge pull request #956 from muzimuzhi/improve-doc
+- pgfmathdeclarerandomlist: improve doc and code comment
+- Merge pull request #955 from Ordoviz/master
+- pgfmathrandominteger: reordering of arguments incomplete #954
+- fpu: mark /pgf/fpu/install only as not experimental
+- Fix typos in manual
+- Merge branch 'PimpLuaExamples' of https://github.com/Mo-Gul/pgf
+- docs: set terminal table -> set table #952
+- correct codeexample preamble entries in Lua file
+- made some "normal" `codeexample`s compile again (when extracted)
+- just added end line commata at the end of values/styles
+- added hints which libraries need to be loaded as well to make the example in
+ `pgfmanual-en-tikz-graphs.tex` work closes issue #755)
+
+### Contributors
+
+- Lennard Hofmann
+- muzimuzhi
+- Stefan Pinnow
+
+## [3.1.7a] - 2020-12-01 Henri Menke
+
+### Fixed
+
+Another issue with the new LaTeX hook mechanism surfaced in the external
+library which is being worked around now.
+
+This release also includes other bug fixes. On GitHub you can click the commit
+hashes and the issue numbers to get to the fix and the ticket, respectively.
+
+- 3c46a6974 #947
+
+### Changed
+
+- Assisted release script
+- Attempt uploading to CTAN in CI
+- Attempt signing builds in CI
+- Protect possible parentheses in computing looseness #947
+- Superficial fix for hook ordering problem
+- Add pgf-parametric-example-cut.table
+
+## [3.1.7] - 2020-11-21 Henri Menke
+
+### Fixed
+
+Mostly spurious spaces have been fixed and some code has been adapted to work
+with the latest LaTeX release. In principle it should still be backwards
+compatible to older LaTeX releases but regressions cannot be excluded.
+
+Some other bug fixes:
+
+- 67295ec8 #946
+- 74b2cc30 #934
+- 8beaf970 #928
+- bf46600f #654
+- 1e8ee728 #930
+
+### Changed
+
+- CI: Create release from tag
+- pgffor: new expand list option
+- Fix spurious spaces #946
+- Merge pull request #943 from agrahn/offpagefading
+- hiding smask in the PS viewer
+- Merge pull request #940 from Ordoviz/patch-1
+- Merge pull request #941 from Skillmon/improve-parser-doc
+- macros are 'letters' for pgfparser as well
+- fix comment in example code
+- minor change to pgfparserletter
+- minor change to pgfparserdefunknown
+- minor change to pgfparserlet
+- more info for pgfparserdef
+- typos
+- more precise pgfparserreinsert description
+- [doc] Fix typo
+- Fix trailing else problem in pgfkeys
+- Merge branch 'pgfkeys-small-fixing' of https://github.com/muzimuzhi/pgf
+- Always place shadings in TLT in LuaTeX #934
+- DOC: typo fix in en-tikz-actions
+- pgfkeys: fix spurious spaces in "/errors" keys
+- pgfkeys: in "/.add code", ensure `/. at cmd` is long
+- Random shifts to fix output routine shenenigans #928
+- Revert "pgfkeys: make `.initial` compatible with `.code`, fix #654"
+- doc: various minor fix
+- doc: minor fix, #930
+
+### Contributors
+
+- Alexander Grahn
+- Andras Deak
+- Henri Menke
+- Jonathan Spratte
+- Lennard Hofmann
+- muzimuzhi
+
+## [3.1.6a] - 2020-10-01 Henri Menke
+
+Hotfix for `intersections` library. In the last version
+`\pgfintersectionoflines` was set to always return the intersection in the
+untransformed coordinate system #889. This however broke the interplay with
+other coordinate transformations and had to be reverted.
+
+### Changed
+
+- Revert "Invert transform before assigning intersection #889"
+- Omit missing library and fix spurious space
+- Fix spurious spaces in pgfmathparse with fpu #508 #915
+- Revert "Added sanity check for the catcode of '$' to avoid incompatibilities with onlyamsmath package"
+
+## [3.1.6] - 2020-09-28 Henri Menke
+
+### Acknowledgements
+
+This release stands in the name of the two contributors **Alexander Grahn** and
+**Yukai Chou** without whom this release would not have been nearly as great.
+Thank you very much!
+
+### BREAKING CHANGES
+
+- In the last version, in an attempt to fix updating `local bounding box` in a
+ clipping scope the `\pgf at path@size at hook` in `\pgf at protocolsizes` was set to be
+ executed unconditionally. Unfortunately, this broke all other uses of `local
+ bounding box` and has been reverted. If you need to use `local bounding box`
+ in a clipping scope, use the `overlay` option.
+
+- The recent Ghostscript version 9.53 has changed the primitives for
+ transparency, blend mode, and transparency groups. These are now supported by
+ PGF and should in principle go unnoticed by the user. (Thanks Alexander
+ Grahn!)
+
+- `\pgfintersectionoflines` will now always return the intersection in the
+ untransformed coordinate system. This however requires an additional
+ `\pgftransforminvert` which comes with a loss of precision and can potentially
+ lead to `Dimension too large` errors in edge cases.
+
+- PGF now supports the new hook management that will be introduced in LaTeX
+ 2020/10/01. While this should not lead to any noticeable changes, please look
+ out for breakages with overlays and the `current page` nodes. Please report
+ problems on the PGF or LaTeX issue trackers.
+
+### Added
+
+You can read about these new features in the manual:
+
+- PS-3 functional shading, opacity masks (fadings) and image masks for
+ dvips. (Thanks Alexander Grahn!)
+
+- The `dvisvgm4ht` driver developed by Michal Hoftich has been merged into
+ PGF/TikZ.
+
+- The `pgfparser` module has been slightly refactored such that it can be used
+ without loading all of PGF.
+
+- The order in which the inner styles are applied in a `\matrix` is now
+ configurable. #867
+
+- The file `pgfmanual-en-macros.tex` is developed specifically for typesetting
+ the PGF manual, however, many other package developers have found it useful
+ and made good use of it. To this end, we now install
+ `pgfmanual-en-macros.tex` into a directory that is searched by kpathsea such
+ that developers no longer have to copy the file into their own distribution.
+
+- The CI system was switched from Travis CI to GitHub Actions for better
+ integration with GitHub and direct deployment of build artefacts to the status
+ page.
+
+### Removed
+
+- The `bbox` library introduced in PGF 3.1.5 was removed. I further recommend
+ that if there are files containing `bbox` code left over from a previous
+ version that these are removed to avoid potential issues.
+
+### Fixed
+
+Lots of bug fixes. On GitHub you can click the commit hashes and the issue
+numbers to get to the fix and the ticket, respectively.
+
+- 44bb29fd #900 #923
+- 2ae12cb4 #924
+- f6039046 #918
+- 908db001 #889
+- 71becc18 #909
+- 83069dce #508 #915
+- c5a6dbbb #671
+- 0f52b63c #654
+- 17e588d5 #912
+- 197450c0 #755
+- eaf9c096 #888
+- d96c3f2f #843
+- 6a0e08db #640 #839
+- bd8c9c45 #876
+- 4773c311 #748
+- 2145bcfb #872
+- c44960e7 #872
+- 1ca59c70 #871
+- 65bcaaff #867
+- 68bebd7a #823
+- 1c380999 #808
+- 494bd677 #861
+- 1e520dc7 #863
+- 1efebdf7 #856
+- e1eac8af #859
+- ca1f30e1 #795
+- 6b79a6dc #855
+- a7cccca0 #848
+- 7098976d #855
+- 8095bc57 #846
+- 08041e44 #855
+- 730a3437 #853
+- ff3fe4c4 #852
+- 6e8397b5 #851
+- 6c88ed94 #851
+- e6e91c40 #848
+- 29de799f #845
+- 2a6eaefb #840
+- 357bc059 #837
+- 15c943b7 #831
+- 314a00ad #829
+- 03aa54d2 #816
+- 4e1529ba #822
+- 4ccfe0d4 #813
+- 1f21e3ba #819 #698
+
+### Changed
+
+- Activate CTAN zip action
+- Adapt shipout to new hook management #900 #923
+- improved functional shading (dvips); \pgfsys at definemask fixed
+- More missing args to \pgfmath at error
+- Add missing args to \pgfmath at error
+- Replace \pgfmath at PackageError by \pgfmath at error
+- Use \pgfmath at tonumber in pgfmath (fixes #924)
+- Merge branch 'master' of https://github.com/erihe251/pgf
+- fixed typo notes -> nodes
+- Merge branch 'pgfkeys-doc' of https://github.com/muzimuzhi/pgf into master
+- Remove unused `.expand two once` #918
+- [doc] pgfkeys: update examples of ".search also"
+- [doc] pgfkeys: document \pgfkeyssetevalue
+- [doc] pgfkeys: unify order of ".code" and ".style"
+- [doc] pgfkeys: typo
+- Invert transform before assigning intersection #889
+- pgfsys-xetex: sync with upstream, #909
+- Provide a convenient workaround for #508 (also #915)
+- pgfkeys: avoid \pgfkeysalso used in ".search also"
+- Fix CI badge; add PR template
+- Merge branch 'ps3shading-fading-imgmask-dvips-3' of https://github.com/agrahn/pgf
+- Merge branch 'fix-pgfkeys' of https://github.com/muzimuzhi/pgf
+- pgfkeys: make `.initial` compatible with `.code`, fix #654
+- pgfkeys: specially treat `.style n args={1}{...}`, fix #912
+- fixing code lines with assignments, as requested in the review
+- Merging upstream changes into ps3shading-fading-imgmask-dvips-3
+- Switch to GitHub Actions
+- optimizing sampling procedure (funct shadings, dvips)
+- merging recent upstream changes
+- addressing requested changes from review
+- doc: correct some typos
+- [doc] pgffor: replace \diameter with \r
+- [doc] fix typo, s/to/two/ in "between to point"
+- PS-3 functional shading for dvips
+- PS-3 shadings, opacity masks (fadings) and image masks for dvips
+- doc: remove reference to old "-to" arrow
+- Merge branch 'context-module-wrap' of https://github.com/LeonardKoenig/pgf
+- Update build instructions [ci skip]
+- context: Fix 'module wrapping error'
+- Merge branch 'minor-change' of https://github.com/muzimuzhi/pgf
+- Fix critical typo in documentation
+- [doc] enhanced consistency
+- [doc] fix wrong description for \pgfmathsubtract
+- fix typo in comment
+- Add library loading hints #755
+- Fixed typo: of -> off
+- Fixed typo, if -> of
+- gs-9.53 transparency; blend mode; transparency groups
+- Install pgfmanual-en-macros.tex
+- Revert "- removed some trailing spaces and replaced TABs with spaces"
+- Merge branch 'doc-fix-pdf-dest' of https://github.com/muzimuzhi/pgf
+- Fix pt/bp confusion in dvipdfmx driver #888
+- [doc] rename counter, "dummy" -> "pgfmanualentry"
+- [script] use value of "maxruns" in not-converge message
+- [doc] move two key labels inside "key" env
+- [doc] fix typo
+- [doc] fix wrong pdf dest
+- [doc] external lib
+- transform shape clashes with label position #843
+- Add options to Lua examples #640 #839
+- Resolve clash of object ids in SVG #876
+- Decorations are implicitly sloped #748
+- DOC:matrix:Use only default colorsin example
+- DOC:matrix: Adjust the column color in example
+- Fix merge conflicts
+- Remove bbox library
+- followed @joulev's suggestion
+- Update doc/generic/pgf/text-en/pgfmanual-en-library-fpu.tex
+- Update doc/generic/pgf/text-en/pgfmanual-en-library-decorations.tex
+- added `codeexample` plus some text to the `decorations` library manual as
+ suggested in pull request #872
+- removed braces as suggested in pull request #872
+- "improved" colors given in the `codeexample` of pull request #871
+- added reference from `matrix` library to "basic" matrix section
+- adapted formatting in `pgf/text-en/pgfmanual-en-tikz-matrices.tex`
+- changed order of mentioned libraries so they fit the order of references in
+ the next sentence in `pgf/text-en/pgfmanual-en-tikz-shapes.tex`
+- Little improvements for matrix/inner style
+- Convert quotes to TeX quotes
+- DOC:matrix: Add example for every row/col keys
+- Configurable matrix inner styles #867
+- Add key visualize as smooth cycle #823
+- /.style -> /.code #808
+- Documentation for /pgf/fpu/install only
+- New key `/pgf/fpu/install only` #861
+- Merge branch 'new-unit-px' of https://github.com/muzimuzhi/pgf
+- Remove \pgfkeys at ifcsname #863
+- pgfmathparser.code.tex: add pdfTeX/LuaTeX unit px
+- use fpu reciprocal is still under consideration
+- fixing typo in pgfmanual-en-tutorial-Euclid.tex
+- Update bbox library #856
+- Shift before rotate #859
+- Fix undefined control sequence in \pgfutil at pushedmacro
+- Revert "Execute size hook unconditionally #795"
+- Another improvement for #855
+- corrected typo in patch of issue #848
+- Improved fix for #855
+- If prefixed name does not exist, look up global name #846
+- Fix broken \foreach initializer #855
+- Check if set is defined #853
+- Forbid some more operations in patterns #852
+- Trim surrounding whitespace from pattern name #851
+- Use comma hack for pattern keys as well #851
+- Merge branch 'master' of https://github.com/Mo-Gul/pgf
+- incorporated tallmarmots suggestion of issue #848
+- Fix \pgfmathfloattoextentedprecision #845
+- (again) found double-space instances
+- minor issue additionally stated in issue #840
+- Fix chiral anomaly #837
+- dvisvgm4ht: ProvidesFileRCS and copyright
+- Merge remote-tracking branch 'dvisvgm4ht/master'
+- multiple is noun; multiply is verb
+- New pgfparser utility package
+- Fix typo in fadings driver for Lua/pdfTeX
+- Don't swallow the delimiter #831
+- Include dependencies in Makefile #829
+- pgfmathparser.code.tex: add pdfTeX/LuaTeX/pTeX units
+- Update manual issue template
+- Address the CTAN issues #816
+- Cherry-pick the useable stuff from #822
+- Issue template: Reminder to use latest manual
+- `arrows` library replaced by `arrows.meta`
+- Math parse looseness on to paths #813
+- Update README and fix .travis.yml
+- Error checking for postaction, correct xetex postaction
+- Mistake in code example
+- removed some more remaining instances of the `arrows` library (#819, #698)
+- Pass emptry group as a \Picture argument
+- Handle nesting
+- Added comments
+- Support display math inside picture
+- check for the vmode
+- Make the tex4ht patches active only at \begin{document}
+- test for existence of tex4ht commands
+- code cleanup
+- Removed \Rcs command
+- Initial commit
+
+### Contributors
+
+- Alexander Grahn
+- Arkonos
+- Erik
+- Hironobu Yamashita
+- Ilhan Polat
+- Kamil Ziemian
+- Leonard König
+- letzfets
+- Michal Hoftich
+- muzimuzhi
+- PhelypeOleinik
+- Stefan Pinnow
+- tallmarmot
+- thinbold
+
+## [3.1.5b] - 2020-01-08 Henri Menke
+
+Hotfix for the `external` library.
+
+The fix for #759 broke existing uses and has been reverted.
+
+## [3.1.5a] - 2019-12-21 Henri Menke
+
+Hotfix for `tikz-3dplot` compatibility
+
+The release includes a bugfix for #809
+
+## [3.1.5] - 2019-12-19 Henri Menke
+
+### BREAKING CHANGES
+
+- The computation of path times in the `intersection` library was wrong when
+ sorting intersections and did therefore not work correctly (#480). This is
+ fixed now, but that also means that the order of intersections might change if
+ you were using sorting before. You can easily check this by looking for
+ `\pgfintersectionsortbyfirstpath` and `\pgfintersectionsortbyfirstpath` or the
+ `sort by` key if you are using intersections in Ti*k*Z.
+
+- It turned out that in `\pgf at protocolsizes` the `\pgf at path@size at hook` was
+ executed only if the picture was actually to be placed. This led to the
+ problem that the `local bounding box` was not updated correctly (#795). To
+ correct this, the hook is now executed unconditionally.
+
+- To get name prefixes for `pic` working (#311) the resolution of node names in
+ `\tikz at calc@anchor` now has two stages. First it tries to look up the
+ prefixed name and uses it if it exists. If there is no prefixed name, the
+ global name without prefix will be looked up and used (fixes #717).
+ Previously, if the prefixed name did not exist and error was issued
+ immediately without attempting to look up the global name.
+
+- There was a bug in old PGF versions that the body of `\pgfkeysedef` was not
+ fully expanded #305. This was fixed in PGF 3.1 (ac33f7e5) by the use of
+ `\scantokens`. Unfortunately when expanding the body the catcodes at the
+ point of use are taken instead of the catcodes at the point of definition.
+ This led to new bugs like #669. With the new version we are taking a middle
+ ground. We support macro definitions within edef bodies by doubling all the
+ hashes followed by numbers. All other hashes have to be escaped manually. We
+ assume that this is not a common use case.
+
+### Added
+
+You can read about these new features in the manual:
+
+- The `patterns.meta` library now provides a couple of predefined patterns which
+ can be used as replacements for the ones provided by the `patterns` library.
+
+- Tight bounding boxes for Bezier curves using the `bbox` library. This feature
+ was contributed by @tallmarmot. Thanks!
+
+- New pgfkeys handler `.evaluated`
+
+- The RGB color model is now supported in Plain TeX, i.e. values can be integers
+ 0-255 instead of floats 0-1 for rgb.
+
+- Annotations for code examples in the manual as to which libraries are
+ required. These were contributed by Stefan Pinnow (@Mo-Gul). Thanks!
+
+- GitHub issue templates for more streamlined bug reporting.
+
+- New build system based on Lua. We'd like to have a more cross-platform build
+ system. The old system was based on Makefiles, which will be retained for a
+ while but gradually phased out. In the future we hope to be able to implement
+ a regression test suite.
+
+# Removed
+
+- In the last release the undocumented commands `\rawx`, `\rawy`, `\rawz`, and
+ `\coord` were added to the `\path let` operation. These proved to be not as
+ useful as anticipated (#731) and were therefore removed again.
+
+# Bug fixes
+
+Lots of bug fixes. On GitHub you can click the commit hashes and the issue
+numbers to get to the fix and the ticket, respectively.
+
+- 0b095288 #793
+- ba8628c8 #804
+- c6ef774c #305 #669
+- 135e361e #759
+- be8dfa7e #769
+- 26cea424 #805 #806
+- f63131b4 #801
+- 4204b35b #803
+- 167a78eb #798
+- 8445f362 #796
+- 03b89120 #795
+- acd2ca38 #480
+- d2caaf3a #387
+- a5989c1e #442
+- 9d4e1020 #428
+- 96f41c41 #730
+- b2bbefda #775 #776
+- d9e677f5 #400
+- 94be30ee #788
+- a632c4d0 #790
+- 41a85559 #789
+- 319cae01 #512
+- 969b1f8d #726
+- 888f902c #785
+- 226808c3 #784
+- 13dab67d #736
+- 92faccff #643 #773 #774
+- 3c909b77 #770
+- 6ccafffa #519 #751
+- 3cf72768 #627
+- 37c39d0e #602
+- a547358e #727
+- 97a18d33 #767
+- 2e11f549 #728
+- f7a24c56 #719
+- 88951be5 #311 #717
+- 08275e30 #747
+- fddaaad7 #753
+- a93c47eb #762
+- 88954e20 #768
+- 1302de8a #756
+- b2656567 #743
+- 47f87253 #742
+- 5e2f4a88 #284
+- aee5465f #735
+- 4aaa25e6 #736
+- 76a69d29 #640 #711 #729
+- 2d5fb0c3 #720
+- bb5614ea #718
+- 5c746e52 #715
+- ff369f8a #721
+- 7ee3a2ca #361
+
+### Changed
+
+- [CI] bigintcalc, etexcmds, gettitlestring, hycolor, intcalc, kvdefinekeys,
+ kvsetkeys, ltxcmds, refcount, uniquecounter
+- Reseed the RNG before every use
+- Remove redundant definition of `center` anchor
+- Rewrite explanation for `\anchorborder`
+- Document loading order for translator #804
+- Hash doubling in pgfkeys edef only for numbers #305 #669
+- Add conditional for externalize to manual
+- Check \ifmeasuring@ #759
+- Add comment about 8 character filename limit in old ConTeXt #769
+- [CI] atbegshi, atveryend, bitset, pdfescape, rerunfilecheck
+- Typos in the manual #805 #806
+- New build system
+- [CI] letltxmacro
+- Document that matrix on path need ampersand replacement #801
+- More nitpicking #803
+- Minor typo fixes and word change suggestions.
+- Missing letter in functional tokens #798
+- [CI] stringenc
+- Remove cleanuplink and friends #796
+- [CI] kvoptions
+- Execute size hook unconditionally #795
+- corrected some spellings - harmonized e.g. "$x$ direction" --> "$x$-direction"
+ with the rest of the manual
+- adjusted "mystars" example so it fits to the "blue code box"
+- renamed `lines` to `mylines` in last `codeexample` to match the previous
+ `mystars` example
+- Fix sorting of intersections #480
+- Update TeX Live CI
+- Document shorten < and > #387
+- pgfinterruptpath is not a scope #442
+- \pgfkeys at temp is not safe to transport over other macros #428
+- Draw to target instead of computed anchor #730
+- Implement and document new patterns #775 #776
+- \pgfmath at ensureregister produced missing characters #400
+- Wrong numerical constant in ln #788
+- AtBeginDocument for ConTeXt #790
+- Some packages got moved out of oberdiek
+- Protect parens and order of operations in turtle #789
+- Missing name prefix in "<dir> of=" positioning #512
+- Fix style key for datavisualization #726
+- New pgfkeys handler .evaluated
+- Forward scanned coordinate untouched #785
+- Nitpick #784
+- Fix spacing for keys in decorations manual
+- Correct typo in tutorial
+- Revert "Add \rawx, \rawy, \rawz to let operation"
+- Revert "Check for \pgfpointxyz before \rawx, \rawy, \rawz"
+- Revert "Making the declared coordinate accessible"
+- Improvements for markup in the manual
+- Support for RGB for Plain TeX (docs)
+- GitHub: Add mailing list link
+- GitHub: Issue templates
+- Add bbox library to manual (oops)
+- corrected spelling of `\todosp`
+- added some `\todosp` comments to `... Barb` arrows where no space between the
+ two words is shown in the manual (v3.1.4b)
+- replaced all instances of `arrows.spaced` with `arrows.meta`
+- replaced most of the instances of `arrows` with `arrows.meta`
+- fixed some more wrongly spelled library names (related to issue #736)
+- marked more libraries in horizontal bars, i.e. `|...|`
+- Change order of options in label and pin #643 #773 #774
+- Support for RGB for Plain TeX
+- Reset transformation in grow cyclic #770
+- First version of the bbox library
+- Correct example for every pic #519 #751
+- Support styling of outer \pgfmatrix node #627
+- Add some predefined patterns to patterns.meta
+- Improve the 'lines' example for patterns.meta #602
+- pgfmathfloat at parser@install in pgfmathfloatparse #727
+- Reverse anchor of spy node #767
+- Cannot use commas in pgfkeys #728
+- Add generated gnuplot files #719
+- Fix `name prefix` for pics
+- Add quotes to error message #747
+- Cheap trick to avoid leading space problem #753
+- Fix pgfkeys pretty printer for single key-value pair #762
+- Merge branch 'master' of https://github.com/lockywolf/pgf
+- Update doc/generic/pgf/text-en/pgfmanual-en-tutorial.tex
+- Install iftex in CI
+- /tikz/radius dropped units #768
+- Update pgfmanual-en-tutorial.tex
+- Fix of a typo
+- Support pattern objects with dvipdfmx
+- Race condition in circle radius #756
+- Merge pull request #757 from Lipen/patch-1
+- Fix typo 'arrow.meta' -> 'arrows.meta'
+- Reset some text parameters inside a node #743
+- principle -> principal
+- Fix misspelled library names
+- Definition should be deferred to \pgfutil at guessdriver
+- ConTeXt MKIV needs the LuaTeX driver #742
+- Merge remote-tracking branch 'Mo-Gul/master'
+- Reset \tikz at intersect@namedpaths at scope boundaries, fixes #284
+- Make \node foreach work if loop variable is used for positioning, fixes #735
+- Correct some typos, fixes #736
+- checked `patterns.meta` library stuff and fixed some minor issues
+- corrected a word in `pgfmanual-en-dv-axes.tex`
+- harmonized spelling of `i.e.` and `e.g.`
+- corrected line breaking in `pgfmanual-en-math-numberprinting.tex` where a
+ |...| was split across lines
+- Merge pull request #733 from hmenke/PimpCodeexamples
+- New .gitignore needs some special treatment
+- handled one more `codeexample` that was added after branching. (related issues #640, #711, #729)
+- moved `colorlet` to the `codeexample` itself instead of to `pre` in `pgfmanual-en-base-quick.tex`
+- included issue #720 ("sub-library" should load "main library" by default)
+- therefore added loading `graphs` library in `graphs.standard` library
+- adjusted `preamble` code in `codeexample`s accordingly
+- there exist `graphdrawing` `codeexample`s in the manual that don't need the
+ `graphs` library --> adjusted `codeexample`s accordingly
+- fixed issue #718 ([manual] \usepgflibrary vs. \usetikzlibrary)
+- missed to commit/push the Lua documentation stuff
+- had a look at the `codeexample`s where a leading space was introduced (see
+ https://github.com/pgf-tikz/pgf/pull/711#issuecomment-514506025). Some of them
+ could be removed but others are introduced because of code added to the `pre`
+ key where I don't have a clue if/how this can be avoided
+- continued(/finished) moving `setup code,hidden` to `preamble` of the `codeexample`s
+- minor stuff
+- corrected wrongly commented Lua comments in the Lua documentation files (of
+ commit 900d47729d91dd9ba3eb59de56d5d9a4ba2eb155
+- moved `setup code` before `pre` in `extract.lua`
+- started moving `setup code,hidden` to `preamble` of the `codeexample`s
+- also need to Lua comment LaTeX comment in the Lua documentation files
+- commented some more `\begin{codeexample}[setup code,hidden]` (as @hmenke
+ suggested in https://github.com/pgf-tikz/pgf/pull/711#discussion_r304140166)
+- implemented suggestions given in https://github.com/pgf-tikz/pgf/pull/711
+- removed commented/unnecessary stuff from `extract.lua`
+- minor stuff
+- accounted for some more `codeexample`s in
+ `tex/generic/graphdrawing/lua/pgf/gd`
+- adapted `extract.lua` after Henri changed it in Master to also account for the
+ manual files at `/tex/generic/pgf/graphdrawing/lua/pgf/`
+- accounted for some more `codeexample`s in `doc/generic/pgf/text-en/`
+- removed an unnecessary empty line
+- % TODOsp: ... --> % TODOsp: codeexamples: ... (so they can be found more easily)
+- continued adding code to make extracted `codeexample`s work
+- changed order of `setup code` and `preamble` in `extract.lua`
+- continued adding code to make extracted `codeexample`s work
+- continued adding code to make extracted `codeexample`s work
+- continued adding code to make extracted `codeexample`s work
+- finished switching from `libraries/tikz={...}` to
+ `preamble={\usetikzlibrary{...}}`
+- continued with following files in the manual
+- adapted `extract.lua`
+- incorporated fixes from main PGF repository (provided by Henri)
+- changed `\documentclass` from `article` to `standalone`
+- reordered some stuff
+- started switching from `libraries/tikz={...}` to
+ `preamble={\usetikzlibrary{...}}`
+- added `pre` stuff to codeexamples of the tutorial doc files so fewer files
+ fail TeXing using the build bash script.
+- finished adding libraries to codeexamples of the tutorial doc files (so far
+ not all needed styles and definitions were added using `pre` key)
+- commented line that adds all libraries to the extracted codeexamples in
+ `extract.lua`
+- started adding libraries to the codeexamples
+- fixes #715
+- .cvsignore -> .gitignore #721
+- Fix a leaking space.
+- Fix text color in nodes #361
+- Halt on error
+- On behalf of @marmot : Improving the calculation of bounding boxes for Bezier curves
+
+### Contributors
+
+- Benjamin Desef
+- doraTeX
+- fmitha
+- Jonathan Spratte
+- JouleV
+- Konstantin Chukharev
+- Lockywolf
+- Matteo Gamboz
+- Mo-Gul
+- quark67
+- samcarter
+- Sašo Živanović
+- Stefan Pinnow
+
+## [3.1.4b] - 2019-08-03 Henri Menke
+
+This is a bugfix release for the dvips driver. A regression was introduced in
+the dvips driver in the last release that led to displaced objects #722. This
+update fixes the regression but also reverts the fix for position tracking #690.
+
+## [3.1.4a] - 2019-07-16 Henri Menke
+
+This is a bugfix release to make the XeTeX driver less broken. A regression was
+introduced in the XeTeX driver in the last release that lead to displaced
+objects #708 #709. This update fixes the regression but also reverts the fix for
+position tracking #353.
+
+## [3.1.4] - 2019-07-12 Henri Menke
+
+### Added
+
+- Document and fix the `patterns.meta` library
+- Stretchable dash patterns
+- Use `\protected at edef` in `\pgfmathparse`
+
+### Fixed
+
+#672, #675, #689, #353, #693, #690, #700, #701, #702
+Revert 00f4e8d4154dcb3133ed4a106b6254b8faf874e2
+`\pgfmathrandominteger` didn't handle expressions as input
+
+### Changed
+
+- after_script runs after deploy
+- Add pgfmanual to release files
+- Add URL of the pdf manual to the README.md file
+- Goodbye SourceForge
+- Clear trap before deploy
+- Switch to a new branch for tlcontrib
+- Stretchable dash patterns #629
+- Try protected at edef in pgfmathparse
+- Hardening patterns.meta a little
+- \pgfmathrandominteger didn't handle expressions as input
+- extract.lua: all extracted files are tex
+- extract.lua: recurse into subdirectories, ignore remember picture
+- Describe \pgfdeclarepattern and \tikzdeclarepattern
+- Add patterns.meta to the manual
+- /pgf/foreach/count is unscoped #702
+- On the way to more configurable patterns
+- Add mailing list to the README
+- Missed stripping pt on dimensions #701
+- Bend angle need not be integer #700
+- No dedicated options for libraries (for now)
+- Add option to hide code
+- Stripping comments was too greedy
+- Small fix to the grammar
+- Typos in luamath
+- Functionality to print libraries in code listings
+- fixed some typos
+- fixed regression (accidentally duplicated part of code)
+- \pgf at nodecallback might be called twice #693
+- Default implementation of \pgfsys at hboxsynced doesn't work for dvips #690
+- Fix position tracking for XeTeX #353
+- Wrong order in definition of \translate #689
+- FILES is generated
+- Change priority of Travis jobs
+- Load imakeidx before hyperref
+- Remove user config from deploy script
+- Revert "Missing spaces in error messages #679"
+- Restored lost functionality in intersections / fillbetween feature
+- Revert 00f4e8d4154dcb3133ed4a106b6254b8faf874e2
+- Fixed regression: the merge cc191ed4ae5bd11df9ce42595102caa4e1f141b4 accidentally deleted a feature
+- Use imakeidx for automatic index creation
+- Looks like I got tex4ht working
+- Use T1 for DVI output for now, see also https://github.com/mgieseki/dvisvgm/issues/2
+- luaotfload was missing this whole time
+- Merge remote-tracking branch 'loopspace/master'
+- Disable T1 encoding for LuaTeX
+- Extended the higher-level save of the last moveto so that it also works with nodes.
+- Added dimensions for saving the last moveto coordinates so that -- cycle works
+ with nodes. The existing method uses the coordinates stored from the last
+ soft path move to, but this has an extra transformation applied to it meaning
+ that when it gets used in node placement the transformation is applied twice.
+- Missing spaces in error messages #679
+- Move tlcontrib to tlnet folder to make room for possible future MikTeX contrib
+- Typo in alternate angles #676
+- Missing xcolor definitions for Plain and ConTeXt #675
+- Typo
+- Some more fixes for the tex4ht manual
+- Merge remote-tracking branch 'Mo-Gul/master'
+- Revert all but the useful changes of 98829b450a96a6790570aba11949cd9834e49e2c
+- Some more cleanup before deploy
+- Fix .lastretry #672
+- Deploy TDS and CTAN zip
+- Get git tag in Makefile
+
+### Contributors
+
+- Andrew Stacey
+- cfeuersaenger
+- Christian Feuersaenger
+- Henri Menke
+- johannesborgstrom
+- Stefan Pinnow
+
+## [3.1.3] - 2019-05-09 Henri Menke
+
+### Changed
+
+- Further unbreaking of shadings #650
+- \ifdim instead of \ifx #412
+- Add push- and popmacro. Useful for smuggling. From ConTeXt
+- Merge pull request #664 from dcpurton/shadings-colorspace
+- Add navigation arrows to SVG manual
+- Typos in pgfmanual-en-library-circuits.tex #667
+- Simpler basename function for extract.lua #640
+- Add copyright and attribution for CMYK and grayscale shadings
+- Update documentation for color model independent shadings
+- CMYK and grayscale shadings library support
+- Functional shading color space conversion functions
+- Support for CMYK and grayscale shadings in set up code
+- Conversion from shade color to grayscale PostScript data support
+- Conversion from shade color to CMYK PostScript data support
+- Add grayscale shading postscript driver support
+- Add CMYK shading postscript driver support
+- Add grayscale shading parsing functions
+- Add CMYK shading parsing functions
+- Adapt shading drivers to allow for multiple color models
+- Produce compilable examples from extract.lua #640
+- Preliminary version of an extractor script for codeexamples #640
+- Manual typos #665
+- Revert "No mode switch for typesetting pictures"
+- Support shading color specifications in CMYK
+- Set up RGB specific shading parsing
+- Fix typos #662
+- No mode switch for typesetting pictures
+- Correct floored division (thanks @josephwright)
+- Merge pull request #661 from dcpurton/mandelbrot-fix
+- Fix Mandelbrot set shading definition #658
+- Add Easter to PGF calendar #593
+- Document save and use path #644
+- Missing definitions in tex4ht driver #660
+- Fix conflicting shading declarations for dvipdfm #659
+- Add some circuit symbols #641
+- Add tlpkg to Travis cache
+- Fix shadings in dvisvgm
+- % is not allowed in DVI #657
+- Fix shading regression #656
+- Don't switch mode in \pgfuseshading #655
+- Use TL usertree in CI
+- Merge pull request #647 from Skillmon/parserx
+- requested changes from review
+- Merge remote-tracking branch 'official/master' into parserx
+- More checks, fewer rsyncs
+- fixed bug ignoring +
+- fixes #628; needs the new parser version
+- fixed a bug in pgfparserlet
+- removed parserx from FILES
+- parserx replaces parser
+- Force push to SourceForge
+- Add revision file to archive
+- Override before_script for SourceForge mirror
+- Update README [ci skip]
+- Typo
+- Missing packages
+- Better commit message
+- Deploy tlcontrib
+- PGF requires etex
+- Looks like we have to rerun twice
+- Rerun check for dvisvgm docs
+- Deployment script for website
+- bugfix default space rule
+- added pgfparserxlet
+- Merge branch 'fix-typos' of ssh://git.code.sf.net/u/frougon/pgf
+- Shading assignment has to global #650
+- Correct initial value for minimum width and height #649
+- use pgfutil at namedef
+- no etex, no folds
+- Merge remote-tracking branch 'official/master' into parserx
+- Merge remote-tracking branch 'kpym/master'
+- Optional e-TeX protection
+- finished parserx documentation and module
+- Fix Travis conditional
+- Only sync when on upstream
+- \noexpand instead of \ignorespaces
+- Automatically mirror changes to SourceForge
+- Allow optional comma in let assignment list #606 (oberdiek)
+
+### Contributors
+
+- David Purton
+- Jonathan Spratte
+
+## [3.1.2] - 2019-04-04 Christian Feuersaenger
+
+### Changed
+
+- Update README
+- Fix #523 (jkinable)
+- Fix #522 (kpymtzanev)
+- Welcome to GitHub :octocat:
+- Renaming perspective library macros
+- Fixed typo and missing backslash
+- Correct copyright statement
+- Added perspective library
+- Fix TeX conditionals on \pgfmathdeclarefunction (Eric Domenjoud) Feature Request #121
+- More accurate \pgfpointnormalised #518 #519 Feature #96
+- tikzmath needs to know about fpu
+- Fix shading angle #516 (Eric Domenjoud)
+- Fix trivial typo #514
+- Missed ligature suppression for dvisvgm #473
+- Now I hopefully got all of the ligatures #473
+- Some fixes for the shading patch #511 (Eric Domenjoud)
+- \long\def
+- Fake \scantokens has to at least strip braces
+- Only use \scantokens if available #508
+- Revert "Revert "Patch for shadings #511 (Eric Domenjoud)""
+- Revert "Patch for shadings #511 (Eric Domenjoud)"
+- Making the declared coordinate accessible
+- Globally remember declare coordinate of a node
+- Check for \pgfpointxyz before \rawx, \rawy, \rawz
+- Add \rawx, \rawy, \rawz to let operation
+- Disable strict nesting for now
+- Patch for shadings #511 (Eric Domenjoud)
+- minor stuff
+- Merge branch 'master' of ssh://git.code.sf.net/p/pgf/git
+- Merge branch 'branch_3.1_hotfix'
+- updated release file
+
+### Contributors
+
+- Henri Menke
+- Max Snippe
+- Stefan Pinnow
+
+## [3.1.1] - 2019-02-02 Christian Feuersaenger
+
+### Changed
+
+- fixed bug #503: regression prevented the use of dvips. This reverts the bugfix
+ for bug #362
+
+## [3.1] - 2019-01-05 Christian Feuersaenger
+
+### Changed
+
+- \pgfmathprintnumber: implemented 'retain unit mantissa=true|false' (feature #92)
+- fixed wrong projection of `canvas is xy plane at z` in `3d` library (bug #410)
+- added documentation of `3d` library to the manual (support request #11)
+- defined CMYK colors for ConTeXt (feature request #33)
+- `text along path` decoration repeated last char multiple times when
+ this was in math mode (bug #479)
+- fixed accidental usage of `\rm` (bug #476)
+- fixed newlines for tex4ht (bug #327)
+- fixed bug that `fit` didn't work with `transform shape` (bug #330)
+- fill color in nodes now respects colormodel (bug #349)
+- fixed broken VTeX support (bug #350)
+- `text=<color>` now works fine when in the nodes' text `\textcolor` is used (bug #362)
+- allowed whitespace between layers in `\pgfsetlayers` (bug #376)
+- fixed `\method` which can now contain empty lines (bug #448)
+- manual improvement regarding `pgfoothis` (bug #452)
+- documented commands `\pgfooeset`, `\pgfooappend`, `\pgfooprefix` (bug #452)
+- fixed bug in \pgfkeysedef (bug #306)
+- `miter limit` now raises an error when a value < 1 is given (bug #347)
+- fixed bug that `\pgfmathmax` and `pgfmathmin` were broken when
+ `fixedpointarithmetic` library was loaded (bug #360)
+- added missing function `\pgfmathpneg` in `fixedpointarithmetic` library (bug #361)
+- fixed bug that brace decorations were malformed for large amplitudes (bug #351)
+- made node parser aware of prefix and suffix (bug #397)
+- (almost) fixed guillemets for LuaTeX (bug #473)
+- fixed incorrect spelling in pgflibrarydecorations.text (bug #479)
+ (but this doesn't solve the bug 100%)
+- fixed 'bend left' bug if used with a formula (bug #423)
+- use \typeout stream instead of \write16 (bug #488)
+- fixed some bugs regarding graphdrawing electrical "springs" (bugs #380 and #381)
+- fixed pgf_lookup_and_require for new luaotfload (bug #493)
+- fixed graphdrawing for ConTeXt (bug #477)
+- added utility \pgfmathifexpression (and special treatment in luamath
+ library and fpu library)
+- intersections lib: improved accuracy of intersections for linear paths
+- fixed incompatibility issue of tikzmath and fpu reported in
+ http://tex.stackexchange.com/questions/349766/pgfplots-on-tikzmath-function-with-conditionals-returns-an-error
+- Improved driver detection (bug #395 TikZ does not create output with LuaTeX 0.95.0)
+- New luatex driver now supports fallback to pdftex driver if
+ luatexversion is older than 95 (let's hope this works reliably - luatex
+ used to have version 240 some time ago!)
+- Fixed bugs that caused pgfsys-dvips.def to generate corrupt
+ PostScript for all nodes.
+- Bounding box computations for animations implemented.
+- Animated arrow tips are now possible.
+- fixed incompatibility between textpos (absolute mode) and external
+- fixed \write18 issues in luatex 0.87 and later (by using os.execute())
+ affects external lib and plot function.
+- Lots of bugfixes in animation and svg code.
+- Added optimizations to reduce file size for svg code
+ (better support by dvisvgm will be needed however for more
+ compact text!).
+- First working, fully documented version of TikZ animations!
+- Fixed manual stuff to compile it with dvisvgm.
+- Rewrote tikz animation lib.
+- added context-related aux file fix of Hans Hagen
+- fixed save stack issues (eliminated 'retaining' issues) about pgf at x and pgf at y
+- external lib: 'force remake' now also updates .md5 files
+- fpu: fixed floor and ceil
+- fixed basic layer floor function
+- lua library: improved interoperability of luamath and fpu
+- unit test now compares luamath, fpu, and pgfbasic math
+- activated math parser in foreach's end notation to allow \foreach \i in {0,...,10-9}
+- Worked on pgfsys-dvisvgm.def a lot. Now requires
+ dvisvgm-1.5.3 because of switch from pt to bp there. Does
+ correct bounding box computations.
+- fixed bug in luamath library
+- external lib: added support to automatically externalize references and
+ labels with 'mode=convert with system call'
+- Reworked implementation of animations for tikz and started
+ on documentation of the backend.
+- First complete implementation of animations for tikz! (for
+ svg backend). Documentation still missing, but works nicely.
+- First work on animations for svg. Added commands in pgfsys
+ and added module pgfmoduleanimations. No documnetation yet.
+
+### Contributors
+
+- Henri Menke
+- Till Tantau
+
+## [3.0.1] - 2015-08-07 Christian Feuersaenger
+
+- fixed regression introduced for pgf 3.0.0 (bug #149): leading empty
+ lines at the beginning of plot files disabled '-- plot'
+- fixed bug #291 (missing white space trimming in node labels)
+- fixed bug #313 (alias option did not respect name prefix/suffix)
+- fixed bug #341 ("is in pic" was not reset)
+- fixed bug #365 (caused by missing adoption after copy-paste in tikzlibraryfolding)
+- fixed bug #315/316 by applying the suggested patch and verifying it
+- fixed fpu math functions for int, ceil, and floor
+- added \pgfmathlogtwo and \pgfmathlogten as requested in bug #359
+- Fixed problem in gd: Creating more than about 15 vertices
+ inside a graph drawing algorithm was impossible since this
+ created too many text input levels. Reorganized the interplay
+ between tex and lua for the coroutine so that no input levels
+ are created.
+- Added number nodes option to graph lib.
+- Fixed nullfont warnings in axes in datavisualization.
+- Fixed wrong axes for school book plots.
+- Fixed nullfont warnings when parsing logic gate inputs.
+- Fixed bug in tikz.code.tex concerning colors for arrow tips:
+ Setting and restoring the global color "trackers"
+ pgf at fillcolor@global over groups was done only in \pgfscope,
+ but not in the scopes opened and closed by tikz when drawing a
+ path (\pgfsys at beginscope is used there). This caused wrong
+ colors to be used.
+- Updated patterns.meta library.
+- context: committed patch to adopt pgfutil-context for new (incompatible)
+ context handling of colors -- contains some cleanup by Hans Hagen.
+- fixed bug in external lib: braces in external filenames confused the generator
+- fixed bug in fpu: equal(x, 0) failed for x<0
+- fixed bug in atan2 (returned wrong sign for atan2(4e-5,-5))
+- implemented atan2 in FPU
+- fixed save stack issue (TeX capacity exceeded, sorry [save size=250000])
+ if the color changes a _huge_ number of times during a single path.
+- worked on LUA math parser: ensured that a suitable first scope of
+ functions works. I also added support for 'declare function'
+- Added provisional code for patterns.meta library. Patterns
+ can now be declared using TikZ code with additional support
+ for tile transformations. Currently only PDF output supported
+ at back-end (uses \pgfsys at declarepattern@meta in pgfsys-pdftex.def).
+- finished first prototype of a LUA math parser. It is orders of magnitude
+ faster than its TeX pendant, features a pure LUA mode and also offers a
+ fallback to the TeX \pgfmathparse for unsupported operations/functions
+ only defined in TeX.
+- fixed bug (regression of bug #229): external lib with dvips produced
+ wrong bounding box (was broken entirely)
+- fixed regression in external lib: 'mode=graphics if exists' broke any
+ undefined label warnigns
+- added automatic "fast lane" to math parser: if the input is a number
+ without units, it will return that as-is. Reduces typesetting time down to
+ 66% for huge scatter plots and has just 1% overhead for math intensive
+ figures.
+- added switch 'trig format=deg|rad' which allows to switch sin,cos,tan,
+ and their friends to radians. It works for all user input
+ arguments - I hope without unanticipated side-effects (marked as
+ experimental)
+- external lib: defined suitable defaults for 'system call' depending on driver
+- external lib: solved incompatibility with biblatex's \cite[][]{name}
+ command (http://tex.stackexchange.com/questions/173465/tikz-error-for-externalized-graphics-but-output-is-correct}
+- number parser/printer: added switch 'read comma as period' to read
+ localized input numbers. Off by default but added useful hint to parser
+ message.
+- Fixed bug #308 fixedpointarithmetic: unwanted spaces by line ends
+- Fixed feature #81: signum function (fpu + pgf basic layer)
+- Fixed all \begin{scope} and \end{scope} in foldings lib,
+ changed them to \scope and \endscope.
+- Fixed #303 Type in pgfmanual (colormixin)
+- Fixed #302 pgf-3.0: Cannot plot a constant function. Will
+ now center the constant line.
+- Addressed #299 Precision problem with explicitily anchored
+ labels: While not a bug, I added a "centered" option for cases
+ similar to this one (although, in this particular case, the
+ new centered option is not what is needed)...
+- Fixed #298 \pgfarrowsdeclare is still mentioned in pgfmanual
+- Fixed #294 Nodes for arcs, which angles are calculated
+ simultaneously.
+- Fixed #292 "node scale and outer sep" by introducing the new
+ option "outer sep=auto", which takes care of both this problem
+ (at least in all normal cases) and also of the draw versus
+ fill problem with outer seps.
+- Fixed #285 \tikz at intersect@namedpaths persists outside
+ scopes as suggested.
+- Fixed #284 Additional rerun statement for overlays (for LyX)
+ by adding the proposed solution (essentially).
+- Added post-fix for #288 by undoing all -- ligatures in
+ verbatim code.
+- Fxied #283 "Is there a smarter way to handle units in math
+ engine?" by adding the "scalar" function.
+- Fixed #288 "All the '£' should be '$' in the examples of
+ pgfmanual..." by switching to T1 enconding.
+- Fixed #282 "\pgfmathredeclarefunction does not work properly."
+- Added first edge routing algorithm to gd.
+- intersections libs: improved robustness and accuracy for curveto paths
+ by using the floating point library together with Mark Wibrow.
+- fixed bug in latex/plain tex shipout routines for xdvipdfmx and xelatex:
+ combination of shadings and standalone package failed to work.
+- Fix for 'rotate around x/y/z' keys which now evaluate
+ the argument provided.
+- intersections lib: detected duplicates in line-to intersections
+ in endpoints and suppressed them.
+- intersections lib: stored time offset for each intersections as optional
+ property (i.e. if it comes for free). This is required to compute fill
+ paths
+
+### Contributors
+
+- Christian Feuersaenger
+- Mark Wibrow
+- Till Tantau
+
+## [3.0.0] - 2013-12-20 Till Tantau
+
+- In preparation for the release 3.0.0, I pimped the manual a
+ bit. It will now automatically detect whether graph drawing
+ C libs are available or not. Also, syntax hilighting is now
+ always switched on. I also some subtle optical hints to
+ crossreferenced words in the code examples; this is pretty
+ useful, I think.
+- Did a lot of cleaning up for the release.
+- Fixed a bug in Vertex.lua that returned wrong anchor
+ positions for non-centered vertices.
+- Fixed bug #280 "Layered layout" produces unknown key with graphs library.
+- Fixed bug #279 "Some parts of arguments in foreach macro are lost".
+- Fixed bug #258 "Default arrow edge style puts circumflex in
+ drawn end node" by now allowing people to say tip=on proper draw.
+- intersections lib: ensured that 'name path global' is reset between main paths.
+- worked on intersections lib (internals only); added O(N) list
+ append/prepend utilities
+- Added keys 'rotate around x', 'rotate around y' and
+ 'rotate around z' to rotate the xyz coordinate system
+ around the x, y, or z axis.
+- Fixes for 'text effects along path' decoration and docs.
+- external lib: added support for 'up to date check=md5' for lualatex.
+ Now, lualatex and pdftex both result in the same checksums (by means of
+ \usepackage{pdftexcmds})
+- Finalised 'text effects along path' decoration and docs.
+- Changed keyval example (and references to define at key)
+ in pgfcalendar documentation to pgfkeys stuff.
+- Minor fixes to decorations.text and math libraries documentation
+- Added 'text effects along path' decoration.
+- Fixed regression/bug in 'name path global'.
+- Applied path for bug #277 "\beforeforegroundpath not working".
+- Prepared manual for new release (fixed overful boxes and
+ index problems).
+- Updated math library (minor fixes).
+- Applied some fixes so that C code for graph drawing works
+ once more.
+- Arrow tips and their doc are now officially finished!
+- Added documentation of nonlinear transformations.
+- modified release script to allow uploads of unstable TDS
+ zips to http://pgf.sourceforge.net using
+ make -f pgf/scripts/pgf/Makefile.pgf_release upload USER=cfeuersaenger
+- Fixed problem with math parser inserting extraneous
+ spaces when parsing \dimenexpr
+- Changed blend mode syntax to standard pgf syntax (since PDF
+ and SVG do not agree on names...).
+- Added scale and slant options for arrow tips.
+- Added more generic arrow tips.
+- First version of comlete arrow documentation finished. Still
+ need to document the arrows.meta library, though.
+- Added "tips" option for drawing arrow tips without drawing
+ paths.
+- Fixed bug #273 "Graph drawing sublayouts fails".
+- Incorporated first partial documentation of the arrow tips
+ into the main documentation.
+- Fixed bug bugs:#272 "SVG parser error after close path" as
+ suggested by Mark Wibrow.
+- Also changed the default syntax for svg path command so that
+ it uses braces instead of quotation marks. (Quotation marks
+ still work, of course.)
+- Started working on arrow doc.
+- Added macro to convert string of digits to comma separated list.
+- First version of new arrow tip management done. Up and
+ running! Still needs documentation and the old arrow tip
+ codes should (but need not) be ported.
+- Did some porting of old code, added fixes. Doc still missing.
+- Fixed bug #264: "\pgfkeys /errors/unknown key should (?) expand first argument"
+- Fixed bug #268: "`matrix of nodes` isn't working properly any more"
+- Corrected typos (bug #266 and bug #265)
+- added magnetic tape shape.
+- Fixed bug #262/267: "Line breaks are not working in labels anyy more."
+- Fixed bug #260: "TikZ node on background in pgfextra"
+- Started work on bending arrows.
+- external lib: fixed bug: file dependency handling was incorrect and
+ suffered from regression caused by MD5 checks
+- repaired incompatibility with pgfplots <= 1.8: samples key was
+ evaluated in context of floating point unit and new pgf code relied on dimension
+ registers.
+- Added "turn" key.
+- Added "angle" pic type and "angles" library.
+- Patched gd loader code so that it works with context mark IV.
+- Added new pic path command.
+- Patched pgfsys-dvipdfmx.def to step around the bug in
+ (x)dvipdfmx that caused scaled boxes (including scaled
+ graphics) inside nodes to be displayed incorrectly.
+- fixed bug in fpu: 0^0 and 0^x both produced nan. Now we get
+ 0^0=1 and 0^x = 0.
+- Removed claims from manual (not by me...) that TikZ does not
+ work with Mark IV of context. I just tried it and everything
+ I tried (including advanced stuff like shadings) worked fine.
+- Fixed pgf intersection library to ensure that
+ specialround tokens are processed.
+- Added support for dvisvgm. Quite nice...
+- Worked on tex4ht code. Works reasonably well know and even
+ graph drawing is possible (when luatex is used for
+ typesetting; for this I needed to fix some latin1 characters in
+ html4.4ht). Also, I renamed /tikz/tex4ht... to /pgf/tex4ht
+ (someone else added that) since tikz has nothing to do with
+ that stuff.
+ Typesetting the manual in tex4ht no longer works, but that seems
+ like too much bother for my taste.
+- Fixed bug #256 "The special \pgfcoordinate macro doesn't
+ expand \pgfpictureid."
+- external lib: fixed incompatibility of pdflscape with
+ external lib
+- Fixed a problem with pdf resources of transparency groups in
+ dvipdfmx.
+- Fixed bug #149 "/tikz/raw gnuplot ignoring segmented plot"
+ by introducing a new way of handling plot streams. There are
+ now new kinds of points (outliers and undefined points) and
+ "new data sets" commands inside streams. Handlers (like the
+ lineto and curve handlers) can be configured to interpret
+ these as jumps (this is the default).
+- Fixed bug #255 "Trig computations offend fp via fixedpointarithmetic lib"
+- Added "math" library. Could be integrated with calc library.
+- Fixed bug in external lib: mode=list and make did not cope well with
+ \ref in externalized images. These will be remade now.
+- Fixed bug #162 "PGF manual examples use undefined "shape example" style"
+- Fixed bug #169 "ghostscript error: /undefined in pgfo"
+- Concerning bug #167 "node pin option sets
+ inconsistent/incorrect angle" I added some clarification in
+ the manual that explains the observed behaviour.
+- Fixed bug #158 "\pgfmathparse does not support e-TeXs
+ \numexpr and \dimexpr". You can now also use
+ \pgfmathsetlength to assign a muskip a value. Internally,
+ "mu" is treated like "pt", but if an expression contains
+ "mu", \pgfmathsetlength and \pgfmathaddtolength will convert
+ the number to "mu" before the assignment.
+- Fixed bug #173 "Tikz's transparency, xelatex and preview
+ package" by adding a specific fix for the interaction
+ between preview.sty and everyshi.sty in pgfutil-latex.def.
+- optimized mark=* and mark=o (q path versions lead to 10% time reduction)
+- adopted new pgfkeys feature to /handler config/full or existing (
+ required when /.search also is used to find the correct key path)
+- Fixed bug #175 "In PGF oo module, calling a method strips grouping"
+- Fixed bug #181 "Need to document |- coordinates using calc notation"
+- Fixed bug #187 "\pgfmathanglebetweenpoints is not documented"
+- Increased accuracy of atan, atan2 and
+ \pgfmathanglebetweenpoints.
+- Fixed bug "#168 PGF is sensitive to dollar catcode"
+- Fixed bug "#186 pgfonlayer makes pgf forget options" and
+ added "every on background layer" option.
+- Fixed bug "#192 pgffor scope iteration is buggy"
+- Fixed bug "#196 Incoherent syntax for Bézier curves"
+- Fixed bug "#199 Drawing error for chamfered rectangle"
+- Fixed bug "#201 Markings fail with "Dimension too Large" on
+ certain paths" by fixing a mistake and the decoration core
+ and, additionally, in pgfmathanglebetweenpoints.
+- Fixed bug "#254 building currenct CVS version fails on
+ graphdrawing with current luatex": Will now work nicely with
+ TeXLive 2013 and Lua 5.2.
+- Added feature request "bug #203 Blending modes and better transparency"
+- Fixed bug #204 "strange influence of \baselinestretch on
+ tikz figure" by no longer sharing \pgfutil at tempa with latex:
+ This register gets changed by LaTeX in a fontchange, which, in
+ turn can happen at the beginning of every
+ \pgfmathsetlength.
+- Fixed bug #207 "Decoration markings not on path on large
+ lines" by using a more precise computation of positions on
+ straight lines in decorations. Also, the angle computation
+ is now much more precise by fixedin bug #201.
+- Fixed bug #212 "Error if using plot into a \foreach loop in
+ a single path" by making \pgffor at beginhook and friends local
+ to the current \foreach. A nice side-effect is that one can
+ now nest \foreach statements on a path and also mix in the
+ plots. Hopefully, no one relied on the (undocumented,
+ unsupported) old bevahiour of the hooks.
+- Fixed bug #213 "pgfmathsetcounter only works in local scope"
+ by adding a note in the documentation.
+- Fixed bug #211 "\nodepart ignores text transparency"
+- Fixed bug #220 "Transformations ignored in edge decoration."
+- Fixed bug #221 "xyz spherical and cylindrical coordinate, radius not defined"
+- Fixed bug #225 "pgfkeys "/errors/unknown choice value" ignores parameters"
+- Fixed bug #253 "\pgfkeysfiltered cannot accept long arguments"
+- Fixed bug #252 "I'm not able to build the current CVS
+ version". This included a number of patches to fix problems
+ introduced with the bugfixes introduced recently
+- Fixed bug #226 "matrix column sep=-\pgflinewidth changes after empty cell"
+- Fixed bug #229 "pgfpagesuselayout breaks beamer class"
+ (hopefully, setting page sizes is really messy in TeX!).
+- Fixed bug #232 "pow function broken for 0^x for non-integer values of x"
+- Fixed bug #165 "\draw with empty domain results in infinite calculation"
+- Added better error message to adress bug #244 "mindmap-style
+ "invalidates" coordinate shape."
+- Fixed bug #235 "\def\costhirty{0.8660256} not really used"
+- Fixed bug "#237 CVS-version: pdfimage error: key interpolate undefined"
+- Fixed bug "#245 broken key /pgf/decoration/reset marks"
+- Fixed bug "#239 picture disappear after a zero-width rectangle width shading"
+- Fixed bug "#247 Error messages hard to catch in plain TeX/ConTeXt"
+- Fixed bug "#166 Possibly typos in circuits.logic.IEC"
+- Fixed bug "#249 pgfkeys: /handlers/first char syntax is not
+ 'self-contained' (CVS version)"
+- Fixed bug "#248 circuits adjustable annotation improperly placed"
+- Fixed bug "#250 pgfkyes: .append style and similar undouble # tokens"
+- Fixed bug "#143 label changes center of a matrix node"
+- Fixed bug #128 "fit does not scale if used in scaled scope"
+- Fixed bug #136 "\hrulefill inherits or not pgf line styles"
+- Fixed bug #224 "Including Tikzpicture in third part of
+ multipart node"
+- Fixed bug #251 "cross out shape interacts with path options of path it is drawn on"
+- Fixed bug #139 "Placement of node inside matix environment"
+- Fixed bug #131 "text centering calculates wrong" and added
+ new "node font" option.
+- Fixed bug #121 "Annoying "Underfull \hbox (badness 10000)" message"
+- Fixed bug #134 "Edge node style affecting arrowhead".
+- Fixed bug #132 "Error in matrix with column sep "between"
+ origins"
+- Fixed bug #133 "\draw[-<<,>=stealth] (10,45) -- (40,45); does
+ not work." However, this introduces a (small, only visual)
+ incompatibility with previous versions. If you need the visual
+ effect "-<<" used to have (which, in a sense, was wrong), use
+ "-< <" instead. The new "-> >" is also quite handy.
+- Fixed bug #116 "Decorations can't be repositioned when
+ pre/post used."
+- Fixed bug #241 "div/null error by (270:length) and a fading line."
+- Fixed bug #126 "Incorrect placed labels for inplicite positioned nodes."
+- Added foreach syntax to nodes. This is useful and also
+ needed to fix the problem that the foreach statement cannot
+ be used after a to path.
+- Fixed bug #18 and #74 (active characters and tikz) by virtue
+ of the new "babel" library, which deactivates catcodes at the
+ beginning of tikz pictures and reactivates them in nodes.
+- Fixed bug #110 "cannot add node after cycle operation"
+- Fixed bug #88 "\pgftransformarrow does not rotate with \pgfpointanchor"
+- Fixed bug #86 "macro-expanded tree node has bad edge anchor"
+- Fixed bug #85 "PGF + Crop package, at least for pdftex."
+- Fixed bug #83 "Transparency Problem with \usepackage{endfloat}."
+- Applied patch #19 pgfkeys: ".search also" fails at unbalanced "\if" values
+- Applied patch #18 Missing grid lines with
+ negative increment
+- Applied patch #17 TikZ folding library
+- Applied patch #14 inheritance in the oo module
+- Applied patch #13 leaking space in \pgfpointintersectionoflines
+- Applied patch #11 Patch for Bug #3165961 (\pgfmathmax and \pgfmathmin)
+- Fixed problem of patch #9 Add papersize to XeTeX driver
+- Applied patch #8 Support for changing physical page size with XeTeX
+ (also added position saving support, while I was at it...)
+- Applied patches #3, #4, #5, #6 (typos in manual) as far as possible
+- Fixed bug #236 "Scaled closed paths, start/end points dont exactly match":
+ "cycle" can now be used with all path operations where it
+ makes sense, not only with --. In particular, things like
+ ".. cycle" or "to [bend right] cycle" are now allowed.
+- Reworked handling of edge and vertex paths in gd. In
+ particular, edge--vertex intersections are now computed in
+ Lua, rather than in TikZ. This is much more powerful and
+ allows beautiful arcs between vertices. It is also very
+ useful for planar graph drawings when several edges leave a
+ vertex in the same direction.
+- Did away with luadoc, now using simple handcoded documentor
+ that will also work with Lua 5.2
+- Redid OGDF support. Resonably stable base now.
+- Added better C support.
+- Should now work with both Lua 5.1 and 5.2
+- fixed incompatibility of fixltx2e and external lib
+- Reworked Storage mechanism of graph drawing system.
+- Added phylogenetics library for graph drawing; documentation
+ still only rudimentary.
+- Started adding support for calling C graph drawing functions
+ from Lua.
+- First proof of concept for OGDF finished.
+- Must still address luatex shared library link problems.
+- fixed bug in external lib: \tikzexternalgetnextfilename did reset the
+ value of \tikzsetnextfilename and 'export next'
+- updated driver pgfsys-xetex: now, it supports all that the new driver
+ for dvipdfmx does which includes fadings, functional shadings, and
+ patterns.
+- First complete documentation of the graph drawing
+ system. (Finally!)
+- Renamed gd files to shorter versions: instead of
+ pgf/gd/model/pgf.gd.model.Edges.lua we now have
+ pgf/gd/model/Edge.lua and so on.
+- Worked on gd documentation. Only binding doc is still a
+ mess.
+- Worked on gd documentation.
+- New version of gd lib. The internals have been completely
+ redone. In particular, no tikz libraries are needed for the
+ individual algorithms any longer, all declarations are now
+ done completely inside Lua. This makes gd usable (in
+ principle) independently of tikz and pgf.
+- Because of this, all declarations of algorithms need to be
+ redone.
+- external lib: fixed spurious white space (caused by 'up to date check')
+- manual styles: improved robustness of auto cross references & active spaces
+- Fixed a bug with active colon in circuits lib. Probably more to
+ fix in other libraries.
+- Improved precision of math functions asin and acos (using linear
+ interpolation instead of constant interpolation)
+- Worked on gd.
+- fixed pgfsys-pdftex.def : very old regression with \setbeamercovered{transparent} and \pause
+ Patch by Hendrik Vogt
+- Added support for sublayouts in gd (not yet fully
+ documented). This allows one to use several algorithms inside
+ a single graph.
+- Redone handling of clusters in gd yet again. Renamed them to
+ "collections". Much better system now, can handle hyperedges,
+ subgraphs and other stuff (in principle).
+- Nodes generated by a gd algorithm now have correct size
+ information (this one was tricky!).
+- Redone handling of clusters in gd.
+- Worked on gd documentation.
+- fixed minor expansion issue \foreach \x in {a,...,d} lead to unexpanded value \x
+- externalization: added special switch to deactivate incompatible
+ geometry drivers during externalization
+- Redone pgf.gd.model.Arc
+- Added documentation for said class.
+- Worked on gd documentation.
+- Replaced old luadoc by customized version. Gets called
+ directly from tex.
+- external lib: added support for MD5/diff based up-to-date checks.
+ Changes to a picture will automatically result in a remake of the
+ respective external graphics.
+- Fix bug #3527068 (\pgfmathatantwo did not exist)
+- Changed pgf.gd.new_graph_drawing_algorithm syntax. Not
+ likely to change again...
+- Added support for algorithms to create nodes and edge in the
+ syntactic digraph.
+- Introduced library graphdrawing.examples that includes some
+ code demonstrating how "things are done".
+- context: fixed catcode issues by means of suitable module
+ \protect/\unprotect statements.
+- Introduced a new class model for graph drawing (Digraph,
+ Arc, and Vertex instead of Graph, Edge, Node). I'm currently
+ porting all the old code, but it takes a while and it's a
+ bit messy right now. Some easy algorithms are already based
+ on the new system, old ones not. In the end, things should
+ be significantly faster and also easier to program.
+- Attempt to fix bug in calc lib when '!' or ':' are active (not
+ fully tested but should work).
+- Attempt to fix bug with label and pin when ':' is active (not
+ fully tested but should work).
+- Finished the first two chapters of the documentation of gd
+ (overview and tikz usage).
+- Module system is now redone and the directory structure
+ has been reorganized. No more messing around with lua
+ modules, everything is perfectly portable now.
+- Started to completely redo the module system of graph
+ drawing in lua. I'm in the middle of it, so its currently
+ messy, but it works.
+- Implemented packing procedure for graph drawing.
+- Cleaned up graph drawing source some more.
+- Renamed lots of files (still not happy with it, though).
+- Implemented Reingold-Tilford tree layout.
+- Implemented my first graph drawing algorithm: circular layout.
+- Introduced new declaration mechanism for graph drawing
+ algorithm classes
+- Implemented preprocessing step of decomposing a graph into
+ connected components.
+- Cleaned up graph drawing algorithm directories: Moved
+ obsolete algorithms to special directory.
+- Switched graph drawing calling interface from function-base
+ to object-based: All graph drawing algorithms must now be
+ implemented in a class
+- Cleaned up file and class names of graph drawing engine.
+- Fixed problem that in case math library is loaded before pgf
+ some math functions were broken (because \pgfmath at xa and
+ \pgf at xa were different registers, which they should not be).
+- Added anchoring and orientation to graph drawing library.
+- Added arrows.spaced library.
+- Added quotation syntax to graph lib.
+- Renamed some graph drawing layouts.
+- Worked on documentation of graph drawing lib.
+- Moved wrappers for luatex primitives (\pgfutil at directlua,
+ \pgfutil at ifluatex, \pgfutil at luaescapestring) to pgfutil-common.tex
+- Added support for luatex to the profiler library by emulating
+ \pdfelapsedtime.
+- Fixed wrong edef in graph lib that broke the /-syntax when
+ text contained expandable stuff.
+- More work on the luamath parser and evaluator.
+- Fix a bug in tikz polar coordinates (reported on tex.se
+ http://tex.stackexchange.com/questions/41828/using-math-in-tikz):
+ braces around a delimited argument are removed.
+- Fix a bug in pgfmath != operator (reported and fixed on tex.se
+ http://tex.stackexchange.com/questions/40605/using-in-pgfmathparse)
+- Fix a pgfmath dependency for pgffor.
+- Added pos support to the arc command (finally...).
+- Added support to the graph library for drawing tries.
+- Added support to the graph library for adding edge labels in
+ an easier way.
+- Added the 'fixed relative' number formatting style.
+- Added 'const plot mark mid' and 'jump mark mid' plot handlers.
+- Renamed "layered drawing" to "layered layout" for
+ consistency.
+- More work on the lua math parser and evaluator.
+- Added wrappers for luatex primitives: \pgfutil at directlua,
+ \pgfutil at ifluatex, \pgfutil at luaescapestring
+- Make lua code more lua 5.2 compatible
+- Work on the lua math parser and evaluator. Begin to merge Mark's
+ code with mine.
+- added FPU support for ==, !=, <=, >=, ?
+- fixed problem with pgf number printer: it introduced spurious spaces
+ tracker id 3430171. Thanks to Clemens Koppensteiner for the bugfix.
+- \pgfsetlayers can now be given inside of a pgfpicture (or tikzpicture)
+- The lua math parser now works on basic expressions (no units, no
+ arrays, no strings, no functions, ...?).
+- Some work on a lua (lpeg based) math parser.
+- Added a gnuplot call key to pgfmoduleplot.code.tex (feature
+ request #3308340).
+- graph drawing:
+ - Initial work on layered drawing algorithms.
+- Added dim function for array to pgfmath (to be documented)
+- Some work on a ODE solver
+- removed spurious white spaces in my bugfix for pgfmathdivide
+- Second attempt at fixing spy lib...
+- graph drawing:
+ - added short overview for nodes and edges (lua class documentation)
+- graph drawing:
+ - Separate 'spring layout' and 'spring electrical layout' families.
+ Rename existing algorithms accordingly.
+ - Add an implementation of the Floyd-Warshall algorithm.
+ - Add a new 'Hu2006 spring' algorithm based solely on springs.
+ - Improve the initial layout of 'Hu2006 spring electrical' by
+ taking the graph size and diameter into account.
+ - Rework existing spring electrical algorithms and improve
+ documentation.
+ - Catch -!- edges and remove them from the Lua graph when detected.
+- graph drawing:
+ - Update documentation of spring and spring-electrical parameters.
+ Add TODO items where things are missing, unclear or need to be
+ worked on.
+ - Make initial step dimension and the electric charge of nodes
+ configurable. Both, Walshaw2000 and Hu2006 support this.
+ - Improve the approximation of the repulsive force.
+- Fixed bug 3297817 (spy postscript problem).
+- Fixed bug of missing newpath in postscript and opacity
+ settings.
+- graph drawing:
+ - Rename graphdrawing.spring to graphdrawing.force.
+ - Fix NaN bug in the orientation helper.
+ - Initial work on improving and documenting the parameters for
+ spring and spring-electrical algorithms.
+ - Properly forward default node and edge parameters to Lua.
+- graph drawing:
+ - Add Fibonacci heap and priority queue classes.
+ - Add Lua file for common graph algorithms. Implement Dijkstra.
+ - Add method Graph:getPseudoDiameter().
+ - Hu2006: Scale coordinations of nodes in a coarse graph based on
+ the quotient of its pseudo diameters and that of the parent coarse
+ graph, as described in the paper.
+- graph drawing:
+ - Fix several interpolation bugs in the coarse graph class.
+ - Use the coarse graph class in the Walshaw2000 algorithm.
+- Worked on documentation of gd backend. Still need to
+ document graph parameters.
+- graph drawing:
+ - Remove files from the old graph drawing library tree.
+ - Disable verbose logging by default.
+ - Specify sane initial values for spring algorithm parameters.
+- Added .graph drawing parameter initial key.
+- graph drawing:
+ - Implement graph coarsening in the Hu2006 algorithm.
+ - Name force-based algorithms after the paper author and year.
+- Reorganized graph drawing documentation.
+- Finished the graph drawing library reorganization started by Till.
+- Reorganized the graph drawing key and directory
+ structure. The documentation is still missing. Also, lots of
+ files still need to be moved, but I'll leave that to Jannis.
+- graph drawing:
+ - implement a quadtree optimization in the Walshaw algorithm.
+ - add a simple version of the Hu spring-electrical algorithm that
+ seems to work almost as good as the Walshaw even without
+ the multilevel approach implemented (which is the only thing
+ that really makes the Walshaw algorithm useful).
+- graph drawing:
+ - Initial work on a quad tree implementation for spring and spring
+ electrical algorithms, with unit test.
+ - Improve the internals of the Vector class.
+- graph drawing: Started to cleanup pgf and tikz layers. Ongoing...
+- graph drawing:
+ - Fix Walshaw algorithm to properly set the subnodes when copying
+ the coarse graphs. Simplify the code that updates the node
+ coordinates.
+- graph drawing:
+ - Modify the doclet to allow underscores in parameter names.
+ - Document the Vector class as well as the table, iter and traversal
+ helpers.
+ - Remove old table and iterator helpers. Rename helper files. Rename
+ table.merge() and table.copy() to table.custom_merge() and
+ table.custom_copy() to avoid name clashes with luatools. Add
+ string helpers, including string.parse_braces(). Update algorithms
+ to work with these changes.
+ - Allow vectors to have an origin vector, similar to the Position
+ class. Introduce new alternative table-based syntax for
+ Vector:set() that is much easier to read. Update unit tests
+ and algorithms.
+- fpu: added support for log10 and log2
+- graph drawing:
+ - Drop the 'not yet positionedPGFGDINTERNAL' node name prefix
+ internally. It's stripped off now when nodes are passed over to
+ Lua and its added back again when shipping the node out to TeX.
+ - Drop the Node:shortname() method which is no longer needed.
+ - Improve coding style and documentation of the Interface, Sys,
+ Node, Edge and Graph classes.
+ - Rename Sys:logMessage() to Sys:log().
+ - Make parameter labels in the API docs not appear in bold.
+ - Disable verbose logging by default.
+ - Add methods Edge:getNodes() and Node:getEdges().
+- graph drawing:
+ - Initial work on spring-electrical and layered drawing algorithms.
+ - Major rework of the Lua code of the graphdrawing library: added
+ a Vector class for improved math operations and node positioning,
+ added quite a number of table and iterator helpers, added
+ post-processing code for fixing the orientation of graph drawings,
+ updated the graph/node/edge data structures to store nodes in the order
+ they appear instead of storing them in a random order, implement
+ coordinate keys for nodes, and much more.
+- number printing: added '1000 sep in fractionals' switch
+- Work on pgflibraryluamath (added pgfpointnormalised)
+- Graphdrawing library documentation, split into two files, removed
+ noluatex file, reworked the text (added information).
+- First attempt to do math with lua (very basical): pgflibraryluamath
+- bugfix for rounding error in \pgfmathdivide{83.407811000}{16.68156400}
+ was 4.10, is now 5.0: it could happen in rare cases that digits where
+ appended where they shouldhave been than added (4 + .10 instead of 4 + 1.0)
+- Implemented a G_n subgraph for creating grid (or: mesh) graphs.
+ This also introduces a new key /tikz/graphs/wrap after=<number> that
+ configures how the nodes in such a grid graph are connected. Some of
+ the common subgraph keys such as /tikz/graphs/V and /tikz/graphs/n
+ can be used with G_n subgraphs as well.
+- Added a simple grid placement strategy. It currently does not
+ support the chain shift and group shift keys properly and does not
+ implement any placement order other than left-to-right, so there is
+ room for improvement.
+- external lib: reduced number of \newwrite allocations and allowed to disable features
+ to safe more of them (aux in dpth=false,disable dependency files)
+- added '/pgf/number format/relative' formatting style.
+- Finished documentation of data visualization (sort of)!
+- First usable version of data visualization!
+- Worked on dv documentation. Finished chapter on visualizers,
+ style sheets. Legends still missing
+- Worked on dv documentation. Finished chapter on axes.
+- Incorporated a bugfix of Hans Hagen which makes pgf compatible with
+ Context Mk IV.
+ Verified: the patch is backwards compatible with TL 2009 and TL 2010
+ i.e. Context MkII and it works with Context Mk IV.
+- Worked on dv documentation.
+- Attempt to fix a bug #1911195 with pgfpages and rotation (fix
+ contributed by Mark Wibrow). Note: Mark was not sure it has side
+ effects.
+- Documentation will now compile with auto-xref enabled (a problem
+ with \_ in the graph lib not handled correctly by
+ pgfmanual.pdflinks.code.tex).
+- Fix bug #3104978 thanks to Heiko Oberdiek patch on ctt.
+- Changed the graph syntax for anonymous nodes in the graph
+ library and simplified the as= syntax.
+- Added fresh nodes options to graph library.
+- Fixed graph lib so that it compiles with plain TeX.
+- Small fixed in the graph library.
+- Finished graph library!
+- Nearly finished graph lib and its documentation.
+- Fixed bug #3123605 (hopefully...).
+- Worked on graph lib.
+- Some integer arithmetics functions for the math parser
+ (contributed by Alain Matthes): gcd, isprime, isodd, iseven
+- Second attempt at making \tikz work also with fragile stuff
+ following. The new code will no longer fail in a situation
+ like \tikz \foreach ...
+- Worked on graph lib stuff.
+- A luatex version of the doc is available (fixed inputenc issues
+ since luatex works with utf8 by default).
+- Fix bug in pgfmathfunctions.basic.code.tex (bug reported by
+ Alain Matthes and fixed by Paul Gaborit on fctt): wrong
+ interaction between pow and exp (linked to \pgfmath at x modified
+ outside macro call).
+- Make \pgfkeys at exp@call long (bug reported by Florent Chervet on
+ fctt)
+- Fix bug in pgflibraryshapes.callouts.code.tex: \pgf at test changed
+ to \pgf at node@name (bug reported by Zarko F. Cucej on ctt and fix
+ contributed by Mark Wibrow)
+- fixed bug 3096333 (Fix contributed by Mark Wibrow): pgffor
+ failed to update \lastx in some cases
+
+### Contributors
+
+- Christophe Jorssen
+- Jannis Pohlmann
+- Mark Wibrow
+- Matthias Schulz
+- Till Tantau
+
+## [2.10] - 2010-10-25 Christian Feuersaenger
+
+### Changed
+
+- closed a lot of bugs on sourceforge, especially documentation bugs
+- fixed bug 2429749: gnuplot invocation in tabularx did not work.
+- fixed bug: there was an incompatibility between pgf and beamer due to a
+ missing \interlineskip in the shipout handling for latex.
+- renamed 'halfcircle' marker to 'halfcircle*' and added 'halfcircle'.
+- provided special case 'mark color=none' for the half-filled markers.
+- fixed incorrect fill/stroke coloring of new marker contributions (see
+ ChangeLog 2010-09-27)
+- added more predefined dashed and dotted line patterns for black/white plots
+ to fulfill a related feature request of Tomek
+- fixed bug: the 'name path global' feature did not work in every case...
+ the actual implementation might need to be revised eventually.
+- Imported spell checking results of Stefan Pinnow (thanks!)
+- Dealed with typo in 'sci generic' number formatting style: it now
+ accepts 'mantissa' *and* 'mantisse'
+- External lib: Fixed bug. The 'failed ref warnings for' was not properly \protect'ed.
+- Started on graph lib. Not yet finished and not documented.
+- Added plot markers of Magnus Tewes and Tomek: halfcircle, halfsquare*,
+ halfsquare left*, halfsquare right*, heart
+- Added \pgfpositionnodelater and \pgfpositionnodenow
+ commands.
+- externalization+\ref: fixed a bug
+- external lib: documented how to generate .png graphics and added support
+ switches.
+- added 'baseline=default', 'trim left=default' and 'trim right=default' choices to reset these keys.
+- added support to provide paragraphs in "pin" arguments
+- Worked on data visualization and its documentation.
+- basic level externalization: added \hoffset=0pt and \voffset=0pt to improve
+ compatibility with special document classes
+- added docs for \deferredanchor feature contributed by Christophe Jorssen
+- ConTeXt support: fixed loading problem of calendar lib
+- pgfsys-tex4ht.def: fixed problem with \par in a non-long macro argument,
+ thereby eliminating a compilation problem
+- pgfsys-tex4ht.def: renamed offending macro invocation \Par to \par
+- basic level image externalization: added '/pgf/images/trim external={<left>}{<bottom>}{<right>}{<top>}'
+ to allow modifications to the hardcoded '1truein' shifts.
+- added '/.style n args' key.
+- \usetikzlibrary / \usepgflibrary: added support for white-space trimming
+ and empty arguments in the lists. Now, lines do not need to be terminated
+ by '%' and ',,' is valid.
+- external lib: documented how to solve compatibility problems with
+ \tikzifexternalizing
+- added \deferredanchor feature contributed by Christophe Jorssen
+- added optimized and numerically stable arc path command
+ \pgfpatharctoprecomputed which interpolates start- and end points
+- external lib: fixed incompatibility with 2010/06/08 v2.0b eso-pic package
+- external lib: added sanity checking for failed \ref,\pageref,\cite commands in external images.
+- math parser: improved error messages by providing the complete math expression.
+- added 'trim left' and 'trim right' features to simplify bounding box
+ modifications and allow support for restricted bounding boxes and image
+ externalization.
+- pgfutil-latex.def: changed \usepackage to \RequirePackage (thanks to Christophe Jorssen)
+- external lib: added \tikzappendtofigurename{} shortcut for '\tikzset{external/figure name/.add={}{suffix}}'
+- external lib: added warning at end of document if not all graphics have
+ been found.
+- updated file 'tikzexternal.sty' for \label and \ref support inside of
+ externalized graphics
+- documented how \label and \ref support in external graphics works.
+- activated \label support for mode=convert with system call and
+ documented limitations.
+- added \tikzifinpicture{<true code>}{<false code>} macro
+- Worked on data visualization.
+- Added .list key handler.
+- Worked on data visualization.
+- improved sanity checking in number printer: now, the zero flag is
+ checked even if its exponent > 0
+- floatparsenumber: number format errors after exponents now contain the offending
+ character instead of '\relax'
+- number printer: added 'frac denom' and 'frac whole' for fine tuning of
+ fractional number printing.
+- number printer: made \protect portable across TeX variants (doesn't
+ produce bugs with context anymore)
+- fpu: optimized \pgfmathfloatgetflagstomacro
+- added \pgfresetboundingbox
+- added \pgfgetlastxy coordinate macro
+- added '/pgf/images/include external/<image name>' code key.
+- fpu: added convenience method \pgfmathfloattoint
+- number printer: added 'frac' style to automatically create fractionals.
+- splitted basic level file pgfcoreimage.code.tex: there is now a
+ pgfcoreexternal.code.tex file.
+- \pgfmathprintnumber is no longer a "fragile" command (it is \protect'ed
+ automatically in LaTeX).
+- Fixed baseline alignment with "text width" option in LaTeX.
+- New divide function
+- Rewrote code foreach extensions. Now no longer an impenetrable mess.
+ pgffor.code.tex is much larger, but contains some (as yet) undocumented
+ features which may get optimised out.
+- Image externalization: added '/pgf/images/aux in dpth' feature.
+ It allows to store \label and other .aux file related stuff in the image's
+ .dpth file which is processed when when the main document includes the
+ image.
+ The new switch is on for the semi-automatic modes of the external lib, otherwise it is
+ off.
+- pgfkeys: added '.code n args' handler. The difference to '.code
+ args={#1#2#3}' is that keys defined with 'code n args' gobble spaces
+ between the arguments.
+ Note: 'code 2 args' remains as-is (it has the special feature that the
+ second argument is optional).
+- fixed bug in '/.add code' key handler: it didn't work properly for
+ complicated keys
+- pgfkeys manual section: updated xrefs and docs
+- external lib: \tikzexternalize no longer needs (but still accepts) the
+ main job's name. Changes are now documented and the replacement |.sty|
+ file has been updated.
+- intersection lib: added 'name path global' feature.
+- external lib: partially fixed incompatibility with glossary package and
+ documented work-around
+- FPU: added \pgfmathfloatifapproxequalrel
+- number printing: added style to configure |sci precision|
+- number printing: added style to configure |std=<lower e>:<upper e>|
+- external lib: the <real job's name> argument from \tikzexternalize is
+ now optional. It can be deduced automatically if it is missing.
+- number printing: added 'sci generic' style to customize the appearance
+ of scientific format and a 'verbatim' style which doesn't use TeX macros
+ for the formatted numbers.
+- external lib: now, a |\jobname.auxlock| file will be generated in order
+ to detect whether the \jobname.aux file is in its final state. This allows
+ to export any images containing |\ref{}| manually; the automatic procedure
+ will not use the .aux file.
+- Added \ifpgfexternalreadmainaux switch. Will be used to avoid buffering
+ problems during externalization mode 'convert with system call'.
+- Fixed bug "papersize not supported by pgfsys-xetex.def - ID: 2934982"
+- Improved automatic cross referencing: auto key path prefixing failed for
+ spaces in key paths.
+- Added "on background layer" key to backgrounds lib.
+- added \pgfmathifisint
+- supported \nofiles in auto xref generation
+- externalization: both, basic layer and external lib now support \ref{}s
+ inside of externalized pictures. Furthermore, they won't generate any aux
+ files on their own (which wouldn't be thread safe and is not useful
+ anyway)
+- external lib: fixed bug with figure list/makefile handling and file
+ deps: calling file dependency handlings outside of a picture could result
+ in compilation failures
+- external lib: mode=list and make now supports the force remake keys.
+- external lib: the -shell-escape switch for nested system calls is
+ activated only if it was active for the main document. This should allow a
+ reasonable security measure for mode=list and make (which will also work
+ without system calls from within TeX).
+- external lib: added support for file dependencies.
+ For mode=list and make, any file dependencies configured with
+ \tikzpicturedependsonfile{<name>} will be checked by the generated
+ makefile.
+- profiler library now uses an output file which contains the current date
+ and time. Furthermore, it counts every invocation and allows to show every
+ command invocation (optionally with arguments expanded).
+- profiler library can now profile macros with arbitrary argument pattern
+ and is more rebust with respect to save stack usage
+- worked on profiler library and added docs for it.
+- added first draft of the pgf 'profiler' library
+- Fix for rounded corners affecting custom fills in rectangle
+ split shape.
+- updated the 'make dist' documentation target such that it compresses
+ every pdf object. The resulting manual is half as large than without
+ compression, but it requires pdf 1.5 (at least acrobat 6.0).
+- external lib: some output messages did not respect the 'verbose
+ IO=false' flag; fixed that
+- fixed buggy treatment of some automatic cross references in manual
+- external lib: improved the tikzexternal.sty package which can be used
+ without pgf installed.
+- added spy library.
+- imported a patch of Andy Schlaikjer which extends the 'plot gnuplot'
+ feature to read the “unbounded point” information provided by gnuplot.
+- added \r at pgf@reada temporary \openin register for compatibility with
+ other packages
+- fixed an auto xref bug which wrote '\pgfkeys{}' although the manual
+ contained |\pgfkeys|.
+- external lib: the 'optimize command away' things where not activated
+ accidentally. I fixed it.
+- added support for new paragraphs in pgfkeys values
+- fixed bug in |const plot| handler (and all its variants): the first
+ coordinate was transformed twice
+- auto xrefs now support point coordinate systems.
+- auto xrefs now provide an interface to deal with tricky active
+ characters (for |-)
+- external lib: improved compatibility with |fadings| libary.
+- replaced 'set terminal table; set output "<file>"' by 'set table "<file>"'
+ to maintain compatibility with the new gnuplot version.
+- pgfmanual.pdf: provided a 'make dist' target in version_for_pdftex/en
+ which activates automatic hyper references from codeexamples to key
+ declarations.
+ This utilizes larger memory limits, configured in
+ doc/generic/pgf/text-en/texmf.cnf
+- Added the 'small mindmap' style.
+- FPU: improved sanity checks and exception handling for the decompose
+ routines (pgfmathfloatgetexponent etc) and the number parser.
+ Added exception 'wrong lowlevel format'.
+- renamed 'text mark/style' to 'text mark style' and 'text mark/as node'
+ to 'text mark as node' (there are backw. compatibility hooks).
+ This should avoid confusion with '.unknown' handlers.
+- improved error recovery of external lib.
+- temporarily disabled the auto cross references -- it seems they compile
+ only with increased memory.
+- Installed preliminary version of automatic cross referencing tool.
+ Now, every codeexample is parsed for options and control sequences which
+ have been defined somewhere else in the document; pdf cross references are
+ built automatically as well.
+- configured links to be blue throughout the document.
+- external lib: added \tikzexternaldisable such that partial externalization is possible
+ although the document contains unsupported constructs (where environments
+ can't be identified without macro expansion).
+ The pgfmanual compiles with image externalization now.
+- added \pgfutilsolvetwotwoleq to solve 2x2 linear equation systems using
+ column pivotisation and gauss elim. Should result in improved quality
+ compared with \pgftransforminvert as internal equation solver
+- Defined \pgfdeclaregenericanchor to allow anchors which get the shape
+ name as argument. Only useful internally.
+- Fixed buggy treatment of white spaces in \jobname and 'plot function'
+ using \pgfutilpreparefilename.
+- Fixed bug item #2834141 [wrong reversed double arrows]
+- Fixed bug item #2834233 [shapes libraries]
+- Fixed bug item #2822265 [tangent coordinates not working in CVS]
+- Changed \rm to \tf in Context.
+- external lib: added 'mode=list and make'. Now, image externalisation
+ time can be reduced with 'make -j 2 -f mainfile.makefile'.
+- external lib: fixed treatment of long arguments in \tikz ... ; shortcut
+ command.
+- fixed white space bug in \pgfkeysdeactivatefamily
+- added \pgfmathfloatvalueof
+- added a '*' feature to '\pgfmathdeclarefunction' which overwrites
+ existing functions.
+- added '/tikz/no marks' key.
+- fixed typo in external lib documentation: the key is called 'figure name',
+ not 'file name'
+- added \pgfgettransformentries and \pgfsettransformentries.
+- updated the external library such that it deals with active characters
+ in the same way as without external library.
+- fixed bug in fpu cosh, sinh and tanh
+- provided two new aliases for key filters, added \pgfkeyssetfamily.
+- allowed numbers like '.9' in fpu.
+- Fix for signal shape.
+- Applied the patches for dvipdfmx driver,
+ pgf-doc-diff.version2cvs (2009-04-18) and
+ pgf-generic-diff.version2cvs (2009-04-19).
+- Restored processing of unknown keys in the predefined key filters 'and',
+ 'not', 'or' and 'false': it was not improvement...
+- fixed the sequence of arguments of
+ \pgfqkeysactivatefamiliesandfilteroptions and
+ \pgfqkeysactivatesinglefamilyandfilteroptions
+ in the reference manual.
+- key filtering: the composed key filter handlers 'not', 'and', 'false' and 'or' now
+ ignore unknown options and call the .unknown handlers.
+- pgfkeys: removed the experimental \pgfkeyssetdefaultpathforhandled method.
+ It doesn't fit into the clean interface for pgfkeys - and the problem of
+ default paths for handled keys can be solved better with the '/handler
+ config' method.
+- provided API function \pgfmathfloatifflags to simplify special cases in
+ FPU.
+- added (primitive) veclen implementation for FPU.
+- added cosh, sinh, tanh to FPU
+- fixed bug in external lib: empty lines in tikzpicture environments were not accepted
+ for some operating modes.
+- added \pgfqpointscale
+- added an optional argument count to 'optimize command away' in external
+ library.
+- added the |figure name| key to the externalization library
+- improved docs for externalization library
+- improved sanity checking of floating point comparison: does now also
+ yield results for infty/nan
+- added fix for precedence bug for unary minus (fix has been suggested by
+ Mark Wibrow, by mail conversation)
+- Replaced \z@ by 0pt for context.
+- external library: fixed the 'optimize' feature: pictures which won't be
+ exported could not be optimized away (although they should)
+- Replaced \toks@ and \voidb at x by \pgfutil at toks@ and
+ \pgfutil at voidb@x.
+- improved docs for .search also.
+- fixed initial value for 'domain' such that it really uses the default
+ samples=25.
+- Added patch for context color support in luatex.
+- improved the optimization facilities of the external library:
+ |optimize=false| will now properly restore any optimized material
+ when used in \tikzset
+- added |/handler config=all,only existing,full or existing|
+ configuration.
+- added |.search also| key handler as a simple implementation of key
+ search paths.
+- fixed default value for /tikz/samples at- there are no really 25
+ samples, not 26. I forgot to fix this last time when I fixed 'samples'
+- added |\pgfkeyssetdefaultpathforhandled| feature as improvement for
+ multiple key paths to pgfkeys. Reference documentation and an
+ application example is in the manual.
+- added 'mark=text' which draws arbitrary TeX content as plot marks to
+ plot mark library.
+- Added key 'define function' to define simple local functions.
+- Worked on dv stuff.
+- Index argument to array is automatically truncated to an
+ integer.
+- Text decoration can now be aligned along or fitted to a path.
+- Added key '/pgf/decoration/reverse path' to decorate a path
+ backwards.
+- the FPU deactivation command is now assembled once and for all during
+ its first usage.
+- Changed the "ellipse", "circle" and "arc" commands, so that
+ they take options. This gives a much clearer and more
+ flexible syntax. Naturally, the old syntax continues to work
+ as expected.
+- Documented svg stuff and added tikz interface. Most useful
+ for quickly converting svg pictures to tikz pictures...
+- fixed fpu 'round' method - it rounded mantissas instead of the complete
+ number before.
+- Fixed some math stuff
+- Renamed \pgfpathcurvebetweentime* to
+ \pgfpathcurvebetweentimecontinue.
+- Added svg.path lib. It allows one to directly use
+ the svg syntax for paths (like "M10 10 L 20 20"). Not yet
+ documented.
+- Added tutorial for mind/lecture maps.
+- implemented fpu factorial
+- if the fixed point library is activated, the fpu will be deactivated
+ automatically.
+- added draft for FPU documentation
+- fixed bug in fpu sqrt.
+- added logical commands to fpu.
+- fixed bug in fpu related to multi-argument-commands
+- provided feature to disable fpu manually.
+- added support for pgf 2.00 and the fpu (works only with additional
+ and technical work - the fpu file is not all which is needed)
+- added pow and greaterthan to FPU
+- fixed some FPU issues
+- fixed processing of '/tikz/domain' key - it produced N+1 samples instead
+ of N.
+- added further functions to fpu; improved sanity checking; fixed smaller
+ bugs related to fpu
+- improved internal floating point code: it is possible to change the
+ low-level representation with minimal number of code lines.
+- modified low-level floating point representation. All high level code
+ should be completely unaffected; the changes are backwards compatible.
+- Wrote first draft of a floating point unit library (fpu) similar in
+ spirit to the fixed point library of Mark Wibrow.
+- Moved all floating point math operations (functions) into the fpu
+ library. It is now necessary to include the library in order to use
+ floating point math operations. The number formatting methods are still
+ available as before.
+- added trigonometric functions to floating point unit.
+- Added \colorlet to ConTeXt stuff.
+- Worked some more on data visualization stuff. Still in
+ pre-alpha.
+- added \pgfmathfloatexp.
+- floating point macros now always use the basic pgf math methods for
+ mantisse computations, even if the fixed point library is active.
+- 'mark=none' is now equivalent with 'mark=' (disables plot marks).
+ The previous behavior was to issue \pgfuseplotmark{none} which is
+ equivalent to \relax (and wastes time).
+- Changed exp function code in
+ pgfmathfunctions.basic.code.tex. It is now *much* more
+ precise for negative values and also more precise for
+ positive values.
+- optimized \pgfmathfloattofixed for speed (although it introduces
+ redundand zeros)
+- Added '/pgf/image/include external' command key as public interface
+ to modify the '\includegraphics' command in image externalization routines.
+- fixed bug with |overlay| option and matrizes: now, cell pictures won't
+ collapse any more if the matrix has |overlay| enabled. However, the
+ matrix' bounding box won't contribute to the image as desired.
+- added support for active '!' characters (for example in blue!30!black
+ and french babel setting)
+- modified processing of 'domain' option: the argument is '\edef'ed such
+ that any potentially active ':' characters will be expanded to non-active
+ ones (avoiding errors in the following processing).
+- Fixed \pgfnodealias bug that caused chains to fail in matrices.
+- Added shading library, mainly containing the new color wheel
+ shading donated by Ken Starks.
+- More fixes for insertion of spaces.
+- Added square arrow send by
+ gvtjongahung at users.sourceforge.net.
+- Changed pgfutil-context.def so that driver detection should
+ work once more.
+- Fixed insertion of space when parsing exponents.
+- added int truncation to floating point unit.
+- added abs, abserror and relerror to floating point unit.
+- added sqrt for floating point unit, built on top of pgfmathsqrt.
+- Fixed the wrong lengths of support vectors for circles. Used to
+ be 0.555 (found by trial and error), while the correct value
+ is 4/3*(sqrt(2)-1) = 0.5522847, which gives much better
+ circles.
+ Thanks to Ken Starks for point this out.
+- Fixed rounded rectangle right arc bug.
+- Fixed missing treatment of 'assume math mode' in \pgfmathprintnumber'
+- Fixed missing switching off of auto anchors in positioning
+ library.
+- Fixed matrix/pdfsync incompatibility.
+- Fixed some parsing bugs with arrays.
+- Fix for parsing of arrays in TikZ coordinates.
+- Added number formatting option 'min exponent for 1000 sep'.
+- Fixed bug in math parser which inserted spaces into text
+ or picture.
+- added number formatting style 'sci superscript'
+ Example: formats the number 42 as 4.2^1 instead of 4.2 \cdot 10^1
+- Fixed bug "TikZ, the shadow library and ConTeXt MKIV
+ (LuaTeX)".
+- Fixed bug #2105132 for rounded rectangle.
+- Fixed bug #2044129 for chamfered rectangle.
+- Added \pgfpathcurvebetweentime.
+- Fixed problem with nodes on a line inside a picture that is
+ inside a node of another picture. Pictures will now always
+ start with "pos=.5" set.
+- Slight hack of decorations so that the input path can consist of a
+ single move to. This enables stuff like
+ \path [decoration={some decoration}, decorate] (4,5);
+- fixed small bug related to '@dec sep mark' and not-a-number in number
+ formatting routines.
+- Solutions for path intersections can now be sorted along either path.
+- \pgfintersectionsolutions is now a macro, not a count register.
+- fix for `Missing character...` warnings in logfile when using
+ foreach.
+- removed `trim integers' option from foreach as int function
+ can now be used.
+- Rewrote math parser. Anyone who relies on, or has hacked internal
+ parser or function macros, or has defined their own functions for
+ the parser will need to reconsult the code and/or documentation.
+- Files for functions definitions split (possibly permanantly) into
+ different files.
+- Scaling of results at the end of the parse is no longer the default
+ action. This doesn't break PGF or TikZ, but it may break user code
+ that depended on this scaling. To turn it back on use
+ \let\pgfmathpostparse=\pgfmathscaleresult.
+- Modifying existing functions or creating new functions must now be
+ done using \pgfmathdeclarefunction and \pgfmathredeclarefunction.
+- Single argument functions do not need parentheses, provided the
+ funtion is followed by a space, so sin 60 is the same as sin(60).
+ But! Functions have the highest precedence, so sin 60*\x is the
+ same as sin(60)*\x.
+- Added {} operators for array specification and [] operators for
+ array access - see docs for details.
+- added postfix ! factorial operator.
+- added c++/java style conditional e.g., \x > 10 ? 13 : 20.
+- added >=, <=, !=, prefix !, &&, || operators.
+- added atan2, log10, log2, e, int and frac functions.
+- adapted cosh, sinh and tanh from Martin Heller.
+- added lua-style random function for generating random integers.
+- added Mod function (note capital letter). Uses floored division
+ and is never negative.
+- min, max, veclen and pow can now be nested in any argument
+ position.
+- min and max can now take a variable number of arguments.
+- For compatability \pgfmathmax and \pgfmathmin still take two
+ arguments (although these can contain comma separated expressions).
+ However \pgfmathmin@ and \pgfmathmax@ now only take
+ one argument in the form \pgfmathmin@{{1}{2}{3}{4}{5}} (for 5
+ arguments).
+- added hex, Hex, bin, and oct functions. These functions will not
+ work properly if the post-parse scaling is turned back on.
+- 0 prefix for integers now specifies an octal number which is
+ automatically converted to base 10.
+- 0x or 0X prefix for integers now specifies a hexadecimal number,
+ which is automatically converted to base 10.
+- 0b or 0B prefix for integers now specifies a binary number,
+ which is automatically converted to base 10.
+- "" characters turn off parsing (!) for part of an expression.
+- added width, height, and depth functions for text e.g.,
+ width("Some text"), but as an expression is \edef'ed before
+ parsing other commands will have to be `protected` e.g.,
+ width("\noexpand\Huge Some text").
+- bugfix for tan and cot.
+- added '/tikz/external/export={true,false}' key for externalization
+ library.
+- added documentation for basic layer externalization and baseline option.
+- added 'showpos' key to number printing (and alias 'print sign').
+- fixed typo in pgfmathfloat.code.tex
+- added 'optimize command away=\macro' key to externalization library. It
+ allows to discard unnecessary and possibly expensive user macros during
+ export (unnecessary = not in selected picture).
+- Fixed bug in system layer path collecting. Very long paths
+ are now processed more efficiently (the bug disabled an optimization).
+- added "marker" positions into the output of number formatting routines
+ to find period positions (even if no period is typeset) and exponent
+ positions. Allows alignment within auxiliary routines.
+- Fixed dash phase bug.
+- Fixed missing library include in automata lib.
+- Added "align" option. "text ragged" and friends are now
+ deprecated. Text width need no longer not, but can, be
+ specified. The following now has the expected effect: \node
+ [draw,align=center] {Hello\\world.};
+- added \pgfqpointxy and \pgfqpointxyz to complement the "quick" point
+ commands in basic layer.
+- added 'every mark' style.
+- 'mark options' simply overwrites 'every mark' (consistent with its old
+ definition)
+- Finished circuit library and documentation (well, some
+ shapes still missing, but that's something users should
+ contribute).
+- the external library now handles active double quotes ",
+ single quotes ', and active semicolons ';' in its system call
+ correctly. Furthermore, \\ will expand to a normal
+ backslash. The initial system call now uses double quotes
+ for indows compatibility, it also contains the shell-escape
+ feature for gnuplot invocations.
+- Did some documentation of circuit lib.
+- Removed the separated documentation of the intersection
+ library and made this documentation part of the main
+ documentation.
+- The intersection cs is now deprecated, the documentation
+ is now only based on the intersection lib.
+- Added a "by" option so that "name intersections={of=A and
+ B,by={c,d,e}}" will create an alias c for intersection-1, d
+ for intersection-2 and e for intersection-3.
+- Renamed "path name" to "name path" in the intersection
+ lib. This is more consistent with "name intersections".
+- Minor changes on float stuff, wrote pgfmathfloatmultiply and
+ pgfmathfloatdivide on top of pgfmathmultiply and pgfmathdivide
+- Added `Fixed Point Arithmetic' library, which provides
+ a parsing interface to the fp package. Dealing with plotting
+ files still a bit crude.
+- This library means the manual now requires the fp pacakge
+ to compile.
+- Fixed floor function for negative numbers.
+- Fixed \pgfmathsetseed.
+- Font and group fix for external documentation.
+- Complete change of TikZ intersections (PGF unchanged).
+- Slight hack of the TikZ scopes library to permit local
+ path naming. Should work...
+- Continued with circuit library.
+- Introduced subdirectories inside the pgf library
+ directory and moved libs into them.
+ You may need to update your checkout.
+- The external library now typesets as horizontal material by issueing
+ \leavevmode. This fixes an inconsistency with the normal tikzpictures.
+- Added intersection library + documentation for
+ intersecting “named” paths.
+- Fixed bug in external library. Now, strings like '#1' occuring
+ somewhere in an image is collected correctly.
+- Removed new intersection stuff. Need to restart from scratch...
+- Started working on circuit library documentation.
+- Added PGF code and docs for intersections of two curves and
+ intersections of a line and a curve.
+- Fixed bug in foreach code when registers are used with dots
+ statement.
+- Created first version of circuit libraries for electrical
+ engineering (circuits.ee.*).
+- Added libraries so that ee circuits and logical circuits can
+ be accessed using the same interface. (circuits.logic.*)
+- The tikz lib shapes.gates.logic.* will no
+ longer be needed, the circuits.logic.* will replace them. (The
+ pgf libs shapes.gates.* are still used as before, however.)
+- Minor patch in shapes.gates.logic.US so that the .0 and .180
+ anchors of a not gate or a buffer gate are the same as the
+ input or output anchors.
+- All this is not documented, yet.
+- Worked some more on dv stuff, but nothing to "show", yet.
+- Fixed parsing bug in foreach code.
+- Added "rotate fit" key to fit library, so (e.g.) a rotated
+ rectangle can be fitted around nodes/coordinates.
+- Added documentation for tikz 'external' library.
+- created pgfexternalwithdepth.tex file to use the 'baseline' information.
+- improved some issues of the external library.
+- Added '/pgf/images/draft' option
+- Modified implementation of draft images to show the image file name
+ instead of the internal image name
+- Added tikz library 'external' which allows automatic or semiautomatic
+ export of each tikzpicture to pdf. Documentation is not yet ready.
+- Added self-contained latex package tikzexternal.sty to read those images
+ without tikz/pgf installed.
+- Added support for the 'baseline' option in \beginpgfgraphicnamed ... \endpgfgraphicnamed
+ by storing the box depth into a separate file.
+- Added first ideas for a circuit library.
+- Bugfixes in scoping behaviour.
+- Changed scoping rules for to path operation: Options are now
+ local. This may break existing code, but is much more
+ consistent with everything else and removes other problems.
+- Patched mindmap lib to account for these changed rules.
+- Added insert path option.
+- Deprecated "after node path". Use "append after command" and
+ "prefix after command" instead.
+- Moved datavisualization libraries to separate subdirectory.
+- Changed label and pin options once again, to allow more
+ flexibility. In particular, the angle can now be
+ omitted. Also, for rotated main nodes the anchors are now
+ chosen in more sensible ways.
+- Added tiny little turtle graphics library for fun.
+- Changed scoping rules for \foreach statement on a path: the
+ last coordinate is now persistent not only after the foreach
+ statement, but also between different iterations.
+- Changed positioning of "label" when you attach a label to a
+ transformed shape. The position is now absolute with respect
+ to the page, unless the "transform shape" option is used.
+- Fixed the bug fix for character checking in foreach.
+- Updates and fixes for new foreach code.
+- Fixed bug in new \foreach stuff that causes an error on
+ things like \foreach \i in {1,...,\foo}. If a list element
+ is a macro, no is-it-a-character check is done.
+- Checked in proposed \foreach extensions. Possibly the
+ extensions would be better contained in a pgflibrary...
+- list items can now be evaluated.
+- dots replacement is context sensitive.
+- sequences indicated by dots can be character sequences.
+- a list item can be “remembered” in the next iteration.
+- access to the number of the current item in the list is
+ provided.
+- Worked a bit on data visualization stuff.
+- Added '/pgf/number format/1000 sep' and 'dec sep' shortcut
+ styles which simply call 'set thousands separator' and 'set
+ decimal separator'. Those option are somewhat long...
+- Fixed the "local bounding box" option so that it honors the
+ "relevant for picture size"-if.
+- Fixed buggy "mid left" and "mid right" options.
+- Added "between positions" option to the "mark" option. This
+ makes it possible to create paths with "repeated arrows along
+ the path". This did not work before.
+- Added '/pgf/number format/assume math mode' to disable math checks.
+ This allows to assemble tabulars, apply \pgfmathprintnumber to each cell
+ and use the dcolumn package to align at decimal separators (no
+ documentation for that feature yet)
+- Fixed pgfpages in conjunction with everyshi.
+- Semantics of |/pgf/number format/fixed zerofill| changed: it now simply
+ sets a boolean which affects all numbers in fixed format; it does not
+ SET fixed format. The same holds for sci zerofill.
+- Provided \pgfmathprintnumberto macro in addition to
+ \pgfmathprintnumber.
+- Revised Lindenmayer system stuff. Documentation should
+ now be up to date.
+- Added 'xbar interval' and 'ybar interval' plot handlers.
+- Moved plot handler options to /pgf key tree.
+- added 'bar shift' option.
+- bar width option is now evaluated when needed.
+- Added documentation for plot handler library changes and for tikz-plot
+ interfaces.
+- Modified pgf manual macros: codeexamples section now employs pgfkeys,
+ xkeyval no longer required. Introduced style 'every codeexample' to
+ maintain compatibility and allow customization for users.
+- Added missing documentation of moveto-decoration.
+- Changed the processing of \pgflsystemstep. Now a TeX
+ dimension, it permits a symbol to shorten the step.
+- Added Lindemayer system drawing library.
+- Renamed the ranomization keys for the step and angle.
+- Updated the L-system docs.
+- Added documentation of oo-subsystem.
+- Started documentation of data visualization-subsystem.
+- Fixed hyperlink problem in dvipdfm(x)/xetex.
+- Fixed typos in Lindemayer system doc.
+- Added \pgfmathfloatadd, \pgfmathfloatsubtract and
+ \pgfmathfloatmultiplyfixed based on pgf's normal math parser
+- Added tests for float arithmetics
+- Added \pgfmathfloattoextentedprecision for 8-digit mantisse precision
+- Added documentation for these methods
+- Added basic layer input stream methods to set zero levels for [xy]comb/[xy]bar;
+ allows to start bars at different offsets than x=0 / y=0.
+- Added documentation for zero level streams.
+- Added "path picture" option, mostly for the implementation
+ of the corrected mindmap connecting bars.
+- Fixed buggy code of mindmap connect bars: Shading angles
+ where sometimes wrong and shading was sometimes at the wrong
+ position.
+- Completely rewrote management of pdf resources. This affects
+ pdftex, dvipdfm, dvipdfmx and xetex backends and all front
+ ends. They should now all work together in harmony, as far
+ as this is supported by them.
+- Completely rewrote driver detection in plain and context
+ mode.
+- dvipdfmx and xetex now use \special{pdf:literal direct},
+ which can *considerably* reduce file sizes (up to a factor
+ of 2).
+- Fixed compatability issue with old calc code.
+- documented '.lasttry' key handler
+- introduced documentation for key filtering routines (as \input section
+ in pgfmanual-en-pgfkeys.tex). Main section of pgfkeys not really updated
+ yet; I only removed the 'family limitation' item in the introduction.
+- Multiple fixes for signal shape.
+- added \pgfplotbarwidth and docs
+- used \pgfmathparse to assign \pgfsetplotbarwidth
+- added 'const plot mark right' to plot handler library to complete the
+ different variants of left/right connected/jump handlers.
+- Fixed parser for expressions that begin and end with braces.
+- Added \pgfmathapproxequalto operation and documentation below
+ \pgfmathequalto
+- Added some user-interface methods to floating point arithmetics
+- Added options
+ /pgf/number format/set decimal separator
+ /pgf/number format/set thousands separator
+ /pgf/number format/skip 0.
+- Added documentation for floating point arithmetics
+- Added documentation for number printing
+- Added PGF plot handlers to plot handler library:
+ - \pgfplothandlerxbar
+ - \pgfplothandlerybar
+ with parameter \pgfsetplotbarwidth{} and
+ - \pgfplothandlerconstantlineto
+ - \pgfplothandlerjumpmarkleft
+ - \pgfplothandlerjumpmarkright
+- Added Tikz-Plot handlers
+ - /tikz/xbar
+ - /tikz/ybar
+ with option '/tikz/bar width' and
+ - /tikz/const plot
+ - /tikz/jump mark left
+ - /tikz/jump mark right
+- Added documentation for new plot handlers to Tikz- and plot handler
+ section in manual
+- Documented changed double line handling.
+- Made some arrow tips work with double lines.
+- Added (not yet documented) "inner lines", which move the
+ double line mechanism from tikz to the basic layer. This
+ allows the definition of special arrow tips for double lines.
+- Added (not yet documented) new arrow tip "implies" using
+ this mechanism.
+- New version of rectangle split shape. Now supports horizontal
+ as well as vertical spliting. Also supports up to 20 parts.
+- Added pgfkeysfiltered.code.tex which provides key filtering
+ and provides key-selection utilities like xkeyvals families
+- changed pgfkeys.code.tex to '\input' pgfkeysfiltered.code.tex
+- Added \tikzaddtikzonlycommandshortcutlet and
+ \tikzaddtikzonlycommandshortcutdef to install shortcut commands at the
+ beginning of tikzpicture.
+- pgfkeys.code.tex: fixed incompatibility .try with .is choice
+- Fixed patterns in dvips mode (were broken).
+- Switched to everyshi in latex mode to hack into
+ \shipout. Wrote direct code to hack into \shipout in plain
+ mode. Hacking into \shipout in Context is still unclear.
+- Added space arrow.
+- Reimplemented parsing of operands.
+- Added cirlce solidus shape by Manuel Lacruz.
+- `curve control points` decoration no longer exists. It is
+ replaced by the `show path construction` decoration.
+- added code + docs for defining changable patterns.
+- Parser altered to access \pgfmathfloatparsenumber when
+ \ifpgfmathfloat is true (old interface to \pgfmathfloat deleted).
+- Added generic/pgf/math/pgfmathfloat.code.tex
+- Modified pgfmath.code.tex to include pgfmathfloat.code.tex
+- Added generic/pgf/testsuite/mathtest/pgfmathtestsuite.tex [dvipdfm/pdflatex]
+ which provides testing for pgfmathfloat.code.tex
+- Fixed minimum width handling in rounded rectangle shape.
+- Added key for rectangle split to ignore empty parts.
+- Extended \pgfshadecolortorgb to define macros for the
+ individual color components.
+- Added `curve control points` decoration for drawing
+ curve controls. NB: names/keys may change.
+- Fix for (some) “hidden” bugs: `Missing character:
+ There is no <char> in font nullfont!`. This is usually
+ only seen in log file. Fixed for star, circular sector
+ and math macros.
+- Fixed documentation "placment" replaced by "positioning"
+- Fixed ConTeXt page resource problem. (ConTeXt support is
+ still not as smooth as support of other formats)
+- Checked in some data visualization stuff, without any
+ documentation. Everything still likely to change
+ completely.
+- Moved module management to pgfutil.
+- Added support for simple oo-programming, not documented.
+- Fixed bug in pgfkeysaddvalue.
+- Fixed bug of stack leak in function shadings in postscript.
+- Fixed missing image inclusion documentation.
+- Fixed atan bug in documentation example.
+- Fixed missing dependency of chains--positioning library
+- Fixed missing dependency of mindmap--decorations library
+
+### Contributors
+
+- Christian Feuersaenger
+- Jin-Hwan Cho
+- Mark Wibrow
+
+## [2.00] - 2008-02-20 Till Tantau
+
+### Changed
+
+- Fixed "initial"/"accepting" distance bug.
+- Fixed wrong intersection computation bug.
+- Added "local bounding box" option for Fabien...
+- Finished chains and chain tutorial.
+- Fixed height of rounded rectangle shape.
+- Added "auto end on length" and "auto corner on length"
+ options to decorations.
+- Added "if input segment is closepath" option to
+ decorations.
+- Renamed "subpath" in decoration code to "inputsegment". In
+ the pdf-specification (and in the rest of the pgf manual) a
+ path is made up of subpath, which are started by movetos,
+ and these in turn are made up of segments. In decorations,
+ segments used to be called subpaths, which was too
+ confusing...
+- More renaming in chains, but its stabilizing now.
+- Started a tutorial on chains.
+- Moved chain part inside "positioning" into "chains"
+ library.
+- Renamed things in the chains library, yet again and added
+ branches.
+- Fixed bug with "xyz of" placements.
+- Renamed "placements" library to "positioning".
+- Renamed and changed all chain commands.
+- Added scopes library.
+- Renamed cap and join to line cap and line join (but old ones
+ are still available).
+- Patched Makefiles according to suggestion by Hans Meine.
+- Fixed bug: duplicate fading name in pgflibraryfadings.
+- Fixed bug: wrong size of functional shading in dvips.
+- Fixed bud: documentation a4paper setting.
+- Fixed bug: Manual now compiles with tex4ht once more.
+- Fixed bug: Manual now is hyperlinked also for dvipdfm.
+- Fixed bug: wrong size of all shadings in svg code.
+- Slight change in placement lib, default chain now has a
+ name.
+- Removed internal asin tables as asin is now calculated from
+ acos tables.
+- Misc. updates for shapes docs.
+- Changed fit library, so that nodes are now "completely"
+ fitted.
+- Changed tutorial so that fit library is now used.
+- Added placement library and documentation.
+- Fixes in snake compatibility code.
+- Added dvipdfmx support (identical to dvipdfm).
+- Fixed missing braces and color stack problem in
+ shapes.logic.IEC.
+- Patched (and hopefully fixed) hyperref support.
+- Made matrix inversion more precise.
+- Added tutorial for geometric constructions.
+- Fixed partway and intersection computations.
+- Added line to circle intersection.
+- Added through library (still very simple...).
+- Added computation of intersection of circles and tangent to
+ a circle.
+- Updated isosceles triangle shape. Positioning of node
+ contents improved. Added key so minimum width and height
+ can be applied independently
+- Fix for trapezium shape for minimum height. This fix may
+ “break” exisiting code by making any trapezium enlarged using
+ minimum height to appear slightly wider than before. But...
+- Added keys for trapezium so that minimum width and height
+ can be applied independently, or to just the `body` of the
+ trapezium.
+- Reimplemented shape `tape`. Anchors should behave a bit
+ better now.
+- Fixed problem with pin a relative coordinates.
+- Added `logic gate IEC symbol color` key to change color
+ for all symbols simultaneously.
+- Fix for loading US and IEC shape library separately.
+- Misc. updates for decoration docs.
+- Modified calc library. Working on documentation.
+- Added calc library and ($...$) notation for coordinates.
+- Reorganised logic shapes. Now two libraries:
+ shapes.gates.logic.US (for “American” gates) and
+ shapes.gates.logic.IEC (for rectangular gates).
+ Gates are now named `and gate US` or `and gate IEC` etc.
+ TikZ key `use US style logic gates` and `use IEC style
+ logic gates` set up styles so that (e.g.) `and gate`
+ becomes a synonym for `shape=and gate US`. See docs for
+ details.
+- Added decorations.markings.
+- Fixed pgfpatharc: Fractional angles are now handled
+ correctly.
+- Fixed incompatability with bm package: Changed hack to
+ \@@end to \AtEndDocument.
+- Changed things in the math engine to speed up things: First,
+ \pgfmath at returnone now uses simpler and faster code. Second,
+ some marshals in the internal math commands like
+ \pgfmathadd@ have been removed. This makes it necessary that
+ the second operand in a call to an internal math macro no
+ longer uses \pgf at x or \pgf at xa and I fixed the 3 places where
+ this was the case.
+- Added footprint decoration and merged Marks footprints.
+- Added buffering to the subpath mechanism. This speeds up
+ constructions of very long paths by a factor of 10 or more.
+- Fixed missing declaration of \iftikz at decoratepath in
+ tikz.code.tex.
+- Added logic shapes library. Includes AND gate, NAND gate,
+ OR gate, NOR gate, XOR gate, XNOR gate and NOT gate.
+- Fooled around with title page.
+- Changed TikZ path scoping rules: Scopes no longer affect the
+ last point on a path. This was a nuiseance before and became
+ a real problem with decorations.
+- Finished my move from snakes to decorations. Also finished
+ documentation.
+ We are now ready for a new release!
+- Removed \externalcode command for decoration states as
+ persistent pre/postcomputation stuff does a similar job.
+- Added \externalcode command for decoration states. Allows
+ code to be executed outside the TeX-group the state code
+ is executed in.
+- Split decoration lib into several libs.
+- Renamed lineto decoration to curveto decoration.
+- Renamed many keys of decorations and snakes to shorter
+ names.
+- Changed the tikz setting of decoration options.
+- No documentation yet.
+- Started merging snakes and decorations. Not yet finished.
+- (Partly) rewrote the tikz support for decorations. There is
+ now a "decorate" path command:
+ \draw ... decorate [decoration=zigzag] { (0,0) -- (1,2) };
+ This yields a much cleaner interface.
+- There is also a decorate=true/false option that causes the
+ whole path to be decorated.
+- Decorated path can now contain nodes.
+- Node paths can also be decorated now.
+- Fixed missing \pgftransformreset inside decoration
+ environment.
+- Changed the decoration documentation a bit. Still not quite
+ perfect...
+- Restructured the basic layer. There is a central core (which
+ got slightly larger) and "modules", which can be included
+ using \usepgfmodule. All the pgfbaseXXX files are now
+ obsolete and only included for the old ones for
+ compatibility.
+ The {pgf} package no longer includes the modules "pattern",
+ "snakes" and "decorations" by default. However, these
+ modules are loaded by their respective libraries, so,
+ normally, no one will notice.
+- Fix for minimum size in ellipse split shape.
+- Added decorations documentation.
+- Coordinates like (2,3cm) are now allowed. Has the same
+ effect as ([shift={(2,0)}]0pt,3cm), which is what everybody
+ would expect.
+- Moved tikz hacks inside tikzlibrarydecorations into
+ tikz.code.tex itself.
+- Fix for save stack overflow in decorations.
+- Renamed \pgfdecorate \endpgfdecorate, now \pgfdecoration
+ \endpgfdecoration. Makes it more consistent with...
+- Meta decorations! Automata that decorate the path with
+ decoration automata! Increased fancyness! Docs soon.
+- Removed a bunch of keys from \tikzlibrarydecorations as
+ not really necessary.
+- Changed shadow lib once more and added it to CVS.
+- Added decorations files. Docs to follow soon(ish).
+- Fix for `star point ratio` and `star point height`
+ keys in star shape.
+- Added copy shadow.
+- Added random steps snake.
+- Added shadow library, removed shadow shapes (no longer
+ needed).
+- Added preaction and postaction options (very useful).
+- Added transform canvas option.
+- Added scale around option.
+- Moved tikz.code.tex to tikz/tikz.code.tex
+- Moved .../libraries/pgflibrarytikzXXXX.code.tex to
+ .../frontendlayer/tikz/libraries/tikzlibraryXXXX.code.tex.
+- Fixed missing example bbs for dvipdfm.
+- Fixed buggy swirl shading.
+- Finished documentation switch from \itemoption to {key}.
+- Changed TikZ fading options. More consistent and easier to use,
+ now.
+- Added `ellipse split` shape.
+- Fixed spaces problem with external graphics.
+- Added [missing] option to supress children.
+- Reduced number of libs includes by {shapes} to geometric,
+ misc and symbol. Shapes is now more or less deprecated.
+- Added shadowed shapes.
+- Added pgfsys-xetex for native xetex support.
+- Added documentation hint on scoping inside \foreach.
+- Fixed bug [1620194] "tikz library mindmap requires trees"
+- Fixed bug [1787504] "Usage of \@namelet in xxcolor.sty clases with memoir."
+- Fixed bug [1809693] "background rectangle is scaled".
+- Added fadings.
+- Added functional shadings.
+- Fixed bug in double drawing with arrows.
+- Fix for all math functions with two arguments.
+- Fix for tikz when y-coordinate is a function within braces.
+- Fix for distance calculation in shape snake.
+- Added `cloud callout` shape.
+- cloud shape can now use (or ignore) `aspect` key.
+- More key updates/fixes for shapes.
+- Corrected minimum size of a diamond shape (was twice the
+ correct size -- this may break existing code, but that cannot
+ be avoided!).
+- Changed some more documentation from \itemoption to {key}s. Not
+ yet finished.
+- Updated math documentation. Code examples now consistent with
+ the rest of the manual.
+- Fixed hyperref-dvipdfm-problem.
+- Updated cloud shape for minimum size calculations.
+- Reimplemented rounded rectangle. Now supports concave arcs.
+- Removed all stuff for Fancy hyperlinked picture of shapes.
+- \foreach will now allow a macro name to be given as list
+ argument (as in \foreach \x in \mylist {...})
+- Fixed keys problem when .try is used with a comma.
+- Fixed shape snake for drawing to other pictures.
+- Added shapes `arrow box` shape, `rectangle callout` and
+ `ellipse callout`.
+- Fixed dvipdfm problem with hyperref.
+- pgfbasesnakes: changed length calculation and added angle calculation.
+- added `shape snake` to snake library.
+- added cylinder shape to geometric shapes.
+- renamed `bevelled rectangle`. Now called `chamfered rectangle`.
+- renamed pgfsavepgf at process. Now called pgfextract at process.
+- Fixed bug #1803811 gobbling of tokens after \pgfmathaddtocounter.
+- Fixed insertion of spaces after \pgfmath stuff.
+- Fixed bug #1811862.
+- Fix for cot and tan. Now correctly return negative values.
+- Added `...head indent` option for single and doube arrow
+ shapes (allows the arrowheads to look more “fancy”).
+- Updated tikzshapes.geometric and tikzshapes.symbols so
+ the incircle border construction can be used in TikZ
+ if libraries are loaded separately.
+- Misc. fixes and updates for shapes doc.
+- Fixed isosceles triangle, circular sector and circle split
+ for `text width` key.
+- Fixed star, cloud and rectangle shape for using anchors for
+ positioning.
+- New shapes:Rectangle split, rounded rectangle,
+ bevelled rectangle, tape, signal, single arrow and double arrow.
+- Fancy hyperlinked picture of all shapes added to shape lib. doc.
+- Updated math doc.
+- Fix for square root.
+- Fix for parsing negative box dimensions.
+- (Yet another) division version.
+- Added cloud shape.
+- Updated all shapes (and doc.) for pgfkeys.
+- Changed Kite key: Now use (e.g.) '/pgf/kite vertex angles=60 and 70' (see doc.)
+- Added keys /pgf/shape aspect and /pgf/shape aspect inverse, (but \pgfsetshapeaspect
+ and, TikZ option `apsect` are still there for compatability).
+- Updated diamond shape (and doc.) to use keys.
+- “Housekeeping” stuff (moved some macros around).
+- Trapezium shape updated. No longer uses left and right
+ extensions. Uses internal angles instead.
+ - Updated pgfkeys for shapes (not done \pgfsetshapeaspect for
+ diamond shape)
+ - Added new starburst shape to misc shapes.
+ - Updated all shapes to pgfkeys.
+- Added fitting library.
+ - Fixed parser for expressions beginning with groups
+ preceeded by signs e.g. -(4+3)
+ - This also fixes problem in TikZ when specifiying coordinates
+ contatining groups. Coordinates in the form (1, {(2+3)}) will
+ work even if there are spaces after the comma.
+- Started to use new pgfkeys also in pgf. In particular,
+ commands like \pgfsetshape... are now replaced by keys.
+ (Not yet finished.)
+- Added new geometric shape: `circular sector`.
+- Updated pgfbaseshapes.code.tex for saved macro support.
+- Added overlay functionality to \node.
+- Added pgfkeys and its documentation.
+- Updated all “new” geometric shapes: polygon, star, trapezium,
+ semicircle, isosceles triangle, kite, dart.
+- `isosceles triangle` and `simple isosceles triangle` combined
+ into one shape.
+- more accurate anchor positioning in polygon and star shapes.
+- Added `shape border uses incircle` option for supporting shapes.
+- Added `shape border rotate` option for supporting shapes.
+- Added support for sec, cosec and cot.
+- Fixed missing compatibility \pgfsincos
+- Fixed wrong \pgfmathsincos
+- Added semicircle shape.
+- Updated documentation for all new shapes.
+- Added support for savedmacros in \pgfdeclareshape.
+- Added trapezium shape.
+- Added support for “legacy” calc code (\real, \minof, \maxof, \ratio).
+- Fixed 'public' sqrt macro in \pgfmathoperations.code.tex
+- Added isosceles triangle shape: uses incircle, but supports arbitrary
+ rotation of border.
+- Added simple isosceles triangle shape: much tighter fit of node
+ contents, but restricted rotation of border.
+- Fixed text width problem in matrix of nodes.
+
+### Contributors
+
+- Mark Wibrow
+
+## [1.18] - 2007-01-18 Till Tantau
+
+- Added regular polygon and star shapes (by Mark Wibrow).
+- Added graphic externalization commands.
+- Added barycentric coordinate system.
+- Added direct TikZ plotting of function based on math engine.
+- Added math documentation into main documentation.
+- Added Mark Wibrow's math library.
+- Added calendar support.
+- Added matrix stuff.
+- Added automatic driver selection for xetex.
+- Added "growth parent anchor" option.
+- Fixed superfluous spaces in quick math parse code
+- Fixed superfluous \newboxes in math and image code
+- Fixed mth parser to recognize \wd\mybox.
+- Fixed wrong \pgfmathsetrandomseed
+- Fixed wrong \pgfmathradians@
+- Fixed problems with long mantissa and plain tex math code.
+- Fixed things so that \setlength works in pictures, once
+ more.
+- Fixed selectfont problem in pdfsys-dvipdfm.def
+- Fixed problem with lost lastx/lasty in foreach in TikZ.
+- Fixed snake+rectangle+transform problem.
+- Fixed rectangle+rounded corner problem.
+- Fixed postscrip eofill1 problem.
+- Fixed amsmath/pgf clash because of wrong definition of \:
+- Fixed size of hyperlinks inside nodes.
+- Fixed ConTeXt problem in pgfbaseplot.
+- Fixed .aux problems in plain and ConTeXt mode. Using .pgf as
+ extension now.
+
+## [1.10] - 2006-10-26 Till Tantau
+
+- Renamed \pgf at sys@pdf at mark to \pgfsyspdfmark.
+- Fixed the ConTeXt support so that it is usable (which is wasn't).
+
+## [1.09] - 2006-10-11 Till Tantau
+
+- Added \usepgflibrary and \usetikzlibrary to simplify adding
+ new libraries.
+- Added native ConTeXt support in the form of module
+ wrappers.
+- Added patterns.
+- Added crosses snake.
+- Added to and edge path operations.
+- Added to path library. In particular, this gives decent
+ curved paths.
+- Added tikz automata library.
+- Added tikz er diagram library.
+- Added tikz Petri net library.
+- Added tikz mindmap library.
+- Added access to nodes in other pictures (!).
+- Added extended baseline setting.
+- Added functionality to add new coordinate systems.
+- Added polar xy coordinate system.
+- Added diamond shape (!).
+- Added plot mark phase, repeat and indices.
+- Added text height and text depth options.
+- Added label and pin options.
+- Added automatic node placement (!).
+- Added pgfsys-dvi.def for pure dvi mode. Supports only
+ black and white drawing (not documented and not really usable).
+- Added 3d library (not documented and not really usable).
+- Cleared up license chaos.
+- Reorganized library documentation.
+- Removed pgflibraryautomata, use pgflibrarytikzautomata instead.
+- Fixed tree level option bug.
+- Fixed missing options for coordinates.
+- Fixed bug in TikZ parabola code.
+- Fixed bug in TikZ snake cycle code.
+- Fixed bug with empty list in pgffor
+- Fixed bug in code for insertion of dvips header specials.
+- Fixed bug in shading code (wrong bigpoint correction).
+- Fixed bug #1472666.
+- Fixed bug #1473255.
+- Fixed bug #1526175.
+- Fixed bug #1542512.
+- Fixed bug in TikZ transformation code for nested pictures.
+- Fixed patch #1443606.
+- Fixed path #1526178.
+
+## [1.01] - 2005-11-16 Till Tantau
+
+- Added textures support.
+- Added text opacity option.
+- Fixed bug in pgfbasesnakes.code.tex causing lot's of
+ 'missing = in nullfont' message in log file.
+- Fixed bug that made plain tex mode unusable.
+- Fixed missing pgfsys-vtex.def in FILES.
+- Fixed wrong box placements in compatibility mode.
+- Fixed SVG support to create legal xml.
+- Moved documentation to doc/generic/pgf.
+
+## [1.00] - 2005-10-23 Till Tantau
+
+- There have not been any real changes since 0.99.
+
+## [0.99] - 2005-10-11 Till Tantau
+
+- Added vtex support (finally!).
+- Added multi part mechanism to nodes.
+- Added very simple pgflibraryautomata.
+- Changed coordinate shape such that it now never produces a
+ text label.
+- Renamed \pgfshapebox to \pgfnodeparttextbox (made necessary
+ by the node part mechanism).
+
+## [0.98] - 2005-09-20 Till Tantau
+
+- Added transparency to PGF (quite nice...).
+- Added foreach option to child path operation (also nice...).
+- Fixed problem with \\ in centered text.
+- Fixed problem with hyperlinks in nodes.
+- Fixed wrong arrows in trees.
+
+## [0.97] - 2005-09-08 Till Tantau
+
+- Reorganised directory structure of documentation.
+- Added tree mechanism.
+- Added snake mechanism.
+- Added layer mechanism.
+- Added new shapes: cross out, strike out, forbidden sign.
+- Added some more documentation.
+- Added "none" drawing and filling colors.
+- Added pgflibrarytikzbackgrounds.
+- Changed syntax of \pgfqbox.
+- Changed syntax of several \pgfsys at xxxx commands.
+- Added SVG support / a tex4ht backend. (Complicated text
+ inside svg graphics is not supported well, but that's mainly
+ a shortcoming of the svg specification.)
+
+## 0.96 - 2005-07-06 Till Tantau
+
+This is a beta version. Version 1.00 will be the first stable
+version of TikZ/pgf.
+
+- Fixed spacing problem in dvips.
+- Changed syntax of plot and plot marks.
+- Changed syntax of ellipse and elliptical arc options.
+- Fixed baseline bug in tikz.
+- Fixed bug in pgfpages.
+- Introduced "every xxxx" styles, got rid of shape actions option.
+- Added "intersection of" syntax for coordinates.
+- Started revising the documentation.
+- Changed names of some pgfpages commands.
+- Changed syntax of parabola command.
+- Proof read documentation.
+
+## 0.95 - 2005-06-12 Till Tantau
+
+This is an *alpha* prerelease version. Syntax changes
+are still possible before the beta version. Version 1.00
+will be the stable version.
+
+### Changed (this is almost a new program):
+
+- Introduced three layers: system, basic, frontends.
+- Wrote two frontends: TikZ (*most* useful!) and pgfpict2e (a
+ demonstration).
+- Largely rewrote the basic layer.
+- Largely rewrote the system layer.
+- Completely rewrote the documentation.
+- Added two utilities: pgfpages and pgffor.
+- Made macro naming more consistent.
+- Added plain tex support.
+- Added dvipdfm support.
+- Restructured directory structure.
+- Zillions of small bugfixes.
+
+## 0.65 - 2004-10-20 Till Tantau
+
+- Fixed bug in pgfshade.sty that arises in conjunction with
+ calc.sty and latex+dvips.
+
+## 0.64 - 2004-10-08 Till Tantau
+
+- Fixed missing depth of \pgfnodebox.
+- Fixed bug that caused infinite stack loop with pictures inside
+ nodes.
+
+## 0.63 - 2004-07-08 Till Tantau
+
+- Added \pgfextractx, \pgfextracty, \pgfcorner.
+- Added some documentation on masks and images.
+- Fixed a somewhat obscure bug having to do with the modification
+ of \spaceskip.
+- \pgfex and \pgfem no loner needed. Use 1ex etc. once more.
+- calc.sty is now supported.
+
+## 0.62 - 2004-07-06 Till Tantau
+
+- Fixed problem in xxcolor with option "gray" and xcolor.
+- Switched to xcolor version 2.00.
+- Added eofill and eofillstroke commands.
+- Added option to shadings, so that they are automatically
+ recalculated upon color changes.
+- Changed names of example images to start with pgf.
+
+## 0.61 - 2004-04-07 Till Tantau
+
+- Added \pgfex and \pgfem dimensions.
+- Fixed bug that causes pgfshade to fail to work if xcolor
+ is called with option "gray".
+- Fixed PostScript code for radial shadings.
+- xxcolor now works with xcolor 1.10 (and only 1.10).
+
+## 0.60 - 2004-02-18 Till Tantau
+
+- Replaced some commands for the postscript code by shorter
+ versions for smaller file size.
+- Fixed bug in pgfbox command that caused incorrect kerning in
+ postscript output.
+- Fixed bug in pgfsys at defineimage that made page inclusion
+ impossible.
+- Fixed bug in pgfshading that did not reset dash patterns in
+ shadings in the PostScript version.
+- Spaces are now allowed inside the pgfpicture environment.
+- Added \pgfgrid command.
+
+## 0.50 - 2004-01-13 Till Tantau
+
+- Switched to version 1.06 of xcolor.
+- Core pgf no longer relies on xxcolor.
+- The syntax of the mechanism for choosing alternate images and
+ shadings is more flexible now. The syntax has been changed
+ (mainly, you now have to have a dot between the original name and
+ the alternate extension).
+- Some xxcolor commands have been removed.
+
+## 0.43 - 2003-12-02 Till Tantau
+
+- Fixed \normalcolor, so that it works also in preamble.
+
+## 0.42 - 2003-11-20 Till Tantau
+
+- Documented masks.
+- Fixed bug in pgf.sty for nested pictures.
+
+## 0.41 - 2003-11-18 Till Tantau
+
+- Added masks (not yet documented).
+
+## 0.40 - 2003-11-12 Till Tantau
+
+- Changed syntax of \pgfdeclareimage. Uses key=value scheme
+ now. All parameters may now be omitted.
+- Added \pgfimage command.
+- Option for selecting a specific page from an image file.
+- Fixed bug in xxcolor.sty having to do with \@ifempty command.
+- Reworked the formatting of the user's guide.
+
+## 0.34 - 2003-10-29 Till Tantau
+
+- Shadings now work together with color mix-ins.
+- Shadings can now take color names as parameters.
+
+## 0.33 - 2003-10-24 Till Tantau
+
+- Fixed problem with missing \leavevmode in \pgfuseimage.
+- Reworked code for image inclusion.
+- "Draft" option is now supported. Supresses reading of images.
+- Added xxcolor package.
+- pgfpictures will now inherit the color from their surroundings.
+
+## 0.32 - 2003-10-20 Till Tantau
+
+- Updated installation procedure information.
+
+## 0.31 - 2003-09-18 Till Tantau
+
+- One parameter for \pgfdeclareimage may now be omitted. It will
+ be computed automatically.
+
+## 0.30 - 2003-08-21 Till Tantau
+
+- Created ChangeLog
+- Added pgfshade.sty
+
+[3.1.10]: https://github.com/pgf-tikz/pgf/compare/3.1.9a...3.1.10
+[3.1.9a]: https://github.com/pgf-tikz/pgf/compare/3.1.9...3.1.9a
+[3.1.9]: https://github.com/pgf-tikz/pgf/compare/3.1.8b...3.1.9
+[3.1.8b]: https://github.com/pgf-tikz/pgf/compare/3.1.8a...3.1.8b
+[3.1.8a]: https://github.com/pgf-tikz/pgf/compare/3.1.8...3.1.8a
+[3.1.8]: https://github.com/pgf-tikz/pgf/compare/3.1.7a...3.1.8
+[3.1.7a]: https://github.com/pgf-tikz/pgf/compare/3.1.7...3.1.7a
+[3.1.7]: https://github.com/pgf-tikz/pgf/compare/3.1.6a...3.1.7
+[3.1.6a]: https://github.com/pgf-tikz/pgf/compare/3.1.6...3.1.6a
+[3.1.6]: https://github.com/pgf-tikz/pgf/compare/3.1.5b...3.1.6
+[3.1.5b]: https://github.com/pgf-tikz/pgf/compare/3.1.5a...3.1.5b
+[3.1.5a]: https://github.com/pgf-tikz/pgf/compare/3.1.5...3.1.5a
+[3.1.5]: https://github.com/pgf-tikz/pgf/compare/3.1.4b...3.1.5
+[3.1.4b]: https://github.com/pgf-tikz/pgf/compare/3.1.4a...3.1.4b
+[3.1.4a]: https://github.com/pgf-tikz/pgf/compare/3.1.4...3.1.4a
+[3.1.4]: https://github.com/pgf-tikz/pgf/compare/3.1.3...3.1.4
+[3.1.3]: https://github.com/pgf-tikz/pgf/compare/3.1.2...3.1.3
+[3.1.2]: https://github.com/pgf-tikz/pgf/compare/3.1.1...3.1.2
+[3.1.1]: https://github.com/pgf-tikz/pgf/compare/3.1...3.1.1
+[3.1]: https://github.com/pgf-tikz/pgf/compare/3.0.1...3.1
+[3.0.1]: https://github.com/pgf-tikz/pgf/compare/version-3-0-0...3.0.1
+[3.0.0]: https://github.com/pgf-tikz/pgf/compare/2.10...version-3-0-0
+[2.10]: https://github.com/pgf-tikz/pgf/compare/version-2-00...2.10
+[2.00]: https://github.com/pgf-tikz/pgf/compare/version-1-18...version-2-00
+[1.18]: https://github.com/pgf-tikz/pgf/compare/version-1-10...version-1-18
+[1.10]: https://github.com/pgf-tikz/pgf/compare/version-1-09...version-1-10
+[1.09]: https://github.com/pgf-tikz/pgf/compare/version-1-01...version-1-09
+[1.01]: https://github.com/pgf-tikz/pgf/compare/version-1-00...version-1-01
+[1.00]: https://github.com/pgf-tikz/pgf/compare/version-0-99...version-1-00
+[0.99]: https://github.com/pgf-tikz/pgf/compare/version-0-98...version-0-99
+[0.98]: https://github.com/pgf-tikz/pgf/compare/tag-version-0-97...version-0-98
+[0.97]: https://github.com/pgf-tikz/pgf/releases/tag/tag-version-0-97
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/CHANGELOG.md
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/CTAN_NOTES.md
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/CTAN_NOTES.md (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/CTAN_NOTES.md 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,4 @@
+The release files are signed using a detached signature. You can obtain the
+signature from the GitHub release page
+
+ https://github.com/pgf-tikz/pgf/releases/download/3.1.10/pgf_3.1.10.ctan.flatdir.zip.sig
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/CTAN_NOTES.md
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Deleted: trunk/Master/texmf-dist/doc/generic/pgf/ChangeLog
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/ChangeLog 2023-01-15 20:55:58 UTC (rev 65552)
+++ trunk/Master/texmf-dist/doc/generic/pgf/ChangeLog 2023-01-15 20:58:27 UTC (rev 65553)
@@ -1,5992 +0,0 @@
-2021-05-15 Henri Menke
-
- - Release 3.1.9a
-
-2021-05-08 Henri Menke
-
- - Merge pull request #1012 from TorbjornT/incontrol_doc
-
-2021-05-08 Torbjørn T
-
- - Specify that relative coord is to end point
-
-2021-04-12 Henri Menke
-
- - Merge pull request #1005 from kechtel/patch-1
-
-2021-04-12 Christoph Kecht
-
- - Fix typo in guidelines on graphics
-
-2021-04-11 Henri Menke
-
- - CI: Expire the cache
-
-2021-04-11 Henri Menke
-
- - Merge pull request #1004 from michal-h21/patch-1
-
-2021-04-11 Michal Hoftich
-
- - Update pgfsys-dvisvgm4ht.def
-
-2021-04-03 Henri Menke
-
- - Merge pull request #1003 from tknuth/patch-1
-
-2021-04-03 Dr. Tobias Knuth
-
- - fixed typo
-
-2021-04-02 muzimuzhi
-
- - Merge pull request #977 from muzimuzhi/pgf-point-node-border
-
-2021-04-01 muzimuzhi
-
- - adjust comments
-
-2021-01-16 muzimuzhi
-
- - \pgfpointshapeborder: measure by distance < 0.02pt
-
-2021-01-14 muzimuzhi
-
- - \pgfpointshapeborder: more doc words
-
-2021-01-13 muzimuzhi
-
- - doc: use paired `` and ''
-
-2021-01-13 muzimuzhi
-
- - \pgfpointshapeborder: doc new behavior
-
-2021-01-13 muzimuzhi
-
- - pgf/shapes: add warning when \pgfpointshapeborder gives up
-
-2021-01-10 muzimuzhi
-
- - pgf/shapes: improve \pgfpointshapeborder, #908
-
-2021-03-25 Henri Menke
-
- - Merge pull request #1002 from muzimuzhi/edef-keys
-
-2021-03-24 muzimuzhi
-
- - pgfkeys: enhance edef keys, #305
-
-2021-03-05 Henri Menke
-
- - fixup! build: copy the README into the TDS archive
-
-2021-03-02 Henri Menke
-
- - build: copy the README into the TDS archive
-
-2021-03-02 Henri Menke
-
- - Release 3.1.9
-
-2021-03-02 Henri Menke
-
- - Merge pull request #996 from muzimuzhi/dvips-blend-mode
-
-2021-02-28 muzimuzhi
-
- - dvips: fix displacement after blend group, #995
-
-2021-02-24 muzimuzhi
-
- - Revert "syntax is similar to METAPOST not METAFONT"
-
-2021-02-23 muzimuzhi
-
- - Merge pull request #994 from itmm/master
-
-2021-02-22 Timm Knape
-
- - syntax is similar to METAPOST not METAFONT
-
-2021-02-14 Henri Menke
-
- - Merge pull request #992 from joel-coffman/dev/fix-code-2-args-documentation
-
-2021-02-13 Joel Coffman
-
- - Correct documentation for .code 2 args second arg
-
-2021-01-22 Henri Menke
-
- - Merge pull request #987 from muzimuzhi/doc-typo
-
-2021-01-22 muzimuzhi
-
- - doc: fix typo #986
-
-2021-01-14 muzimuzhi
-
- - Merge pull request #981 from muzimuzhi/fix-tikz at handle
-
-2021-01-14 muzimuzhi
-
- - Apply suggestions from code review
-
-2021-01-13 muzimuzhi
-
- - tikz: fix uses of \pgfutil at switch
-
-2021-01-11 Henri Menke
-
- - Merge pull request #979 from muzimuzhi/doc-install-only
-
-2021-01-11 muzimuzhi
-
- - doc/fpu: fpu: mark /pgf/fpu/install only as not experimental
-
-2020-12-25 Henri Menke
-
- - Fix and document dim() #964
-
-2021-01-04 Henri Menke
-
- - Merge pull request #976 from muzimuzhi/tikz-math
-
-2021-01-05 muzimuzhi
-
- - tikz/math: gobble spaces between for list and loop body
-
-2021-01-04 Henri Menke
-
- - Merge pull request #970 from muzimuzhi/reset-tikz at expandcount
-
-2021-01-05 muzimuzhi
-
- - tikz: retry to handle \relax on path #966
-
-2021-01-04 Henri Menke
-
- - tikz/calendar: switch over \pgf at let@token in \tikz at lib@cal at handle
-
-2021-01-02 Henri Menke
-
- - Merge pull request #973 from schtandard/spurious_show
-
-2021-01-02 schtandard
-
- - Remove a spurious \show
-
-2021-01-02 Henri Menke
-
- - Merge pull request #972 from alisaaalehi/patch-1
-
-2021-01-02 Ali Salehi
-
- - doc: fix typo
-
-2021-01-01 Henri Menke
-
- - tikz: switch over \pgf at let@token in \tikz at handle
-
-2020-12-29 Henri Menke
-
- - tikz: improve \tikz at expandcount handling
-
-2020-12-29 muzimuzhi
-
- - tikz: reset \tikz at expandcount more frequent #969
-
-2020-12-27 Henri Menke
-
- - Release 3.1.8b
-
-2020-12-27 Henri Menke
-
- - Revert "tikz: handle \relax and frozen \relax on path #966"
-
-2020-12-27 Henri Menke
-
- - Release 3.1.8a
-
-2020-12-25 Henri Menke
-
- - fixup! Preserve coordinate relativity across ..
-
-2020-12-25 Henri Menke
-
- - Release 3.1.8
-
-2020-12-03 Henri Menke
-
- - CI: Use GitHub Actions from pgf-tikz/actions
-
-2020-12-01 Henri Menke
-
- - Remove empty or outdated files
-
-2020-12-25 Henri Menke
-
- - Preserve coordinate relativity across ..
-
-2020-12-22 Henri Menke
-
- - Merge pull request #967 from muzimuzhi/handle-relax
-
-2020-12-22 Henri Menke
-
- - fixup! doc: Add note on expandsion of path operations #966
-
-2020-12-22 muzimuzhi
-
- - Remove spurious spaces, terminate \advance in time
-
-2020-12-22 muzimuzhi
-
- - tikz: handle \relax and frozen \relax on path #966
-
-2020-12-21 Henri Menke
-
- - doc: Add note on expandsion of path operations #966
-
-2020-12-17 Henri Menke
-
- - Merge pull request #961 from muzimuzhi/improve-doc
-
-2020-12-18 muzimuzhi
-
- - doc: relation of /.code & /.initial will remain
-
-2020-12-17 Henri Menke
-
- - Only force signed releases #962
-
-2020-12-18 muzimuzhi
-
- - doc: clarify /.code keys don't respect /.initial #654
-
-2020-12-18 muzimuzhi
-
- - Added doc for \pgfpointtransformed #844
-
-2020-12-17 Henri Menke
-
- - Merge pull request #959 from muzimuzhi/improve-doc
-
-2020-12-15 muzimuzhi
-
- - doc: clarify path or full key start with slash #904
-
-2020-12-17 Henri Menke
-
- - Merge pull request #956 from muzimuzhi/improve-doc
-
-2020-12-15 muzimuzhi
-
- - pgfmathdeclarerandomlist: improve doc and code comment
-
-2020-12-14 Henri Menke
-
- - Merge pull request #955 from Ordoviz/master
-
-2020-12-14 Henri Menke
-
- - pgfmathrandominteger: reordering of arguments incomplete #954
-
-2020-12-12 Henri Menke
-
- - fpu: mark /pgf/fpu/install only as not experimental
-
-2020-11-30 Lennard Hofmann
-
- - Fix typos in manual
-
-2020-12-11 Henri Menke
-
- - Merge branch 'PimpLuaExamples' of https://github.com/Mo-Gul/pgf
-
-2020-12-11 Henri Menke
-
- - docs: set terminal table -> set table #952
-
-2020-06-21 Stefan Pinnow
-
- - correct codeexample preamble entries in Lua file
-
-2020-06-21 Stefan Pinnow
-
- - made some "normal" `codeexample`s compile again (when extracted)
-
-2020-06-21 Stefan Pinnow
-
- - just added end line commata at the end of values/styles
-
-2020-06-18 Stefan Pinnow
-
- - added hints which libraries need to be loaded as well to make the example in `pgfmanual-en-tikz-graphs.tex` work closes issue #755)
-
-2020-12-01 Henri Menke
-
- - Release 3.1.7a
-
-2020-11-29 Henri Menke
-
- - Assisted release script
-
-2020-11-29 Henri Menke
-
- - Attempt uploading to CTAN in CI
-
-2020-11-29 Henri Menke
-
- - Attempt signing builds in CI
-
-2020-11-29 Henri Menke
-
- - Protect possible parentheses in computing looseness #947
-
-2020-11-27 Henri Menke
-
- - Superficial fix for hook ordering problem
-
-2020-11-27 Henri Menke
-
- - Add pgf-parametric-example-cut.table
-
-2020-11-21 Henri Menke
-
- - Release 3.1.7
-
-2020-11-21 Henri Menke
-
- - CI: Create release from tag
-
-2020-11-21 Henri Menke
-
- - pgffor: new expand list option
-
-2020-11-06 Henri Menke
-
- - Fix spurious spaces #946
-
-2020-11-03 Henri Menke
-
- - Merge pull request #943 from agrahn/offpagefading
-
-2020-10-29 Alexander Grahn
-
- - hiding smask in the PS viewer
-
-2020-10-24 Henri Menke
-
- - Merge pull request #940 from Ordoviz/patch-1
-
-2020-10-24 Henri Menke
-
- - Merge pull request #941 from Skillmon/improve-parser-doc
-
-2020-10-23 Jonathan Spratte
-
- - macros are 'letters' for pgfparser as well
-
-2020-10-23 Jonathan Spratte
-
- - fix comment in example code
-
-2020-10-23 Jonathan Spratte
-
- - minor change to pgfparserletter
-
-2020-10-23 Jonathan Spratte
-
- - minor change to pgfparserdefunknown
-
-2020-10-23 Jonathan Spratte
-
- - minor change to pgfparserlet
-
-2020-10-23 Jonathan Spratte
-
- - more info for pgfparserdef
-
-2020-10-23 Jonathan Spratte
-
- - typos
-
-2020-10-19 Jonathan Spratte
-
- - more precise pgfparserreinsert description
-
-2020-10-23 Lennard Hofmann
-
- - [doc] Fix typo
-
-2020-10-12 Henri Menke
-
- - Fix trailing else problem in pgfkeys
-
-2020-10-12 Henri Menke
-
- - Merge branch 'pgfkeys-small-fixing' of https://github.com/muzimuzhi/pgf
-
-2020-10-12 Henri Menke
-
- - Always place shadings in TLT in LuaTeX #934
-
-2020-10-11 Andras Deak
-
- - DOC: typo fix in en-tikz-actions
-
-2020-10-11 muzimuzhi
-
- - pgfkeys: fix spurious spaces in "/errors" keys
-
-2020-10-11 muzimuzhi
-
- - pgfkeys: in "/.add code", ensure `/. at cmd` is long
-
-2020-10-04 Henri Menke
-
- - Random shifts to fix output routine shenenigans #928
-
-2020-10-04 Henri Menke
-
- - Revert "pgfkeys: make `.initial` compatible with `.code`, fix #654"
-
-2020-10-03 muzimuzhi
-
- - doc: various minor fix
-
-2020-10-03 muzimuzhi
-
- - doc: minor fix, #930
-
-2020-10-01 Henri Menke
-
- - Release 3.1.6a
-
-2020-10-01 Henri Menke
-
- - Revert "Invert transform before assigning intersection #889"
-
-2020-10-01 Henri Menke
-
- - Omit missing library and fix spurious space
-
-2020-09-30 Henri Menke
-
- - Fix spurious spaces in pgfmathparse with fpu #508 #915
-
-2020-09-28 Henri Menke
-
- - Revert "Added sanity check for the catcode of '$' to avoid incompatibilities with onlyamsmath package"
-
-2020-09-28 Henri Menke
-
- - Release 3.1.6
-
-2020-09-28 Henri Menke
-
- - Activate CTAN zip action
-
-2020-09-28 Henri Menke
-
- - Adapt shipout to new hook management #900 #923
-
-2020-09-24 Alexander Grahn
-
- - improved functional shading (dvips); \pgfsys at definemask fixed
-
-2020-09-20 PhelypeOleinik
-
- - More missing args to \pgfmath at error
-
-2020-09-20 PhelypeOleinik
-
- - Add missing args to \pgfmath at error
-
-2020-09-20 PhelypeOleinik
-
- - Replace \pgfmath at PackageError by \pgfmath at error
-
-2020-09-20 PhelypeOleinik
-
- - Use \pgfmath at tonumber in pgfmath (fixes #924)
-
-2020-09-09 Henri Menke
-
- - Merge branch 'master' of https://github.com/erihe251/pgf
-
-2020-09-09 Erik
-
- - fixed typo notes -> nodes
-
-2020-09-05 Henri Menke
-
- - Merge branch 'pgfkeys-doc' of https://github.com/muzimuzhi/pgf into master
-
-2020-09-05 Henri Menke
-
- - Remove unused `.expand two once' #918
-
-2020-09-05 muzimuzhi
-
- - [doc] pgfkeys: update examples of ".search also"
-
-2020-09-05 muzimuzhi
-
- - [doc] pgfkeys: document \pgfkeyssetevalue
-
-2020-09-05 muzimuzhi
-
- - [doc] pgfkeys: unify order of ".code" and ".style"
-
-2020-09-04 muzimuzhi
-
- - [doc] pgfkeys: typo
-
-2020-07-07 Henri Menke
-
- - Invert transform before assigning intersection #889
-
-2020-09-03 muzimuzhi
-
- - pgfsys-xetex: sync with upstream, #909
-
-2020-09-03 Henri Menke
-
- - Provide a convenient workaround for #508 (also #915)
-
-2020-08-30 muzimuzhi
-
- - pgfkeys: avoid \pgfkeysalso used in ".search also"
-
-2020-08-31 Henri Menke
-
- - Fix CI badge; add PR template
-
-2020-08-29 Henri Menke
-
- - Merge branch 'ps3shading-fading-imgmask-dvips-3' of https://github.com/agrahn/pgf
-
-2020-08-29 Henri Menke
-
- - Merge branch 'fix-pgfkeys' of https://github.com/muzimuzhi/pgf
-
-2020-08-29 muzimuzhi
-
- - pgfkeys: make `.initial` compatible with `.code`, fix #654
-
-2020-08-29 muzimuzhi
-
- - pgfkeys: specially treat `.style n args={1}{...}`, fix #912
-
-2020-08-28 Alexander Grahn
-
- - fixing code lines with assignments, as requested in the review
-
-2020-08-27 Alexander Grahn
-
- - Merging upstream changes into ps3shading-fading-imgmask-dvips-3
-
-2020-07-02 Henri Menke
-
- - Switch to GitHub Actions
-
-2020-08-16 Alexander Grahn
-
- - optimizing sampling procedure (funct shadings, dvips)
-
-2020-08-13 Alexander Grahn
-
- - merging recent upstream changes
-
-2020-08-13 Alexander Grahn
-
- - addressing requested changes from review
-
-2020-08-12 Henri Menke
-
- - doc: correct some typos
-
-2020-08-02 muzimuzhi
-
- - [doc] pgffor: replace \diameter with \r
-
-2020-08-02 muzimuzhi
-
- - [doc] fix typo, s/to/two/ in "between to point"
-
-2020-08-07 Alexander Grahn
-
- - PS-3 functional shading for dvips
-
-2020-08-03 Alexander Grahn
-
- - PS-3 shadings, opacity masks (fadings) and image masks for dvips
-
-2020-08-02 Henri Menke
-
- - doc: remove reference to old "-to" arrow
-
-2020-07-22 Henri Menke
-
- - Merge branch 'context-module-wrap' of https://github.com/LeonardKoenig/pgf
-
-2020-07-20 Henri Menke
-
- - Update build instructions [ci skip]
-
-2020-07-17 Leonard König
-
- - context: Fix 'module wrapping error'
-
-2020-07-10 Henri Menke
-
- - Merge branch 'minor-change' of https://github.com/muzimuzhi/pgf
-
-2020-07-10 Henri Menke
-
- - Fix critical typo in documentation
-
-2020-07-08 muzimuzhi
-
- - [doc] enhanced consistency
-
-2020-07-08 muzimuzhi
-
- - [doc] fix wrong description for \pgfmathsubtract
-
-2020-07-08 muzimuzhi
-
- - fix typo in comment
-
-2020-06-18 Stefan Pinnow
-
- - Add library loading hints #755
-
-2020-06-16 thinbold
-
- - Fixed typo: of -> off
-
-2020-07-03 Erik
-
- - Fixed typo, if -> of
-
-2020-07-03 Alexander Grahn
-
- - gs-9.53 transparency; blend mode; transparency groups
-
-2020-06-30 Henri Menke
-
- - Install pgfmanual-en-macros.tex
-
-2020-06-29 Henri Menke
-
- - Revert "- removed some trailing spaces and replaced TABs with spaces"
-
-2020-06-28 Henri Menke
-
- - Merge branch 'doc-fix-pdf-dest' of https://github.com/muzimuzhi/pgf
-
-2020-06-28 Henri Menke
-
- - Fix pt/bp confusion in dvipdfmx driver #888
-
-2020-06-28 muzimuzhi
-
- - [doc] rename counter, "dummy" -> "pgfmanualentry"
-
-2020-06-27 muzimuzhi
-
- - [script] use value of "maxruns" in not-converge message
-
-2020-06-27 muzimuzhi
-
- - [doc] move two key labels inside "key" env
-
-2020-06-27 muzimuzhi
-
- - [doc] fix typo
-
-2020-06-27 muzimuzhi
-
- - [doc] fix wrong pdf dest
-
-2020-06-25 muzimuzhi
-
- - [doc] external lib
-
-2020-06-17 Henri Menke
-
- - transform shape clashes with label position #843
-
-2020-06-17 Henri Menke
-
- - Add options to Lua examples #640 #839
-
-2020-06-17 Henri Menke
-
- - Resolve clash of object ids in SVG #876
-
-2020-06-17 Henri Menke
-
- - Decorations are implicitly sloped #748
-
-2020-06-16 Ilhan Polat
-
- - DOC:matrix:Use only default colorsin example
-
-2020-06-13 Ilhan Polat
-
- - DOC:matrix: Adjust the column color in example
-
-2020-06-16 Ilhan Polat
-
- - Fix merge conflicts
-
-2020-06-16 Henri Menke
-
- - Remove bbox library
-
-2020-06-15 Stefan Pinnow
-
- - followed @joulev's suggestion
-
-2020-06-13 Mo-Gul
-
- - Update doc/generic/pgf/text-en/pgfmanual-en-library-fpu.tex
-
-2020-06-13 Mo-Gul
-
- - Update doc/generic/pgf/text-en/pgfmanual-en-library-decorations.tex
-
-2020-06-12 Stefan Pinnow
-
- - added `codeexample` plus some text to the `decorations` library manual as suggested in pull request #872
-
-2020-06-12 Stefan Pinnow
-
- - removed braces as suggested in pull request #872
-
-2020-06-05 Stefan Pinnow
-
- - "improved" colors given in the `codeexample` of pull request #871
-
-2020-06-01 Stefan Pinnow
-
- - added reference from `matrix` library to "basic" matrix section
-
-2020-05-30 Stefan Pinnow
-
- - - adapted formatting in `pgf/text-en/pgfmanual-en-tikz-matrices.tex` - changed order of mentioned libraries so they fit the order of references in the next sentence in `pgf/text-en/pgfmanual-en-tikz-shapes.tex`
-
-2020-06-01 Henri Menke
-
- - Little improvements for matrix/inner style
-
-2020-06-04 Ilhan Polat
-
- - Convert quotes to TeX quotes
-
-2020-06-04 Ilhan Polat
-
- - DOC:matrix: Add example for every row/col keys
-
-2020-05-29 Henri Menke
-
- - Configurable matrix inner styles #867
-
-2020-05-28 Henri Menke
-
- - Add key visualize as smooth cycle #823
-
-2020-05-28 Henri Menke
-
- - /.style -> /.code #808
-
-2020-05-26 Henri Menke
-
- - Documentation for /pgf/fpu/install only
-
-2020-05-26 Henri Menke
-
- - New key `/pgf/fpu/install only' #861
-
-2020-05-26 Henri Menke
-
- - Merge branch 'new-unit-px' of https://github.com/muzimuzhi/pgf
-
-2020-05-26 Henri Menke
-
- - Remove \pgfkeys at ifcsname #863
-
-2020-05-26 muzimuzhi
-
- - pgfmathparser.code.tex: add pdfTeX/LuaTeX unit px
-
-2020-05-25 Henri Menke
-
- - use fpu reciprocal is still under consideration
-
-2020-05-24 Arkonos
-
- - fixing typo in pgfmanual-en-tutorial-Euclid.tex
-
-2020-05-24 tallmarmot
-
- - Update bbox library #856
-
-2020-05-24 Henri Menke
-
- - Shift before rotate #859
-
-2020-05-24 Henri Menke
-
- - Fix undefined control sequence in \pgfutil at pushedmacro
-
-2020-05-23 Henri Menke
-
- - Revert "Execute size hook unconditionally #795"
-
-2020-05-22 muzimuzhi
-
- - Another improvement for #855
-
-2020-05-19 Mo-Gul
-
- - corrected typo in patch of issue #848
-
-2020-05-19 muzimuzhi
-
- - Improved fix for #855
-
-2020-05-18 Henri Menke
-
- - If prefixed name does not exist, look up global name #846
-
-2020-05-18 Henri Menke
-
- - Fix broken \foreach initializer #855
-
-2020-05-18 Henri Menke
-
- - Check if set is defined #853
-
-2020-05-18 Henri Menke
-
- - Forbid some more operations in patterns #852
-
-2020-04-30 Henri Menke
-
- - Trim surrounding whitespace from pattern name #851
-
-2020-04-29 Henri Menke
-
- - Use comma hack for pattern keys as well #851
-
-2020-04-29 Henri Menke
-
- - Merge branch 'master' of https://github.com/Mo-Gul/pgf
-
-2020-04-24 Stefan Pinnow
-
- - incorporated tallmarmots suggestion of issue #848
-
-2020-04-14 Henri Menke
-
- - Fix \pgfmathfloattoextentedprecision #845
-
-2020-03-29 Stefan Pinnow
-
- - - (again) found double-space instances
-
-2020-03-23 Stefan Pinnow
-
- - - minor issue additionally stated in issue #840
-
-2020-03-04 Henri Menke
-
- - Fix chiral anomaly #837
-
-2020-03-04 Henri Menke
-
- - dvisvgm4ht: ProvidesFileRCS and copyright
-
-2020-03-03 Henri Menke
-
- - Merge remote-tracking branch 'dvisvgm4ht/master'
-
-2020-03-02 thinbold
-
- - multiple is noun; multiply is verb
-
-2020-02-20 Henri Menke
-
- - New pgfparser utility package
-
-2020-02-20 Henri Menke
-
- - Fix typo in fadings driver for Lua/pdfTeX
-
-2020-02-06 Henri Menke
-
- - Don't swallow the delimiter #831
-
-2020-02-06 letzfets
-
- - Include dependencies in Makefile #829
-
-2020-01-30 Hironobu Yamashita
-
- - pgfmathparser.code.tex: add pdfTeX/LuaTeX/pTeX units
-
-2020-02-02 Henri Menke
-
- - Update manual issue template
-
-2020-01-16 Henri Menke
-
- - Address the CTAN issues #816
-
-2020-01-16 Henri Menke
-
- - Cherry-pick the useable stuff from #822
-
-2020-01-16 Henri Menke
-
- - Issue template: Reminder to use latest manual
-
-2020-01-07 Kamil Ziemian
-
- - `arrows` library replaced by `arrows.meta`
-
-2020-01-06 Henri Menke
-
- - Math parse looseness on to paths #813
-
-2019-12-21 Henri Menke
-
- - Update README and fix .travis.yml
-
-2019-12-21 Henri Menke
-
- - Error checking for postaction, correct xetex postaction
-
-2019-12-25 Kamil Ziemian
-
- - Mistake in code example
-
-2020-01-11 Stefan Pinnow
-
- - - removed some more remaining instances of the `arrows` library (#819, #698) - minor change
-
-2019-05-04 Michal Hoftich
-
- - Pass emptry group as a \Picture argument
-
-2019-05-02 Michal Hoftich
-
- - Handle nesting
-
-2019-05-02 Michal Hoftich
-
- - Added comments
-
-2019-05-02 Michal Hoftich
-
- - Support display math inside picture
-
-2019-05-02 Michal Hoftich
-
- - check for the vmode
-
-2019-04-11 Michal Hoftich
-
- - Make the tex4ht patches active only at \begin{document}
-
-2019-04-10 Michal Hoftich
-
- - test for existence of tex4ht commands
-
-2019-04-03 Michal Hoftich
-
- - code cleanup
-
-2019-01-23 Michal Hoftich
-
- - Removed \Rcs command
-
-2018-06-26 Michal Hoftich
-
- - Initial commit
-
-2020-01-08 Henri Menke
-
- - Release 3.1.5b
-
-2020-01-08 Henri Menke
-
- - CI: Try to fix the usual oberdiek shenanigans
-
-2020-01-08 Henri Menke
-
- - Revert "Check \ifmeasuring@ #759"
-
-2019-12-21 Henri Menke
-
- Release 3.1.5a
-
-2019-12-21 Henri Menke
-
- - Revert "Forward scanned coordinate untouched #785" #809
-
-2019-12-19 Henri Menke
-
- Release 3.1.5
-
-2019-12-19 Henri Menke
-
- - [CI] bigintcalc, etexcmds, gettitlestring, hycolor, intcalc, kvdefinekeys, kvsetkeys, ltxcmds, refcount, uniquecounter
-
-2019-12-17 Henri Menke
-
- - Reseed the RNG before every use
-
-2019-12-16 Benjamin Desef
-
- - Remove redundant definition of `center` anchor
-
-2019-12-16 Benjamin Desef
-
- - Rewrite explanation for `\anchorborder`
-
-2019-12-16 Henri Menke
-
- - Document loading order for translator #804
-
-2019-12-15 Henri Menke
-
- - Hash doubling in pgfkeys edef only for numbers #305 #669
-
-2019-12-15 Henri Menke
-
- - Add conditional for externalize to manual
-
-2019-12-14 Henri Menke
-
- - Check \ifmeasuring@ #759
-
-2019-12-13 Henri Menke
-
- - Add comment about 8 character filename limit in old ConTeXt #769
-
-2019-12-13 Henri Menke
-
- - [CI] atbegshi, atveryend, bitset, pdfescape, rerunfilecheck
-
-2019-12-13 Henri Menke
-
- - Typos in the manual #805 #806
-
-2019-12-04 Henri Menke
-
- - New build system
-
-2019-12-05 Henri Menke
-
- - [CI] letltxmacro
-
-2019-12-05 Henri Menke
-
- - Document that matrix on path need ampersand replacement #801
-
-2019-12-05 Henri Menke
-
- - More nitpicking #803
-
-2019-12-05 fmitha
-
- - Minor typo fixes and word change suggestions.
-
-2019-12-03 Henri Menke
-
- - Missing letter in functional tokens #798
-
-2019-12-02 Henri Menke
-
- - [CI] stringenc
-
-2019-12-02 Henri Menke
-
- - Remove cleanuplink and friends #796
-
-2019-12-01 Henri Menke
-
- - [CI] kvoptions
-
-2019-12-01 Henri Menke
-
- - Execute size hook unconditionally #795
-
-2019-11-30 Stefan Pinnow
-
- - issue #775 - corrected some spellings - harmonized e.g. "$x$ direction" --> "$x$-direction" with the rest of the manual - adjusted "mystars" example so it fits to the "blue code box" - renamed `lines` to `mylines` in last `codeexample` to match the previous `mystars` example
-
-2019-11-29 Henri Menke
-
- - Fix sorting of intersections #480
-
-2019-11-29 Henri Menke
-
- - Update TeX Live CI
-
-2019-11-29 Henri Menke
-
- - Document shorten < and > #387
-
-2019-11-29 Henri Menke
-
- - pgfinterruptpath is not a scope #442
-
-2019-11-28 Henri Menke
-
- - \pgfkeys at temp is not safe to transport over other macros #428
-
-2019-11-28 Henri Menke
-
- - Draw to target instead of computed anchor #730
-
-2019-11-27 Henri Menke
-
- - Implement and document new patterns #775 #776
-
-2019-11-27 Henri Menke
-
- - \pgfmath at ensureregister produced missing characters #400
-
-2019-11-27 Henri Menke
-
- - Wrong numerical constant in ln #788
-
-2019-11-27 Henri Menke
-
- - AtBeginDocument for ConTeXt #790
-
-2019-11-26 Henri Menke
-
- - Some packages got moved out of oberdiek
-
-2019-11-26 Henri Menke
-
- - Protect parens and order of operations in turtle #789
-
-2019-11-24 Henri Menke
-
- - Missing name prefix in "<dir> of=" positioning #512
-
-2019-11-20 Henri Menke
-
- - Fix style key for datavisualization #726
-
-2019-11-18 Henri Menke
-
- - New pgfkeys handler .evaluated
-
-2019-11-18 Henri Menke
-
- - Forward scanned coordinate untouched #785
-
-2019-11-18 Henri Menke
-
- - Nitpick #784
-
-2019-11-16 JouleV
-
- - Fix spacing for keys in decorations manual
-
-2019-11-15 Matteo Gamboz
-
- - Correct typo in tutorial
-
-2019-11-14 Henri Menke
-
- - Revert "Add \rawx, \rawy, \rawz to let operation"
-
-2019-11-14 Henri Menke
-
- - Revert "Check for \pgfpointxyz before \rawx, \rawy, \rawz"
-
-2019-11-14 Henri Menke
-
- - Revert "Making the declared coordinate accessible"
-
-2019-11-13 samcarter
-
- - Improvements for markup in the manual
-
-2019-11-13 Henri Menke
-
- - Support for RGB for Plain TeX (docs)
-
-2019-11-12 Henri Menke
-
- - GitHub: Add mailing list link
-
-2019-11-12 Henri Menke
-
- - GitHub: Issue templates
-
-2019-11-10 Henri Menke
-
- - Add bbox library to manual (oops)
-
-2019-09-13 Stefan Pinnow
-
- - - corrected spelling of `\todosp`
-
-2019-09-13 Stefan Pinnow
-
- - - added some `\todosp` comments to `... Barb` arrows where no space between the two words is shown in the manual (v3.1.4b)
-
-2019-09-13 Stefan Pinnow
-
- - - replaced all instances of `arrows.spaced` with `arrows.meta` - replaced most of the instances of `arrows` with `arrows.meta`
-
-2019-09-01 Stefan Pinnow
-
- - - fixed some more wrongly spelled library names (related to issue #736) - marked more libraries in horizontal bars, i.e. `|...|`
-
-2019-11-10 Henri Menke
-
- - Change order of options in label and pin #643 #773 #774
-
-2019-11-10 Henri Menke
-
- - Support for RGB for Plain TeX
-
-2019-11-08 Henri Menke
-
- - Reset transformation in grow cyclic #770
-
-2019-11-06 Henri Menke
-
- - First version of the bbox library
-
-2019-11-05 Henri Menke
-
- - Correct example for every pic #519 #751
-
-2019-11-05 Henri Menke
-
- - Support styling of outer \pgfmatrix node #627
-
-2019-11-05 Henri Menke
-
- - Add some predefined patterns to patterns.meta
-
-2019-11-05 Henri Menke
-
- - Improve the 'lines' example for patterns.meta #602
-
-2019-11-05 Henri Menke
-
- - pgfmathfloat at parser@install in pgfmathfloatparse #727
-
-2019-11-04 Henri Menke
-
- - Reverse anchor of spy node #767
-
-2019-11-04 Henri Menke
-
- - Cannot use commas in pgfkeys #728
-
-2019-11-04 Henri Menke
-
- - Add generated gnuplot files #719
-
-2019-11-04 Henri Menke
-
- - Fix `name prefix' for pics
-
-2019-11-04 Henri Menke
-
- - Add quotes to error message #747
-
-2019-11-04 Henri Menke
-
- - Cheap trick to avoid leading space problem #753
-
-2019-11-04 Henri Menke
-
- - Fix pgfkeys pretty printer for single key-value pair #762
-
-2019-11-04 Henri Menke
-
- - Merge branch 'master' of https://github.com/lockywolf/pgf
-
-2019-11-03 Lockywolf
-
- - Update doc/generic/pgf/text-en/pgfmanual-en-tutorial.tex
-
-2019-11-03 Henri Menke
-
- - Install iftex in CI
-
-2019-11-03 Henri Menke
-
- - /tikz/radius dropped units #768
-
-2019-11-01 Lockywolf
-
- - Update pgfmanual-en-tutorial.tex
-
-2019-10-29 quark67
-
- - Fix of a typo
-
-2019-10-28 doraTeX
-
- - Support pattern objects with dvipdfmx
-
-2019-10-18 Henri Menke
-
- - Race condition in circle radius #756
-
-2019-10-20 Mo-Gul
-
- - Merge pull request #757 from Lipen/patch-1
-
-2019-10-19 Konstantin Chukharev
-
- - Fix typo 'arrow.meta' -> 'arrows.meta'
-
-2019-09-13 Henri Menke
-
- - Reset some text parameters inside a node #743
-
-2019-09-17 Henri Menke
-
- - principle -> principal
-
-2019-09-01 Stefan Pinnow
-
- - Fix misspelled library names
-
-2019-09-11 Henri Menke
-
- - Definition should be deferred to \pgfutil at guessdriver
-
-2019-09-11 Henri Menke
-
- - ConTeXt MKIV needs the LuaTeX driver #742
-
-2019-09-06 Henri Menke
-
- - Merge remote-tracking branch 'Mo-Gul/master'
-
-2019-08-28 Henri Menke
-
- - Reset \tikz at intersect@namedpaths at scope boundaries, fixes #284
-
-2019-08-29 Henri Menke
-
- - Make \node foreach work if loop variable is used for positioning, fixes #735
-
-2019-08-29 Henri Menke
-
- - Correct some typos, fixes #736
-
-2019-08-27 Stefan Pinnow
-
- - - checked `pattern.meta` library stuff and fixed some minor issues
-
-2019-08-27 Stefan Pinnow
-
- - - corrected a word in `pgfmanual-en-dv-axes.tex` - harmonized spelling of `i.e.` and `e.g.` - corrected line breaking in `pgfmanual-en-math-numberprinting.tex` where a |...| was split across lines
-
-2019-08-27 Mo-Gul
-
- - Merge pull request #733 from hmenke/PimpCodeexamples
-
-2019-08-27 Henri Menke
-
- - New .gitignore needs some special treatment
-
-2019-08-20 Stefan Pinnow
-
- - - handled one more `codeexample` that was added after branching. (related issues #640, #711, #729)
-
-2019-08-05 Mo-Gul
-
- - - moved `colorlet` to the `codeexample` itself instead of to `pre` in `pgfmanual-en-base-quick.tex`
-
-2019-07-28 Stefan Pinnow
-
- - - included issue #720 ("sub-library" should load "main library" by default) - therefore added loading `graphs` library in `graphs.standard` library - adjusted `preamble` code in `codeexample`s accordingly - there exist `graphdrawing` `codeexample`s in the manual that don't need the `graphs` library --> adjusted `codeexample`s accordingly
-
-2019-07-27 Stefan Pinnow
-
- - - fixed issue #718 ([manual] \usepgflibrary vs. \usetikzlibrary)
-
-2019-07-24 Stefan Pinnow
-
- - - missed to commit/push the Lua documentation stuff - had a look at the `codeexample`s where a leading space was introduced (see https://github.com/pgf-tikz/pgf/pull/711#issuecomment-514506025). Some of them could be removed but others are introduced because of code added to the `pre` key where I don't have a clue if/how this can be avoided
-
-2019-07-23 Stefan Pinnow
-
- - - continued(/finished) moving `setup code,hidden` to `preamble` of the `codeexample`s - minor stuff
-
-2019-07-20 Stefan Pinnow
-
- - - corrected wrongly commented Lua comments in the Lua documentation files (of commit 900d47729d91dd9ba3eb59de56d5d9a4ba2eb155
-
-2019-07-20 Stefan Pinnow
-
- - - moved `setup code` before `pre` in `extract.lua` - started moving `setup code,hidden` to `preamble` of the `codeexample`s
-
-2019-07-18 Stefan Pinnow
-
- - - also need to Lua comment LaTeX comment in the Lua documentation files
-
-2019-07-18 Stefan Pinnow
-
- - - commented some more `\begin{codeexample}[setup code,hidden]` (as @hmenke suggested in https://github.com/pgf-tikz/pgf/pull/711#discussion_r304140166)
-
-2019-07-18 Stefan Pinnow
-
- - - implemented suggestions given in https://github.com/pgf-tikz/pgf/pull/711
-
-2019-07-18 Stefan Pinnow
-
- - - removed commented/unnecessary stuff from `extract.lua` - minor stuff
-
-2019-07-14 Stefan Pinnow
-
- - - accounted for some more `codeexample`s in `tex/generic/graphdrawing/lua/pgf/gd`
-
-2019-07-13 Stefan Pinnow
-
- - - adapted `extract.lua` after Henri changed it in Master to also account for the manual files at `/tex/generic/pgf/graphdrawing/lua/pgf/` - accounted for some more `codeexample`s in `doc/generic/pgf/text-en/`
-
-2019-07-03 Stefan Pinnow
-
- - - removed an unnecessary empty line
-
-2019-07-03 Stefan Pinnow
-
- - - % TODOsp: ... --> % TODOsp: codeexamples: ... (so they can be found more easily)
-
-2019-07-03 Stefan Pinnow
-
- - - continued adding code to make extracted `codeexample`s work
-
-2019-07-02 Stefan Pinnow
-
- - - changed order of `setup code` and `preamble` in `extract.lua` - continued adding code to make extracted `codeexample`s work
-
-2019-07-02 Stefan Pinnow
-
- - - continued adding code to make extracted `codeexample`s work
-
-2019-07-01 Stefan Pinnow
-
- - - continued adding code to make extracted `codeexample`s work
-
-2019-06-27 Stefan Pinnow
-
- - - finished switching from `libraries/tikz={...}` to `preamble={\usetikzlibrary{...}}` - continued with following files in the manual
-
-2019-06-26 Stefan Pinnow
-
- - - adapted `extract.lua` - incorporated fixes from main PGF repository (provided by Henri) - changed `\documentclass` from `article` to `standalone` - reordered some stuff - started switching from `libraries/tikz={...}` to `preamble={\usetikzlibrary{...}}`
-
-2019-06-25 Stefan Pinnow
-
- - - added `pre` stuff to codeexamples of the tutorial doc files so fewer files fail TeXing using the build bash script.
-
-2019-06-25 Stefan Pinnow
-
- - - finished adding libraries to codeexamples of the tutorial doc files (so far not all needed styles and definitions were added using `pre` key)
-
-2019-06-24 Stefan Pinnow
-
- - - commented line that adds all libraries to the extracted codeexamples in `extract.lua` - started adding libraries to the codeexamples
-
-2019-07-23 Jonathan Spratte
-
- - fixes #715
-
-2019-07-30 Henri Menke
-
- - .cvsignore -> .gitignore #721
-
-2019-07-28 Sašo Živanović
-
- - Fix a leaking space.
-
-2019-07-12 Henri Menke
-
- - Fix text color in nodes #361
-
-2019-07-19 Henri Menke
-
- - Halt on error
-
-2019-07-18 samcarter
-
- - On behalf of @marmot : Improving the calculation of bounding boxes for Bezier curves
-
-2019-08-03 Henri Menke
-
- - Release 3.1.4b
-
-2019-08-03 Henri Menke
-
- - Revert "Default implementation of \pgfsys at hboxsynced doesn't work for dvips #690"
-
-2019-07-16 Henri Menke
-
- - Release 3.1.4a
-
-2019-07-15 Henri Menke
-
- - Revert "Fix position tracking for XeTeX #353"
-
-2019-07-12 Henri Menke
-
- - Release 3.1.4
-
-2019-07-12 Henri Menke
-
- - after_script runs after deploy
-
-2019-07-11 Henri Menke
-
- - Add pgfmanual to release files
-
-2019-07-11 johannesborgstrom
-
- - Add URL of the pdf manual to the README.md file
-
-2019-07-11 Henri Menke
-
- - Goodbye SourceForge
-
-2019-07-11 Henri Menke
-
- - Clear trap before deploy
-
-2019-07-11 Henri Menke
-
- - Switch to a new branch for tlcontrib
-
-2019-07-10 Henri Menke
-
- - Stretchable dash patterns #629
-
-2019-07-09 Henri Menke
-
- - Try protected at edef in pgfmathparse
-
-2019-07-05 Henri Menke
-
- - Hardening patterns.meta a little
-
-2019-07-04 Henri Menke
-
- - \pgfmathrandominteger didn't handle expressions as input
-
-2019-07-04 Henri Menke
-
- - extract.lua: all extracted files are tex
-
-2019-07-04 Henri Menke
-
- - extract.lua: recurse into subdirectories, ignore remember picture
-
-2019-07-03 Henri Menke
-
- - Describe \pgfdeclarepattern and \tikzdeclarepattern
-
-2019-07-03 Henri Menke
-
- - Add patterns.meta to the manual
-
-2019-06-27 Henri Menke
-
- - /pgf/foreach/count is unscoped #702
-
-2019-04-22 Henri Menke
-
- - On the way to more configurable patterns
-
-2019-06-27 Henri Menke
-
- - Add mailing list to the README
-
-2019-06-26 Henri Menke
-
- - Missed stripping pt on dimensions #701
-
-2019-06-26 Henri Menke
-
- - Bend angle need not be integer #700
-
-2019-06-26 Henri Menke
-
- - No dedicated options for libraries (for now)
-
-2019-06-26 Henri Menke
-
- - Add option to hide code
-
-2019-06-26 Henri Menke
-
- - Stripping comments was too greedy
-
-2019-06-26 Henri Menke
-
- - Small fix to the grammar
-
-2019-06-25 Henri Menke
-
- - Typos in luamath
-
-2019-06-24 Henri Menke
-
- - Functionality to print libraries in code listings
-
-2019-06-23 Stefan Pinnow
-
- - - fixed some typos
-
-2019-06-22 Stefan Pinnow
-
- - - fixed regression (accidentally duplicated part of code)
-
-2019-06-21 Henri Menke
-
- - \pgf at nodecallback might be called twice #693
-
-2019-06-21 Henri Menke
-
- - Default implementation of \pgfsys at hboxsynced doesn't work for dvips #690
-
-2019-06-21 Henri Menke
-
- - Fix position tracking for XeTeX #353
-
-2019-06-06 Henri Menke
-
- - Wrong order in definition of \translate #689
-
-2019-06-05 Henri Menke
-
- - FILES is generated
-
-2019-06-05 Henri Menke
-
- - Change priority of Travis jobs
-
-2019-06-05 Henri Menke
-
- - Load imakeidx before hyperref
-
-2019-06-05 Henri Menke
-
- - Remove user config from deploy script
-
-2019-06-03 Henri Menke
-
- - Revert "Missing spaces in error messages #679"
-
-2019-05-31 cfeuersaenger
-
- - Restored lost functionality in intersections / fillbetween feature
-
-2019-05-30 Christian Feuersaenger
-
- - Revert 00f4e8d4154dcb3133ed4a106b6254b8faf874e2
-
-2019-05-30 Christian Feuersaenger
-
- - Fixed regression: the merge cc191ed4ae5bd11df9ce42595102caa4e1f141b4 accidentally deleted a feature
-
-2019-05-24 Henri Menke
-
- - Use imakeidx for automatic index creation
-
-2019-05-23 Henri Menke
-
- - Looks like I got tex4ht working
-
-2019-05-23 Henri Menke
-
- - Use T1 for DVI output for now, see also https://github.com/mgieseki/dvisvgm/issues/2
-
-2019-05-23 Henri Menke
-
- - luaotfload was missing this whole time
-
-2019-05-23 Henri Menke
-
- - Merge remote-tracking branch 'loopspace/master'
-
-2019-05-23 Henri Menke
-
- - Disable T1 encoding for LuaTeX
-
-2019-05-21 Andrew Stacey
-
- - Extended the higher-level save of the last moveto so that it also works with nodes.
-
-2019-05-21 Andrew Stacey
-
- - Added dimensions for saving the last moveto coordinates so that -- cycle works with nodes. The existing method uses the coordinates stored from the last soft path move to, but this has an extra transformation applied to it meaning that when it gets used in node placement the transformation is applied twice.
-
-2019-05-20 Henri Menke
-
- - Missing spaces in error messages #679
-
-2019-05-17 Henri Menke
-
- - Move tlcontrib to tlnet folder to make room for possible future MikTeX contrib
-
-2019-05-17 Henri Menke
-
- - Typo in alternate angles #676
-
-2019-05-15 Henri Menke
-
- - Missing xcolor definitions for Plain and ConTeXt #675
-
-2019-05-13 Henri Menke
-
- - Typo
-
-2019-05-13 Henri Menke
-
- - Some more fixes for the tex4ht manual
-
-2019-05-13 Henri Menke
-
- - Merge remote-tracking branch 'Mo-Gul/master'
-
-2019-05-13 Henri Menke
-
- - Revert all but the useful changes of 98829b450a96a6790570aba11949cd9834e49e2c
-
-2019-05-13 Henri Menke
-
- - Some more cleanup before deploy
-
-2019-05-10 Henri Menke
-
- - Fix .lastretry #672
-
-2019-05-13 Henri Menke
-
- - Deploy TDS and CTAN zip
-
-2019-05-13 Henri Menke
-
- - Get git tag in Makefile
-
-2019-05-09 Henri Menke
-
- - Release 3.1.3
-
-2019-05-09 Henri Menke
-
- - Further unbreaking of shadings #650
-
-2019-05-09 Henri Menke
-
- - \ifdim instead of \ifx #412
-
-2019-05-08 Henri Menke
-
- - Add push- and popmacro. Useful for smuggling. From ConTeXt
-
-2019-05-02 Henri Menke
-
- - Merge pull request #664 from dcpurton/shadings-colorspace
-
-2019-04-29 Henri Menke
-
- - Add navigation arrows to SVG manual
-
-2019-04-28 Henri Menke
-
- - Typos in pgfmanual-en-library-circuits.tex #667
-
-2019-04-25 Henri Menke
-
- - Simpler basename function for extract.lua #640
-
-2019-04-25 David Purton
-
- - Add copyright and attribution for CMYK and grayscale shadings
-
-2019-04-24 David Purton
-
- - Update documentation for color model independent shadings
-
-2019-04-21 David Purton
-
- - CMYK and grayscale shadings library support
-
-2019-04-21 David Purton
-
- - Functional shading color space conversion functions
-
-2019-04-21 David Purton
-
- - Support for CMYK and grayscale shadings in set up code
-
-2019-04-21 David Purton
-
- - Conversion from shade color to grayscale PostScript data support
-
-2019-04-21 David Purton
-
- - Conversion from shade color to CMYK PostScript data support
-
-2019-04-21 David Purton
-
- - Add grayscale shading postscript driver support
-
-2019-04-21 David Purton
-
- - Add CMYK shading postscript driver support
-
-2019-04-21 David Purton
-
- - Add grayscale shading parsing functions
-
-2019-04-21 David Purton
-
- - Add CMYK shading parsing functions
-
-2019-04-20 David Purton
-
- - Adapt shading drivers to allow for multiple color models
-
-2019-04-25 Henri Menke
-
- - Produce compilable examples from extract.lua #640
-
-2019-04-25 Henri Menke
-
- - Preliminary version of an extractor script for codeexamples #640
-
-2019-04-25 Henri Menke
-
- - Manual typos #665
-
-2019-04-23 Henri Menke
-
- - Revert "No mode switch for typesetting pictures"
-
-2019-04-20 David Purton
-
- - Support shading color specifications in CMYK
-
-2019-04-20 David Purton
-
- - Set up RGB specific shading parsing
-
-2019-04-22 Henri Menke
-
- - Fix typos #662
-
-2019-04-22 Henri Menke
-
- - No mode switch for typesetting pictures
-
-2019-04-22 Henri Menke
-
- - Correct floored division (thanks @josephwright)
-
-2019-04-21 Henri Menke
-
- - Merge pull request #661 from dcpurton/mandelbrot-fix
-
-2019-04-20 David Purton
-
- - Fix Mandelbrot set shading definition #658
-
-2019-04-20 Henri Menke
-
- - Add Easter to PGF calendar #593
-
-2019-04-19 Henri Menke
-
- - Document save and use path #644
-
-2019-04-19 Henri Menke
-
- - Missing definitions in tex4ht driver #660
-
-2019-04-19 Henri Menke
-
- - Fix conflicting shading declarations for dvipdfm #659
-
-2019-04-17 Henri Menke
-
- - Add some circuit symbols #641
-
-2019-04-17 Henri Menke
-
- - Add tlpkg to Travis cache
-
-2019-04-17 Henri Menke
-
- - Fix shadings in dvisvgm
-
-2019-04-17 Henri Menke
-
- - % is not allowed in DVI #657
-
-2019-04-17 Henri Menke
-
- - Fix shading regression #656
-
-2019-04-17 Henri Menke
-
- - Don't switch mode in \pgfuseshading #655
-
-2019-04-12 Henri Menke
-
- - Use TL usertree in CI
-
-2019-04-11 Henri Menke
-
- - Merge pull request #647 from Skillmon/parserx
-
-2019-04-11 Jonathan Spratte
-
- - requested changes from review
-
-2019-04-11 Jonathan Spratte
-
- - Merge remote-tracking branch 'official/master' into parserx
-
-2019-04-11 Henri Menke
-
- - More checks, fewer rsyncs
-
-2019-04-11 Jonathan Spratte
-
- - fixed bug ignoring +
-
-2019-04-10 Jonathan Spratte
-
- - fixes #628; needs the new parser version
-
-2019-04-10 Jonathan Spratte
-
- - fixed a bug in pgfparserlet
-
-2019-04-10 Jonathan Spratte
-
- - removed parserx from FILES
-
-2019-04-10 Jonathan Spratte
-
- - parserx replaces parser
-
-2019-04-10 Henri Menke
-
- - Force push to SourceForge
-
-2019-04-10 Henri Menke
-
- - Add revision file to archive
-
-2019-04-10 Henri Menke
-
- - Override before_script for SourceForge mirror
-
-2019-04-10 Henri Menke
-
- - Update README [ci skip]
-
-2019-04-10 Henri Menke
-
- - Typo
-
-2019-04-10 Henri Menke
-
- - Missing packages
-
-2019-04-10 Henri Menke
-
- - Better commit message
-
-2019-04-10 Henri Menke
-
- - Deploy tlcontrib
-
-2019-04-10 Henri Menke
-
- - PGF requires etex
-
-2019-04-09 Henri Menke
-
- - Looks like we have to rerun twice
-
-2019-04-09 Henri Menke
-
- - Rerun check for dvisvgm docs
-
-2019-04-09 Henri Menke
-
- - Deployment script for website
-
-2019-04-08 Jonathan Spratte
-
- - bugfix default space rule
-
-2019-04-08 Jonathan Spratte
-
- - added pgfparserxlet
-
-2019-04-08 Henri Menke
-
- - Merge branch 'fix-typos' of ssh://git.code.sf.net/u/frougon/pgf
-
-2019-04-08 Henri Menke
-
- - Shading assignment has to global #650
-
-2019-04-07 Henri Menke
-
- - Correct initial value for minimum width and height #649
-
-2019-04-06 Jonathan Spratte
-
- - use pgfutil at namedef
-
-2019-04-06 Jonathan Spratte
-
- - no etex, no folds
-
-2019-04-06 Jonathan Spratte
-
- - Merge remote-tracking branch 'official/master' into parserx
-
-2019-04-06 Henri Menke
-
- - Merge remote-tracking branch 'kpym/master'
-
-2019-04-06 Henri Menke
-
- - Optional e-TeX protection
-
-2019-04-05 Jonathan Spratte
-
- - finished parserx documentation and module
-
-2019-04-05 Henri Menke
-
- - Fix Travis conditional
-
-2019-04-05 Henri Menke
-
- - Only sync when on upstream
-
-2019-04-05 Henri Menke
-
- - \noexpand instead of \ignorespaces
-
-2019-04-05 Henri Menke
-
- - Automatically mirror changes to SourceForge
-
-2019-04-04 Henri Menke
-
- - Allow optional comma in let assignment list #606 (oberdiek)
-
-2019-04-04 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - Release 3.1.2!
-
-2019-04-04 Henri Menke
-
- - Update README
-
-2019-04-03 Henri Menke
-
- - Fix #523 (jkinable)
-
-2019-04-03 Henri Menke
-
- - Fix #522 (kpymtzanev)
-
-2019-04-02 Henri Menke
-
- - Welcome to GitHub :octocat:
-
-2019-03-13 Max Snippe
-
- - Renaming perspective library macros
-
-2019-03-13 Max Snippe
-
- - Fixed typo and missing backslash
-
-2019-03-11 Henri Menke
-
- - Correct copyright statement
-
-2019-03-08 Max Snippe
-
- - Added perspective library
-
-2019-03-06 Henri Menke
-
- - Fix TeX conditionals on \pgfmathdeclarefunction (Eric Domenjoud) Feature Request #121
-
-2019-02-28 Henri Menke
-
- - More accurate \pgfpointnormalised #518 #519 Feature #96
-
-2019-02-22 Henri Menke
-
- - tikzmath needs to know about fpu
-
-2019-02-20 Henri Menke
-
- - Fix shading angle #516 (Eric Domenjoud)
-
-2019-02-14 Henri Menke
-
- - Fix trivial typo #514
-
-2019-02-08 Henri Menke
-
- - Missed ligature suppression for dvisvgm #473
-
-2019-02-08 Henri Menke
-
- - Now I hopefully got all of the ligatures #473
-
-2019-02-05 Henri Menke
-
- - Some fixes for the shading patch #511 (Eric Domenjoud)
-
-2019-02-05 Henri Menke
-
- - \long\def
-
-2019-02-05 Henri Menke
-
- - Fake \scantokens has to at least strip braces
-
-2019-02-05 Henri Menke
-
- - Only use \scantokens if available #508
-
-2019-02-04 Henri Menke
-
- - Revert "Revert "Patch for shadings #511 (Eric Domenjoud)""
-
-2019-02-04 Henri Menke
-
- - Revert "Patch for shadings #511 (Eric Domenjoud)"
-
-2019-02-04 Henri Menke
-
- - Making the declared coordinate accessible
-
-2019-02-04 Henri Menke
-
- - Globally remember declare coordinate of a node
-
-2019-02-04 Henri Menke
-
- - Check for \pgfpointxyz before \rawx, \rawy, \rawz
-
-2019-02-04 Henri Menke
-
- - Add \rawx, \rawy, \rawz to let operation
-
-2019-02-04 Henri Menke
-
- - Disable strict nesting for now
-
-2019-02-04 Henri Menke
-
- - Patch for shadings #511 (Eric Domenjoud)
-
-2019-02-03 Stefan Pinnow
-
- - - minor stuff
-
-2019-02-02 Christian Feuersaenger
-
- - Merge branch 'master' of ssh://git.code.sf.net/p/pgf/git
-
-2019-02-02 Christian Feuersaenger
-
- - Merge branch 'branch_3.1_hotfix'
-
-2019-02-02 Christian Feuersaenger
-
- - updated release file
-
-2019-02-02 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - Release 3.1.1!
-
-2019-02-01 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - fixed bug #503: regression prevented the use of dvips. This reverts the
- bugfix for bug #362
-
-2019-01-05 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - Release 3.1!
-
-2018-12-28 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - \pgfmathprintnumber: implemented 'retain unit mantissa=true|false' (feature #92)
-
-2018-12-30 Henri Menke
-
- - fixed wrong projection of `canvas is xy plane at z` in `3d` library (bug #410)
- - added documentation of `3d` library to the manual (support request #11)
- - defined CMYK colors for ConTeXt (feature request #33)
- - `text along path` decoration repeated last char multiple times when
- this was in math mode (bug #479)
-
-2018-12-29 Henri Menke
-
- - fixed accidental usage of `\rm` (bug #476)
-
-2018-12-28 Henri Menke
-
- - fixed newlines for tex4ht (bug #327)
- - fixed bug that `fit` didn't work with `transform shape` (bug #330)
- - fill color in nodes now respects colormodel (bug #349)
- - fixed broken VTeX support (bug #350)
- - `text=<color>` now works fine when in the nodes' text `\textcolor` is used (bug #362)
-
-2018-12-26 Henri Menke
-
- - allowed whitespace between layers in `\pgfsetlayers` (bug #376)
-
-2018-12-25 Henri Menke
-
- - fixed `\method` which can now contain empty lines (bug #448)
- - manual improvement regarding `pgfoothis` (bug #452)
- - documented commands `\pgfooeset`, `\pgfooappend`, `\pgfooprefix` (bug #452)
-
-2018-12-24 Henri Menke
-
- - fixed bug in \pgfkeysedef (bug #306)
- - `miter limit` now raises an error when a value < 1 is given (bug #347)
- - fixed bug that `\pgfmathmax` and `pgfmathmin` were broken when
- `fixedpointarithmetic` library was loaded (bug #360)
- - added missing function `\pgfmathpneg` in `fixedpointarithmetic` library (bug #361)
- - fixed bug that brace decorations were malformed for large amplitudes (bug #351)
- - made node parser aware of prefix and suffix (bug #397)
-
-2018-12-23 Henri Menke
-
- - (almost) fixed guillemets for LuaTeX (bug #473)
-
-2018-12-21 Henri Menke
-
- - fixed incorrect spelling in pgflibrarydecorations.text (bug #479)
- (but this doesn't solve the bug 100%)
- - fixed 'bend left' bug if used with a formula (bug #423)
- - use \typeout stream instead of \write16 (bug #488)
- - fixed some bugs regarding graphdrawing electrical "springs" (bugs #380 and #381)
-
- 2018-12-20 Henri Menke
-
- - fixed pgf_lookup_and_require for new luaotfload (bug #493)
- - fixed graphdrawing for ConTeXt (bug #477)
-
-2018-04-30 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - added utility \pgfmathifexpression (and special treatment in luamath
- library and fpu library)
-
-2017-11-14 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - intersections lib: improved accuracy of intersections for linear paths
-
-2017-02-08 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - fixed incompatibility issue of tikzmath and fpu reported in
- http://tex.stackexchange.com/questions/349766/pgfplots-on-tikzmath-function-with-conditionals-returns-an-error
-
-2016-12-31 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - Improved driver detection (bug #395 TikZ does not create output with LuaTeX 0.95.0)
- - New luatex driver now supports fallback to pdftex driver if
- luatexversion is older than 95 (let's hope this works reliably - luatex
- used to have version 240 some time ago!)
-
-2016-08-10 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed bugs that caused pgfsys-dvips.def to generate corrupt
- PostScript for all nodes.
-
-2016-07-16 Till Tantau <tantau at users.sourceforge.net>
-
- - Bounding box computations for animations implemented.
- - Animated arrow tips are now possible.
-
-2016-07-13 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - fixed incompatibility between textpos (absolute mode) and external
-
-2016-06-17 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - fixed \write18 issues in luatex 0.87 and later (by using os.execute())
- affects external lib and plot function.
-
-2016-03-31 Till Tantau <tantau at users.sourceforge.net>
-
- - Lots of bugfixes in animation and svg code.
- - Added optimizations to reduce file size for svg code
- (better support by dvisvgm will be needed however for more
- compact text!).
-
-2016-03-18 Till Tantau <tantau at users.sourceforge.net>
-
- - First working, fully documented version of TikZ animations!
-
-2016-02-24 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed manual stuff to compile it with dvisvgm.
-
-2016-02-02 Till Tantau <tantau at users.sourceforge.net>
-
- - Rewrote tikz animation lib.
-
-2016-01-06 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - added context-related aux file fix of Hans Hagen
-
-2016-01-02 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - fixed save stack issues (eliminated 'retaining' issues) about pgf at x and pgf at y
-
-2015-12-29 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - external lib: 'force remake' now also updates .md5 files
-
-2015-11-28 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - fpu: fixed floor and ceil
- - fixed basic layer floor function
- - lua library: improved interoperability of luamath and fpu
- - unit test now compares luamath, fpu, and pgfbasic math
-
-2015-11-15 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - activated math parser in foreach's end notation to allow \foreach \i in {0,...,10-9}
-
-2015-09-09 Till Tantau <tantau at users.sourceforge.net>
-
- - Worked on pgfsys-dvisvgm.def a lot. Now requires
- dvisvgm-1.5.3 because of switch from pt to bp there. Does
- correct bounding box computations.
-
-2015-09-06 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - fixed bug in luamath library
-
-2015-08-29 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - external lib: added support to automatically externalize references and
- labels with 'mode=convert with system call'
-
-2015-08-24 Till Tantau <tantau at users.sourceforge.net>
-
- - Reworked implementation of animations for tikz and started
- on documentation of the backend.
-
-2015-08-20 Till Tantau <tantau at users.sourceforge.net>
-
- - First complete implementation of animations for tikz! (for
- svg backend). Documentation still missing, but works nicely.
-
-2015-08-13 Till Tantau <tantau at users.sourceforge.net>
-
- - First work on animations for svg. Added commands in pgfsys
- and added module pgfmoduleanimations. No documnetation yet.
-
-2015-08-07 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - Release 3.0.1!
-
-2015-08-03 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - fixed regression introduced for pgf 3.0.0 (bug #149): leading empty
- lines at the beginning of plot files disabled '-- plot'
- - fixed bug #291 (missing white space trimming in node labels)
- - fixed bug #313 (alias option did not respect name prefix/suffix)
- - fixed bug #341 ("is in pic" was not reset)
- - fixed bug #365 (caused by missing adoption after copy-paste in tikzlibraryfolding)
- - fixed bug #315/316 by applying the suggested patch and verifying it
-
-2015-06-12 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - fixed fpu math functions for int, ceil, and floor
- - added \pgfmathlogtwo and \pgfmathlogten as requested in bug #359
-
-
-2015-06-06 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed problem in gd: Creating more than about 15 vertices
- inside a graph drawing algorithm was impossible since this
- created too many text input levels. Reorganized the interplay
- between tex and lua for the coroutine so that no input levels
- are created.
-
-2015-06-05 Till Tantau <tantau at users.sourceforge.net>
-
- - Added number nodes option to graph lib.
-
-2015-05-18 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed nullfont warnings in axes in datavisualization.
- - Fixed wrong axes for school book plots.
-
-2015-05-15 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Fixed nullfont warnings when parsing logic gate inputs.
-
-2015-05-08 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed bug in tikz.code.tex concerning colors for arrow tips:
- Setting and restoring the global color "trackers"
- pgf at fillcolor@global over groups was done only in \pgfscope,
- but not in the scopes opened and closed by tikz when drawing a
- path (\pgfsys at beginscope is used there). This caused wrong
- colors to be used.
-
-2015-05-08 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Updated patterns.meta library.
-
-2015-05-02 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - context: committed patch to adopt pgfutil-context for new (incompatible)
- context handling of colors -- contains some cleanup by Hans Hagen.
-
-2015-03-28 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - fixed bug in external lib: braces in external filenames confused the generator
-
-2015-01-02 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - fixed bug in fpu: equal(x, 0) failed for x<0
-
-2014-12-30 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - fixed bug in atan2 (returned wrong sign for atan2(4e-5,-5))
- - implemented atan2 in FPU
-
-2014-11-02 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - fixed save stack issue (TeX capacity exceeded, sorry [save size=250000])
- if the color changes a _huge_ number of times during a single path.
-
-2014-10-11 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - worked on LUA math parser: ensured that a suitable first scope of
- functions works. I also added support for 'declare function'
-
-2014-10-11 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Added provisional code for patterns.meta library. Patterns
- can now be declared using TikZ code with additional support
- for tile transformations. Currently only PDF output supported
- at back-end (uses \pgfsys at declarepattern@meta in pgfsys-pdftex.def).
-
-2014-08-04 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - finished first prototype of a LUA math parser. It is orders of magnitude
- faster than its TeX pendant, features a pure LUA mode and also offers a
- fallback to the TeX \pgfmathparse for unsupported operations/functions
- only defined in TeX.
-
-2014-07-09 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - fixed bug (regression of bug #229): external lib with dvips produced
- wrong bounding box (was broken entirely)
-
-2014-07-08 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - fixed regression in external lib: 'mode=graphics if exists' broke any
- undefined label warnigns
- - added automatic "fast lane" to math parser: if the input is a number
- without units, it will return that as-is. Reduces typesetting time down to
- 66% for huge scatter plots and has just 1% overhead for math intensive
- figures.
-
-2014-06-22 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - added switch 'trig format=deg|rad' which allows to switch sin,cos,tan,
- and their friends to radians. It works for all user input
- arguments - I hope without unanticipated side-effects (marked as
- experimental)
-
-2014-05-17 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - external lib: defined suitable defaults for 'system call' depending on driver
- - external lib: solved incompatibility with biblatex's \cite[][]{name}
- command (http://tex.stackexchange.com/questions/173465/tikz-error-for-externalized-graphics-but-output-is-correct}
- - number parser/printer: added switch 'read comma as period' to read
- localized input numbers. Off by default but added useful hint to parser
- message.
-
-2014-05-06 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - Fixed bug #308 fixedpointarithmetic: unwanted spaces by line ends
-
-2014-03-30 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - Fixed feature #81: signum function (fpu + pgf basic layer)
-
-2014-03-24 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed all \begin{scope} and \end{scope} in foldings lib,
- changed them to \scope and \endscope.
-
-2014-03-21 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed #303 Type in pgfmanual (colormixin)
- - Fixed #302 pgf-3.0: Cannot plot a constant function. Will
- now center the constant line.
- - Addressed #299 Precision problem with explicitily anchored
- labels: While not a bug, I added a "centered" option for cases
- similar to this one (although, in this particular case, the
- new centered option is not what is needed)...
- - Fixed #298 \pgfarrowsdeclare is still mentioned in pgfmanual
- - Fixed #294 Nodes for arcs, which angles are calculated
- simultaneously.
- - Fixed #292 "node scale and outer sep" by introducing the new
- option "outer sep=auto", which takes care of both this problem
- (at least in all normal cases) and also of the draw versus
- fill problem with outer seps.
-
-2014-03-20 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed #285 \tikz at intersect@namedpaths persists outside
- scopes as suggested.
- - Fixed #284 Additional rerun statement for overlays (for LyX)
- by adding the proposed solution (essentially).
- - Added post-fix for #288 by undoing all -- ligatures in
- verbatim code.
-
-2014-03-19 Till Tantau <tantau at users.sourceforge.net>
-
- - Fxied #283 "Is there a smarter way to handle units in math
- engine?" by adding the "scalar" function.
- - Fixed #288 "All the '£' should be '$' in the examples of
- pgfmanual..." by switching to T1 enconding.
- - Fixed #282 "\pgfmathredeclarefunction does not work properly."
-
-2014-02-24 Till Tantau <tantau at users.sourceforge.net>
-
- - Added first edge routing algorithm to gd.
-
-2014-02-02 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - intersections libs: improved robustness and accuracy for curveto paths
- by using the floating point library together with Mark Wibrow.
-
-2014-01-08 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - fixed bug in latex/plain tex shipout routines for xdvipdfmx and xelatex:
- combination of shadings and standalone package failed to work.
-
-2013-12-31 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Fix for 'rotate around x/y/z' keys which now evaluate
- the argument provided.
-
-2013-12-25 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - intersections lib: detected duplicates in line-to intersections
- in endpoints and suppressed them.
- - intersections lib: stored time offset for each intersections as optional
- property (i.e. if it comes for free). This is required to compute fill
- paths
-
-2013-12-20 Till Tantau <tantau at users.sourceforge.net>
-
- - Release 3.0.0!
-
-2013-12-20 Till Tantau <tantau at users.sourceforge.net>
-
- - In preparation for the release 3.0.0, I pimped the manual a
- bit. It will now automatically detect whether graph drawing
- C libs are available or not. Also, syntax hilighting is now
- always switched on. I also some subtle optical hints to
- crossreferenced words in the code examples; this is pretty
- useful, I think.
- - Did a lot of cleaning up for the release.
-
-2013-12-18 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed a bug in Vertex.lua that returned wrong anchor
- positions for non-centered vertices.
-
-2013-12-13 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed bug #280 "Layered layout" produces unknown key with graphs library.
- - Fixed bug #279 "Some parts of arguments in foreach macro are lost".
- - Fixed bug #258 "Default arrow edge style puts circumflex in
- drawn end node" by now allowing people to say tip=on proper draw.
-
-2013-12-08 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - intersections lib: ensured that 'name path global' is reset between main paths.
-
-2013-11-30 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - worked on intersections lib (internals only); added O(N) list
- append/prepend utilities
-
-2013-11-18 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Added keys 'rotate around x', 'rotate around y' and
- 'rotate around z' to rotate the xyz coordinate system
- around the x, y, or z axis.
-
-2013-11-17 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Fixes for 'text effects along path' decoration and docs.
-
-2013-11-16 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - external lib: added support for 'up to date check=md5' for lualatex.
- Now, lualatex and pdftex both result in the same checksums (by means of
- \usepackage{pdftexcmds})
-
-2013-11-16 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Finalised 'text effects along path' decoration and docs.
-
-2013-11-11 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Changed keyval example (and references to define at key)
- in pgfcalendar documentation to pgfkeys stuff.
-
-2013-11-08 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Minor fixes to decorations.text and math libraries documentation
-
-2013-11-07 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Added 'text effects along path' decoration.
-
-2013-11-01 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - Fixed regression/bug in 'name path global'.
-
-2013-10-31 Till Tantau <tantau at users.sourceforge.net>
-
- - Applied path for bug #277 "\beforeforegroundpath not working".
-
-2013-10-09 Till Tantau <tantau at users.sourceforge.net>
-
- - Prepared manual for new release (fixed overful boxes and
- index problems).
-
-2013-10-08 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Updated math library (minor fixes).
-
-2013-10-07 Till Tantau <tantau at users.sourceforge.net>
-
- - Applied some fixes so that C code for graph drawing works
- once more.
- - Arrow tips and their doc are now officially finished!
- - Added documentation of nonlinear transformations.
-
-2013-10-06 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - modified release script to allow uploads of unstable TDS
- zips to http://pgf.sourceforge.net using
- make -f pgf/scripts/pgf/Makefile.pgf_release upload USER=cfeuersaenger
-
-2013-10-02 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Fixed problem with math parser inserting extraneous
- spaces when parsing \dimenexpr
-
-2013-09-30 Till Tantau <tantau at users.sourceforge.net>
-
- - Changed blend mode syntax to standard pgf syntax (since PDF
- and SVG do not agree on names...).
- - Added scale and slant options for arrow tips.
- - Added more generic arrow tips.
-
-2013-09-24 Till Tantau <tantau at users.sourceforge.net>
-
- - First version of comlete arrow documentation finished. Still
- need to document the arrows.meta library, though.
- - Added "tips" option for drawing arrow tips without drawing
- paths.
-
-2013-09-23 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed bug #273 "Graph drawing sublayouts fails".
- - Incorporated first partial documentation of the arrow tips
- into the main documentation.
- - Fixed bug bugs:#272 "SVG parser error after close path" as
- suggested by Mark Wibrow.
- - Also changed the default syntax for svg path command so that
- it uses braces instead of quotation marks. (Quotation marks
- still work, of course.)
-
-2013-09-22 Till Tantau <tantau at users.sourceforge.net>
-
- - Started working on arrow doc.
-
-2013-09-20 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Added macro to convert string of digits to comma separated list.
-
-2013-09-18 Till Tantau <tantau at users.sourceforge.net>
-
- - First version of new arrow tip management done. Up and
- running! Still needs documentation and the old arrow tip
- codes should (but need not) be ported.
- - Did some porting of old code, added fixes. Doc still missing.
-
-2013-09-17 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed bug #264: "\pgfkeys /errors/unknown key should (?) expand first argument"
- - Fixed bug #268: "`matrix of nodes' isn't working properly any more"
-
-2013-09-11 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Corrected typos (bug #266 and bug #265)
-
-2013-09-11 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - added magnetic tape shape.
-
-2013-09-09 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed bug #262/267: "Line breaks are not working in labels anyy more."
- - Fixed bug #260: "TikZ node on background in pgfextra"
- - Started work on bending arrows.
-
-2013-09-05 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - external lib: fixed bug: file dependency handling was incorrect and
- suffered from regression caused by MD5 checks
-
-2013-08-31 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - repaired incompatibility with pgfplots <= 1.8: samples key was
- evaluated in context of floating point unit and new pgf code relied on dimension
- registers.
-
-2013-08-29 Till Tantau <tantau at users.sourceforge.net>
-
- - Added "turn" key.
-
-2013-08-28 Till Tantau <tantau at users.sourceforge.net>
-
- - Added "angle" pic type and "angles" library.
- - Patched gd loader code so that it works with context mark IV.
-
-2013-08-27 Till Tantau <tantau at users.sourceforge.net>
-
- - Added new pic path command.
- - Patched pgfsys-dvipdfmx.def to step around the bug in
- (x)dvipdfmx that caused scaled boxes (including scaled
- graphics) inside nodes to be displayed incorrectly.
-
-2013-08-24 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - fixed bug in fpu: 0^0 and 0^x both produced nan. Now we get
- 0^0=1 and 0^x = 0.
-
-2013-08-22 Till Tantau <tantua at users.sourceforge.net>
-
- - Removed claims from manual (not by me...) that TikZ does not
- work with Mark IV of context. I just tried it and everything
- I tried (including advanced stuff like shadings) worked fine.
-
-2013-08-18 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Fixed pgf intersection library to ensure that
- specialround tokens are processed.
-
-2013-08-06 Till Tantau <tantua at users.sourceforge.net>
-
- - Added support for dvisvgm. Quite nice...
-
-2013-08-05 Till Tantau <tantua at users.sourceforge.net>
-
- - Worked on tex4ht code. Works reasonably well know and even
- graph drawing is possible (when luatex is used for
- typesetting; for this I needed to fix some latin1 characters in
- html4.4ht). Also, I renamed /tikz/tex4ht... to /pgf/tex4ht
- (someone else added that) since tikz has nothing to do with
- that stuff.
- Typesetting the manual in tex4ht no longer works, but that seems
- like too much bother for my taste.
-
-2013-08-02 Till Tantau <tantua at users.sourceforge.net>
-
- - Fixed bug #256 "The special \pgfcoordinate macro doesn't
- expand \pgfpictureid."
-
-2013-08-04 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - external lib: fixed incompatibility of pdflscape with
- external lib
-
-2013-08-01 Till Tantau <tantua at users.sourceforge.net>
-
- - Fixed a problem with pdf resources of transparency groups in
- dvipdfmx.
-
-2013-07-31 Till Tantau <tantua at users.sourceforge.net>
-
- - Fixed bug #149 "/tikz/raw gnuplot ignoring segmented plot"
- by introducing a new way of handling plot streams. There are
- now new kinds of points (outliers and undefined points) and
- "new data sets" commands inside streams. Handlers (like the
- lineto and curve handlers) can be configured to interpret
- these as jumps (this is the default).
- - Fixed bug #255 "Trig computations offend fp via fixedpointarithmetic lib"
-
-2013-07-31 Mark Wibrow <vibrovski at users.sourceforge.net>
- - Added "math" library. Could be integrated with calc library.
-
-2013-07-26 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - Fixed bug in external lib: mode=list and make did not cope well with
- \ref in externalized images. These will be remade now.
-
-2013-07-24 Till Tantau <tantua at users.sourceforge.net>
-
- - Fixed bug #162 "PGF manual examples use undefined "shape example" style"
- - Fixed bug #169 "ghostscript error: /undefined in pgfo"
- - Concerning bug #167 "node pin option sets
- inconsistent/incorrect angle" I added some clarification in
- the manual that explains the observed behaviour.
- - Fixed bug #158 "\pgfmathparse does not support e-TeXs
- \numexpr and \dimexpr". You can now also use
- \pgfmathsetlength to assign a muskip a value. Internally,
- "mu" is treated like "pt", but if an expression contains
- "mu", \pgfmathsetlength and \pgfmathaddtolength will convert
- the number to "mu" before the assignment.
-
-2013-07-22 Till Tantau <tantua at users.sourceforge.net>
-
- - Fixed bug #173 "Tikz's transparency, xelatex and preview
- package" by adding a specific fix for the interaction
- between preview.sty and everyshi.sty in pgfutil-latex.def.
-
-2013-07-19 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - optimized mark=* and mark=o (q path versions lead to 10% time reduction)
- - adopted new pgfkeys feature to /handler config/full or existing (
- required when /.search also is used to find the correct key path)
-
-2013-07-19 Till Tantau <tantua at users.sourceforge.net>
-
- - Fixed bug #175 "In PGF oo module, calling a method strips grouping"
- - Fixed bug #181 "Need to document |- coordinates using calc notation"
- - Fixed bug #187 "\pgfmathanglebetweenpoints is not documented"
- - Increased accuracy of atan, atan2 and
- \pgfmathanglebetweenpoints.
-
-2013-07-18 Till Tantau <tantua at users.sourceforge.net>
-
- - Fixed bug "#168 PGF is sensitive to dollar catcode"
- - Fixed bug "#186 pgfonlayer makes pgf forget options" and
- added "every on background layer" option.
- - Fixed bug "#192 pgffor scope iteration is buggy"
- - Fixed bug "#196 Incoherent syntax for Bézier curves"
- - Fixed bug "#199 Drawing error for chamfered rectangle"
- - Fixed bug "#201 Markings fail with "Dimension too Large" on
- certain paths" by fixing a mistake and the decoration core
- and, additionally, in pgfmathanglebetweenpoints.
- - Fixed bug "#254 building currenct CVS version fails on
- graphdrawing with current luatex": Will now work nicely with
- TeXLive 2013 and Lua 5.2.
- - Added feature request "bug #203 Blending modes and better transparency"
-
-2013-07-17 Till Tantau <tantua at users.sourceforge.net>
-
- - Fixed bug #204 "strange influence of \baselinestretch on
- tikz figure" by no longer sharing \pgfutil at tempa with latex:
- This register gets changed by LaTeX in a fontchange, which, in
- turn can happen at the beginning of every
- \pgfmathsetlength.
- - Fixed bug #207 "Decoration markings not on path on large
- lines" by using a more precise computation of positions on
- straight lines in decorations. Also, the angle computation
- is now much more precise by fixedin bug #201.
- - Fixed bug #212 "Error if using plot into a \foreach loop in
- a single path" by making \pgffor at beginhook and friends local
- to the current \foreach. A nice side-effect is that one can
- now nest \foreach statements on a path and also mix in the
- plots. Hopefully, no one relied on the (undocumented,
- unsupported) old bevahiour of the hooks.
- - Fixed bug #213 "pgfmathsetcounter only works in local scope"
- by adding a note in the documentation.
- - Fixed bug #211 "\nodepart ignores text transparency"
- - Fixed bug #220 "Transformations ignored in edge decoration."
- - Fixed bug #221 "xyz spherical and cylindrical coordinate, radius not defined"
- - Fixed bug #225 "pgfkeys "/errors/unknown choice value" ignores parameters"
- - Fixed bug #253 "\pgfkeysfiltered cannot accept long arguments"
- - Fixed bug #252 "I'm not able to build the current CVS
- version". This included a number of patches to fix problems
- introduced with the bugfixes introduced recently
-
-2013-07-16 Till Tantau <tantua at users.sourceforge.net>
-
- - Fixed bug #226 "matrix column sep=-\pgflinewidth changes after empty cell"
- - Fixed bug #229 "pgfpagesuselayout breaks beamer class"
- (hopefully, setting page sizes is really messy in TeX!).
- - Fixed bug #232 "pow function broken for 0^x for non-integer values of x"
- - Fixed bug #165 "\draw with empty domain results in infinite calculation"
- - Added better error message to adress bug #244 "mindmap-style
- "invalidates" coordinate shape."
- - Fixed bug #235 "\def\costhirty{0.8660256} not really used"
-
-2013-07-15 Till Tantau <tantua at users.sourceforge.net>
-
- - Fixed bug "#237 CVS-version: pdfimage error: key interpolate undefined"
- - Fixed bug "#245 broken key /pgf/decoration/reset marks"
- - Fixed bug "#239 picture disappear after a zero-width rectangle width shading"
- - Fixed bug "#247 Error messages hard to catch in plain TeX/ConTeXt"
- - Fixed bug "#166 Possibly typos in circuits.logic.IEC"
- - Fixed bug "#249 pgfkeys: /handlers/first char syntax is not
- 'self-contained' (CVS version)"
- - Fixed bug "#248 circuits adjustable annotation improperly placed"
-
-2013-07-13 Till Tantau <tantua at users.sourceforge.net>
-
- - Fixed bug "#250 pgfkyes: .append style and similar undouble # tokens"
- - Fixed bug "#143 label changes center of a matrix node"
-
-2013-07-12 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed bug #128 "fit does not scale if used in scaled scope"
- - Fixed bug #136 "\hrulefill inherits or not pgf line styles"
- - Fixed bug #224 "Including Tikzpicture in third part of
- multipart node"
-
-2013-07-11 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed bug #251 "cross out shape interacts with path options of path it is drawn on"
- - Fixed bug #139 "Placement of node inside matix environment"
- - Fixed bug #131 "text centering calculates wrong" and added
- new "node font" option.
- - Fixed bug #121 "Annoying "Underfull \hbox (badness 10000)" message"
- - Fixed bug #134 "Edge node style affecting arrowhead".
-
-2013-07-08 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed bug #132 "Error in matrix with column sep "between"
- origins"
- - Fixed bug #133 "\draw[-<<,>=stealth] (10,45) -- (40,45); does
- not work." However, this introduces a (small, only visual)
- incompatibility with previous versions. If you need the visual
- effect "-<<" used to have (which, in a sense, was wrong), use
- "-< <" instead. The new "-> >" is also quite handy.
-
-2013-06-28 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed bug #116 "Decorations can't be repositioned when
- pre/post used."
-
-2013-06-25 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed bug #241 "div/null error by (270:length) and a fading line."
- - Fixed bug #126 "Incorrect placed labels for inplicite positioned nodes."
- - Added foreach syntax to nodes. This is useful and also
- needed to fix the problem that the foreach statement cannot
- be used after a to path.
-
-2013-06-24 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed bug #18 and #74 (active characters and tikz) by virtue
- of the new "babel" library, which deactivates catcodes at the
- beginning of tikz pictures and reactivates them in nodes.
-
-2013-06-21 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed bug #110 "cannot add node after cycle operation"
- - Fixed bug #88 "\pgftransformarrow does not rotate with \pgfpointanchor"
- - Fixed bug #86 "macro-expanded tree node has bad edge anchor"
- - Fixed bug #85 "PGF + Crop package, at least for pdftex."
-
-2013-06-20 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed bug #83 "Transparency Problem with \usepackage{endfloat}."
- - Applied patch #19 pgfkeys: ".search also" fails at unbalanced "\if" values
- - Applied patch #18 Missing grid lines with
- negative increment
- - Applied patch #17 TikZ folding library
- - Applied patch #14 inheritance in the oo module
- - Applied patch #13 leaking space in \pgfpointintersectionoflines
- - Applied patch #11 Patch for Bug #3165961 (\pgfmathmax and \pgfmathmin)
- - Fixed problem of patch #9 Add papersize to XeTeX driver
- - Applied patch #8 Support for changing physical page size with XeTeX
- (also added position saving support, while I was at it...)
- - Applied patches #3, #4, #5, #6 (typos in manual) as far as possible
-
-2013-06-18 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed bug #236 "Scaled closed paths, start/end points dont exactly match":
- "cycle" can now be used with all path operations where it
- makes sense, not only with --. In particular, things like
- ".. cycle" or "to [bend right] cycle" are now allowed.
-
-2013-05-23 Till Tantau <tantau at users.sourceforge.net>
-
- - Reworked handling of edge and vertex paths in gd. In
- particular, edge--vertex intersections are now computed in
- Lua, rather than in TikZ. This is much more powerful and
- allows beautiful arcs between vertices. It is also very
- useful for planar graph drawings when several edges leave a
- vertex in the same direction.
-
-2013-04-08 Till Tantau <tantau at users.sourceforge.net>
-
- - Did away with luadoc, now using simple handcoded documentor
- that will also work with Lua 5.2
- - Redid OGDF support. Resonably stable base now.
- - Added better C support.
- - Should now work with both Lua 5.1 and 5.2
-
-2013-03-15 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - fixed incompatibility of fixltx2e and external lib
-
-2013-02-08 Till Tantau <tantau at users.sourceforge.net>
-
- - Reworked Storage mechanism of graph drawing system.
- - Added phylogenetics library for graph drawing; documentation
- still only rudimentary.
-
-2012-12-30 Till Tantau <tantau at users.sourceforge.net>
-
- - Started adding support for calling C graph drawing functions
- from Lua.
- - First proof of concept for OGDF finished.
- - Must still address luatex shared library link problems.
-
-2012-12-25 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - fixed bug in external lib: \tikzexternalgetnextfilename did reset the
- value of \tikzsetnextfilename and 'export next'
-
-2012-11-30 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - updated driver pgfsys-xetex: now, it supports all that the new driver
- for dvipdfmx does which includes fadings, functional shadings, and
- patterns.
-
-2012-11-30 Till Tantau <tantau at users.sourceforge.net>
-
- - First complete documentation of the graph drawing
- system. (Finally!)
-
-2012-11-27 Till Tantau <tantau at users.sourceforge.net>
-
- - Renamed gd files to shorter versions: instead of
- pgf/gd/model/pgf.gd.model.Edges.lua we now have
- pgf/gd/model/Edge.lua and so on.
- - Worked on gd documentation. Only binding doc is still a
- mess.
-
-2012-11-26 Till Tantau <tantau at users.sourceforge.net>
-
- - Worked on gd documentation.
-
-2012-11-21 Till Tantau <tantau at users.sourceforge.net>
-
- - New version of gd lib. The internals have been completely
- redone. In particular, no tikz libraries are needed for the
- individual algorithms any longer, all declarations are now
- done completely inside Lua. This makes gd usable (in
- principle) independently of tikz and pgf.
- - Because of this, all declarations of algorithms need to be
- redone.
-
-2012-11-10 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - external lib: fixed spurious white space (caused by 'up to date check')
-
-2012-11-01 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - manual styles: improved robustness of auto cross references & active spaces
-
-2012-10-18 Christophe Jorssen <cjorssen at users.sourceforge.net>
-
- - Fixed a bug with active colon in circuits lib. Probably more to
- fix in other libraries.
-
-2012-10-11 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
-
- - Improved precision of math functions asin and acos (using linear
- interpolation instead of constant interpolation)
-
-2012-09-27 Till Tantau <tantau at users.sourceforge.net>
-
- - Worked on gd.
-
-2012-09-26 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
- - fixed pgfsys-pdftex.def : very old regression with \setbeamercovered{transparent} and \pause
- Patch by Hendrik Vogt
-
-2012-08-29 Till Tantau <tantau at users.sourceforge.net>
-
- - Added support for sublayouts in gd (not yet fully
- documented). This allows one to use several algorithms inside
- a single graph.
-
-2012-06-28 Till Tantau <tantau at users.sourceforge.net>
-
- - Redone handling of clusters in gd yet again. Renamed them to
- "collections". Much better system now, can handle hyperedges,
- subgraphs and other stuff (in principle).
- - Nodes generated by a gd algorithm now have correct size
- information (this one was tricky!).
-
-2012-06-22 Till Tantau <tantau at users.sourceforge.net>
-
- - Redone handling of clusters in gd.
- - Worked on gd documentation.
-
-2012-06-18 Christian Feuersaenger <cfeuersaenger at users.sourceforge.net>
- - fixed minor expansion issue \foreach \x in {a,...,d} lead to unexpanded value \x
-
-2012-06-18 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - externalization: added special switch to deactivate incompatible
- geometry drivers during externalization
-
-2012-05-31 Till Tantau <tantau at users.sourceforge.net>
-
- - Redone pgf.gd.model.Arc
- - Added documentation for said class.
-
-2012-05-23 Till Tantau <tantau at users.sourceforge.net>
-
- - Worked on gd documentation.
- - Replaced old luadoc by customized version. Gets called
- directly from tex.
-
-2012-05-17 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - external lib: added support for MD5/diff based up-to-date checks.
- Changes to a picture will automatically result in a remake of the
- respective external graphics.
-
-2012-05-03 Christophe Jorssen <cjorssen at users.sourceforge.net>
-
- - Fix bug #3527068 (\pgfmathatantwo did not exist)
-
-2012-05-14 Till Tantau <tantau at users.sourceforge.net>
-
- - Changed pgf.gd.new_graph_drawing_algorithm syntax. Not
- likely to change again...
- - Added support for algorithms to create nodes and edge in the
- syntactic digraph.
- - Introduced library graphdrawing.examples that includes some
- code demonstrating how "things are done".
-
-
-2012-05-13 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - context: fixed catcode issues by means of suitable module
- \protect/\unprotect statements.
-
-2012-05-06 Till Tantau <tantau at users.sourceforge.net>
-
- - Introduced a new class model for graph drawing (Digraph,
- Arc, and Vertex instead of Graph, Edge, Node). I'm currently
- porting all the old code, but it takes a while and it's a
- bit messy right now. Some easy algorithms are already based
- on the new system, old ones not. In the end, things should
- be significantly faster and also easier to program.
-
-2012-05-03 Christophe Jorssen <cjorssen at users.sourceforge.net>
-
- - Attempt to fix bug in calc lib when '!' or ':' are active (not
- fully tested but should work).
-
-2012-05-02 Christophe Jorssen <cjorssen at users.sourceforge.net>
-
- - Attempt to fix bug with label and pin when ':' is active (not
- fully tested but should work).
-
-2012-04-19 Till Tantau <tantau at users.sourceforge.net>
-
- - Finished the first two chapters of the documentation of gd
- (overview and tikz usage).
- - Module system is now redone and the directory structure
- has been reorganized. No more messing around with lua
- modules, everything is perfectly portable now.
-
-2012-04-17 Till Tantau <tantau at users.sourceforge.net>
-
- - Started to completely redo the module system of graph
- drawing in lua. I'm in the middle of it, so its currently
- messy, but it works.
-
-2012-04-12 Till Tantau <tantau at users.sourceforge.net>
-
- - Implemented packing procedure for graph drawing.
- - Cleaned up graph drawing source some more.
- - Renamed lots of files (still not happy with it, though).
-
-2012-04-11 Till Tantau <tantau at users.sourceforge.net>
-
- - Implemented Reingold-Tilford tree layout.
-
-2012-04-05 Till Tantau <tantau at users.sourceforge.net>
-
- - Implemented my first graph drawing algorithm: circular layout.
-
-2012-04-03 Till Tantau <tantau at users.sourceforge.net>
-
- - Introduced new declaration mechanism for graph drawing
- algorithm classes
- - Implemented preprocessing step of decomposing a graph into
- connected components.
-
-2012-04-02 Till Tantau <tantau at users.sourceforge.net>
-
- - Cleaned up graph drawing algorithm directories: Moved
- obsolete algorithms to special directory.
- - Switched graph drawing calling interface from function-base
- to object-based: All graph drawing algorithms must now be
- implemented in a class
- - Cleaned up file and class names of graph drawing engine.
-
-2012-03-30 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed problem that in case math library is loaded before pgf
- some math functions were broken (because \pgfmath at xa and
- \pgf at xa were different registers, which they should not be).
-
-2012-03-29 Till Tantau <tantau at users.sourceforge.net>
-
- - Added anchoring and orientation to graph drawing library.
-
-2012-03-21 Till Tantau <tantau at users.sourceforge.net>
-
- - Added arrows.spaced library.
- - Added quotation syntax to graph lib.
- - Renamed some graph drawing layouts.
- - Worked on documentation of graph drawing lib.
-
-2012-03-07 Christophe Jorssen <cjorssen at users.sourceforge.net>
-
- - Moved wrappers for luatex primitives (\pgfutil at directlua,
- \pgfutil at ifluatex, \pgfutil at luaescapestring) to pgfutil-common.tex
- - Added support for luatex to the profiler library by emulating
- \pdfelapsedtime.
-
-2012-02-27 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed wrong edef in graph lib that broke the /-syntax when
- text contained expandable stuff.
-
-2012-02-21 Christophe Jorssen <cjorssen at users.sourceforge.net>
-
- - More work on the luamath parser and evaluator.
-
-2012-01-24 Christophe Jorssen <cjorssen at users.sourceforge.net>
-
- - Fix a bug in tikz polar coordinates (reported on tex.se
- http://tex.stackexchange.com/questions/41828/using-math-in-tikz):
- braces around a delimited argument are removed.
-
-2012-01-10 Christophe Jorssen <cjorssen at users.sourceforge.net>
-
- - Fix a bug in pgfmath != operator (reported and fixed on tex.se
- http://tex.stackexchange.com/questions/40605/using-in-pgfmathparse)
-
-2012-01-09 Christophe Jorssen <cjorssen at users.sourceforge.net>
-
- - Fix a pgfmath dependency for pgffor.
-
-2012-01-03 Till Tantau <tantau at users.sourceforge.net>
-
- - Added pos support to the arc command (finally...).
- - Added support to the graph library for drawing tries.
- - Added support to the graph library for adding edge labels in
- an easier way.
-
-2011-12-29 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Added the 'fixed relative' number formatting style.
-
-2011-12-28 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Added 'const plot mark mid' and 'jump mark mid' plot handlers.
-
-2011-12-02 Till Tantau <tantau at users.sourceforge.net>
-
- - Renamed "layered drawing" to "layered layout" for
- consistency.
-
-2011-11-12 Christophe Jorssen <cjorssen at users.sourceforge.net>
-
- - More work on the lua math parser and evaluator.
- - Added wrappers for luatex primitives: \pgfutil at directlua,
- \pgfutil at ifluatex, \pgfutil at luaescapestring
- - Make lua code more lua 5.2 compatible
-
-2011-11-11 Christophe Jorssen <cjorssen at users.sourceforge.net>
-
- - Work on the lua math parser and evaluator. Begin to merge Mark's
- code with mine.
-
-2011-11-03 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added FPU support for ==, !=, <=, >=, ?
-
-2011-10-29 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - fixed problem with pgf number printer: it introduced spurious spaces
- tracker id 3430171. Thanks to Clemens Koppensteiner for the bugfix.
-
-2011-09-25 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - \pgfsetlayers can now be given inside of a pgfpicture (or tikzpicture)
-
-2011-06-22 Christophe Jorssen <cjorssen at users.sourceforge.net>
-
- - The lua math parser now works on basic expressions (no units, no
- arrays, no strings, no functions, ...?).
-
-2011-06-02 Christophe Jorssen <cjorssen at users.sourceforge.net>
-
- - Some work on a lua (lpeg based) math parser.
-
-2011-05-31 Christophe Jorssen <cjorssen at users.sourceforge.net>
-
- - Added a gnuplot call key to pgfmoduleplot.code.tex (feature
- request #3308340).
-
-2011-05-30 Jannis Pohlmann <jannis at xfce.org>
-
- - graph drawing:
- - Initial work on layered drawing algorithms.
-
-2011-05-25 Christophe Jorssen <cjorssen at users.sourceforge.net>
-
- - Added dim function for array to pgfmath (to be documented)
- - Some work on a ODE solver
-
-2011-05-20 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - removed spurious white spaces in my bugfix for pgfmathdivide
-
-2011-05-19 Till Tantau <tantau at users.sourceforge.net>
-
- - Second attempt at fixing spy lib...
-
-2011-05-18 Matthias Schulz <ma.schulz at email.de>
-
- - graph drawing:
- - added short overview for nodes and edges (lua class documentation)
-
-2011-05-17 Jannis Pohlmann <jannis at xfce.org>
-
- - graph drawing:
- - Separate 'spring layout' and 'spring electrical layout' families.
- Rename existing algorithms accordingly.
- - Add an implementation of the Floyd-Warshall algorithm.
- - Add a new 'Hu2006 spring' algorithm based solely on springs.
- - Improve the initial layout of 'Hu2006 spring electrical' by
- taking the graph size and diameter into account.
- - Rework existing spring electrical algorithms and improve
- documentation.
- - Catch -!- edges and remove them from the Lua graph when detected.
-
-2011-05-14 Jannis Pohlmann <jannis at xfce.org>
-
- - graph drawing:
- - Update documentation of spring and spring-electrical parameters.
- Add TODO items where things are missing, unclear or need to be
- worked on.
- - Make initial step dimension and the electric charge of nodes
- configurable. Both, Walshaw2000 and Hu2006 support this.
- - Improve the approximation of the repulsive force.
-
-2011-05-13 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed bug 3297817 (spy postscript problem).
- - Fixed bug of missing newpath in postscript and opacity
- settings.
-
-2011-05-13 Jannis Pohlmann <jannis at xfce.org>
-
- - graph drawing:
- - Rename graphdrawing.spring to graphdrawing.force.
- - Fix NaN bug in the orientation helper.
- - Initial work on improving and documenting the parameters for
- spring and spring-electrical algorithms.
- - Properly forward default node and edge parameters to Lua.
-
-2011-05-12 Jannis Pohlmann <jannis at xfce.org>
-
- - graph drawing:
- - Add Fibonacci heap and priority queue classes.
- - Add Lua file for common graph algorithms. Implement Dijkstra.
- - Add method Graph:getPseudoDiameter().
- - Hu2006: Scale coordinations of nodes in a coarse graph based on
- the quotient of its pseudo diameters and that of the parent coarse
- graph, as described in the paper.
-
-2011-05-11 Jannis Pohlmann <jannis at xfce.org>
-
- - graph drawing:
- - Fix several interpolation bugs in the coarse graph class.
- - Use the coarse graph class in the Walshaw2000 algorithm.
-
-2011-05-11 Till Tantau <tantau at users.sourceforge.net>
-
- - Worked on documentation of gd backend. Still need to
- document graph parameters.
-
-2011-05-10 Jannis Pohlmann <jannis at xfce.org>
-
- - graph drawing:
- - Remove files from the old graph drawing library tree.
- - Disable verbose logging by default.
- - Specify sane initial values for spring algorithm parameters.
-
-2011-05-10 Till Tantau <tantau at users.sourceforge.net>
-
- - Added .graph drawing parameter initial key.
-
-2011-05-09 Jannis Pohlmann <jannis at xfce.org>
-
- - graph drawing:
- - Implement graph coarsening in the Hu2006 algorithm.
- - Name force-based algorithms after the paper author and year.
-
-2011-05-09 Till Tantau <tantau at users.sourceforge.net>
-
- - Reorganized graph drawing documentation.
-
-2011-05-06 Jannis Pohlmann <jannis at xfce.org>
-
- - Finished the graph drawing library reorganization started by Till.
-
-2011-05-06 Till Tantau <tantau at users.sourceforge.net>
-
- - Reorganized the graph drawing key and directory
- structure. The documentation is still missing. Also, lots of
- files still need to be moved, but I'll leave that to Jannis.
-
-2011-05-06 Jannis Pohlmann <jannis at xfce.org>
-
- - graph drawing:
- - implement a quadtree optimization in the Walshaw algorithm.
- - add a simple version of the Hu spring-electrical algorithm that
- seems to work almost as good as the Walshaw even without
- the multilevel approach implemented (which is the only thing
- that really makes the Walshaw algorithm useful).
-
-2011-05-04 Jannis Pohlmann <jannis at xfce.org>
-
- - graph drawing:
- - Initial work on a quad tree implementation for spring and spring
- electrical algorithms, with unit test.
- - Improve the internals of the Vector class.
-
-2011-05-03 Till Tantau <tantau at users.sourceforge.net>
-
- - graph drawing: Started to cleanup pgf and tikz layers. Ongoing...
-
-2011-05-03 Jannis Pohlmann <jannis at xfce.org>
-
- - graph drawing:
- - Fix Walshaw algorithm to properly set the subnodes when copying
- the coarse graphs. Simplify the code that updates the node
- coordinates.
-
-2011-05-02 Jannis Pohlmann <jannis at xfce.org>
-
- - graph drawing:
- - Modify the doclet to allow underscores in parameter names.
- - Document the Vector class as well as the table, iter and traversal
- helpers.
- - Remove old table and iterator helpers. Rename helper files. Rename
- table.merge() and table.copy() to table.custom_merge() and
- table.custom_copy() to avoid name clashes with luatools. Add
- string helpers, including string.parse_braces(). Update algorithms
- to work with these changes.
- - Allow vectors to have an origin vector, similar to the Position
- class. Introduce new alternative table-based syntax for
- Vector:set() that is much easier to read. Update unit tests
- and algorithms.
-
-2011-05-02 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - fpu: added support for log10 and log2
-
-2011-05-02 Jannis Pohlmann <jannis at xfce.org>
-
- - graph drawing:
- - Drop the 'not yet positionedPGFGDINTERNAL' node name prefix
- internally. It's stripped off now when nodes are passed over to
- Lua and its added back again when shipping the node out to TeX.
- - Drop the Node:shortname() method which is no longer needed.
- - Improve coding style and documentation of the Interface, Sys,
- Node, Edge and Graph classes.
- - Rename Sys:logMessage() to Sys:log().
- - Make parameter labels in the API docs not appear in bold.
- - Disable verbose logging by default.
- - Add methods Edge:getNodes() and Node:getEdges().
-
-2011-05-02 Jannis Pohlmann <jannis at xfce.org>
-
- - graph drawing:
- - Initial work on spring-electrical and layered drawing algorithms.
- - Major rework of the Lua code of the graphdrawing library: added
- a Vector class for improved math operations and node positioning,
- added quite a number of table and iterator helpers, added
- post-processing code for fixing the orientation of graph drawings,
- updated the graph/node/edge data structures to store nodes in the order
- they appear instead of storing them in a random order, implement
- coordinate keys for nodes, and much more.
-
-2011-04-30 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - number printing: added '1000 sep in fractionals' switch
-
-2011-04-29 Christophe Jorssen <cjorssen at users.sourceforge.net>
-
- - Work on pgflibraryluamath (added pgfpointnormalised)
-
-2011-04-27 Matthias Schulz <ma.schulz at email.de>
-
- - Graphdrawing library documentation, split into two files, removed
- noluatex file, reworked the text (added information).
-
-2011-04-25 Christophe Jorssen <cjorssen at users.sourceforge.net>
-
- - First attempt to do math with lua (very basical): pgflibraryluamath
-
-2011-04-18 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - bugfix for rounding error in \pgfmathdivide{83.407811000}{16.68156400}
- was 4.10, is now 5.0: it could happen in rare cases that digits where
- appended where they shouldhave been than added (4 + .10 instead of 4 + 1.0)
-
-2011-04-22 Jannis Pohlmann <jannis at xfce.org>
-
- - Implemented a G_n subgraph for creating grid (or: mesh) graphs.
- This also introduces a new key /tikz/graphs/wrap after=<number> that
- configures how the nodes in such a grid graph are connected. Some of
- the common subgraph keys such as /tikz/graphs/V and /tikz/graphs/n
- can be used with G_n subgraphs as well.
- - Added a simple grid placement strategy. It currently does not
- support the chain shift and group shift keys properly and does not
- implement any placement order other than left-to-right, so there is
- room for improvement.
-
-2011-04-18 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - external lib: reduced number of \newwrite allocations and allowed to disable features
- to safe more of them (aux in dpth=false,disable dependency files)
-
-2011-04-17 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added '/pgf/number format/relative' formatting style.
-
-2011-03-22 Till Tantau <tantau at users.sourceforge.net>
-
- - Finished documentation of data visualization (sort of)!
- - First usable version of data visualization!
-
-2011-03-15 Till Tantau <tantau at users.sourceforge.net>
-
- - Worked on dv documentation. Finished chapter on visualizers,
- style sheets. Legends still missing
-
-2011-03-07 Till Tantau <tantau at users.sourceforge.net>
-
- - Worked on dv documentation. Finished chapter on axes.
-
-2011-03-07 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Incorporated a bugfix of Hans Hagen which makes pgf compatible with
- Context Mk IV.
- Verified: the patch is backwards compatible with TL 2009 and TL 2010
- i.e. Context MkII and it works with Context Mk IV.
-
-2011-01-22 Till Tantau <tantau at users.sourceforge.net>
-
- - Worked on dv documentation.
-
-2011-01-05 Christophe Jorssen <cjorssen at users.sourceforge.net>
-
- - Attempt to fix a bug #1911195 with pgfpages and rotation (fix
- contributed by Mark Wibrow). Note: Mark was not sure it has side
- effects.
-
-2010-12-17 Christophe Jorssen <cjorssen at users.sourceforge.net>
-
- - Documentation will now compile with auto-xref enabled (a problem
- with \_ in the graph lib not handled correctly by
- pgfmanual.pdflinks.code.tex).
- - Fix bug #3104978 thanks to Heiko Oberdiek patch on ctt.
-
-2010-12-17 Till Tantau <tantau at users.sourceforge.net>
-
- - Changed the graph syntax for anonymous nodes in the graph
- library and simplified the as= syntax.
- - Added fresh nodes options to graph library.
-
-2010-12-14 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed graph lib so that it compiles with plain TeX.
-
-2010-12-10 Till Tantau <tantau at users.sourceforge.net>
-
- - Small fixed in the graph library.
-
-2010-12-07 Till Tantau <tantau at users.sourceforge.net>
-
- - Finished graph library!
-
-2010-12-06 Till Tantau <tantau at users.sourceforge.net>
-
- - Nearly finished graph lib and its documentation.
-
-2010-11-30 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed bug #3123605 (hopefully...).
- - Worked on graph lib.
-
-2010-11-19 Christophe Jorssen <cjorssen at users.sourceforge.net>
-
- - Some integer arithmetics functions for the math parser
- (contributed by Alain Matthes): gcd, isprime, isodd, iseven
-
-2010-11-19 Till Tantau <tantau at users.sourceforge.net>
-
- - Second attempt at making \tikz work also with fragile stuff
- following. The new code will no longer fail in a situation
- like \tikz \foreach ...
- - Worked on graph lib stuff.
-
-2010-11-06 Christophe Jorssen <cjorssen at users.sourceforge.net>
-
- - A luatex version of the doc is available (fixed inputenc issues
- since luatex works with utf8 by default).
-
-2010-11-04 Christophe Jorssen <cjorssen at users.sourceforge.net>
-
- - Fix bug in pgfmathfunctions.basic.code.tex (bug reported by
- Alain Matthes and fixed by Paul Gaborit on fctt): wrong
- interaction between pow and exp (linked to \pgfmath at x modified
- outside macro call).
-
-2010-11-01 Christophe Jorssen <cjorssen at users.sourceforge.net>
-
- - Make \pgfkeys at exp@call long (bug reported by Florent Chervet on
- fctt)
- - Fix bug in pgflibraryshapes.callouts.code.tex: \pgf at test changed
- to \pgf at node@name (bug reported by Zarko F. Cucej on ctt and fix
- contributed by Mark Wibrow)
-
-2010-10-27 Christophe Jorssen <cjorssen at users.sourceforge.net>
-
- - fixed bug 3096333 (Fix contributed by Mark Wibrow): pgffor
- failed to update \lastx in some cases
-
-2010-10-25 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- Released version 2.10
-
-2010-10-22 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - closed a lot of bugs on sourceforge, especially documentation bugs
- - fixed bug 2429749: gnuplot invocation in tabularx did not work.
-
-2010-10-21 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - fixed bug: there was an incompatibility between pgf and beamer due to a
- missing \interlineskip in the shipout handling for latex.
-
-2010-10-15 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - renamed 'halfcircle' marker to 'halfcircle*' and added 'halfcircle'.
- - provided special case 'mark color=none' for the half-filled markers.
-
-2010-10-13 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - fixed incorrect fill/stroke coloring of new marker contributions (see
- ChangeLog 2010-09-27)
- - added more predefined dashed and dotted line patterns for black/white plots
- to fulfill a related feature request of Tomek
- - fixed bug: the 'name path global' feature did not work in every case...
- the actual implementation might need to be revised eventually.
-
-2010-10-12 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Imported spell checking results of Stefan Pinnow (thanks!)
- - Dealed with typo in 'sci generic' number formatting style: it now
- accepts 'mantissa' *and* 'mantisse'
-
-2010-10-11 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - External lib: Fixed bug. The 'failed ref warnings for' was not properly \protect'ed.
-
-2010-09-27 Till Tantau <tantua at users.sourceforge.net>
-
- - Started on graph lib. Not yet finished and not documented.
-
-
-2010-09-21 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Added plot markers of Magnus Tewes and Tomek: halfcircle, halfsquare*,
- halfsquare left*, halfsquare right*, heart
-
-2010-09-08 Till Tantau <tantua at users.sourceforge.net>
-
- - Added \pgfpositionnodelater and \pgfpositionnodenow
- commands.
-
-
-2010-08-31 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - externalization+\ref: fixed a bug
-
-2010-08-30 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - external lib: documented how to generate .png graphics and added support
- switches.
-
-2010-08-26 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added 'baseline=default', 'trim left=default' and 'trim right=default' choices to reset these keys.
-
-2010-08-25 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added support to provide paragraphs in "pin" arguments
-
-2010-08-24 Till Tantau <tantau at users.sourceforge.net>
-
- - Worked on data visualization and its documentation.
-
-
-2010-08-23 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - basic level externalization: added \hoffset=0pt and \voffset=0pt to improve
- compatibility with special document classes
- - added docs for \deferredanchor feature contributed by Christophe Jorssen <cjorssen at users.sourceforge.net>
- - ConTeXt support: fixed loading problem of calendar lib
-
-
-2010-08-18 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - pgfsys-tex4ht.def: fixed problem with \par in a non-long macro argument,
- thereby eliminating a compilation problem
- - pgfsys-tex4ht.def: renamed offending macro invocation \Par to \par
-
-
-2010-08-16 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - basic level image externalization: added '/pgf/images/trim external={<left>}{<bottom>}{<right>}{<top>}'
- to allow modifications to the hardcoded '1truein' shifts.
- - added '/.style n args' key.
- - \usetikzlibrary / \usepgflibrary: added support for white-space trimming
- and empty arguments in the lists. Now, lines do not need to be terminated
- by '%' and ',,' is valid.
-
-2010-08-13 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - external lib: documented how to solve compatibility problems with
- \tikzifexternalizing
-
-2010-08-11 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added \deferredanchor feature contributed by Christophe Jorssen <cjorssen at users.sourceforge.net>
-
-2010-08-03 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added optimized and numerically stable arc path command
- \pgfpatharctoprecomputed which interpolates start- and end points
-
-2010-07-10 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - external lib: fixed incompatibility with 2010/06/08 v2.0b eso-pic package
-
-2010-07-06 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - external lib: added sanity checking for failed \ref,\pageref,\cite commands in external images.
-
-2010-07-01 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - math parser: improved error messages by providing the complete math expression.
-
-2010-06-30 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added 'trim left' and 'trim right' features to simplify bounding box
- modifications and allow support for restricted bounding boxes and image
- externalization.
-
-2010-06-16 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - pgfutil-latex.def: changed \usepackage to \RequirePackage (thanks to Christophe Jorssen)
- - external lib: added \tikzappendtofigurename{} shortcut for '\tikzset{external/figure name/.add={}{suffix}}'
-
-2010-06-14 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - external lib: added warning at end of document if not all graphics have
- been found.
-
-2010-06-10 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - updated file 'tikzexternal.sty' for \label and \ref support inside of
- externalized graphics
- - documented how \label and \ref support in external graphics works.
- - activated \label support for mode=convert with system call and
- documented limitations.
-
-2010-06-09 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added \tikzifinpicture{<true code>}{<false code>} macro
-
-2010-05-31 Till Tantau <tantau at users.sourceforge.net>
-
- - Worked on data visualization.
-
-2010-05-30 Till Tantau <tantau at users.sourceforge.net>
-
- - Added .list key handler.
-
-2010-05-26 Till Tantau <tantau at users.sourceforge.net>
-
- - Worked on data visualization.
-
-2010-05-06 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - improved sanity checking in number printer: now, the zero flag is
- checked even if its exponent > 0
-
-2010-04-22 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - floatparsenumber: number format errors after exponents now contain the offending
- character instead of '\relax'
-
-2010-04-12 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - number printer: added 'frac denom' and 'frac whole' for fine tuning of
- fractional number printing.
-
-2010-04-10 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - number printer: made \protect portable across TeX variants (doesn't
- produce bugs with context anymore)
- - fpu: optimized \pgfmathfloatgetflagstomacro
-
-2010-04-09 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added \pgfresetboundingbox
- - added \pgfgetlastxy coordinate macro
- - added '/pgf/images/include external/<image name>' code key.
-
-2010-04-08 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - fpu: added convenience method \pgfmathfloattoint
-
-2010-03-31 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - number printer: added 'frac' style to automatically create fractionals.
-
-2010-03-25 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - splitted basic level file pgfcoreimage.code.tex: there is now a
- pgfcoreexternal.code.tex file.
-
-2010-03-24 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - \pgfmathprintnumber is no longer a "fragile" command (it is \protect'ed
- automatically in LaTeX).
-
-2010-03-23 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed baseline alignment with "text width" option in LaTeX.
-
-2010-03-23 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - New divide function
- - Rewrote code foreach extensions. Now no longer an impenetrable mess.
- pgffor.code.tex is much larger, but contains some (as yet) undocumented
- features which may get optimised out.
-
-2010-03-19 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Image externalization: added '/pgf/images/aux in dpth' feature.
- It allows to store \label and other .aux file related stuff in the image's
- .dpth file which is processed when when the main document includes the
- image.
- The new switch is on for the semi-automatic modes of the external lib, otherwise it is
- off.
-
-2010-03-17 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - pgfkeys: added '.code n args' handler. The difference to '.code
- args={#1#2#3}' is that keys defined with 'code n args' gobble spaces
- between the arguments.
- Note: 'code 2 args' remains as-is (it has the special feature that the
- second argument is optional).
- - fixed bug in '/.add code' key handler: it didn't work properly for
- complicated keys
- - pgfkeys manual section: updated xrefs and docs
-
-2010-03-15 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - external lib: \tikzexternalize no longer needs (but still accepts) the
- main job's name. Changes are now documented and the replacement |.sty|
- file has been updated.
- - intersection lib: added 'name path global' feature.
-
-2010-03-11 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - external lib: partially fixed incompatibility with glossary package and
- documented work-around
-
-2010-03-05 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - FPU: added \pgfmathfloatifapproxequalrel
- - number printing: added style to configure |sci precision|
- - number printing: added style to configure |std=<lower e>:<upper e>|
-
-2010-03-03 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - external lib: the <real job's name> argument from \tikzexternalize is
- now optional. It can be deduced automatically if it is missing.
-
-2010-02-18 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - number printing: added 'sci generic' style to customize the appearance
- of scientific format and a 'verbatim' style which doesn't use TeX macros
- for the formatted numbers.
-
-2010-02-17 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - external lib: now, a |\jobname.auxlock| file will be generated in order
- to detect whether the \jobname.aux file is in its final state. This allows
- to export any images containing |\ref{}| manually; the automatic procedure
- will not use the .aux file.
-
-2010-02-16 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Added \ifpgfexternalreadmainaux switch. Will be used to avoid buffering
- problems during externalization mode 'convert with system call'.
-
-2010-02-16 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed bug "papersize not supported by pgfsys-xetex.def - ID: 2934982"
-
-
-2010-02-09 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Improved automatic cross referencing: auto key path prefixing failed for
- spaces in key paths.
-
-2010-02-08 Till Tantau <tantau at users.sourceforge.net>
-
- - Added "on background layer" key to backgrounds lib.
-
-2010-02-02 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added \pgfmathifisint
- - supported \nofiles in auto xref generation
-
-2010-02-01 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - externalization: both, basic layer and external lib now support \ref{}s
- inside of externalized pictures. Furthermore, they won't generate any aux
- files on their own (which wouldn't be thread safe and is not useful
- anyway)
-
-2010-01-29 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - external lib: fixed bug with figure list/makefile handling and file
- deps: calling file dependency handlings outside of a picture could result
- in compilation failures
-
-2010-01-27 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - external lib: mode=list and make now supports the force remake keys.
- - external lib: the -shell-escape switch for nested system calls is
- activated only if it was active for the main document. This should allow a
- reasonable security measure for mode=list and make (which will also work
- without system calls from within TeX).
-
-2010-01-18 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - external lib: added support for file dependencies.
- For mode=list and make, any file dependencies configured with
- \tikzpicturedependsonfile{<name>} will be checked by the generated
- makefile.
-
-
-2010-01-16 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - profiler library now uses an output file which contains the current date
- and time. Furthermore, it counts every invocation and allows to show every
- command invocation (optionally with arguments expanded).
-
-2010-01-14 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - profiler library can now profile macros with arbitrary argument pattern
- and is more rebust with respect to save stack usage
-
-2010-01-11 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - worked on profiler library and added docs for it.
-
-2010-01-10 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added first draft of the pgf 'profiler' library
-
-2010-01-07 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Fix for rounded corners affecting custom fills in rectangle
- split shape.
-
-2009-12-29 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - updated the 'make dist' documentation target such that it compresses
- every pdf object. The resulting manual is half as large than without
- compression, but it requires pdf 1.5 (at least acrobat 6.0).
-
-2009-12-22 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - external lib: some output messages did not respect the 'verbose
- IO=false' flag; fixed that
- - fixed buggy treatment of some automatic cross references in manual
-
-2009-12-15 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - external lib: improved the tikzexternal.sty package which can be used
- without pgf installed.
-
-2009-12-04 Till Tantau <tantau at users.sourceforge.net>
-
- - added spy library.
-
-2009-12-02 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - imported a patch of Andy Schlaikjer which extends the 'plot gnuplot'
- feature to read the ``unbounded point'' information provided by gnuplot.
-
-2009-11-29 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added \r at pgf@reada temporary \openin register for compatibility with
- other packages
-
-2009-11-19 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - fixed an auto xref bug which wrote '\pgfkeys{}' although the manual
- contained |\pgfkeys|.
-
-2009-11-18 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - external lib: the 'optimize command away' things where not activated
- accidentally. I fixed it.
- - added support for new paragraphs in pgfkeys values
- - fixed bug in |const plot| handler (and all its variants): the first
- coordinate was transformed twice
-
-2009-11-15 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - auto xrefs now support point coordinate systems.
- - auto xrefs now provide an interface to deal with tricky active
- characters (for |-)
- - external lib: improved compatibility with |fadings| libary.
- - replaced 'set terminal table; set output "<file>"' by 'set table "<file>"'
- to maintain compatibility with the new gnuplot version.
-
-2009-11-14 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - pgfmanual.pdf: provided a 'make dist' target in version_for_pdftex/en
- which activates automatic hyper references from codeexamples to key
- declarations.
- This utilizes larger memory limits, configured in
- doc/generic/pgf/text-en/texmf.cnf
-
-2009-11-12 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Added the 'small mindmap' style.
-
-2009-11-06 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - FPU: improved sanity checks and exception handling for the decompose
- routines (pgfmathfloatgetexponent etc) and the number parser.
- Added exception 'wrong lowlevel format'.
-
-2009-10-20 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - renamed 'text mark/style' to 'text mark style' and 'text mark/as node'
- to 'text mark as node' (there are backw. compatibility hooks).
- This should avoid confusion with '.unknown' handlers.
-
-2009-10-19 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - improved error recovery of external lib.
-
-2009-10-16 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - temporarily disabled the auto cross references -- it seems they compile
- only with increased memory.
-
-2009-10-15 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Installed preliminary version of automatic cross referencing tool.
- Now, every codeexample is parsed for options and control sequences which
- have been defined somewhere else in the document; pdf cross references are
- built automatically as well.
- - configured links to be blue throughout the document.
- - external lib: added \tikzexternaldisable such that partial externalization is possible
- although the document contains unsupported constructs (where environments
- can't be identified without macro expansion).
- The pgfmanual compiles with image externalization now.
-
-2009-10-13 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added \pgfutilsolvetwotwoleq to solve 2x2 linear equation systems using
- column pivotisation and gauss elim. Should result in improved quality
- compared with \pgftransforminvert as internal equation solver
-
-2009-10-09 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Defined \pgfdeclaregenericanchor to allow anchors which get the shape
- name as argument. Only useful internally.
-
-2009-09-15 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Fixed buggy treatment of white spaces in \jobname and 'plot function'
- using \pgfutilpreparefilename.
-
-2009-09-04 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed bug item #2834141 [wrong reversed double arrows]
- - Fixed bug item #2834233 [shapes libraries]
- - Fixed bug item #2822265 [tangent coordinates not working in CVS]
- - Changed \rm to \tf in Context.
-
-2009-07-31 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - external lib: added 'mode=list and make'. Now, image externalisation
- time can be reduced with 'make -j 2 -f mainfile.makefile'.
-
-2009-07-08 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - external lib: fixed treatment of long arguments in \tikz ... ; shortcut
- command.
-
-2009-06-30 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - fixed white space bug in \pgfkeysdeactivatefamily
- - added \pgfmathfloatvalueof
-
-2009-06-22 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added a '*' feature to '\pgfmathdeclarefunction' which overwrites
- existing functions.
-
-2009-06-11 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added '/tikz/no marks' key.
- - fixed typo in external lib documentation: the key is called 'figure name',
- not 'file name'
-
-2009-06-10 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added \pgfgettransformentries and \pgfsettransformentries.
- - updated the external library such that it deals with active characters
- in the same way as without external library.
- - fixed bug in fpu cosh, sinh and tanh
-
-2009-06-09 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - provided two new aliases for key filters, added \pgfkeyssetfamily.
-
-2009-05-29 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - allowed numbers like '.9' in fpu.
-
-2009-02-29 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Fix for signal shape.
-
-
-2009-05-22 Jin-Hwan Cho <jinhwancho at users.sourceforge.net>
-
- - Applied the patches for dvipdfmx driver,
- pgf-doc-diff.version2cvs (2009-04-18) and
- pgf-generic-diff.version2cvs (2009-04-19).
-
-2009-05-18 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Restored processing of unknown keys in the predefined key filters 'and',
- 'not', 'or' and 'false': it was not improvement...
-
-2009-05-17 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - fixed the sequence of arguments of
- \pgfqkeysactivatefamiliesandfilteroptions and
- \pgfqkeysactivatesinglefamilyandfilteroptions
- in the reference manual.
-
-2009-05-16 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - key filtering: the composed key filter handlers 'not', 'and', 'false' and 'or' now
- ignore unknown options and call the .unknown handlers.
- - pgfkeys: removed the experimental \pgfkeyssetdefaultpathforhandled method.
- It doesn't fit into the clean interface for pgfkeys - and the problem of
- default paths for handled keys can be solved better with the '/handler
- config' method.
-
-2009-04-24 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - provided API function \pgfmathfloatifflags to simplify special cases in
- FPU.
-
-2009-04-23 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added (primitive) veclen implementation for FPU.
- - added cosh, sinh, tanh to FPU
-
-2009-04-21 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - fixed bug in external lib: empty lines in tikzpicture environments were not accepted
- for some operating modes.
-
-2009-04-18 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added \pgfqpointscale
-
-2009-04-08 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added an optional argument count to 'optimize command away' in external
- library.
-
-2009-04-03 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added the |figure name| key to the externalization library
- - improved docs for externalization library
-
-2009-03-30 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - improved sanity checking of floating point comparison: does now also
- yield results for infty/nan
- - added fix for precedence bug for unary minus (fix has been suggested by
- Mark Wibrow, by mail conversation)
-
-2009-03-22 Till Tantau <tantau at users.sourceforge.net>
-
- - Replaced \z@ by 0pt for context.
-
-2009-03-21 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - external library: fixed the 'optimize' feature: pictures which won't be
- exported could not be optimized away (although they should)
-
-2009-03-20 Till Tantau <tantau at users.sourceforge.net>
-
- - Replaced \toks@ and \voidb at x by \pgfutil at toks@ and
- \pgfutil at voidb@x.
-
-2009-03-14 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - improved docs for .search also.
- - fixed initial value for 'domain' such that it really uses the default
- samples=25.
-
-
-2009-03-09 Till Tantau <tantau at users.sourceforge.net>
-
- - Added patch for context color support in luatex.
-
-2009-02-26 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - improved the optimization facilities of the external library:
- |optimize=false| will now properly restore any optimized material
- when used in \tikzset
-
-2009-02-23 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added |/handler config=all,only existing,full or existing|
- configuration.
- - added |.search also| key handler as a simple implementation of key
- search paths.
- - fixed default value for /tikz/samples at- there are no really 25
- samples, not 26. I forgot to fix this last time when I fixed 'samples'
-
-2009-02-20 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added |\pgfkeyssetdefaultpathforhandled| feature as improvement for
- multiple key paths to pgfkeys. Reference documentation and an
- application example is in the manual.
-
-2009-02-13 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added 'mark=text' which draws arbitrary TeX content as plot marks to
- plot mark library.
-
-2009-02-06 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Added key 'define function' to define simple local functions.
-
-2009-02-04 Till Tantau <tantau at users.sourceforge.net>
-
- - Worked on dv stuff.
-
-2009-02-01 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Index argument to array is automatically truncated to an
- integer.
- - Text decoration can now be aligned along or fitted to a path.
- - Added key '/pgf/decoration/reverse path' to decorate a path
- backwards.
-
-2009-01-24 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - the FPU deactivation command is now assembled once and for all during
- its first usage.
-
-2009-01-23 Till Tantau <tantau at users.sourceforge.net>
-
- - Changed the "ellipse", "circle" and "arc" commands, so that
- they take options. This gives a much clearer and more
- flexible syntax. Naturally, the old syntax continues to work
- as expected.
- - Documented svg stuff and added tikz interface. Most useful
- for quickly converting svg pictures to tikz pictures...
-
-2009-01-23 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - fixed fpu 'round' method - it rounded mantissas instead of the complete
- number before.
-
-2009-01-22 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed some math stuff
- - Renamed \pgfpathcurvebetweentime* to
- \pgfpathcurvebetweentimecontinue.
- - Added svg.path lib. It allows one to directly use
- the svg syntax for paths (like "M10 10 L 20 20"). Not yet
- documented.
-
-2009-01-06 Till Tantau <tantau at users.sourceforge.net>
-
- - Added tutorial for mind/lecture maps.
-
-2009-01-06 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - implemented fpu factorial
- - if the fixed point library is activated, the fpu will be deactivated
- automatically.
- - added draft for FPU documentation
-
-2009-01-03 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - fixed bug in fpu sqrt.
- - added logical commands to fpu.
- - fixed bug in fpu related to multi-argument-commands
- - provided feature to disable fpu manually.
-
-2008-12-31 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added support for pgf 2.00 and the fpu (works only with additional
- and technical work - the fpu file is not all which is needed)
- - added pow and greaterthan to FPU
- - fixed some FPU issues
- - fixed processing of '/tikz/domain' key - it produced N+1 samples instead
- of N.
-
-2008-12-30 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added further functions to fpu; improved sanity checking; fixed smaller
- bugs related to fpu
-
-2008-12-29 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - improved internal floating point code: it is possible to change the
- low-level representation with minimal number of code lines.
- - modified low-level floating point representation. All high level code
- should be completely unaffected; the changes are backwards compatible.
- - Wrote first draft of a floating point unit library (fpu) similar in
- spirit to the fixed point library of Mark Wibrow.
- - Moved all floating point math operations (functions) into the fpu
- library. It is now necessary to include the library in order to use
- floating point math operations. The number formatting methods are still
- available as before.
-
-2008-12-28 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added trigonometric functions to floating point unit.
-
-2008-12-17 Till Tantau <tantau at users.sourceforge.net>
-
- - Added \colorlet to ConTeXt stuff.
-
-2008-12-14 Till Tantau <tantau at users.sourceforge.net>
-
- - Worked some more on data visualization stuff. Still in
- pre-alpha.
-
-2008-12-11 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added \pgfmathfloatexp.
-
-2008-12-07 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - floating point macros now always use the basic pgf math methods for
- mantisse computations, even if the fixed point library is active.
-
-2008-12-06 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - 'mark=none' is now equivalent with 'mark=' (disables plot marks).
- The previous behavior was to issue \pgfuseplotmark{none} which is
- equivalent to \relax (and wastes time).
-
-2008-12-03 Till Tantau <tantau at users.sourceforge.net>
-
- - Changed exp function code in
- pgfmathfunctions.basic.code.tex. It is now *much* more
- precise for negative values and also more precise for
- positive values.
-
-2008-11-28 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - optimized \pgfmathfloattofixed for speed (although it introduces
- redundand zeros)
- - Added '/pgf/image/include external' command key as public interface
- to modify the '\includegraphics' command in image externalization routines.
-
-2008-11-24 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - fixed bug with |overlay| option and matrizes: now, cell pictures won't
- collapse any more if the matrix has |overlay| enabled. However, the
- matrix' bounding box won't contribute to the image as desired.
-
-2008-11-23 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added support for active '!' characters (for example in blue!30!black
- and french babel setting)
- - modified processing of 'domain' option: the argument is '\edef'ed such
- that any potentially active ':' characters will be expanded to non-active
- ones (avoiding errors in the following processing).
-
-2008-11-13 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed \pgfnodealias bug that caused chains to fail in matrices.
-
-2008-10-30 Till Tantau <tantau at users.sourceforge.net>
-
- - Added shading library, mainly containing the new color wheel
- shading donated by Ken Starks.
-
-2008-10-27 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - More fixes for insertion of spaces.
-
-2008-10-27 Till Tantau <tantau at users.sourceforge.net>
-
- - Added square arrow send by
- gvtjongahung at users.sourceforge.net.
- - Changed pgfutil-context.def so that driver detection should
- work once more.
-
-2008-10-27 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Fixed insertion of space when parsing exponents.
-
-2008-10-23 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added int truncation to floating point unit.
-
-2008-10-22 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added abs, abserror and relerror to floating point unit.
-
-2008-10-21 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added sqrt for floating point unit, built on top of pgfmathsqrt.
-
-2008-10-09 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed the wrong lengths of support vectors for circles. Used to
- be 0.555 (found by trial and error), while the correct value
- is 4/3*(sqrt(2)-1) = 0.5522847, which gives much better
- circles.
- Thanks to Ken Starks for point this out.
-
-2008-10-07 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Fixed rounded rectangle right arc bug.
-
-2008-10-06 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Fixed missing treatment of 'assume math mode' in \pgfmathprintnumber'
-
-2008-10-05 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed missing switching off of auto anchors in positioning
- library.
-
-2008-10-01 Till Tantau <tantau at tcs.uni-luebeck.de>
-
- - Fixed matrix/pdfsync incompatibility.
-
-2008-09-30 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Fixed some parsing bugs with arrays.
- - Fix for parsing of arrays in TikZ coordinates.
-
-2008-09-25 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Added number formatting option 'min exponent for 1000 sep'.
-
-2008-09-21 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Fixed bug in math parser which inserted spaces into text
- or picture.
-
-2008-09-17 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added number formatting style 'sci superscript'
- Example: formats the number 42 as 4.2^1 instead of 4.2 \cdot 10^1
-
-2008-09-15 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed bug "TikZ, the shadow library and ConTeXt MKIV
- (LuaTeX)".
-
-2008-09-14 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Fixed bug #2105132 for rounded rectangle.
- - Fixed bug #2044129 for chamfered rectangle.
-
-2008-09-12 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Added \pgfpathcurvebetweentime.
-
-2008-09-10 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed problem with nodes on a line inside a picture that is
- inside a node of another picture. Pictures will now always
- start with "pos=.5" set.
-
-2008-09-07 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Slight hack of decorations so that the input path can consist of a
- single move to. This enables stuff like
- \path [decoration={some decoration}, decorate] (4,5);
-
-2008-09-03 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - fixed small bug related to '@dec sep mark' and not-a-number in number
- formatting routines.
-
-2008-09-03 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Solutions for path intersections can now be sorted along either path.
- - \pgfintersectionsolutions is now a macro, not a count register.
-
-2008-08-31 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - fix for ``Missing character...' warnings in logfile when using
- foreach.
- - removed `trim integers' option from foreach as int function
- can now be used.
-
-2008-08-31 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Rewrote math parser. Anyone who relies on, or has hacked internal
- parser or function macros, or has defined their own functions for
- the parser will need to reconsult the code and/or documentation.
- - Files for functions definitions split (possibly permanantly) into
- different files.
- - Scaling of results at the end of the parse is no longer the default
- action. This doesn't break PGF or TikZ, but it may break user code
- that depended on this scaling. To turn it back on use
- \let\pgfmathpostparse=\pgfmathscaleresult.
- - Modifying existing functions or creating new functions must now be
- done using \pgfmathdeclarefunction and \pgfmathredeclarefunction.
- - Single argument functions do not need parentheses, provided the
- funtion is followed by a space, so sin 60 is the same as sin(60).
- But! Functions have the highest precedence, so sin 60*\x is the
- same as sin(60)*\x.
- - Added {} operators for array specification and [] operators for
- array access - see docs for details.
- - added postfix ! factorial operator.
- - added c++/java style conditional e.g., \x > 10 ? 13 : 20.
- - added >=, <=, !=, prefix !, &&, || operators.
- - added atan2, log10, log2, e, int and frac functions.
- - adapted cosh, sinh and tanh from Martin Heller.
- - added lua-style random function for generating random integers.
- - added Mod function (note capital letter). Uses floored division
- and is never negative.
- - min, max, veclen and pow can now be nested in any argument
- position.
- - min and max can now take a variable number of arguments.
- - For compatability \pgfmathmax and \pgfmathmin still take two
- arguments (although these can contain comma separated expressions).
- However \pgfmathmin@ and \pgfmathmax@ now only take
- one argument in the form \pgfmathmin@{{1}{2}{3}{4}{5}} (for 5
- arguments).
- - added hex, Hex, bin, and oct functions. These functions will not
- work properly if the post-parse scaling is turned back on.
- - 0 prefix for integers now specifies an octal number which is
- automatically converted to base 10.
- - 0x or 0X prefix for integers now specifies a hexadecimal number,
- which is automatically converted to base 10.
- - 0b or 0B prefix for integers now specifies a binary number,
- which is automatically converted to base 10.
- - "" characters turn off parsing (!) for part of an expression.
- - added width, height, and depth functions for text e.g.,
- width("Some text"), but as an expression is \edef'ed before
- parsing other commands will have to be `protected' e.g.,
- width("\noexpand\Huge Some text").
- - bugfix for tan and cot.
-
-2008-08-27 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added '/tikz/external/export={true,false}' key for externalization
- library.
-
-2008-08-05 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added documentation for basic layer externalization and baseline option.
-
-2008-07-28 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added 'showpos' key to number printing (and alias 'print sign').
-
-2008-07-22 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - fixed typo in pgfmathfloat.code.tex
- - added 'optimize command away=\macro' key to externalization library. It
- allows to discard unnecessary and possibly expensive user macros during
- export (unnecessary = not in selected picture).
-
-2008-07-18 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Fixed bug in system layer path collecting. Very long paths
- are now processed more efficiently (the bug disabled an optimization).
-
-2008-07-14 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added "marker" positions into the output of number formatting routines
- to find period positions (even if no period is typeset) and exponent
- positions. Allows alignment within auxiliary routines.
-
-2008-07-14 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed dash phase bug.
- - Fixed missing library include in automata lib.
- - Added "align" option. "text ragged" and friends are now
- deprecated. Text width need no longer not, but can, be
- specified. The following now has the expected effect: \node
- [draw,align=center] {Hello\\world.};
-
-2008-07-10 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added \pgfqpointxy and \pgfqpointxyz to complement the "quick" point
- commands in basic layer.
-
-2008-07-09 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added 'every mark' style.
- - 'mark options' simply overwrites 'every mark' (consistent with its old
- definition)
-
-2008-07-07 Till Tantau <tantau at users.sourceforge.net>
-
- - Finished circuit library and documentation (well, some
- shapes still missing, but that's something users should
- contribute).
-
-2008-07-01 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - the external library now handles active double quotes ",
- single quotes ', and active semicolons ';' in its system call
- correctly. Furthermore, \\ will expand to a normal
- backslash. The initial system call now uses double quotes
- for indows compatibility, it also contains the shell-escape
- feature for gnuplot invocations.
-
-2008-06-30 Till Tantau <tantau at users.sourceforge.net>
-
- - Did some documentation of circuit lib.
- - Removed the separated documentation of the intersection
- library and made this documentation part of the main
- documentation.
- - The intersection cs is now deprecated, the documentation
- is now only based on the intersection lib.
- - Added a "by" option so that "name intersections={of=A and
- B,by={c,d,e}}" will create an alias c for intersection-1, d
- for intersection-2 and e for intersection-3.
- - Renamed "path name" to "name path" in the intersection
- lib. This is more consistent with "name intersections".
-
-2008-06-29 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Minor changes on float stuff, wrote pgfmathfloatmultiply and
- pgfmathfloatdivide on top of pgfmathmultiply and pgfmathdivide
-
-2008-06-29 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Added `Fixed Point Arithmetic' library, which provides
- a parsing interface to the fp package. Dealing with plotting
- files still a bit crude.
- - This library means the manual now requires the fp pacakge
- to compile.
- - Fixed floor function for negative numbers.
- - Fixed \pgfmathsetseed.
- - Font and group fix for external documentation.
-
-2008-06-27 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Complete change of TikZ intersections (PGF unchanged).
- - Slight hack of the TikZ scopes library to permit local
- path naming. Should work...
-
-2008-06-26 Till Tantau <tantau at users.sourceforge.net>
-
- - Continued with circuit library.
- - Introduced subdirectories inside the pgf library
- directory and moved libs into them.
- You may need to update your checkout.
-
-2008-06-26 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - The external library now typesets as horizontal material by issueing
- \leavevmode. This fixes an inconsistency with the normal tikzpictures.
-
-2008-06-25 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Added intersection library + documentation for
- intersecting ``named'' paths.
-
-2008-06-25 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Fixed bug in external library. Now, strings like '#1' occuring
- somewhere in an image is collected correctly.
-
-2008-06-24 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Removed new intersection stuff. Need to restart from scratch...
-
-2008-06-23 Till Tantau <tantau at users.sourceforge.net>
-
- - Started working on circuit library documentation.
-
-2008-06-23 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Added PGF code and docs for intersections of two curves and
- intersections of a line and a curve.
- - Fixed bug in foreach code when registers are used with dots
- statement.
-
-2008-06-22 Till Tantau <tantau at users.sourceforge.net>
-
- - Created first version of circuit libraries for electrical
- engineering (circuits.ee.*).
- - Added libraries so that ee circuits and logical circuits can
- be accessed using the same interface. (circuits.logic.*)
- - The tikz lib shapes.gates.logic.* will no
- longer be needed, the circuits.logic.* will replace them. (The
- pgf libs shapes.gates.* are still used as before, however.)
- - Minor patch in shapes.gates.logic.US so that the .0 and .180
- anchors of a not gate or a buffer gate are the same as the
- input or output anchors.
- - All this is not documented, yet.
- - Worked some more on dv stuff, but nothing to "show", yet.
-
-2008-06-21 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Fixed parsing bug in foreach code.
- - Added "rotate fit" key to fit library, so (e.g.) a rotated
- rectangle can be fitted around nodes/coordinates.
-
-2008-06-21 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Added documentation for tikz 'external' library.
- - created pgfexternalwithdepth.tex file to use the 'baseline' information.
- - improved some issues of the external library.
- - Added '/pgf/images/draft' option
- - Modified implementation of draft images to show the image file name
- instead of the internal image name
-
-2008-06-19 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Added tikz library 'external' which allows automatic or semiautomatic
- export of each tikzpicture to pdf. Documentation is not yet ready.
- - Added self-contained latex package tikzexternal.sty to read those images
- without tikz/pgf installed.
- - Added support for the 'baseline' option in \beginpgfgraphicnamed ... \endpgfgraphicnamed
- by storing the box depth into a separate file.
-
-2008-06-19 Till Tantau <tantau at users.sourceforge.net>
-
- - Added first ideas for a circuit library.
- - Bugfixes in scoping behaviour.
- - Changed scoping rules for to path operation: Options are now
- local. This may break existing code, but is much more
- consistent with everything else and removes other problems.
- - Patched mindmap lib to account for these changed rules.
- - Added insert path option.
- - Deprecated "after node path". Use "append after command" and
- "prefix after command" instead.
- - Moved datavisualization libraries to separate subdirectory.
-
-2008-06-18 Till Tantau <tantau at users.sourceforge.net>
-
- - Changed label and pin options once again, to allow more
- flexibility. In particular, the angle can now be
- omitted. Also, for rotated main nodes the anchors are now
- chosen in more sensible ways.
-
-2008-06-16 Till Tantau <tantau at users.sourceforge.net>
-
- - Added tiny little turtle graphics library for fun.
- - Changed scoping rules for \foreach statement on a path: the
- last coordinate is now persistent not only after the foreach
- statement, but also between different iterations.
- - Changed positioning of "label" when you attach a label to a
- transformed shape. The position is now absolute with respect
- to the page, unless the "transform shape" option is used.
-
-2008-06-11 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Fixed the bug fix for character checking in foreach.
- - Updates and fixes for new foreach code.
-
-2008-06-13 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed bug in new \foreach stuff that causes an error on
- things like \foreach \i in {1,...,\foo}. If a list element
- is a macro, no is-it-a-character check is done.
-
-2008-06-11 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Checked in proposed \foreach extensions. Possibly the
- extensions would be better contained in a pgflibrary...
- - list items can now be evaluated.
- - dots replacement is context sensitive.
- - sequences indicated by dots can be character sequences.
- - a list item can be ``remembered'' in the next iteration.
- - access to the number of the current item in the list is
- provided.
-
-2008-06-09 Till Tantau <tantau at users.sourceforge.net>
-
- - Worked a bit on data visualization stuff.
-
-2008-06-07 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Added '/pgf/number format/1000 sep' and 'dec sep' shortcut
- styles which simply call 'set thousands separator' and 'set
- decimal separator'. Those option are somewhat long...
-
-2008-06-06 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed the "local bounding box" option so that it honors the
- "relevant for picture size"-if.
-
-2008-06-04 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed buggy "mid left" and "mid right" options.
- - Added "between positions" option to the "mark" option. This
- makes it possible to create paths with "repeated arrows along
- the path". This did not work before.
-
-2008-06-03 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Added '/pgf/number format/assume math mode' to disable math checks.
- This allows to assemble tabulars, apply \pgfmathprintnumber to each cell
- and use the dcolumn package to align at decimal separators (no
- documentation for that feature yet)
-
-2008-06-02 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed pgfpages in conjunction with everyshi.
-
-2008-05-31 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Semantics of |/pgf/number format/fixed zerofill| changed: it now simply
- sets a boolean which affects all numbers in fixed format; it does not
- SET fixed format. The same holds for sci zerofill.
-
-2008-05-30 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Provided \pgfmathprintnumberto macro in addition to
- \pgfmathprintnumber.
-
-2008-05-22 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Revised Lindenmayer system stuff. Documentation should
- now be up to date.
-
-2008-05-22 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Added 'xbar interval' and 'ybar interval' plot handlers.
- - Moved plot handler options to /pgf key tree.
- - added 'bar shift' option.
- - bar width option is now evaluated when needed.
- - Added documentation for plot handler library changes and for tikz-plot
- interfaces.
- - Modified pgf manual macros: codeexamples section now employs pgfkeys,
- xkeyval no longer required. Introduced style 'every codeexample' to
- maintain compatibility and allow customization for users.
-
-2008-05-21 Till Tantau <tantau at users.sourceforge.net>
-
- - Added missing documentation of moveto-decoration.
-
-2008-05-20 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Changed the processing of \pgflsystemstep. Now a TeX
- dimension, it permits a symbol to shorten the step.
-
-2008-05-19 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Added Lindemayer system drawing library.
- - Renamed the ranomization keys for the step and angle.
- - Updated the L-system docs.
-
-2008-05-19 Till Tantau <tantau at users.sourceforge.net>
-
- - Added documentation of oo-subsystem.
- - Started documentation of data visualization-subsystem.
- - Fixed hyperlink problem in dvipdfm(x)/xetex.
- - Fixed typos in Lindemayer system doc.
-
-2008-05-17 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Added \pgfmathfloatadd, \pgfmathfloatsubtract and
- \pgfmathfloatmultiplyfixed based on pgf's normal math parser
- - Added tests for float arithmetics
- - Added \pgfmathfloattoextentedprecision for 8-digit mantisse precision
- - Added documentation for these methods
- - Added basic layer input stream methods to set zero levels for [xy]comb/[xy]bar;
- allows to start bars at different offsets than x=0 / y=0.
- - Added documentation for zero level streams.
-
-2008-05-15 Till Tantau <tantau at users.sourceforge.net>
-
- - Added "path picture" option, mostly for the implementation
- of the corrected mindmap connecting bars.
- - Fixed buggy code of mindmap connect bars: Shading angles
- where sometimes wrong and shading was sometimes at the wrong
- position.
-
-2008-05-14 Till Tantau <tantau at users.sourceforge.net>
-
- - Completely rewrote management of pdf resources. This affects
- pdftex, dvipdfm, dvipdfmx and xetex backends and all front
- ends. They should now all work together in harmony, as far
- as this is supported by them.
- - Completely rewrote driver detection in plain and context
- mode.
- - dvipdfmx and xetex now use \special{pdf:literal direct},
- which can *considerably* reduce file sizes (up to a factor
- of 2).
-
-2008-05-14 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Fixed compatability issue with old calc code.
-
-2008-05-13 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - documented '.lasttry' key handler
- - introduced documentation for key filtering routines (as \input section
- in pgfmanual-en-pgfkeys.tex). Main section of pgfkeys not really updated
- yet; I only removed the 'family limitation' item in the introduction.
-
-2008-05-11 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Multiple fixes for signal shape.
-
-2008-05-03 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - added \pgfplotbarwidth and docs
- - used \pgfmathparse to assign \pgfsetplotbarwidth
- - added 'const plot mark right' to plot handler library to complete the
- different variants of left/right connected/jump handlers.
-
-2008-05-01 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Fixed parser for expressions that begin and end with braces.
-
-2008-04-27 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Added \pgfmathapproxequalto operation and documentation below
- \pgfmathequalto
- - Added some user-interface methods to floating point arithmetics
- - Added options
- /pgf/number format/set decimal separator
- /pgf/number format/set thousands separator
- /pgf/number format/skip 0.
- - Added documentation for floating point arithmetics
- - Added documentation for number printing
-
-2008-04-26 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Added PGF plot handlers to plot handler library:
- - \pgfplothandlerxbar
- - \pgfplothandlerybar
- with parameter \pgfsetplotbarwidth{} and
- - \pgfplothandlerconstantlineto
- - \pgfplothandlerjumpmarkleft
- - \pgfplothandlerjumpmarkright
- - Added Tikz-Plot handlers
- - /tikz/xbar
- - /tikz/ybar
- with option '/tikz/bar width' and
- - /tikz/const plot
- - /tikz/jump mark left
- - /tikz/jump mark right
- - Added documentation for new plot handlers to Tikz- and plot handler
- section in manual
-
-2008-04-23 Till Tantau <tantau at users.sourceforge.net>
-
- - Documented changed double line handling.
- - Made some arrow tips work with double lines.
-
-2008-04-22 Till Tantau <tantau at users.sourceforge.net>
-
- - Added (not yet documented) "inner lines", which move the
- double line mechanism from tikz to the basic layer. This
- allows the definition of special arrow tips for double lines.
- - Added (not yet documented) new arrow tip "implies" using
- this mechanism.
-
-2008-04-21 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - New version of rectangle split shape. Now supports horizontal
- as well as vertical spliting. Also supports up to 20 parts.
-
-2008-04-17 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Added pgfkeysfiltered.code.tex which provides key filtering
- and provides key-selection utilities like xkeyvals families
- - changed pgfkeys.code.tex to '\input' pgfkeysfiltered.code.tex
-
-2008-04-14 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Added \tikzaddtikzonlycommandshortcutlet and
- \tikzaddtikzonlycommandshortcutdef to install shortcut commands at the
- beginning of tikzpicture.
- - pgfkeys.code.tex: fixed incompatibility .try with .is choice
-
-2008-04-10 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed patterns in dvips mode (were broken).
-
-2008-04-03 Till Tantau <tantau at users.sourceforge.net>
-
- - Switched to everyshi in latex mode to hack into
- \shipout. Wrote direct code to hack into \shipout in plain
- mode. Hacking into \shipout in Context is still unclear.
- - Added space arrow.
-
-2008-4-02 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Reimplemented parsing of operands.
-
-2008-04-01 Till Tantau <tantau at users.sourceforge.net>
-
- - Added cirlce solidus shape by Manuel Lacruz.
-
-2008-03-19 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - `curve control points' decoration no longer exists. It is
- replaced by the `show path construction' decoration.
- - added code + docs for defining changable patterns.
- - Parser altered to access \pgfmathfloatparsenumber when
- \ifpgfmathfloat is true (old interface to \pgfmathfloat deleted).
-
-2008-03-18 Christian Feuersaenger <ludewich at users.sourceforge.net>
-
- - Added generic/pgf/math/pgfmathfloat.code.tex
- - Modified pgfmath.code.tex to include pgfmathfloat.code.tex
- - Added generic/pgf/testsuite/mathtest/pgfmathtestsuite.tex [dvipdfm/pdflatex]
- which provides testing for pgfmathfloat.code.tex
-
-2008-03-17 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed minimum width handling in rounded rectangle shape.
-
-2008-03-12 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Added key for rectangle split to ignore empty parts.
- - Extended \pgfshadecolortorgb to define macros for the
- individual color components.
-
-2008-03-08 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Added `curve control points' decoration for drawing
- curve controls. NB: names/keys may change.
-
-2008-03-07 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Fix for (some) `hidden' bugs: ``Missing character:
- There is no <char> in font nullfont!''. This is usually
- only seen in log file. Fixed for star, circular sector
- and math macros.
-
-2008-03-03 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed documentation "placment" replaced by "positioning"
- - Fixed ConTeXt page resource problem. (ConTeXt support is
- still not as smooth as support of other formats)
- - Checked in some data visualization stuff, without any
- documentation. Everything still likely to change
- completely.
- - Moved module management to pgfutil.
- - Added support for simple oo-programming, not documented.
-
-2008-02-26 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed bug in pgfkeysaddvalue.
- - Fixed bug of stack leak in function shadings in postscript.
- - Fixed missing image inclusion documentation.
- - Fixed atan bug in documentation example.
- - Fixed missing dependency of chains--positioning library
- - Fixed missing dependency of mindmap--decorations library
-
-2008-02-20 Till Tantau <tantau at users.sourceforge.net>
-
- Released version 2.00
-
-2008-02-14 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed "initial"/"accepting" distance bug.
- - Fixed wrong intersection computation bug.
-
-2008-02-13 Till Tantau <tantau at users.sourceforge.net>
-
- - Added "local bounding box" option for Fabien...
-
-2008-02-12 Till Tantau <tantau at users.sourceforge.net>
-
- - Finished chains and chain tutorial.
- - Fixed height of rounded rectangle shape.
-
-2008-02-11 Till Tantau <tantau at users.sourceforge.net>
-
- - Added "auto end on length" and "auto corner on length"
- options to decorations.
- - Added "if input segment is closepath" option to
- decorations.
- - Renamed "subpath" in decoration code to "inputsegment". In
- the pdf-specification (and in the rest of the pgf manual) a
- path is made up of subpath, which are started by movetos,
- and these in turn are made up of segments. In decorations,
- segments used to be called subpaths, which was too
- confusing...
- - More renaming in chains, but its stabilizing now.
- - Started a tutorial on chains.
-
-2008-02-10 Till Tantau <tantau at users.sourceforge.net>
-
- - Moved chain part inside "positioning" into "chains"
- library.
- - Renamed things in the chains library, yet again and added
- branches.
- - Fixed bug with "xyz of" placements.
-
-2008-02-08 Till Tantau <tantau at users.sourceforge.net>
-
- - Renamed "placements" library to "positioning".
- - Renamed and changed all chain commands.
- - Added scopes library.
- - Renamed cap and join to line cap and line join (but old ones
- are still available).
-
-2008-02-07 Till Tantau <tantau at users.sourceforge.net>
-
- - Patched Makefiles according to suggestion by Hans Meine.
- - Fixed bug: duplicate fading name in pgflibraryfadings.
- - Fixed bug: wrong size of functional shading in dvips.
- - Fixed bud: documentation a4paper setting.
- - Fixed bug: Manual now compiles with tex4ht once more.
- - Fixed bug: Manual now is hyperlinked also for dvipdfm.
- - Fixed bug: wrong size of all shadings in svg code.
- - Slight change in placement lib, default chain now has a
- name.
-
-2008-02-07 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Removed internal asin tables as asin is now calculated from
- acos tables.
- - Misc. updates for shapes docs.
-
-
-2008-02-06 Till Tantau <tantau at users.sourceforge.net>
-
- - Changed fit library, so that nodes are now "completely"
- fitted.
- - Changed tutorial so that fit library is now used.
- - Added placement library and documentation.
-
-2008-02-05 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixes in snake compatibility code.
- - Added dvipdfmx support (identical to dvipdfm).
- - Fixed missing braces and color stack problem in
- shapes.logic.IEC.
-
-2008-02-04 Till Tantau <tantau at users.sourceforge.net>
-
- - Patched (and hopefully fixed) hyperref support.
- - Made matrix inversion more precise.
- - Added tutorial for geometric constructions.
- - Fixed partway and intersection computations.
- - Added line to circle intersection.
-
-2008-02-03 Till Tantau <tantau at users.sourceforge.net>
-
- - Added through library (still very simple...).
- - Added computation of intersection of circles and tangent to
- a circle.
-
-2008-01-31 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Updated isosceles triangle shape. Positioning of node
- contents improved. Added key so minimum width and height
- can be applied independently
- - Fix for trapezium shape for minimum height. This fix may
- ``break'' exisiting code by making any trapezium enlarged using
- minimum height to appear slightly wider than before. But...
- - Added keys for trapezium so that minimum width and height
- can be applied independently, or to just the `body' of the
- trapezium.
-
-2008-01-30 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Reimplemented shape `tape'. Anchors should behave a bit
- better now.
-
-2008-01-29 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed problem with pin a relative coordinates.
-
-2008-01-27 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Added `logic gate IEC symbol color` key to change color
- for all symbols simultaneously.
- - Fix for loading US and IEC shape library separately.
- - Misc. updates for decoration docs.
-
-2008-01-26 Till Tantau <tantau at users.sourceforge.net>
-
- - Modified calc library. Working on documentation.
- - Added calc library and ($...$) notation for coordinates.
-
-2008-01-25 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Reorganised logic shapes. Now two libraries:
- shapes.gates.logic.US (for `American' gates) and
- shapes.gates.logic.IEC (for rectangular gates).
- Gates are now named `and gate US' or `and gate IEC' etc.
- TikZ key `use US style logic gates' and `use IEC style
- logic gates' set up styles so that (e.g.) `and gate'
- becomes a synonym for `shape=and gate US'. See docs for
- details.
-
-2008-01-23 Till Tantau <tantau at users.sourceforge.net>
-
- - Added decorations.markings.
-
-2008-01-22 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed pgfpatharc: Fractional angles are now handled
- correctly.
- - Fixed incompatability with bm package: Changed hack to
- \@@end to \AtEndDocument.
- - Changed things in the math engine to speed up things: First,
- \pgfmath at returnone now uses simpler and faster code. Second,
- some marshals in the internal math commands like
- \pgfmathadd@ have been removed. This makes it necessary that
- the second operand in a call to an internal math macro no
- longer uses \pgf at x or \pgf at xa and I fixed the 3 places where
- this was the case.
- - Added footprint decoration and merged Marks footprints.
- - Added buffering to the subpath mechanism. This speeds up
- constructions of very long paths by a factor of 10 or more.
- - Fixed missing declaration of \iftikz at decoratepath in
- tikz.code.tex.
-
-2008-01-22 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Added logic shapes library. Includes AND gate, NAND gate,
- OR gate, NOR gate, XOR gate, XNOR gate and NOT gate.
-
-2008-01-22 Till Tantau <tantau at users.sourceforge.net>
-
- - Fooled around with title page.
- - Changed TikZ path scoping rules: Scopes no longer affect the
- last point on a path. This was a nuiseance before and became
- a real problem with decorations.
- - Finished my move from snakes to decorations. Also finished
- documentation.
- We are now ready for a new release!
-
-2008-01-19 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Removed \externalcode command for decoration states as
- persistent pre/postcomputation stuff does a similar job.
-
-2008-01-18 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Added \externalcode command for decoration states. Allows
- code to be executed outside the TeX-group the state code
- is executed in.
-
-2008-01-17 Till Tantau <tantau at users.sourceforge.net>
-
- - Split decoration lib into several libs.
- - Renamed lineto decoration to curveto decoration.
- - Renamed many keys of decorations and snakes to shorter
- names.
- - Changed the tikz setting of decoration options.
- - No documentation yet.
-
-2008-01-17 Till Tantau <tantau at users.sourceforge.net>
-
- - Started merging snakes and decorations. Not yet finished.
-
-2008-01-16 Till Tantau <tantau at users.sourceforge.net>
-
- - (Partly) rewrote the tikz support for decorations. There is
- now a "decorate" path command:
- \draw ... decorate [decoration=zigzag] { (0,0) -- (1,2) };
- This yields a much cleaner interface.
- - There is also a decorate=true/false option that causes the
- whole path to be decorated.
- - Decorated path can now contain nodes.
- - Node paths can also be decorated now.
- - Fixed missing \pgftransformreset inside decoration
- environment.
-
-2008-01-15 Till Tantau <tantau at users.sourceforge.net>
-
- - Changed the decoration documentation a bit. Still not quite
- perfect...
- - Restructured the basic layer. There is a central core (which
- got slightly larger) and "modules", which can be included
- using \usepgfmodule. All the pgfbaseXXX files are now
- obsolete and only included for the old ones for
- compatibility.
- The {pgf} package no longer includes the modules "pattern",
- "snakes" and "decorations" by default. However, these
- modules are loaded by their respective libraries, so,
- normally, no one will notice.
-
-2008-01-15 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Fix for minimum size in ellipse split shape.
- - Added decorations documentation.
-
-2008-01-14 Till Tantau <tantau at users.sourceforge.net>
-
- - Coordinates like (2,3cm) are now allowed. Has the same
- effect as ([shift={(2,0)}]0pt,3cm), which is what everybody
- would expect.
- - Moved tikz hacks inside tikzlibrarydecorations into
- tikz.code.tex itself.
-
-2008-01-14 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Fix for save stack overflow in decorations.
- - Renamed \pgfdecorate \endpgfdecorate, now \pgfdecoration
- \endpgfdecoration. Makes it more consistent with...
- - Meta decorations! Automata that decorate the path with
- decoration automata! Increased fancyness! Docs soon.
- - Removed a bunch of keys from \tikzlibrarydecorations as
- not really necessary.
-
-2008-01-13 Till tantau <tantau at users.sourceforge.net>
-
- - Changed shadow lib once more and added it to CVS.
-
-2008-01-13 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Added decorations files. Docs to follow soon(ish).
- - Fix for `star point ratio' and `star point height'
- keys in star shape.
-
-2008-01-11 Till Tantau <tantau at users.sourceforge.net>
-
- - Added copy shadow.
-
-2008-01-10 Till Tantau <tantau at users.sourceforge.net>
-
- - Added random steps snake.
-
-2008-01-09 Till Tantau <tantau at users.sourceforge.net>
-
- - Added shadow library, removed shadow shapes (no longer
- needed).
- - Added preaction and postaction options (very useful).
- - Added transform canvas option.
- - Added scale around option.
- - Moved tikz.code.tex to tikz/tikz.code.tex
- - Moved .../libraries/pgflibrarytikzXXXX.code.tex to
- .../frontendlayer/tikz/libraries/tikzlibraryXXXX.code.tex.
-
-2007-12-20 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed missing example bbs for dvipdfm.
- - Fixed buggy swirl shading.
- - Finished documentation switch from \itemoption to {key}.
- - Changed TikZ fading options. More consistent and easier to use,
- now.
-
-2007-12-20 Mark Wibrow <vibrovski at users.sourceforge.net>
- - Added `ellipse split' shape.
-
-2007-12-17 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed spaces problem with external graphics.
- - Added [missing] option to supress children.
- - Reduced number of libs includes by {shapes} to geometric,
- misc and symbol. Shapes is now more or less deprecated.
- - Added shadowed shapes.
- - Added pgfsys-xetex for native xetex support.
- - Added documentation hint on scoping inside \foreach.
- - Fixed bug [1620194] "tikz library mindmap requires trees"
- - Fixed bug [1787504] "Usage of \@namelet in xxcolor.sty clases with memoir."
- - Fixed bug [1809693] "background rectangle is scaled".
-
-2007-12-13 Till Tantau <tantau at users.sourceforge.net>
-
- - Added fadings.
- - Added functional shadings.
- - Fixed bug in double drawing with arrows.
-
-2007-11-24 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Fix for all math functions with two arguments.
- - Fix for tikz when y-coordinate is a function within braces.
- - Fix for distance calculation in shape snake.
- - Added `cloud callout' shape.
- - cloud shape can now use (or ignore) `aspect' key.
- - More key updates/fixes for shapes.
-
-2007-11-23 Till Tantau <tantau at users.sourceforge.net>
-
- - Corrected minimum size of a diamond shape (was twice the
- correct size -- this may break existing code, but that cannot
- be avoided!).
- - Changed some more documentation from \itemoption to {key}s. Not
- yet finished.
-
-2007-11-19 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Updated math documentation. Code examples now consistent with
- the rest of the manual.
-
-2007-11-12 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed hyperref-dvipdfm-problem.
-
-2007-11-10 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Updated cloud shape for minimum size calculations.
- - Reimplemented rounded rectangle. Now supports concave arcs.
- - Removed all stuff for Fancy hyperlinked picture of shapes.
-
-2007-11-07 Till Tantau <tantau at users.sourceforge.net>
-
- - \foreach will now allow a macro name to be given as list
- argument (as in \foreach \x in \mylist {...})
-
-2007-10-29 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed keys problem when .try is used with a comma.
-
-2007-10-28 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Fixed shape snake for drawing to other pictures.
- - Added shapes `arrow box' shape, `rectangle callout` and
- `ellipse callout'.
-
-2007-10-26 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed dvipdfm problem with hyperref.
-
-2007-10-13 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - pgfbasesnakes: changed length calculation and added angle calculation.
- - added `shape snake' to snake library.
- - added cylinder shape to geometric shapes.
- - renamed `bevelled rectangle'. Now called `chamfered rectangle'.
- - renamed pgfsavepgf at process. Now called pgfextract at process.
-
-2007-10-12 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Fixed bug #1803811 gobbling of tokens after \pgfmathaddtocounter.
- - Fixed insertion of spaces after \pgfmath stuff.
- - Fixed bug #1811862.
-
-2007-09-19 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Fix for cot and tan. Now correctly return negative values.
- - Added `...head indent' option for single and doube arrow
- shapes (allows the arrowheads to look more `fancy').
- - Updated tikzshapes.geometric and tikzshapes.symbols so
- the incircle border construction can be used in TikZ
- if libraries are loaded separately.
- - Misc. fixes and updates for shapes doc.
-
-2007-09-18 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Fixed isosceles triangle, circular sector and circle split
- for `text width' key.
- - Fixed star, cloud and rectangle shape for using anchors for
- positioning.
- - New shapes:Rectangle split, rounded rectangle,
- bevelled rectangle, tape, signal, single arrow and double arrow.
- - Fancy hyperlinked picture of all shapes added to shape lib. doc.
- - Updated math doc.
- - Fix for square root.
- - Fix for parsing negative box dimensions.
- - (Yet another) division version.
-
-
-2007-08-20 Mark Wibrow <vibrovski at users.sourceforge.net>
- - Added cloud shape.
- - Updated all shapes (and doc.) for pgfkeys.
- - Changed Kite key: Now use (e.g.) '/pgf/kite vertex angles=60 and 70' (see doc.)
- - Added keys /pgf/shape aspect and /pgf/shape aspect inverse, (but \pgfsetshapeaspect
- and, TikZ option `apsect' are still there for compatability).
- - Updated diamond shape (and doc.) to use keys.
- -`Housekeeping' stuff (moved some macros around).
-
-
-2007-08-10 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Trapezium shape updated. No longer uses left and right
- extensions. Uses internal angles instead.
- - Updated pgfkeys for shapes (not done \pgfsetshapeaspect for
- diamond shape)
-
-2007-08-09 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Added new starburst shape to misc shapes.
- - Updated all shapes to pgfkeys.
-
-2007-08-08 Till Tantau <tantau at users.sourceforge.net>
-
- - Added fitting library.
-
-2007-07-28 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Fixed parser for expressions beginning with groups
- preceeded by signs e.g. -(4+3)
- - This also fixes problem in TikZ when specifiying coordinates
- contatining groups. Coordinates in the form (1, {(2+3)}) will
- work even if there are spaces after the comma.
-
-2007-07-23 Till Tantau <tantau at users.sourceforge.net>
-
- - Started to use new pgfkeys also in pgf. In particular,
- commands like \pgfsetshape... are now replaced by keys.
- (Not yet finished.)
-
-2007-07-21 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Added new geometric shape: `circular sector'.
- - Updated pgfbaseshapes.code.tex for saved macro support.
-
-2007-07-12 Till Tantau <tantau at users.sourceforge.net>
-
- - Added overlay functionality to \node.
- - Added pgfkeys and its documentation.
-
-2007-07-10 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Updated all `new' geometric shapes: polygon, star, trapezium,
- semicircle, isosceles triangle, kite, dart.
- - `isosceles triangle' and `simple isosceles triangle' combined
- into one shape.
- - more accurate anchor positioning in polygon and star shapes.
- - Added `shape border uses incircle' option for supporting shapes.
- - Added `shape border rotate' option for supporting shapes.
-
-2007-07-04 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Added support for sec, cosec and cot.
-
-2007-07-03 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed missing compatibility \pgfsincos
- - Fixed wrong \pgfmathsincos
-
-2007-06-23 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Added semicircle shape.
- - Updated documentation for all new shapes.
-
-2007-06-22 Mark Wibrow <vibrovski at users.sourceforge.net>
-
- - Added support for savedmacros in \pgfdeclareshape.
- - Added trapezium shape.
- - Added support for `legacy' calc code (\real, \minof, \maxof, \ratio).
- - Fixed 'public' sqrt macro in \pgfmathoperations.code.tex
- - Added isosceles triangle shape: uses incircle, but supports arbitrary
- rotation of border.
- - Added simple isosceles triangle shape: much tighter fit of node
- contents, but restricted rotation of border.
-
-2007-06-21 Till Tantau <tantau at users.sourceforge.net>
-
- - Fixed text width problem in matrix of nodes.
-
-2007-01-18 Till Tantau <tantau at users.sourceforge.net>
-
- Version 1.18:
-
- - Added regular polygon and star shapes (by Mark Wibrow).
- - Added graphic externalization commands.
- - Added barycentric coordinate system.
- - Added direct TikZ plotting of function based on math engine.
- - Added math documentation into main documentation.
- - Added Mark Wibrow's math library.
- - Added calendar support.
- - Added matrix stuff.
- - Added automatic driver selection for xetex.
- - Added "growth parent anchor" option.
- - Fixed superfluous spaces in quick math parse code
- - Fixed superfluous \newboxes in math and image code
- - Fixed mth parser to recognize \wd\mybox.
- - Fixed wrong \pgfmathsetrandomseed
- - Fixed wrong \pgfmathradians@
- - Fixed problems with long mantissa and plain tex math code.
- - Fixed things so that \setlength works in pictures, once
- more.
- - Fixed selectfont problem in pdfsys-dvipdfm.def
- - Fixed problem with lost lastx/lasty in foreach in TikZ.
- - Fixed snake+rectangle+transform problem.
- - Fixed rectangle+rounded corner problem.
- - Fixed postscrip eofill1 problem.
- - Fixed amsmath/pgf clash because of wrong definition of \:
- - Fixed size of hyperlinks inside nodes.
- - Fixed ConTeXt problem in pgfbaseplot.
- - Fixed .aux problems in plain and ConTeXt mode. Using .pgf as
- extension now.
-
-2006-10-26 Till Tantau <tantau at users.sourceforge.net>
-
- Version 1.10:
-
- - Renamed \pgf at sys@pdf at mark to \pgfsyspdfmark.
- - Fixed the ConTeXt support so that it is usable (which is wasn't).
-
-2006-10-11 Till Tantau <tantau at users.sourceforge.net>
-
- Version 1.09:
-
- - Added \usepgflibrary and \usetikzlibrary to simplify adding
- new libraries.
- - Added native ConTeXt support in the form of module
- wrappers.
- - Added patterns.
- - Added crosses snake.
- - Added to and edge path operations.
- - Added to path library. In particular, this gives decent
- curved paths.
- - Added tikz automata library.
- - Added tikz er diagram library.
- - Added tikz Petri net library.
- - Added tikz mindmap library.
- - Added access to nodes in other pictures (!).
- - Added extended baseline setting.
- - Added functionality to add new coordinate systems.
- - Added polar xy coordinate system.
- - Added diamond shape (!).
- - Added plot mark phase, repeat and indices.
- - Added text height and text depth options.
- - Added label and pin options.
- - Added automatic node placement (!).
- - Added pgfsys-dvi.def for pure dvi mode. Supports only
- black and white drawing (not documented and not really usable).
- - Added 3d library (not documented and not really usable).
- - Cleared up license chaos.
- - Reorganized library documentation.
- - Removed pgflibraryautomata, use pgflibrarytikzautomata instead.
- - Fixed tree level option bug.
- - Fixed missing options for coordinates.
- - Fixed bug in TikZ parabola code.
- - Fixed bug in TikZ snake cycle code.
- - Fixed bug with empty list in pgffor
- - Fixed bug in code for insertion of dvips header specials.
- - Fixed bug in shading code (wrong bigpoint correction).
- - Fixed bug #1472666.
- - Fixed bug #1473255.
- - Fixed bug #1526175.
- - Fixed bug #1542512.
- - Fixed bug in TikZ transformation code for nested pictures.
- - Fixed patch #1443606.
- - Fixed path #1526178.
-
-2005-11-16 Till Tantau <tantau at users.sourceforge.net>
-
- Version 1.01:
-
- - Added textures support.
- - Added text opacity option.
- - Fixed bug in pgfbasesnakes.code.tex causing lot's of
- 'missing = in nullfont' message in log file.
- - Fixed bug that made plain tex mode unusable.
- - Fixed missing pgfsys-vtex.def in FILES.
- - Fixed wrong box placements in compatibility mode.
- - Fixed SVG support to create legal xml.
- - Moved documentation to doc/generic/pgf.
-
-2005-10-23 Till Tantau <tantau at users.sourceforge.net>
-
- Version 1.00:
-
- - There have not been any real changes since 0.99.
-
-
-2005-10-11 Till Tantau <tantau at users.sourceforge.net>
-
- Version 0.99:
-
- - Added vtex support (finally!).
- - Added multi part mechanism to nodes.
- - Added very simple pgflibraryautomata.
- - Changed coordinate shape such that it now never produces a
- text label.
- - Renamed \pgfshapebox to \pgfnodeparttextbox (made necessary
- by the node part mechanism).
-
-2005-09-20 Till Tantau <tantau at users.sourceforge.net>
-
- Version 0.98:
-
- - Added transparency to PGF (quite nice...).
- - Added foreach option to child path operation (also nice...).
- - Fixed problem with \\ in centered text.
- - Fixed problem with hyperlinks in nodes.
- - Fixed wrong arrows in trees.
-
-2005-09-08 Till Tantau <tantua at users.sourceforge.net>
-
- Version 0.97:
-
- - Reorganised directory structure of documentation.
- - Added tree mechanism.
- - Added snake mechanism.
- - Added layer mechanism.
- - Added new shapes: cross out, strike out, forbidden sign.
- - Added some more documentation.
- - Added "none" drawing and filling colors.
- - Added pgflibrarytikzbackgrounds.
- - Changed syntax of \pgfqbox.
- - Changed syntax of several \pgfsys at xxxx commands.
- - Added SVG support / a tex4ht backend. (Complicated text
- inside svg graphics is not supported well, but that's mainly
- a shortcoming of the svg specification.)
-
-2005-07-06 Till Tantau <tantau at users.sourceforge.net>
-
- Version 0.96:
-
- This is a beta version. Version 1.00 will be the first stable
- version of TikZ/pgf.
-
- - Fixed spacing problem in dvips.
- - Changed syntax of plot and plot marks.
- - Changed syntax of ellipse and elliptical arc options.
- - Fixed baseline bug in tikz.
- - Fixed bug in pgfpages.
- - Introduced "every xxxx" styles, got rid of shape actions option.
- - Added "intersection of" syntax for coordinates.
- - Started revising the documentation.
- - Changed names of some pgfpages commands.
- - Changed syntax of parabola command.
- - Proof read documentation.
-
-2005-06-12 Till Tantau <tantau at users.sourceforge.net>
-
- Version 0.95:
-
- This is an *alpha* prerelease version. Syntax changes
- are still possible before the beta version. Version 1.00
- will be the stable version.
-
- Changes (this is almost a new program):
- - Introduced three layers: system, basic, frontends.
- - Wrote two frontends: TikZ (*most* useful!) and pgfpict2e (a
- demonstration).
- - Largely rewrote the basic layer.
- - Largely rewrote the system layer.
- - Completely rewrote the documentation.
- - Added two utilities: pgfpages and pgffor.
- - Made macro naming more consistent.
- - Added plain tex support.
- - Added dvipdfm support.
- - Restructured directory structure.
- - Zillions of small bugfixes.
-
-2004-10-20 Till Tantau <tantau at users.sourceforge.net>
-
- Version 0.65:
- - Fixed bug in pgfshade.sty that arises in conjunction with
- calc.sty and latex+dvips.
-
-2004-10-08 Till Tantau <tantau at users.sourceforge.net>
-
- Version 0.64:
- - Fixed missing depth of \pgfnodebox.
- - Fixed bug that caused infinite stack loop with pictures inside
- nodes.
-
-2004-07-08 Till Tantau <tantau at users.sourceforge.net>
-
- Version 0.63:
- - Added \pgfextractx, \pgfextracty, \pgfcorner.
- - Added some documentation on masks and images.
- - Fixed a somewhat obscure bug having to do with the modification
- of \spaceskip.
- - \pgfex and \pgfem no loner needed. Use 1ex etc. once more.
- - calc.sty is now supported.
-
-2004-07-06 Till Tantau <tantau at users.sourceforge.net>
-
- Version 0.62:
- - Fixed problem in xxcolor with option "gray" and xcolor.
- - Switched to xcolor version 2.00.
- - Added eofill and eofillstroke commands.
- - Added option to shadings, so that they are automatically
- recalculated upon color changes.
- - Changed names of example images to start with pgf.
-
-2004-04-07 Till Tantau <tantau at cs.tu-berlin.de>
-
- Version 0.61:
- - Added \pgfex and \pgfem dimensions.
- - Fixed bug that causes pgfshade to fail to work if xcolor
- is called with option "gray".
- - Fixed PostScript code for radial shadings.
- - xxcolor now works with xcolor 1.10 (and only 1.10).
-
-2004-02-18 Till Tantau <tantau at cs.tu-berlin.de>
-
- Version 0.60:
- - Replaced some commands for the postscript code by shorter
- versions for smaller file size.
- - Fixed bug in pgfbox command that caused incorrect kerning in
- postscript output.
- - Fixed bug in pgfsys at defineimage that made page inclusion
- impossible.
- - Fixed bug in pgfshading that did not reset dash patterns in
- shadings in the PostScript version.
- - Spaces are now allowed inside the pgfpicture environment.
- - Added \pgfgrid command.
-
-2004-01-13 Till Tantau <tantau at cs.tu-berlin.de>
-
- Version 0.50:
- - Switched to version 1.06 of xcolor.
- - Core pgf no longer relies on xxcolor.
- - The syntax of the mechanism for choosing alternate images and
- shadings is more flexible now. The syntax has been changed
- (mainly, you now have to have a dot between the original name and
- the alternate extension).
- - Some xxcolor commands have been removed.
-
-2003-12-02 Till Tantau <tantau at cs.tu-berlin.de>
-
- Version 0.43:
- - Fixed \normalcolor, so that it works also in preamble.
-
-2003-11-20 Till Tantau <tantau at cs.tu-berlin.de>
-
- Version 0.42:
- - Documented masks.
- - Fixed bug in pgf.sty for nested pictures.
-
-2003-11-18 Till Tantau <tantau at cs.tu-berlin.de>
-
- Version 0.41:
- - Added masks (not yet documented).
-
-2003-11-12 Till Tantau <tantau at cs.tu-berlin.de>
-
- Version 0.40:
- - Changed syntax of \pgfdeclareimage. Uses key=value scheme
- now. All parameters may now be omitted.
- - Added \pgfimage command.
- - Option for selecting a specific page from an image file.
- - Fixed bug in xxcolor.sty having to do with \@ifempty command.
- - Reworked the formatting of the user's guide.
-
-2003-10-29 Till Tantau <tantau at cs.tu-berlin.de>
-
- Version 0.34:
- - Shadings now work together with color mix-ins.
- - Shadings can now take color names as parameters.
-
-2003-10-24 Till Tantau <tantau at cs.tu-berlin.de>
-
- Version 0.33:
- - Fixed problem with missing \leavevmode in \pgfuseimage.
- - Reworked code for image inclusion.
- - "Draft" option is now supported. Supresses reading of images.
- - Added xxcolor package.
- - pgfpictures will now inherit the color from their surroundings.
-
-2003-10-20 Till Tantau <tantau at cs.tu-berlin.de>
-
- Version 0.32:
- - Updated installation procedure information.
-
-2003-09-18 Till Tantau <tantau at cs.tu-berlin.de>
-
- Version 0.31:
- - One parameter for \pgfdeclareimage may now be omitted. It will
- be computed automatically.
-
-2003-08-21 Till Tantau <tantau at cs.tu-berlin.de>
-
- Version 0.30:
- - Created ChangeLog
- - Added pgfshade.sty
-
-
-
-;;; Local Variables:
-;;; coding: undecided-unix
-;;; End:
Deleted: trunk/Master/texmf-dist/doc/generic/pgf/FILES
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/FILES 2023-01-15 20:55:58 UTC (rev 65552)
+++ trunk/Master/texmf-dist/doc/generic/pgf/FILES 2023-01-15 20:58:27 UTC (rev 65553)
@@ -1,918 +0,0 @@
-doc/generic/pgf/ChangeLog
-doc/generic/pgf/FILES
-doc/generic/pgf/INSTALL
-doc/generic/pgf/README.md
-doc/generic/pgf/RELEASE_NOTES.md
-doc/generic/pgf/description.html
-doc/generic/pgf/extract.lua
-doc/generic/pgf/images/brave-gnu-world-logo-mask.bb
-doc/generic/pgf/images/brave-gnu-world-logo-mask.eps
-doc/generic/pgf/images/brave-gnu-world-logo-mask.jpg
-doc/generic/pgf/images/brave-gnu-world-logo.25.bb
-doc/generic/pgf/images/brave-gnu-world-logo.25.eps
-doc/generic/pgf/images/brave-gnu-world-logo.25.jpg
-doc/generic/pgf/images/brave-gnu-world-logo.bb
-doc/generic/pgf/images/brave-gnu-world-logo.eps
-doc/generic/pgf/images/brave-gnu-world-logo.jpg
-doc/generic/pgf/images/brave-gnu-world-logo.xbb
-doc/generic/pgf/images/pgfmanual-mindmap-1.pdf
-doc/generic/pgf/images/pgfmanual-mindmap-2.pdf
-doc/generic/pgf/licenses/LICENSE
-doc/generic/pgf/licenses/gnu-free-documentation-license-1.2.txt
-doc/generic/pgf/licenses/gnu-public-license-2.txt
-doc/generic/pgf/licenses/latex-project-public-license-1.3c.txt
-doc/generic/pgf/licenses/manifest-code.txt
-doc/generic/pgf/licenses/manifest-documentation.txt
-doc/generic/pgf/pgfmanual.pdf
-doc/generic/pgf/text-en/pgfmanual-en-base-actions.tex
-doc/generic/pgf/text-en/pgfmanual-en-base-animations.tex
-doc/generic/pgf/text-en/pgfmanual-en-base-arrows.tex
-doc/generic/pgf/text-en/pgfmanual-en-base-decorations.tex
-doc/generic/pgf/text-en/pgfmanual-en-base-design.tex
-doc/generic/pgf/text-en/pgfmanual-en-base-external.tex
-doc/generic/pgf/text-en/pgfmanual-en-base-images.tex
-doc/generic/pgf/text-en/pgfmanual-en-base-internalregisters.tex
-doc/generic/pgf/text-en/pgfmanual-en-base-layers.tex
-doc/generic/pgf/text-en/pgfmanual-en-base-matrices.tex
-doc/generic/pgf/text-en/pgfmanual-en-base-nodes.tex
-doc/generic/pgf/text-en/pgfmanual-en-base-paths.tex
-doc/generic/pgf/text-en/pgfmanual-en-base-patterns.tex
-doc/generic/pgf/text-en/pgfmanual-en-base-plots.tex
-doc/generic/pgf/text-en/pgfmanual-en-base-points.tex
-doc/generic/pgf/text-en/pgfmanual-en-base-quick.tex
-doc/generic/pgf/text-en/pgfmanual-en-base-scopes.tex
-doc/generic/pgf/text-en/pgfmanual-en-base-shadings.tex
-doc/generic/pgf/text-en/pgfmanual-en-base-transformations.tex
-doc/generic/pgf/text-en/pgfmanual-en-base-transparency.tex
-doc/generic/pgf/text-en/pgfmanual-en-drivers.tex
-doc/generic/pgf/text-en/pgfmanual-en-dv-axes.tex
-doc/generic/pgf/text-en/pgfmanual-en-dv-backend.tex
-doc/generic/pgf/text-en/pgfmanual-en-dv-examples.tex
-doc/generic/pgf/text-en/pgfmanual-en-dv-formats.tex
-doc/generic/pgf/text-en/pgfmanual-en-dv-introduction.tex
-doc/generic/pgf/text-en/pgfmanual-en-dv-main.tex
-doc/generic/pgf/text-en/pgfmanual-en-dv-polar.tex
-doc/generic/pgf/text-en/pgfmanual-en-dv-stylesheets.tex
-doc/generic/pgf/text-en/pgfmanual-en-dv-visualizers.tex
-doc/generic/pgf/text-en/pgfmanual-en-gd-algorithm-layer.tex
-doc/generic/pgf/text-en/pgfmanual-en-gd-algorithms-in-c.tex
-doc/generic/pgf/text-en/pgfmanual-en-gd-binding-layer.tex
-doc/generic/pgf/text-en/pgfmanual-en-gd-circular.tex
-doc/generic/pgf/text-en/pgfmanual-en-gd-display-layer.tex
-doc/generic/pgf/text-en/pgfmanual-en-gd-edge-routing.tex
-doc/generic/pgf/text-en/pgfmanual-en-gd-examples.tex
-doc/generic/pgf/text-en/pgfmanual-en-gd-force.tex
-doc/generic/pgf/text-en/pgfmanual-en-gd-layered.tex
-doc/generic/pgf/text-en/pgfmanual-en-gd-misc.tex
-doc/generic/pgf/text-en/pgfmanual-en-gd-ogdf.tex
-doc/generic/pgf/text-en/pgfmanual-en-gd-overview.tex
-doc/generic/pgf/text-en/pgfmanual-en-gd-phylogenetics.tex
-doc/generic/pgf/text-en/pgfmanual-en-gd-trees.tex
-doc/generic/pgf/text-en/pgfmanual-en-gd-usage-pgf.tex
-doc/generic/pgf/text-en/pgfmanual-en-gd-usage-tikz.tex
-doc/generic/pgf/text-en/pgfmanual-en-guidelines.tex
-doc/generic/pgf/text-en/pgfmanual-en-installation.tex
-doc/generic/pgf/text-en/pgfmanual-en-introduction.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-3d.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-angles.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-arrows.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-automata.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-babel.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-backgrounds.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-calc.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-calendar.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-chains.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-circuits.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-decorations.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-edges.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-er.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-external.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-fadings.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-fit.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-fixedpoint.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-folding.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-fpu.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-lsystems.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-math.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-matrices.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-mindmaps.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-patterns.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-perspective.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-petri.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-plot-handlers.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-plot-marks.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-profiler.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-rdf.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-shadings.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-shadows.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-shapes.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-spy.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-svg-path.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-through.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-trees.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-turtle.tex
-doc/generic/pgf/text-en/pgfmanual-en-library-views.tex
-doc/generic/pgf/text-en/pgfmanual-en-license.tex
-doc/generic/pgf/text-en/pgfmanual-en-main-body.tex
-doc/generic/pgf/text-en/pgfmanual-en-main-preamble.tex
-doc/generic/pgf/text-en/pgfmanual-en-main.tex
-doc/generic/pgf/text-en/pgfmanual-en-math-algorithms.tex
-doc/generic/pgf/text-en/pgfmanual-en-math-commands.tex
-doc/generic/pgf/text-en/pgfmanual-en-math-design.tex
-doc/generic/pgf/text-en/pgfmanual-en-math-numberprinting.tex
-doc/generic/pgf/text-en/pgfmanual-en-math-parsing.tex
-doc/generic/pgf/text-en/pgfmanual-en-module-parser.tex
-doc/generic/pgf/text-en/pgfmanual-en-oo.tex
-doc/generic/pgf/text-en/pgfmanual-en-pages.tex
-doc/generic/pgf/text-en/pgfmanual-en-pgfcalendar.tex
-doc/generic/pgf/text-en/pgfmanual-en-pgffor.tex
-doc/generic/pgf/text-en/pgfmanual-en-pgfkeys.tex
-doc/generic/pgf/text-en/pgfmanual-en-pgfkeysfiltered.tex
-doc/generic/pgf/text-en/pgfmanual-en-pgfsys-animations.tex
-doc/generic/pgf/text-en/pgfmanual-en-pgfsys-commands.tex
-doc/generic/pgf/text-en/pgfmanual-en-pgfsys-overview.tex
-doc/generic/pgf/text-en/pgfmanual-en-pgfsys-paths.tex
-doc/generic/pgf/text-en/pgfmanual-en-pgfsys-protocol.tex
-doc/generic/pgf/text-en/pgfmanual-en-tikz-actions.tex
-doc/generic/pgf/text-en/pgfmanual-en-tikz-animations.tex
-doc/generic/pgf/text-en/pgfmanual-en-tikz-arrows.tex
-doc/generic/pgf/text-en/pgfmanual-en-tikz-coordinates.tex
-doc/generic/pgf/text-en/pgfmanual-en-tikz-decorations.tex
-doc/generic/pgf/text-en/pgfmanual-en-tikz-design.tex
-doc/generic/pgf/text-en/pgfmanual-en-tikz-graphs.tex
-doc/generic/pgf/text-en/pgfmanual-en-tikz-matrices.tex
-doc/generic/pgf/text-en/pgfmanual-en-tikz-paths.tex
-doc/generic/pgf/text-en/pgfmanual-en-tikz-pics.tex
-doc/generic/pgf/text-en/pgfmanual-en-tikz-plots.tex
-doc/generic/pgf/text-en/pgfmanual-en-tikz-scopes.tex
-doc/generic/pgf/text-en/pgfmanual-en-tikz-shapes.tex
-doc/generic/pgf/text-en/pgfmanual-en-tikz-transformations.tex
-doc/generic/pgf/text-en/pgfmanual-en-tikz-transparency.tex
-doc/generic/pgf/text-en/pgfmanual-en-tikz-trees.tex
-doc/generic/pgf/text-en/pgfmanual-en-tutorial-Euclid.tex
-doc/generic/pgf/text-en/pgfmanual-en-tutorial-chains.tex
-doc/generic/pgf/text-en/pgfmanual-en-tutorial-map.tex
-doc/generic/pgf/text-en/pgfmanual-en-tutorial-nodes.tex
-doc/generic/pgf/text-en/pgfmanual-en-tutorial.tex
-doc/generic/pgf/text-en/pgfmanual-en-xxcolor.tex
-doc/generic/pgf/text-en/plots/pgf-asymptotic-example.gnuplot
-doc/generic/pgf/text-en/plots/pgf-asymptotic-example.table
-doc/generic/pgf/text-en/plots/pgf-exp.gnuplot
-doc/generic/pgf/text-en/plots/pgf-exp.table
-doc/generic/pgf/text-en/plots/pgf-parametric-example.gnuplot
-doc/generic/pgf/text-en/plots/pgf-parametric-example.table
-doc/generic/pgf/text-en/plots/pgf-sin.gnuplot
-doc/generic/pgf/text-en/plots/pgf-sin.table
-doc/generic/pgf/text-en/plots/pgf-tan-example.gnuplot
-doc/generic/pgf/text-en/plots/pgf-tan-example.table
-doc/generic/pgf/text-en/plots/pgf-x.gnuplot
-doc/generic/pgf/text-en/plots/pgf-x.table
-doc/generic/pgf/text-en/plots/pgfmanual-sine.gnuplot
-doc/generic/pgf/text-en/plots/pgfmanual-sine.table
-doc/generic/pgf/text-en/plots/pgfplotgnuplot-example.gnuplot
-doc/generic/pgf/text-en/plots/pgfplotgnuplot-example.table
-doc/generic/pgf/version-for-dvipdfm/en/Makefile
-doc/generic/pgf/version-for-dvipdfm/en/pgfmanual.tex
-doc/generic/pgf/version-for-dvipdfm/en/plots/pgf-asymptotic-example.gnuplot
-doc/generic/pgf/version-for-dvipdfm/en/plots/pgf-asymptotic-example.table
-doc/generic/pgf/version-for-dvipdfm/en/plots/pgf-exp.gnuplot
-doc/generic/pgf/version-for-dvipdfm/en/plots/pgf-exp.table
-doc/generic/pgf/version-for-dvipdfm/en/plots/pgf-parametric-example-cut.gnuplot
-doc/generic/pgf/version-for-dvipdfm/en/plots/pgf-parametric-example.gnuplot
-doc/generic/pgf/version-for-dvipdfm/en/plots/pgf-parametric-example.table
-doc/generic/pgf/version-for-dvipdfm/en/plots/pgf-sin.gnuplot
-doc/generic/pgf/version-for-dvipdfm/en/plots/pgf-sin.table
-doc/generic/pgf/version-for-dvipdfm/en/plots/pgf-tan-example.gnuplot
-doc/generic/pgf/version-for-dvipdfm/en/plots/pgf-tan-example.table
-doc/generic/pgf/version-for-dvipdfm/en/plots/pgf-x.gnuplot
-doc/generic/pgf/version-for-dvipdfm/en/plots/pgf-x.table
-doc/generic/pgf/version-for-dvipdfm/en/plots/pgfmanual-sine.gnuplot
-doc/generic/pgf/version-for-dvipdfm/en/plots/pgfmanual-sine.table
-doc/generic/pgf/version-for-dvipdfm/en/plots/pgfplotgnuplot-example.gnuplot
-doc/generic/pgf/version-for-dvipdfm/en/plots/pgfplotgnuplot-example.table
-doc/generic/pgf/version-for-dvipdfm/pgfmanual-dvipdfm.cfg
-doc/generic/pgf/version-for-dvipdfmx/en/Makefile
-doc/generic/pgf/version-for-dvipdfmx/en/pgfmanual-test.tex
-doc/generic/pgf/version-for-dvipdfmx/en/pgfmanual.tex
-doc/generic/pgf/version-for-dvipdfmx/en/plots/pgf-asymptotic-example.gnuplot
-doc/generic/pgf/version-for-dvipdfmx/en/plots/pgf-asymptotic-example.table
-doc/generic/pgf/version-for-dvipdfmx/en/plots/pgf-exp.gnuplot
-doc/generic/pgf/version-for-dvipdfmx/en/plots/pgf-exp.table
-doc/generic/pgf/version-for-dvipdfmx/en/plots/pgf-parametric-example-cut.gnuplot
-doc/generic/pgf/version-for-dvipdfmx/en/plots/pgf-parametric-example-cut.table
-doc/generic/pgf/version-for-dvipdfmx/en/plots/pgf-parametric-example.gnuplot
-doc/generic/pgf/version-for-dvipdfmx/en/plots/pgf-parametric-example.table
-doc/generic/pgf/version-for-dvipdfmx/en/plots/pgf-sin.gnuplot
-doc/generic/pgf/version-for-dvipdfmx/en/plots/pgf-sin.table
-doc/generic/pgf/version-for-dvipdfmx/en/plots/pgf-tan-example.gnuplot
-doc/generic/pgf/version-for-dvipdfmx/en/plots/pgf-tan-example.table
-doc/generic/pgf/version-for-dvipdfmx/en/plots/pgf-x.gnuplot
-doc/generic/pgf/version-for-dvipdfmx/en/plots/pgf-x.table
-doc/generic/pgf/version-for-dvipdfmx/en/plots/pgfmanual-sine.gnuplot
-doc/generic/pgf/version-for-dvipdfmx/en/plots/pgfmanual-sine.table
-doc/generic/pgf/version-for-dvipdfmx/en/plots/pgfplotgnuplot-example.gnuplot
-doc/generic/pgf/version-for-dvipdfmx/en/plots/pgfplotgnuplot-example.table
-doc/generic/pgf/version-for-dvipdfmx/pgfmanual-dvipdfmx.cfg
-doc/generic/pgf/version-for-dvips/en/Makefile
-doc/generic/pgf/version-for-dvips/en/pgfmanual-test.tex
-doc/generic/pgf/version-for-dvips/en/pgfmanual.tex
-doc/generic/pgf/version-for-dvips/en/plots/pgf-asymptotic-example.gnuplot
-doc/generic/pgf/version-for-dvips/en/plots/pgf-asymptotic-example.table
-doc/generic/pgf/version-for-dvips/en/plots/pgf-exp.gnuplot
-doc/generic/pgf/version-for-dvips/en/plots/pgf-exp.table
-doc/generic/pgf/version-for-dvips/en/plots/pgf-parametric-example-cut.gnuplot
-doc/generic/pgf/version-for-dvips/en/plots/pgf-parametric-example.gnuplot
-doc/generic/pgf/version-for-dvips/en/plots/pgf-parametric-example.table
-doc/generic/pgf/version-for-dvips/en/plots/pgf-sin.gnuplot
-doc/generic/pgf/version-for-dvips/en/plots/pgf-sin.table
-doc/generic/pgf/version-for-dvips/en/plots/pgf-tan-example.gnuplot
-doc/generic/pgf/version-for-dvips/en/plots/pgf-tan-example.table
-doc/generic/pgf/version-for-dvips/en/plots/pgf-x.gnuplot
-doc/generic/pgf/version-for-dvips/en/plots/pgf-x.table
-doc/generic/pgf/version-for-dvips/en/plots/pgfmanual-sine.gnuplot
-doc/generic/pgf/version-for-dvips/en/plots/pgfmanual-sine.table
-doc/generic/pgf/version-for-dvips/en/plots/pgfplotgnuplot-example.gnuplot
-doc/generic/pgf/version-for-dvips/en/plots/pgfplotgnuplot-example.table
-doc/generic/pgf/version-for-dvips/pgfmanual-dvips.cfg
-doc/generic/pgf/version-for-dvisvgm/en/Makefile
-doc/generic/pgf/version-for-dvisvgm/en/color.cfg
-doc/generic/pgf/version-for-dvisvgm/en/pgfmanual-test.html
-doc/generic/pgf/version-for-dvisvgm/en/pgfmanual-test.tex
-doc/generic/pgf/version-for-dvisvgm/en/pgfmanual.html
-doc/generic/pgf/version-for-dvisvgm/en/pgfmanual.tex
-doc/generic/pgf/version-for-dvisvgm/en/plots/pgf-asymptotic-example.gnuplot
-doc/generic/pgf/version-for-dvisvgm/en/plots/pgf-asymptotic-example.table
-doc/generic/pgf/version-for-dvisvgm/en/plots/pgf-exp.gnuplot
-doc/generic/pgf/version-for-dvisvgm/en/plots/pgf-exp.table
-doc/generic/pgf/version-for-dvisvgm/en/plots/pgf-parametric-example-cut.gnuplot
-doc/generic/pgf/version-for-dvisvgm/en/plots/pgf-parametric-example.gnuplot
-doc/generic/pgf/version-for-dvisvgm/en/plots/pgf-parametric-example.table
-doc/generic/pgf/version-for-dvisvgm/en/plots/pgf-sin.gnuplot
-doc/generic/pgf/version-for-dvisvgm/en/plots/pgf-sin.table
-doc/generic/pgf/version-for-dvisvgm/en/plots/pgf-tan-example.gnuplot
-doc/generic/pgf/version-for-dvisvgm/en/plots/pgf-tan-example.table
-doc/generic/pgf/version-for-dvisvgm/en/plots/pgf-x.gnuplot
-doc/generic/pgf/version-for-dvisvgm/en/plots/pgf-x.table
-doc/generic/pgf/version-for-dvisvgm/en/plots/pgfmanual-sine.table
-doc/generic/pgf/version-for-dvisvgm/en/plots/pgfplotgnuplot-example.gnuplot
-doc/generic/pgf/version-for-dvisvgm/en/plots/pgfplotgnuplot-example.table
-doc/generic/pgf/version-for-dvisvgm/pgfmanual-dvisvgm.cfg
-doc/generic/pgf/version-for-luatex/en/Makefile
-doc/generic/pgf/version-for-luatex/en/pgfmanual-test.tex
-doc/generic/pgf/version-for-luatex/en/pgfmanual.tex
-doc/generic/pgf/version-for-luatex/en/plots/pgf-asymptotic-example.gnuplot
-doc/generic/pgf/version-for-luatex/en/plots/pgf-asymptotic-example.table
-doc/generic/pgf/version-for-luatex/en/plots/pgf-exp.gnuplot
-doc/generic/pgf/version-for-luatex/en/plots/pgf-exp.table
-doc/generic/pgf/version-for-luatex/en/plots/pgf-parametric-example-cut.gnuplot
-doc/generic/pgf/version-for-luatex/en/plots/pgf-parametric-example-cut.table
-doc/generic/pgf/version-for-luatex/en/plots/pgf-parametric-example.gnuplot
-doc/generic/pgf/version-for-luatex/en/plots/pgf-parametric-example.table
-doc/generic/pgf/version-for-luatex/en/plots/pgf-sin.gnuplot
-doc/generic/pgf/version-for-luatex/en/plots/pgf-sin.table
-doc/generic/pgf/version-for-luatex/en/plots/pgf-tan-example.gnuplot
-doc/generic/pgf/version-for-luatex/en/plots/pgf-tan-example.table
-doc/generic/pgf/version-for-luatex/en/plots/pgf-x.gnuplot
-doc/generic/pgf/version-for-luatex/en/plots/pgf-x.table
-doc/generic/pgf/version-for-luatex/en/plots/pgfplotgnuplot-example.gnuplot
-doc/generic/pgf/version-for-luatex/en/plots/pgfplotgnuplot-example.table
-doc/generic/pgf/version-for-luatex/pgfmanual-luatex.cfg
-doc/generic/pgf/version-for-pdftex/en/Makefile
-doc/generic/pgf/version-for-pdftex/en/pgfmanual.tex
-doc/generic/pgf/version-for-pdftex/en/plots/pgf-asymptotic-example.gnuplot
-doc/generic/pgf/version-for-pdftex/en/plots/pgf-asymptotic-example.table
-doc/generic/pgf/version-for-pdftex/en/plots/pgf-exp.gnuplot
-doc/generic/pgf/version-for-pdftex/en/plots/pgf-exp.table
-doc/generic/pgf/version-for-pdftex/en/plots/pgf-parametric-example-cut.gnuplot
-doc/generic/pgf/version-for-pdftex/en/plots/pgf-parametric-example.gnuplot
-doc/generic/pgf/version-for-pdftex/en/plots/pgf-parametric-example.table
-doc/generic/pgf/version-for-pdftex/en/plots/pgf-sin.gnuplot
-doc/generic/pgf/version-for-pdftex/en/plots/pgf-sin.table
-doc/generic/pgf/version-for-pdftex/en/plots/pgf-tan-example.gnuplot
-doc/generic/pgf/version-for-pdftex/en/plots/pgf-tan-example.table
-doc/generic/pgf/version-for-pdftex/en/plots/pgf-x.gnuplot
-doc/generic/pgf/version-for-pdftex/en/plots/pgf-x.table
-doc/generic/pgf/version-for-pdftex/en/plots/pgfmanual-sine.gnuplot
-doc/generic/pgf/version-for-pdftex/en/plots/pgfmanual-sine.table
-doc/generic/pgf/version-for-pdftex/en/plots/pgfplotgnuplot-example.gnuplot
-doc/generic/pgf/version-for-pdftex/en/plots/pgfplotgnuplot-example.table
-doc/generic/pgf/version-for-pdftex/pgfmanual-pdftex.cfg
-doc/generic/pgf/version-for-tex4ht/en/Makefile
-doc/generic/pgf/version-for-tex4ht/en/pgfmanual.tex
-doc/generic/pgf/version-for-tex4ht/en/plots/pgf-asymptotic-example.gnuplot
-doc/generic/pgf/version-for-tex4ht/en/plots/pgf-asymptotic-example.table
-doc/generic/pgf/version-for-tex4ht/en/plots/pgf-exp.gnuplot
-doc/generic/pgf/version-for-tex4ht/en/plots/pgf-exp.table
-doc/generic/pgf/version-for-tex4ht/en/plots/pgf-parametric-example.gnuplot
-doc/generic/pgf/version-for-tex4ht/en/plots/pgf-parametric-example.table
-doc/generic/pgf/version-for-tex4ht/en/plots/pgf-sin.gnuplot
-doc/generic/pgf/version-for-tex4ht/en/plots/pgf-sin.table
-doc/generic/pgf/version-for-tex4ht/en/plots/pgf-x.gnuplot
-doc/generic/pgf/version-for-tex4ht/en/plots/pgf-x.table
-doc/generic/pgf/version-for-tex4ht/en/plots/pgfmanual-sine.gnuplot
-doc/generic/pgf/version-for-tex4ht/en/plots/pgfmanual-sine.table
-doc/generic/pgf/version-for-tex4ht/en/plots/pgfplotgnuplot-example.gnuplot
-doc/generic/pgf/version-for-tex4ht/en/plots/pgfplotgnuplot-example.table
-doc/generic/pgf/version-for-tex4ht/pgfmanual-tex4ht.cfg
-doc/generic/pgf/version-for-vtex/en/Makefile
-doc/generic/pgf/version-for-vtex/en/pgfmanual.tex
-doc/generic/pgf/version-for-vtex/en/plots/pgf-asymptotic-example.gnuplot
-doc/generic/pgf/version-for-vtex/en/plots/pgf-asymptotic-example.table
-doc/generic/pgf/version-for-vtex/en/plots/pgf-exp.gnuplot
-doc/generic/pgf/version-for-vtex/en/plots/pgf-exp.table
-doc/generic/pgf/version-for-vtex/en/plots/pgf-parametric-example.gnuplot
-doc/generic/pgf/version-for-vtex/en/plots/pgf-parametric-example.table
-doc/generic/pgf/version-for-vtex/en/plots/pgf-sin.gnuplot
-doc/generic/pgf/version-for-vtex/en/plots/pgf-sin.table
-doc/generic/pgf/version-for-vtex/en/plots/pgf-x.gnuplot
-doc/generic/pgf/version-for-vtex/en/plots/pgf-x.table
-doc/generic/pgf/version-for-vtex/en/plots/pgfmanual-sine.gnuplot
-doc/generic/pgf/version-for-vtex/en/plots/pgfmanual-sine.table
-doc/generic/pgf/version-for-vtex/en/plots/pgfplotgnuplot-example.gnuplot
-doc/generic/pgf/version-for-vtex/en/plots/pgfplotgnuplot-example.table
-doc/generic/pgf/version-for-vtex/pgfmanual-vtex.cfg
-doc/generic/pgf/version-for-xetex/en/Makefile
-doc/generic/pgf/version-for-xetex/en/pgfmanual.tex
-doc/generic/pgf/version-for-xetex/en/plots/pgf-asymptotic-example.gnuplot
-doc/generic/pgf/version-for-xetex/en/plots/pgf-asymptotic-example.table
-doc/generic/pgf/version-for-xetex/en/plots/pgf-exp.gnuplot
-doc/generic/pgf/version-for-xetex/en/plots/pgf-exp.table
-doc/generic/pgf/version-for-xetex/en/plots/pgf-parametric-example-cut.gnuplot
-doc/generic/pgf/version-for-xetex/en/plots/pgf-parametric-example.gnuplot
-doc/generic/pgf/version-for-xetex/en/plots/pgf-parametric-example.table
-doc/generic/pgf/version-for-xetex/en/plots/pgf-sin.gnuplot
-doc/generic/pgf/version-for-xetex/en/plots/pgf-sin.table
-doc/generic/pgf/version-for-xetex/en/plots/pgf-tan-example.gnuplot
-doc/generic/pgf/version-for-xetex/en/plots/pgf-tan-example.table
-doc/generic/pgf/version-for-xetex/en/plots/pgf-x.gnuplot
-doc/generic/pgf/version-for-xetex/en/plots/pgf-x.table
-doc/generic/pgf/version-for-xetex/en/plots/pgfmanual-sine.gnuplot
-doc/generic/pgf/version-for-xetex/en/plots/pgfmanual-sine.table
-doc/generic/pgf/version-for-xetex/en/plots/pgfplotgnuplot-example.gnuplot
-doc/generic/pgf/version-for-xetex/en/plots/pgfplotgnuplot-example.table
-doc/generic/pgf/version-for-xetex/pgfmanual-xetex.cfg
-scripts/pgf/Makefile.pgf_release
-scripts/pgf/pgfrevisionfile.sh
-source/generic/pgf/c/INSTALL
-source/generic/pgf/c/Makefile
-source/generic/pgf/c/config/ExampleLocalMakefileConfig.mk
-source/generic/pgf/c/config/MakefileConfig.mk
-source/generic/pgf/c/graphdrawing/pgf/gd/examples/c/Makefile
-source/generic/pgf/c/graphdrawing/pgf/gd/examples/c/SimpleDemoC.c
-source/generic/pgf/c/graphdrawing/pgf/gd/examples/c/SimpleDemoCPlusPlus.c++
-source/generic/pgf/c/graphdrawing/pgf/gd/interface/c/InterfaceFromC++.c++
-source/generic/pgf/c/graphdrawing/pgf/gd/interface/c/InterfaceFromC++.h
-source/generic/pgf/c/graphdrawing/pgf/gd/interface/c/InterfaceFromC.c
-source/generic/pgf/c/graphdrawing/pgf/gd/interface/c/InterfaceFromC.h
-source/generic/pgf/c/graphdrawing/pgf/gd/interface/c/Makefile
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/InterfaceFromOGDF.c++
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/InterfaceFromOGDF.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/Makefile
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/SimpleDemoOGDF.c++
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/FMMMLayout_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/FastMultipoleEmbedder_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/GEMLayout_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/MultilevelLayout_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/SpringEmbedderFRExact_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/SpringEmbedderFR_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/SpringEmbedderKK_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/energybased_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/multilevelmixer/BarycenterPlacer_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/multilevelmixer/CirclePlacer_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/multilevelmixer/EdgeCoverMerger_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/multilevelmixer/IndependentSetMerger_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/multilevelmixer/LocalBiconnectedMerger_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/multilevelmixer/MatchingMerger_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/multilevelmixer/MedianPlacer_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/multilevelmixer/RandomMerger_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/multilevelmixer/RandomPlacer_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/multilevelmixer/SolarMerger_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/multilevelmixer/SolarPlacer_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/multilevelmixer/ZeroPlacer_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/energybased/multilevelmixer/multilevelmixer_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/layered/BarycenterHeuristic_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/layered/CoffmanGrahamRanking_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/layered/DfsAcyclicSubgraph_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/layered/FastHierarchyLayout_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/layered/FastSimpleHierarchyLayout_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/layered/GreedyCycleRemoval_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/layered/GreedyInsertHeuristic_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/layered/LongestPathRanking_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/layered/MedianHeuristic_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/layered/OptimalRanking_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/layered/SiftingHeuristic_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/layered/SplitHeuristic_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/layered/SugiyamaLayout_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/layered/layered_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/misclayout/BalloonLayout_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/misclayout/CircularLayout_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/misclayout/misclayout_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/module/module_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/ogdf_script.c++
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/planarity/PlanarizationLayout_script.h
-source/generic/pgf/c/graphdrawing/pgf/gd/ogdf/c/planarity/planarity_script.h
-source/generic/pgf/testsuite/external/Makefile
-source/generic/pgf/testsuite/external/tikzexternaltest.code.tex
-source/generic/pgf/testsuite/external/tikzexternaltest.sharedpreamble.tex
-source/generic/pgf/testsuite/external/tikzexternaltest.tex
-source/generic/pgf/testsuite/external/tikzexternaltestmakefile.tex
-source/generic/pgf/testsuite/mathtest/pgfmathtestsuite.tex
-source/generic/pgf/testsuite/mathtest/unittest_luamathparser.tex
-tex/context/third/pgf/basiclayer/t-pgf.tex
-tex/context/third/pgf/basiclayer/t-pgfbim.tex
-tex/context/third/pgf/basiclayer/t-pgfbla.tex
-tex/context/third/pgf/basiclayer/t-pgfbma.tex
-tex/context/third/pgf/basiclayer/t-pgfbpl.tex
-tex/context/third/pgf/basiclayer/t-pgfbpt.tex
-tex/context/third/pgf/basiclayer/t-pgfbsh.tex
-tex/context/third/pgf/basiclayer/t-pgfbsn.tex
-tex/context/third/pgf/basiclayer/t-pgfcor.tex
-tex/context/third/pgf/frontendlayer/t-tikz.tex
-tex/context/third/pgf/math/t-pgfmat.tex
-tex/context/third/pgf/systemlayer/t-pgfsys.tex
-tex/context/third/pgf/utilities/t-pgfcal.tex
-tex/context/third/pgf/utilities/t-pgffor.tex
-tex/context/third/pgf/utilities/t-pgfkey.tex
-tex/context/third/pgf/utilities/t-pgfmod.tex
-tex/context/third/pgf/utilities/t-pgfrcs.tex
-tex/generic/pgf/basiclayer/pgfcore.code.tex
-tex/generic/pgf/basiclayer/pgfcorearrows.code.tex
-tex/generic/pgf/basiclayer/pgfcoreexternal.code.tex
-tex/generic/pgf/basiclayer/pgfcoregraphicstate.code.tex
-tex/generic/pgf/basiclayer/pgfcoreimage.code.tex
-tex/generic/pgf/basiclayer/pgfcorelayers.code.tex
-tex/generic/pgf/basiclayer/pgfcoreobjects.code.tex
-tex/generic/pgf/basiclayer/pgfcorepathconstruct.code.tex
-tex/generic/pgf/basiclayer/pgfcorepathprocessing.code.tex
-tex/generic/pgf/basiclayer/pgfcorepathusage.code.tex
-tex/generic/pgf/basiclayer/pgfcorepatterns.code.tex
-tex/generic/pgf/basiclayer/pgfcorepoints.code.tex
-tex/generic/pgf/basiclayer/pgfcorequick.code.tex
-tex/generic/pgf/basiclayer/pgfcorerdf.code.tex
-tex/generic/pgf/basiclayer/pgfcorescopes.code.tex
-tex/generic/pgf/basiclayer/pgfcoreshade.code.tex
-tex/generic/pgf/basiclayer/pgfcoretransformations.code.tex
-tex/generic/pgf/basiclayer/pgfcoretransparency.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/circuits/tikzlibrarycircuits.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/circuits/tikzlibrarycircuits.ee.IEC.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/circuits/tikzlibrarycircuits.ee.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/circuits/tikzlibrarycircuits.logic.CDH.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/circuits/tikzlibrarycircuits.logic.IEC.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/circuits/tikzlibrarycircuits.logic.US.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/circuits/tikzlibrarycircuits.logic.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/datavisualization/tikzlibrarydatavisualization.3d.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/datavisualization/tikzlibrarydatavisualization.barcharts.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/datavisualization/tikzlibrarydatavisualization.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/datavisualization/tikzlibrarydatavisualization.formats.functions.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/datavisualization/tikzlibrarydatavisualization.polar.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/datavisualization/tikzlibrarydatavisualization.sparklines.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/graphs/tikzlibrarygraphs.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/graphs/tikzlibrarygraphs.standard.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzexternalshared.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrary3d.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryangles.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryanimations.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryarrows.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryautomata.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarybabel.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarybackgrounds.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarybending.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarycalc.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarycalendar.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarychains.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarydecorations.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarydecorations.footprints.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarydecorations.fractals.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarydecorations.markings.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarydecorations.pathmorphing.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarydecorations.pathreplacing.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarydecorations.shapes.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarydecorations.text.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryer.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryfadings.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryfit.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryfixedpointarithmetic.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryfolding.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryfpu.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryintersections.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarylindenmayersystems.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarymath.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarymatrix.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarymindmap.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarypatterns.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarypatterns.meta.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryperspective.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarypetri.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryplothandlers.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryplotmarks.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarypositioning.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryquotes.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryrdf.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryscopes.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryshadings.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryshadows.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryshapes.arrows.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryshapes.callouts.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryshapes.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryshapes.gates.logic.IEC.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryshapes.gates.logic.US.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryshapes.geometric.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryshapes.misc.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryshapes.multipart.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryshapes.symbols.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarysnakes.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryspy.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarysvg.path.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarythrough.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarytopaths.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibrarytrees.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryturtle.code.tex
-tex/generic/pgf/frontendlayer/tikz/libraries/tikzlibraryviews.code.tex
-tex/generic/pgf/frontendlayer/tikz/tikz.code.tex
-tex/generic/pgf/graphdrawing/lua/LUA_CODING_STYLE
-tex/generic/pgf/graphdrawing/lua/pgf.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/bindings.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/bindings/Binding.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/bindings/BindingToPGF.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/circular.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/circular/Tantau2012.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/circular/doc.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/circular/library.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/control.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/control/Anchoring.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/control/ComponentAlign.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/control/ComponentDirection.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/control/ComponentDistance.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/control/ComponentOrder.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/control/Components.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/control/Distances.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/control/FineTune.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/control/LayoutPipeline.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/control/NodeAnchors.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/control/Orientation.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/control/Sublayouts.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/control/doc.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/control/library.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/deprecated/Cluster.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/deprecated/Edge.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/deprecated/Graph.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/deprecated/Iterators.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/deprecated/Node.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/deprecated/Vector.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/energybased.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/energybased/FMMMLayout.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/energybased/FastMultipoleEmbedder.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/energybased/GEMLayout.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/energybased/MultilevelLayout.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/energybased/SpringEmbedderFR.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/energybased/SpringEmbedderFRExact.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/energybased/SpringEmbedderKK.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/energybased/multilevelmixer/BarycenterPlacer.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/energybased/multilevelmixer/CirclePlacer.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/energybased/multilevelmixer/EdgeCoverMerger.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/energybased/multilevelmixer/IndependentSetMerger.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/energybased/multilevelmixer/LocalBiconnectedMerger.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/energybased/multilevelmixer/MatchingMerger.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/energybased/multilevelmixer/MedianPlacer.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/energybased/multilevelmixer/RandomMerger.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/energybased/multilevelmixer/RandomPlacer.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/energybased/multilevelmixer/SolarMerger.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/energybased/multilevelmixer/SolarPlacer.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/energybased/multilevelmixer/ZeroPlacer.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/layered.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/layered/BarycenterHeuristic.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/layered/CoffmanGrahamRanking.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/layered/DfsAcyclicSubgraph.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/layered/FastHierarchyLayout.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/layered/FastSimpleHierarchyLayout.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/layered/GreedyCycleRemoval.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/layered/GreedyInsertHeuristic.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/layered/LongestPathRanking.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/layered/MedianHeuristic.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/layered/OptimalRanking.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/layered/SiftingHeuristic.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/layered/SplitHeuristic.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/layered/SugiyamaLayout.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/misclayout.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/misclayout/BalloonLayout.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/misclayout/CircularLayout.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/module/AcyclicSubgraphModule.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/module/HierarchyLayoutModule.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/module/InitialPlacer.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/module/MultilevelBuilder.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/module/RankingModule.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/module/TwoLayerCrossMin.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/planarity.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/doc/ogdf/planarity/PlanarizationLayout.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/examples.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/examples/ASCIIDisplayer.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/examples/BindingToASCII.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/examples/SimpleDemo.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/examples/SimpleEdgeDemo.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/examples/SimpleHuffman.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/examples/example_graph_for_ascii_displayer.txt
-tex/generic/pgf/graphdrawing/lua/pgf/gd/examples/library.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/experimental/evolving/GraphAnimationCoordination.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/experimental/evolving/GreedyTemporalCycleRemoval.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/experimental/evolving/Skambath2016.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/experimental/evolving/Supergraph.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/experimental/evolving/SupergraphVertexSplitOptimization.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/experimental/evolving/TimeSpec.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/experimental/evolving/doc.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/experimental/evolving/layered.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/experimental/evolving/library.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/CoarseGraph.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/ControlCoarsening.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/ControlDeclare.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/ControlElectric.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/ControlIteration.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/ControlSprings.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/ControlStart.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/QuadTree.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/SpringElectricalHu2006.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/SpringElectricalLayouts.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/SpringElectricalWalshaw2000.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/SpringHu2006.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/SpringLayouts.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/jedi/algorithms/FruchtermanReingold.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/jedi/algorithms/HuSpringElectricalFW.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/jedi/algorithms/SimpleSpring.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/jedi/algorithms/SocialGravityCloseness.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/jedi/algorithms/SocialGravityDegree.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/jedi/base/CoarseGraphFW.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/jedi/base/ForceController.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/jedi/base/ForceTemplate.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/jedi/base/InitialTemplate.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/jedi/base/PathLengthsFW.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/jedi/base/Preprocessing.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/jedi/doc.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/jedi/forcetypes/ForceAbsoluteValue.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/jedi/forcetypes/ForceCanvasDistance.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/jedi/forcetypes/ForceCanvasPosition.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/jedi/forcetypes/ForceGraphDistance.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/jedi/forcetypes/ForcePullToGrid.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/jedi/forcetypes/ForcePullToPoint.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/jedi/initialpositioning/CircularInitialPositioning.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/jedi/initialpositioning/GridInitialPositioning.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/jedi/initialpositioning/RandomInitialPositioning.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/jedi/library.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/force/library.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/interface.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/interface/InterfaceCore.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/interface/InterfaceToAlgorithms.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/interface/InterfaceToC.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/interface/InterfaceToDisplay.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/interface/Scope.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/layered.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/layered/CrossingMinimizationGansnerKNV1993.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/layered/CycleRemovalBergerS1990a.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/layered/CycleRemovalBergerS1990b.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/layered/CycleRemovalEadesLS1993.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/layered/CycleRemovalGansnerKNV1993.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/layered/EdgeRoutingGansnerKNV1993.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/layered/NetworkSimplex.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/layered/NodePositioningGansnerKNV1993.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/layered/NodeRankingGansnerKNV1993.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/layered/NodeRankingMinimumHeight.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/layered/Ranking.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/layered/Sugiyama.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/layered/crossing_minimization.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/layered/cycle_removal.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/layered/edge_routing.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/layered/library.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/layered/node_positioning.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/layered/node_ranking.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/lib.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/lib/Bezier.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/lib/DepthFirstSearch.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/lib/Direct.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/lib/Event.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/lib/LookupTable.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/lib/PathLengths.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/lib/PriorityQueue.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/lib/Simplifiers.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/lib/Stack.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/lib/Storage.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/lib/Transform.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/model.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/model/Arc.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/model/Collection.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/model/Coordinate.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/model/Digraph.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/model/Edge.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/model/Hyperedge.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/model/Path.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/model/Path_arced.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/model/Vertex.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/model/library.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/ogdf.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/ogdf/library.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/pedigrees.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/pedigrees/Koerner2015.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/pedigrees/library.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/phylogenetics.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/phylogenetics/AuthorDefinedPhylogeny.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/phylogenetics/BalancedMinimumEvolution.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/phylogenetics/BalancedNearestNeighbourInterchange.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/phylogenetics/DistanceMatrix.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/phylogenetics/Maeusle2012.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/phylogenetics/PhylogeneticTree.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/phylogenetics/SokalMichener1958.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/phylogenetics/library.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/planar.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/planar/BoyerMyrvold2004.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/planar/Embedding.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/planar/LinkedList.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/planar/List.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/planar/PDP.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/planar/PlanarLayout.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/planar/ShiftMethod.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/planar/library.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/planar/parameters.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/routing.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/routing/Hints.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/routing/NecklaceRouting.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/routing/library.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/tools/make_gd_wrap.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/trees.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/trees/ChildSpec.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/trees/ReingoldTilford1981.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/trees/SpanningTreeComputation.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/trees/doc.lua
-tex/generic/pgf/graphdrawing/lua/pgf/gd/trees/library.lua
-tex/generic/pgf/graphdrawing/tex/experimental/tikzlibrarygraphdrawing.evolving.code.tex
-tex/generic/pgf/graphdrawing/tex/pgflibrarygraphdrawing.circular.code.tex
-tex/generic/pgf/graphdrawing/tex/pgflibrarygraphdrawing.code.tex
-tex/generic/pgf/graphdrawing/tex/pgflibrarygraphdrawing.examples.code.tex
-tex/generic/pgf/graphdrawing/tex/pgflibrarygraphdrawing.force.code.tex
-tex/generic/pgf/graphdrawing/tex/pgflibrarygraphdrawing.layered.code.tex
-tex/generic/pgf/graphdrawing/tex/pgflibrarygraphdrawing.trees.code.tex
-tex/generic/pgf/graphdrawing/tex/tikzlibrarygraphdrawing.code.tex
-tex/generic/pgf/libraries/datavisualization/pgflibrarydatavisualization.barcharts.code.tex
-tex/generic/pgf/libraries/datavisualization/pgflibrarydatavisualization.formats.functions.code.tex
-tex/generic/pgf/libraries/datavisualization/pgflibrarydatavisualization.polar.code.tex
-tex/generic/pgf/libraries/decorations/pgflibrarydecorations.footprints.code.tex
-tex/generic/pgf/libraries/decorations/pgflibrarydecorations.fractals.code.tex
-tex/generic/pgf/libraries/decorations/pgflibrarydecorations.markings.code.tex
-tex/generic/pgf/libraries/decorations/pgflibrarydecorations.pathmorphing.code.tex
-tex/generic/pgf/libraries/decorations/pgflibrarydecorations.pathreplacing.code.tex
-tex/generic/pgf/libraries/decorations/pgflibrarydecorations.shapes.code.tex
-tex/generic/pgf/libraries/decorations/pgflibrarydecorations.text.code.tex
-tex/generic/pgf/libraries/luamath/pgf/luamath/functions.lua
-tex/generic/pgf/libraries/luamath/pgf/luamath/parser.lua
-tex/generic/pgf/libraries/luamath/pgflibraryluamath.code.tex
-tex/generic/pgf/libraries/pgflibraryarrows.code.tex
-tex/generic/pgf/libraries/pgflibraryarrows.meta.code.tex
-tex/generic/pgf/libraries/pgflibraryarrows.spaced.code.tex
-tex/generic/pgf/libraries/pgflibrarycurvilinear.code.tex
-tex/generic/pgf/libraries/pgflibraryfadings.code.tex
-tex/generic/pgf/libraries/pgflibraryfixedpointarithmetic.code.tex
-tex/generic/pgf/libraries/pgflibraryfpu.code.tex
-tex/generic/pgf/libraries/pgflibraryintersections.code.tex
-tex/generic/pgf/libraries/pgflibrarylindenmayersystems.code.tex
-tex/generic/pgf/libraries/pgflibrarypatterns.code.tex
-tex/generic/pgf/libraries/pgflibrarypatterns.meta.code.tex
-tex/generic/pgf/libraries/pgflibraryplothandlers.code.tex
-tex/generic/pgf/libraries/pgflibraryplotmarks.code.tex
-tex/generic/pgf/libraries/pgflibraryprofiler.code.tex
-tex/generic/pgf/libraries/pgflibraryshadings.code.tex
-tex/generic/pgf/libraries/pgflibrarysnakes.code.tex
-tex/generic/pgf/libraries/pgflibrarysvg.path.code.tex
-tex/generic/pgf/libraries/pgflibrarytimelines.code.tex
-tex/generic/pgf/libraries/shapes/circuits/pgflibraryshapes.gates.ee.IEC.code.tex
-tex/generic/pgf/libraries/shapes/circuits/pgflibraryshapes.gates.ee.code.tex
-tex/generic/pgf/libraries/shapes/circuits/pgflibraryshapes.gates.logic.IEC.code.tex
-tex/generic/pgf/libraries/shapes/circuits/pgflibraryshapes.gates.logic.US.code.tex
-tex/generic/pgf/libraries/shapes/circuits/pgflibraryshapes.gates.logic.code.tex
-tex/generic/pgf/libraries/shapes/pgflibraryshapes.arrows.code.tex
-tex/generic/pgf/libraries/shapes/pgflibraryshapes.callouts.code.tex
-tex/generic/pgf/libraries/shapes/pgflibraryshapes.code.tex
-tex/generic/pgf/libraries/shapes/pgflibraryshapes.geometric.code.tex
-tex/generic/pgf/libraries/shapes/pgflibraryshapes.misc.code.tex
-tex/generic/pgf/libraries/shapes/pgflibraryshapes.multipart.code.tex
-tex/generic/pgf/libraries/shapes/pgflibraryshapes.symbols.code.tex
-tex/generic/pgf/lua/pgf/manual.lua
-tex/generic/pgf/lua/pgf/manual/DocumentParser.lua
-tex/generic/pgf/math/pgfint.code.tex
-tex/generic/pgf/math/pgfmath.code.tex
-tex/generic/pgf/math/pgfmathcalc.code.tex
-tex/generic/pgf/math/pgfmathfloat.code.tex
-tex/generic/pgf/math/pgfmathfunctions.base.code.tex
-tex/generic/pgf/math/pgfmathfunctions.basic.code.tex
-tex/generic/pgf/math/pgfmathfunctions.code.tex
-tex/generic/pgf/math/pgfmathfunctions.comparison.code.tex
-tex/generic/pgf/math/pgfmathfunctions.integerarithmetics.code.tex
-tex/generic/pgf/math/pgfmathfunctions.misc.code.tex
-tex/generic/pgf/math/pgfmathfunctions.random.code.tex
-tex/generic/pgf/math/pgfmathfunctions.round.code.tex
-tex/generic/pgf/math/pgfmathfunctions.trigonometric.code.tex
-tex/generic/pgf/math/pgfmathode.code.tex
-tex/generic/pgf/math/pgfmathparser.code.tex
-tex/generic/pgf/math/pgfmathutil.code.tex
-tex/generic/pgf/modules/pgfmoduleanimations.code.tex
-tex/generic/pgf/modules/pgfmodulebending.code.tex
-tex/generic/pgf/modules/pgfmoduledatavisualization.code.tex
-tex/generic/pgf/modules/pgfmoduledecorations.code.tex
-tex/generic/pgf/modules/pgfmodulematrix.code.tex
-tex/generic/pgf/modules/pgfmodulenonlineartransformations.code.tex
-tex/generic/pgf/modules/pgfmoduleoo.code.tex
-tex/generic/pgf/modules/pgfmoduleparser.code.tex
-tex/generic/pgf/modules/pgfmoduleplot.code.tex
-tex/generic/pgf/modules/pgfmoduleshapes.code.tex
-tex/generic/pgf/modules/pgfmodulesnakes.code.tex
-tex/generic/pgf/modules/pgfmodulesorting.code.tex
-tex/generic/pgf/pgf.revision.tex
-tex/generic/pgf/systemlayer/pgf.cfg
-tex/generic/pgf/systemlayer/pgfsys-common-pdf-via-dvi.def
-tex/generic/pgf/systemlayer/pgfsys-common-pdf.def
-tex/generic/pgf/systemlayer/pgfsys-common-postscript.def
-tex/generic/pgf/systemlayer/pgfsys-common-svg.def
-tex/generic/pgf/systemlayer/pgfsys-dvi.def
-tex/generic/pgf/systemlayer/pgfsys-dvipdfm.def
-tex/generic/pgf/systemlayer/pgfsys-dvipdfmx.def
-tex/generic/pgf/systemlayer/pgfsys-dvips.def
-tex/generic/pgf/systemlayer/pgfsys-dvisvgm.def
-tex/generic/pgf/systemlayer/pgfsys-dvisvgm4ht.def
-tex/generic/pgf/systemlayer/pgfsys-luatex.def
-tex/generic/pgf/systemlayer/pgfsys-pdftex.def
-tex/generic/pgf/systemlayer/pgfsys-tex4ht.def
-tex/generic/pgf/systemlayer/pgfsys-textures.def
-tex/generic/pgf/systemlayer/pgfsys-vtex.def
-tex/generic/pgf/systemlayer/pgfsys-xetex.def
-tex/generic/pgf/systemlayer/pgfsys.code.tex
-tex/generic/pgf/systemlayer/pgfsysanimations.code.tex
-tex/generic/pgf/systemlayer/pgfsysprotocol.code.tex
-tex/generic/pgf/systemlayer/pgfsyssoftpath.code.tex
-tex/generic/pgf/utilities/pgfcalendar.code.tex
-tex/generic/pgf/utilities/pgfexternal.tex
-tex/generic/pgf/utilities/pgfexternalwithdepth.tex
-tex/generic/pgf/utilities/pgffor.code.tex
-tex/generic/pgf/utilities/pgfkeys.code.tex
-tex/generic/pgf/utilities/pgfkeysfiltered.code.tex
-tex/generic/pgf/utilities/pgfrcs.code.tex
-tex/generic/pgf/utilities/pgfutil-common-lists.tex
-tex/generic/pgf/utilities/pgfutil-common.tex
-tex/generic/pgf/utilities/pgfutil-context.def
-tex/generic/pgf/utilities/pgfutil-latex.def
-tex/generic/pgf/utilities/pgfutil-plain.def
-tex/latex/pgf/basiclayer/pgf.sty
-tex/latex/pgf/basiclayer/pgfbaseimage.sty
-tex/latex/pgf/basiclayer/pgfbaselayers.sty
-tex/latex/pgf/basiclayer/pgfbasematrix.sty
-tex/latex/pgf/basiclayer/pgfbasepatterns.sty
-tex/latex/pgf/basiclayer/pgfbaseplot.sty
-tex/latex/pgf/basiclayer/pgfbaseshapes.sty
-tex/latex/pgf/basiclayer/pgfbasesnakes.sty
-tex/latex/pgf/basiclayer/pgfcore.sty
-tex/latex/pgf/compatibility/pgfarrows.sty
-tex/latex/pgf/compatibility/pgfautomata.sty
-tex/latex/pgf/compatibility/pgfcomp-version-0-65.sty
-tex/latex/pgf/compatibility/pgfcomp-version-1-18.sty
-tex/latex/pgf/compatibility/pgfheaps.sty
-tex/latex/pgf/compatibility/pgflibraryarrows.sty
-tex/latex/pgf/compatibility/pgflibraryautomata.sty
-tex/latex/pgf/compatibility/pgflibraryplothandlers.sty
-tex/latex/pgf/compatibility/pgflibraryplotmarks.sty
-tex/latex/pgf/compatibility/pgflibraryshapes.sty
-tex/latex/pgf/compatibility/pgflibrarysnakes.sty
-tex/latex/pgf/compatibility/pgflibrarytikzbackgrounds.sty
-tex/latex/pgf/compatibility/pgflibrarytikztrees.sty
-tex/latex/pgf/compatibility/pgfnodes.sty
-tex/latex/pgf/compatibility/pgfshade.sty
-tex/latex/pgf/doc/pgfmanual-en-macros.tex
-tex/latex/pgf/doc/pgfmanual.code.tex
-tex/latex/pgf/doc/pgfmanual.pdflinks.code.tex
-tex/latex/pgf/doc/pgfmanual.prettyprinter.code.tex
-tex/latex/pgf/doc/pgfmanual.sty
-tex/latex/pgf/frontendlayer/libraries/tikzlibraryexternal.code.tex
-tex/latex/pgf/frontendlayer/pgfpict2e.sty
-tex/latex/pgf/frontendlayer/tikz.sty
-tex/latex/pgf/math/pgfmath.sty
-tex/latex/pgf/systemlayer/pgfsys.sty
-tex/latex/pgf/utilities/pgfcalendar.sty
-tex/latex/pgf/utilities/pgffor.sty
-tex/latex/pgf/utilities/pgfkeys.sty
-tex/latex/pgf/utilities/pgfpages.sty
-tex/latex/pgf/utilities/pgfparser.sty
-tex/latex/pgf/utilities/pgfrcs.sty
-tex/latex/pgf/utilities/tikzexternal.sty
-tex/latex/pgf/utilities/xxcolor.sty
-tex/plain/pgf/basiclayer/pgf.tex
-tex/plain/pgf/basiclayer/pgfbaseimage.tex
-tex/plain/pgf/basiclayer/pgfbaselayers.tex
-tex/plain/pgf/basiclayer/pgfbasematrix.tex
-tex/plain/pgf/basiclayer/pgfbasepatterns.tex
-tex/plain/pgf/basiclayer/pgfbaseplot.tex
-tex/plain/pgf/basiclayer/pgfbaseshapes.tex
-tex/plain/pgf/basiclayer/pgfbasesnakes.tex
-tex/plain/pgf/basiclayer/pgfcore.tex
-tex/plain/pgf/frontendlayer/tikz.tex
-tex/plain/pgf/math/pgfmath.tex
-tex/plain/pgf/systemlayer/pgfsys.tex
-tex/plain/pgf/utilities/pgfcalendar.tex
-tex/plain/pgf/utilities/pgffor.tex
-tex/plain/pgf/utilities/pgfkeys.tex
-tex/plain/pgf/utilities/pgfrcs.tex
Deleted: trunk/Master/texmf-dist/doc/generic/pgf/INSTALL
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/INSTALL 2023-01-15 20:55:58 UTC (rev 65552)
+++ trunk/Master/texmf-dist/doc/generic/pgf/INSTALL 2023-01-15 20:58:27 UTC (rev 65553)
@@ -1,11 +0,0 @@
-Installing pgf:
----------------
-
-For the impatient:
-- Put the whole pgf directory somewhere where TeX can find them.
-- Install the xcolor package version 2.00 or higher.
-
-Long version:
-In the manual, which you find in the file
-doc/generic/pgf/pgfmanual.pdf, you will find a
-detailed explanation on how to install pgf.
Modified: trunk/Master/texmf-dist/doc/generic/pgf/README.md
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/README.md 2023-01-15 20:55:58 UTC (rev 65552)
+++ trunk/Master/texmf-dist/doc/generic/pgf/README.md 2023-01-15 20:58:27 UTC (rev 65553)
@@ -17,6 +17,10 @@
official mailing list at https://tug.org/mailman/listinfo/pgf-tikz to submit
bug reports, request new features, etc.
+We also have a chat on the Matrix network at
+[#pgf-tikz:matrix.org](https://matrix.to/#/#pgf-tikz:matrix.org) ([read-only
+version](https://view.matrix.org/room/!NuxCISwYQJuyWwNsEI:matrix.org/)).
+
## Installation
In general you should just use the version of PGF that is shipped by
@@ -34,7 +38,7 @@
## Development
-Currently PGF does not have a comprehensive test suite to check for
+Currently PGF only has a very rudimentary test suite to check for
regressions, so for now we check for bugs by building the manual for
each commit. To build the manual locally you can either copy the PGF
repository into your texmf tree (not recommended) or use the usertree
@@ -45,7 +49,7 @@
$ tlmgr init-usertree --usertree pgf
$ export TEXMFHOME=$(readlink -f pgf)
$ cd pgf
-$ texlua build.lua manual luatex
+$ l3build doc -q -H
```
We recommend building at least the version for LuaTeX, as shown in the
example above because this has the broadest coverage of PGF features.
Modified: trunk/Master/texmf-dist/doc/generic/pgf/RELEASE_NOTES.md
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/RELEASE_NOTES.md 2023-01-15 20:55:58 UTC (rev 65552)
+++ trunk/Master/texmf-dist/doc/generic/pgf/RELEASE_NOTES.md 2023-01-15 20:58:27 UTC (rev 65553)
@@ -1 +1,111 @@
-Emergency release to fix pgfplots which depends on unreleased parts of PGF.
+## [3.1.10] - 2023-01-13 Henri Menke
+
+Even though this release is not too heavy on user-facing additions it has seen a
+lot of contributed changes. Thanks to everyone who volunteered their time!
+
+### BREAKING CHANGES
+
+- `\pgfversiondatetime` and `\pgfrevisiondatetime` have been removed.
+ `\pgfversiondate` and `\pgfrevisiondate` now use the format `YYYY-MM-DD`.
+ `\pgfrevision{,date}` and `\pgfversion{,date}` are synonyms for now, but the
+ revision should eventually gain back its original meaning. However, as of now
+ this is not supported by l3build.
+- Many operations in `pgfkeys` used to use `\csname` directly which lets the
+ given csname become `\relax` in case it wasn't defined. This resulted in some
+ leakage of accidentally `\relax`ed keys into the global scope. This has been
+ cleaned up a little. To preserve compatibility macros that used to expand to a
+ `\relax`ed csname now expand to a primitive `\relax`. This affects the
+ user-level commands `\pgfkeysgetvalue` and `\pgfkeysgetvalueof`. For the
+ former the change should not be visible except for the number of expansions
+ required. For `\pgfkeysgetvalueof`, however, the behavior is manifestly
+ different in that it will now expand to an alias for the primitive `\relax` in
+ case the value is undefined instead of a `\relax`ed csname. It has always been
+ semantically wrong to assign to the result of `\pgfkeysgetvalueof`, but now it
+ will have undesired side-effects. Therefore this change is breaking.
+- The `textures` and `vtex` drivers have been deprecated. Both engines are no
+ longer in active development and lack eTeX features which are required for
+ quite some time in PGF.
+- The file `pgfutil-common-lists.tex` is deprecated and therefore no longer
+ `\input` by `pgfutil-common.tex`. The macros from this file are specifically
+ meant for pgfplots and are not used in PGF at all.
+
+### Added
+
+- l3build support for packaging PGF/TikZ
+- Add Matrix chat to README
+- Add rhombic polihedra #1022
+- Add Developer Certificate of Origin (DCO) to Pull Request template and enforce
+- Add test set for `graphdrawing` (gd)
+- pgfkeys gained support for loading libraries
+- Add dependabot to keep GitHub Actions up to date
+
+### Fixed
+
+- Wrap logic gate symbol in `\pgfinterruptpicture` for shapes in library
+ `shapes.gates.logic.IEC`
+- Remove superfluous `;` for shape `arrow box`
+- Remove superfluous `/utils/exec` in animations
+- Gobble `\pgf at stop` when parsing finishes in animations
+- Add missing `\pgf at sys@tonumber` before `<dimen>` in drivers and animations
+- Rewrite `dash expand off`
+- Better unknown key error msg in decorations
+- Fix `\let` in drivers for two csnames #1088
+- Protect against comma in pgfkeys arguments #389
+- Let active `"` expand to non-active `"` in pgfmath #1062
+- Protect against comma in `/tikz/rotate fit` argument and make it
+ eagerly evaluated #1071
+- Set pics/code in angle #1068
+- Fix for externalization and horizontal mode
+- Avoid spurious tokens in `\pgfcalendarifdate` expansion
+- Remove angle restriction #1048
+- Fix compatibility of `external` lib with `fadings` lib
+- Only clearpage and flush `\pgfutil at everybye` if non-empty #724
+- Fix foreach documentation #1039
+- Fix pgfmathless documentation #1040
+- Blend mode as array is deprecated #1037
+- One-step expansion for `\pgfmathrandomitem` in pgfmath #1033
+- Check whether expanded is a primitive in all engines
+- Reinsert the last token when giving up on a path #1025
+- Make `/tikz/local bounding box` aware of `name prefix` and `name suffix`
+- Add empty Pattern dictionary to Resources dictionary
+- Spelling and typo fixes in the manual
+- Update Debian installation instructions
+- Suppress white space at line end when `datavisualization` reads from a file
+ #1112
+- Form-only patterns have no specified color #1122
+- Make `graphdrawing` work with `name prefix` and `name suffix` options #1087
+- pgfkeys was a bit too relaxed around `\relax` #1132
+- Remove spurious spaces for `3d view` #1151
+- Fix incorrectly placed matrix delimiters for implicitly positioned nodes #1102
+- Use `/.append` to fix a wrong usage of `/.add` in pgfmanual #1201
+
+### Changed
+
+- Cleanup `\newif`s
+- Remove unused scripts
+- Remove experiments/ folder
+- Simplify loading by delegating to top-level files
+- Promote `Missing character` to errors in building manual
+- Flatten the doc tree
+- Ensure `\tracinglostchars<3` in `\pgf at picture`
+- Use descriptive workflow job ids
+- Ensure `doc` v2 is loaded for pgfmanual
+- Ensure active `^^M` is non-expandable in `codeexample`
+
+### Contributors
+
+- 3geek14
+- BeneIII
+- graue70
+- Gábor Braun
+- Joel Coffman
+- Jonathan Spratte
+- Joseph Wright
+- Mario Frasca
+- Michael Kuron
+- Michal Hoftich
+- muzimuzhi
+- PhelypeOleinik
+- QJLc
+- Stefan Pinnow
+
Added: trunk/Master/texmf-dist/doc/generic/pgf/brave-gnu-world-logo-mask.jpg
===================================================================
(Binary files differ)
Index: trunk/Master/texmf-dist/doc/generic/pgf/brave-gnu-world-logo-mask.jpg
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/brave-gnu-world-logo-mask.jpg 2023-01-15 20:55:58 UTC (rev 65552)
+++ trunk/Master/texmf-dist/doc/generic/pgf/brave-gnu-world-logo-mask.jpg 2023-01-15 20:58:27 UTC (rev 65553)
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/brave-gnu-world-logo-mask.jpg
___________________________________________________________________
Added: svn:mime-type
## -0,0 +1 ##
+application/octet-stream
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/brave-gnu-world-logo.25.jpg
===================================================================
(Binary files differ)
Index: trunk/Master/texmf-dist/doc/generic/pgf/brave-gnu-world-logo.25.jpg
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/brave-gnu-world-logo.25.jpg 2023-01-15 20:55:58 UTC (rev 65552)
+++ trunk/Master/texmf-dist/doc/generic/pgf/brave-gnu-world-logo.25.jpg 2023-01-15 20:58:27 UTC (rev 65553)
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/brave-gnu-world-logo.25.jpg
___________________________________________________________________
Added: svn:mime-type
## -0,0 +1 ##
+application/octet-stream
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/brave-gnu-world-logo.jpg
===================================================================
(Binary files differ)
Index: trunk/Master/texmf-dist/doc/generic/pgf/brave-gnu-world-logo.jpg
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/brave-gnu-world-logo.jpg 2023-01-15 20:55:58 UTC (rev 65552)
+++ trunk/Master/texmf-dist/doc/generic/pgf/brave-gnu-world-logo.jpg 2023-01-15 20:58:27 UTC (rev 65553)
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/brave-gnu-world-logo.jpg
___________________________________________________________________
Added: svn:mime-type
## -0,0 +1 ##
+application/octet-stream
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/color.cfg
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/color.cfg (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/color.cfg 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,5 @@
+% xcolor inputs this file and ignores the global document options to choose the engine
+% Here we just make sure that a driver is selected
+\expandafter\ifx\csname Gin at driver\endcsname\relax
+ \errmessage{No graphics driver has been selected. Load graphicx before xcolor.}%
+\fi
\ No newline at end of file
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/color.cfg
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Deleted: trunk/Master/texmf-dist/doc/generic/pgf/extract.lua
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/extract.lua 2023-01-15 20:55:58 UTC (rev 65552)
+++ trunk/Master/texmf-dist/doc/generic/pgf/extract.lua 2023-01-15 20:58:27 UTC (rev 65553)
@@ -1,171 +0,0 @@
-local lfs = require("lfs")
-local lpeg = require("lpeg")
-local C, Cf, Cg, Ct, P, S, V = lpeg.C, lpeg.Cf, lpeg.Cg, lpeg.Ct, lpeg.P, lpeg.S, lpeg.V
-
--- strip leading and trailing whitespace
-local function strip(str)
- return str:match"^%s*(.-)%s*$"
-end
--- strip braces
-local function strip_braces(str)
- return str:match"^{?(.-)}?$"
-end
-
--- optional whitespace
-local ws = S" \t\n\r"^0
-
--- match string literal
-local function lit(str)
- return ws * P(str) * ws
-end
-
--- setter for options table
-local invalid = string.char(0x8)
-local function set(t,k,v)
- -- strip whitespace from keys
- k = strip(k)
- -- if the value is empty, set it to invalid character
- v = v and strip_braces(v) or invalid
- return rawset(t,k,v)
-end
-
--- Grammar to extract code examples
-local extractor = lpeg.P{"document",
- name =
- C((1 - S",]=")^1),
-
- pair =
- Cg(V"name" * (lit"=" * (V"braces" + V"name"))^0) * lit","^-1,
-
- list =
- Cf(Ct"" * V"pair"^0, set),
-
- balanced =
- "{" * ((1 - S"{}") + V"balanced")^0 * "}",
-
- braces =
- C(V"balanced"),
-
- optarg =
- lit"[" * V"list" * lit"]",
-
- begincodeexample =
- P"\\begin{codeexample}" * V"optarg",
-
- endcodeexample =
- P"\\end{codeexample}",
-
- content =
- C((1 - V"endcodeexample")^0),
-
- codeexample =
- Ct(V"begincodeexample" * V"content" * V"endcodeexample"),
-
- anything =
- (1 - V"codeexample")^0,
-
- document =
- V"anything" * Ct(V"codeexample" * (V"anything" * V"codeexample")^0) * V"anything"
-}
-
--- get the basename and extension of a file
-local function basename(file)
- local basename, ext = string.match(file, "^(.+)%.([^.]+)$")
- return basename or "", ext or file
-end
-
-local pathsep = package.config:sub(1,1)
-
--- Walk the file tree
-local function walk(sourcedir, targetdir)
- -- Make sure the arguments are directories
- assert(lfs.attributes(sourcedir, "mode") == "directory", sourcedir .. " is not a directory")
- assert(lfs.attributes(targetdir, "mode") == "directory", targetdir .. " is not a directory")
-
- -- Append the path separator if necessary
- if sourcedir:sub(-1, -1) ~= pathsep then
- sourcedir = sourcedir .. pathsep
- end
- if targetdir:sub(-1, -1) ~= pathsep then
- targetdir = targetdir .. pathsep
- end
-
- -- Process all items in the directory
- for file in lfs.dir(sourcedir) do
- if file == "." or file == ".." then
- -- Ignore these two special ones
- elseif lfs.attributes(sourcedir .. file, "mode") == "directory" then
- -- Recurse into subdirectories
- lfs.mkdir(targetdir .. file)
- walk(sourcedir .. file .. pathsep, targetdir .. file .. pathsep)
- elseif lfs.attributes(sourcedir .. file, "mode") == "file" then
- print("Processing " .. sourcedir .. file)
-
- -- Read file into memory
- local f = io.open(sourcedir .. file)
- local text = f:read("*all")
- f:close()
- local name, ext = basename(file)
-
- -- preprocess, strip all commented lines
- text = text:gsub("\n%%[^\n]*","")
-
- -- extract all code examples
- local matches = extractor:match(text) or {}
-
- -- write code examples to separate files
- local setup_code = ""
- for n, e in ipairs(matches) do
- local options = e[1]
- local content = e[2]
-
- if content:match("remember picture") then
- goto continue
- end
-
- -- If the snippet is marked as setup code, we have to put it before
- -- every other snippet in the same file
- if options["setup code"] then
- setup_code = setup_code .. strip(content) .. "\n"
- goto continue
- end
-
- -- Skip those that say "code only" or "setup code"
- if not options["code only"] and not options["setup code"] then
- local newname = name .. "-" .. n .. ".tex"
- local examplefile = io.open(targetdir .. newname, "w")
-
- examplefile:write"\\documentclass{standalone}\n"
- examplefile:write"\\usepackage{fp,pgf,tikz,xcolor}\n"
- examplefile:write(options["preamble"] and options["preamble"] .. "\n" or "")
- examplefile:write"\\begin{document}\n"
-
- examplefile:write(setup_code)
- local pre = options["pre"] or ""
- pre = pre:gsub("##", "#")
- examplefile:write(pre .. "\n")
- if options["render instead"] then
- examplefile:write(options["render instead"] .. "\n")
- else
- examplefile:write(strip(content) .. "\n")
- end
- examplefile:write(options["post"] and options["post"] .. "\n" or "")
- examplefile:write"\\end{document}\n"
-
- examplefile:close()
- end
-
- ::continue::
- end
- end
- end
-end
-
--- Main loop
-if #arg < 2 then
- print("Usage: " .. arg[-1] .. " " .. arg[0] .. " <source-dirs...> <target-dir>")
- os.exit(1)
-end
-for n = 1, #arg - 1 do
- walk(arg[n], arg[#arg])
-end
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-actions.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-actions.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-actions.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,530 @@
+% Copyright 2019 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section{Using Paths}
+
+\subsection{Overview}
+
+Once a path has been constructed, it can be \emph{used} in different ways. For
+example, you can draw the path or fill it or use it for clipping.
+
+Numerous graph parameters influence how a path will be rendered. For example,
+when you draw a path, the line width is important as well as the dashing
+pattern. The options that govern how paths are rendered can all be set with
+commands starting with |\pgfset|. \emph{All options that influence how a path
+is rendered always influence the complete path.} Thus, it is not possible to
+draw part of a path using, say, a red color and drawing another part using a
+green color. To achieve such an effect, you must use two paths.
+
+In detail, paths can be used in the following ways:
+%
+\begin{enumerate}
+ \item You can \emph{stroke} (also known as \emph{draw}) a path.
+ \item You can add \emph{arrow tips} to a path.
+ \item You can \emph{fill} a path with a uniform color.
+ \item You can \emph{clip} subsequent renderings against the path.
+ \item You can \emph{shade} a path.
+ \item You can \emph{use the path as bounding box} for the whole picture.
+\end{enumerate}
+%
+You can also perform any combination of the above, though it makes no sense to
+fill and shade a path at the same time.
+
+To perform (a combination of) the first four actions, you can use the following
+command:
+%
+\begin{command}{\pgfusepath\marg{actions}}
+ Applies the given \meta{actions} to the current path. Afterwards, the
+ current path is (globally) empty. The following actions are possible:
+ %
+ \begin{itemize}
+ \item \declare{|fill|} fills the path. See Section~\ref{section-fill}
+ for further details.
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathlineto{\pgfpoint{1cm}{1cm}}
+ \pgfpathlineto{\pgfpoint{1cm}{0cm}}
+ \pgfusepath{fill}
+\end{pgfpicture}
+\end{codeexample}
+ %
+ \item \declare{|stroke|} strokes the path. See
+ Section~\ref{section-stroke} for further details.
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathlineto{\pgfpoint{1cm}{1cm}}
+ \pgfpathlineto{\pgfpoint{1cm}{0cm}}
+ \pgfusepath{stroke}
+\end{pgfpicture}
+\end{codeexample}
+ %
+ \item \declare{|draw|} has the same effect as |stroke|.
+ \item \declare{|clip|} clips all subsequent drawings against the path.
+ Always suppresses arrow tips. See Section~\ref{section-clip} for
+ further details.
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathlineto{\pgfpoint{1cm}{1cm}}
+ \pgfpathlineto{\pgfpoint{1cm}{0cm}}
+ \pgfusepath{stroke,clip}
+ \pgfpathcircle{\pgfpoint{1cm}{1cm}}{0.5cm}
+ \pgfusepath{fill}
+\end{pgfpicture}
+\end{codeexample}
+ %
+ \item \declare{|discard|} discards the path, that is, it is not used at
+ all. Giving this option (alone) has the same effect as giving an
+ empty options list.
+ \end{itemize}
+ %
+ When more than one of the first three actions are given, they are applied
+ in the above ordering, regardless of their ordering in \meta{actions}.
+ Thus, |{stroke,fill}| and |{fill,stroke}| have the same effect.
+\end{command}
+
+To shade a path, use the |\pgfshadepath| command, which is explained in
+Section~\ref{section-shadings}.
+
+
+\subsection{Stroking a Path}
+\label{section-stroke}
+
+When you use |\pgfusepath{stroke}| to stroke a path, several graphic parameters
+influence how the path is drawn. The commands for setting these parameters are
+explained in the following.
+
+Note that all graphic parameters apply to the path as a whole, never only to a
+part of it.
+
+All graphic parameters are local to the current |{pgfscope}|, but they persists
+past \TeX\ groups, \emph{except} for the interior rule (even-odd or nonzero)
+and the arrow tip kinds. The latter graphic parameters only persist till the
+end of the current \TeX\ group, but this may change in the future, so do not
+count on this.
+
+
+\subsubsection{Graphic Parameter: Line Width}
+
+\begin{command}{\pgfsetlinewidth\marg{line width}}
+ This command sets the line width for subsequent strokes (in the current
+ |pgfscope|). The line width is given as a normal \TeX\ dimension like
+ |0.4pt| or |1mm|.
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgfsetlinewidth{1mm}
+ \pgfpathmoveto{\pgfpoint{0mm}{0mm}}
+ \pgfpathlineto{\pgfpoint{2cm}{0mm}}
+ \pgfusepath{stroke}
+ \pgfsetlinewidth{2\pgflinewidth} % double in size
+ \pgfpathmoveto{\pgfpoint{0mm}{5mm}}
+ \pgfpathlineto{\pgfpoint{2cm}{5mm}}
+ \pgfusepath{stroke}
+\end{pgfpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{textoken}{\pgflinewidth}
+ You can access the current line width via the \TeX\ dimension
+ |\pgflinewidth|. It will be set to the correct line width, that is, even
+ when a \TeX\ group closed, the value will be correct since it is set
+ globally, but when a |{pgfscope}| closes, the value is set to the correct
+ value it had before the scope.
+\end{textoken}
+
+
+\subsubsection{Graphic Parameter: Caps and Joins}
+
+\begin{command}{\pgfsetbuttcap}
+ Sets the line cap to a butt cap. See Section~\ref{section-cap-joins} for an
+ explanation of what this is.
+\end{command}
+%
+\begin{command}{\pgfsetroundcap}
+ Sets the line cap to a round cap. See again Section~\ref{section-cap-joins}.
+\end{command}
+\begin{command}{\pgfsetrectcap}
+ Sets the line cap to a square cap. See again Section~\ref{section-cap-joins}.
+\end{command}
+%
+\begin{command}{\pgfsetroundjoin}
+ Sets the line join to a round join. See again Section~\ref{section-cap-joins}.
+\end{command}
+%
+\begin{command}{\pgfsetbeveljoin}
+ Sets the line join to a bevel join. See again Section~\ref{section-cap-joins}.
+\end{command}
+%
+\begin{command}{\pgfsetmiterjoin}
+ Sets the line join to a miter join. See again Section~\ref{section-cap-joins}.
+\end{command}
+%
+\begin{command}{\pgfsetmiterlimit\marg{miter limit factor}}
+ Sets the miter limit to \meta{miter limit factor}. See again
+ Section~\ref{section-cap-joins}.
+\end{command}
+
+
+\subsubsection{Graphic Parameter: Dashing}
+
+\begin{command}{\pgfsetdash\marg{list of even length of dimensions}\marg{phase}}
+ Sets the dashing of a line. The first entry in the list specifies the
+ length of the first solid part of the list. The second entry specifies the
+ length of the following gap. Then comes the length of the second solid
+ part, following by the length of the second gap, and so on. The
+ \meta{phase} specifies where the first solid part starts relative to the
+ beginning of the line.
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgfsetdash{{0.5cm}{0.5cm}{0.1cm}{0.2cm}}{0cm}
+ \pgfpathmoveto{\pgfpoint{0mm}{0mm}}
+ \pgfpathlineto{\pgfpoint{2cm}{0mm}}
+ \pgfusepath{stroke}
+ \pgfsetdash{{0.5cm}{0.5cm}{0.1cm}{0.2cm}}{0.1cm}
+ \pgfpathmoveto{\pgfpoint{0mm}{1mm}}
+ \pgfpathlineto{\pgfpoint{2cm}{1mm}}
+ \pgfusepath{stroke}
+ \pgfsetdash{{0.5cm}{0.5cm}{0.1cm}{0.2cm}}{0.2cm}
+ \pgfpathmoveto{\pgfpoint{0mm}{2mm}}
+ \pgfpathlineto{\pgfpoint{2cm}{2mm}}
+ \pgfusepath{stroke}
+\end{pgfpicture}
+\end{codeexample}
+
+ Use |\pgfsetdash{}{0pt}| to get a solid dashing.
+\end{command}
+
+
+\subsubsection{Graphic Parameter: Stroke Color}
+
+\begin{command}{\pgfsetstrokecolor\marg{color}}
+ Sets the color used for stroking lines to \meta{color}, where \meta{color}
+ is a \LaTeX\ color like |red| or |black!20!red|. Unlike the |\color|
+ command, the effect of this command lasts till the end of the current
+ |{pgfscope}| and not till the end of the current \TeX\ group.
+
+ The color used for stroking may be different from the color used for
+ filling. However, a |\color| command will always ``immediately override''
+ any special settings for the stroke and fill colors.
+
+ In plain \TeX, this command will also work, but the problem of
+ \emph{defining} a color arises. After all, plain \TeX\ does not provide
+ \LaTeX\ colors. For this reason, \pgfname\ implements a minimalistic
+ ``emulation'' of the |\definecolor|, |\colorlet|, and |\color| commands.
+ Only gray-scale and rgb colors are supported. For most cases this turns out
+ to be enough.
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgfsetlinewidth{1pt}
+ \color{red}
+ \pgfpathcircle{\pgfpoint{0cm}{0cm}}{3mm} \pgfusepath{fill,stroke}
+ \pgfsetstrokecolor{black}
+ \pgfpathcircle{\pgfpoint{1cm}{0cm}}{3mm} \pgfusepath{fill,stroke}
+ \color{red}
+ \pgfpathcircle{\pgfpoint{2cm}{0cm}}{3mm} \pgfusepath{fill,stroke}
+\end{pgfpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfsetcolor\marg{color}}
+ Sets both the stroke and fill color. The difference to the normal |\color|
+ command is that the effect lasts till the end of the current |{pgfscope}|,
+ not only till the end of the current \TeX\ group.
+\end{command}
+
+
+\subsubsection{Graphic Parameter: Stroke Opacity}
+
+You can set the stroke opacity using |\pgfsetstrokeopacity|. This command is
+described in Section~\ref{section-transparency}.
+
+
+\subsubsection{Inner Lines}
+
+When a path is stroked, it is possible to request that it is stroked twice, the
+second time with a different line width and a different color. This is a useful
+effect for creating ``double'' lines, for instance by setting the line width to
+2pt and stroking a black line and then setting the inner line width to 1pt and
+stroking a white line on the same path as the original path. This results in
+what looks like two lines, each of thickness 0.5pt, spaced 1pt apart.
+
+You may wonder why there is direct support for this ``double stroking'' in the
+basic layer. After all, this effect is easy to achieve ``by hand''. The main
+reason is that arrow tips must be treated in a special manner when such
+``double lines'' are present. First, the order of actions is important: First,
+the (thick) main line should be stroked, then the (thin) inner line, and only
+then should the arrow tip be drawn. Second, the way an arrow tip looks
+typically depends strongly on the width of the inner line, so the arrow tip
+code, which is part of the basic layer, needs access to the inner line
+thickness.
+
+Two commands are used to set the inner line width and color.
+
+\begin{command}{\pgfsetinnerlinewidth\marg{dimension}}
+ This command sets the width of the inner line. Whenever a path is stroked
+ (and only then), it will be stroked normally and, afterward, it is stroked
+ once more with the color set to the inner line color and the line width set
+ to \meta{dimension}.
+
+ In case arrow tips are added to a path, the path is first stroked normally,
+ then the inner line is stroked, and then the arrow tip is added. In case
+ the main path is shortened because of the added arrow tip, this shortened
+ path is double stroked, not the original path (which is exactly what you
+ want).
+
+ When the inner line width is set to 0pt, which is the default, no inner
+ line is stroked at all (not even a line of width 0pt). So, in order to
+ ``switch off'' double stroking, set \meta{dimension} to~|0pt|.
+
+ The setting of the inner line width is local to the current \TeX\ group and
+ \emph{not} to the current \pgfname\ scope.
+
+ Note that inner lines will \emph{not} be drawn for paths that are also used
+ for clipping. However, this may change in the future, so you should not
+ depend on this.
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathlineto{\pgfpoint{1cm}{1cm}}
+ \pgfpathlineto{\pgfpoint{1cm}{0cm}}
+ \pgfsetlinewidth{2pt}
+ \pgfsetinnerlinewidth{1pt}
+ \pgfusepath{stroke}
+\end{pgfpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfsetinnerstrokecolor\marg{color}}
+ This command sets the \meta{color} that is to be used when the inner line
+ is stroked. The effect of this command is also local to the current \TeX\
+ group.
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathlineto{\pgfpoint{1cm}{1cm}}
+ \pgfpathlineto{\pgfpoint{1cm}{0cm}}
+ \pgfsetlinewidth{2pt}
+ \pgfsetinnerlinewidth{1pt}
+ \pgfsetinnerstrokecolor{red!50}
+ \pgfusepath{stroke}
+\end{pgfpicture}
+\end{codeexample}
+ %
+\end{command}
+
+
+\subsection{Arrow Tips on a Path}
+\label{section-tips}
+
+After a path has been drawn, \pgfname\ can add arrow tips at the ends,
+depending on how the |tips| key is set, on whether |stroke| or |clip| are used
+and on whether the path contains closed subpaths. The exact rules when arrow
+tips are added are explained in Section~\ref{section-arrow-tips-where}.
+
+\begin{command}{\pgfsetarrowsstart\marg{start arrow tip specification}}
+ Sets the arrow tip kind used at the start of a (possibly curved) path. The
+ syntax of the \meta{start arrow specification} is detailed in
+ Section~\ref{section-arrow-spec}.
+
+ To ``clear'' the start arrow, say |\pgfsetarrowsstart{}|.
+ %
+\begin{codeexample}[preamble={\usepgflibrary{arrows.meta}}]
+\begin{pgfpicture}
+ \pgfsetarrowsstart{Latex[length=10pt]}
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathlineto{\pgfpoint{1cm}{0cm}}
+ \pgfusepath{stroke}
+ \pgfsetarrowsstart{Computer Modern Rightarrow}
+ \pgfpathmoveto{\pgfpoint{0cm}{2mm}}
+ \pgfpathlineto{\pgfpoint{1cm}{2mm}}
+ \pgfusepath{stroke}
+\end{pgfpicture}
+\end{codeexample}
+
+ The effect of this command persists only till the end of the current \TeX\
+ scope.
+\end{command}
+
+\begin{command}{\pgfsetarrowsend\marg{end arrow tip specification}}
+ Sets the arrow tip kind used at the end of a path.
+ %
+\begin{codeexample}[preamble={\usepgflibrary{arrows.meta}}]
+\begin{pgfpicture}
+ \pgfsetarrowsstart{Latex[length=10pt]}
+ \pgfsetarrowsend{Computer Modern Rightarrow}
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathlineto{\pgfpoint{1cm}{0cm}}
+ \pgfusepath{stroke}
+\end{pgfpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfsetarrows\marg{argument}}
+ The \meta{argument} can be of the form \meta{start arrow tip
+ specification}|-|\meta{end arrow tip specification}. In this case, both the
+ start and the end arrow specification are set:
+ %
+\begin{codeexample}[preamble={\usepgflibrary{arrows.meta}}]
+\begin{pgfpicture}
+ \pgfsetarrows{Latex[length=10pt]->>}
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathlineto{\pgfpoint{1cm}{0cm}}
+ \pgfusepath{stroke}
+\end{pgfpicture}
+\end{codeexample}
+ %
+ Alternatively, \meta{argument} can be of the form |[|\meta{arrow keys}|]|.
+ In this case, the \meta{arrow keys} will be set for all arrow tips in the
+ current scope, see Section~\ref{section-arrow-scopes}.
+\end{command}
+
+\begin{command}{\pgfsetshortenstart\marg{dimension}}
+ This command will shortened the start of every stroked path by the given
+ dimension. This shortening is done in addition to automatic shortening done
+ by a start arrow, but it can be used even if no start arrow is given.
+
+ It is usually better to use the |sep| key with arrow tips.
+
+ This command is useful if you wish arrows or lines to ``stop shortly
+ before'' a given point.
+ %
+\begin{codeexample}[preamble={\usepgflibrary{arrows.meta}}]
+\begin{pgfpicture}
+ \pgfpathcircle{\pgfpointorigin}{5mm}
+ \pgfusepath{stroke}
+ \pgfsetarrows{Latex-}
+ \pgfsetshortenstart{4pt}
+ \pgfpathmoveto{\pgfpoint{5mm}{0cm}} % would be on the circle
+ \pgfpathlineto{\pgfpoint{2cm}{0cm}}
+ \pgfusepath{stroke}
+\end{pgfpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfsetshortenend\marg{dimension}}
+ Works like |\pgfsetshortenstart|.
+\end{command}
+
+
+\subsection{Filling a Path}
+\label{section-fill}
+
+Filling a path means coloring every interior point of the path with the current
+fill color. It is not always obvious whether a point is ``inside'' a path when
+the path is self-intersecting and/or consists or multiple parts. In this case
+either the nonzero winding number rule or the even-odd crossing number rule is
+used to decide which points lie ``inside''. These rules are explained in
+Section~\ref{section-rules}.
+
+
+\subsubsection{Graphic Parameter: Interior Rule}
+
+You can set which rule is used using the following commands:
+
+\begin{command}{\pgfseteorule}
+ Dictates that the even-odd rule is used in subsequent fillings in the
+ current \emph{\TeX\ scope}. Thus, for once, the effect of this command does
+ not persist past the current \TeX\ scope.
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgfseteorule
+ \pgfpathcircle{\pgfpoint{0mm}{0cm}}{7mm}
+ \pgfpathcircle{\pgfpoint{5mm}{0cm}}{7mm}
+ \pgfusepath{fill}
+\end{pgfpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfsetnonzerorule}
+ Dictates that the nonzero winding number rule is used in subsequent
+ fillings in the current \TeX\ scope. This is the default.
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgfsetnonzerorule
+ \pgfpathcircle{\pgfpoint{0mm}{0cm}}{7mm}
+ \pgfpathcircle{\pgfpoint{5mm}{0cm}}{7mm}
+ \pgfusepath{fill}
+\end{pgfpicture}
+\end{codeexample}
+ %
+\end{command}
+
+
+\subsubsection{Graphic Parameter: Filling Color}
+
+\begin{command}{\pgfsetfillcolor\marg{color}}
+ Sets the color used for filling paths to \meta{color}. Like the stroke
+ color, the effect lasts only till the next use of |\color|.
+\end{command}
+
+
+\subsubsection{Graphic Parameter: Fill Opacity}
+
+You can set the fill opacity using |\pgfsetfillopacity|. This command is
+described in Section~\ref{section-transparency}.
+
+
+\subsection{Clipping a Path}
+\label{section-clip}
+
+When you add the |clip| option, the current path is used for clipping
+subsequent drawings. The same rule as for filling is used to decide whether a
+point is inside or outside the path, that is, either the even-odd rule or the
+nonzero rule.
+
+Clipping never enlarges the clipping area. Thus, when you clip against a
+certain path and then clip again against another path, you clip against the
+intersection of both.
+
+The only way to enlarge the clipping path is to end the |{pgfscope}| in which
+the clipping was done. At the end of a |{pgfscope}| the clipping path that was
+in force at the beginning of the scope is reinstalled.
+
+
+\subsection{Using a Path as a Bounding Box}
+\label{section-using-bb}
+
+When you add the |use as bounding box| option, the bounding box of the picture
+will be enlarged such that the path in encompassed, but any \emph{subsequent}
+paths of the current \TeX\ scope will not have any effect on the size of the
+bounding box. Typically, you use this command at the very beginning of a
+|{pgfpicture}| environment. Alternatively, you can use |\pgfresetboundingbox|,
+followed by |\pgfusepath{use as bounding box}| to overrule the picture's
+bounding box completely.
+%
+\begin{codeexample}[]
+Left
+\begin{pgfpicture}
+ \pgfpathrectangle{\pgfpointorigin}{\pgfpoint{2ex}{1ex}}
+ \pgfusepath{use as bounding box} % draws nothing
+
+ \pgfpathcircle{\pgfpointorigin}{2ex}
+ \pgfusepath{stroke}
+\end{pgfpicture}
+right.
+\end{codeexample}
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-actions.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-animations.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-animations.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-animations.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,1492 @@
+% Copyright 2019 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section{Animations}
+\label{section-base-animations}
+
+\begin{pgfmodule}{animations}
+ This module contains the basic layer support of animations, which is
+ documented in the following.
+\end{pgfmodule}
+
+This section described the basic layer support of animations, the \tikzname\
+support is described in Section~\ref{section-tikz-animations}. As always,
+\tikzname\ mainly converts syntactic constructs (like the special colon or
+quote syntax) to appropriate basic layer commands, which are documented here.
+Note, however, that while many attributes and options are the same on both
+layers, some things are handled differently on the basic layer.
+
+
+\subsection{Overview}
+
+An \emph{animation} changes the way some part of a graphic looks like over
+time. The archetypical animation is, of course, a \emph{movement} of node, but
+a change of, say, the opacity of a path is also an animation. \pgfname\ allows
+you to specify such animations using a set of commands and keys that are
+documented in the following.
+%
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0.5,1,1.5,2},
+]
+\tikz {
+ \pgfanimateattribute{opacity}{
+ whom = node, begin on = {click}, entry = {0s}{1}, entry = {2s}{0} }
+ \node (node) [fill = blue!20, draw = blue, very thick, circle] {Click me!};
+}
+\end{codeexample}
+
+Differently from other packages, the animations created by \pgfname\ are not
+precomputed sequences of pictures that are displayed in rapid succession.
+Rather, an animation created by \pgfname\ consists mainly of an annotation in
+the output that a certain attribute of a certain object should change over time
+in some specific way when the object is displayed. It is the job of the
+document viewer application to actually compute and display the animation.
+Interestingly, this means that animations neither increase the size of the
+output files noticeably nor does it put a special burden on \TeX. The hard and
+complicated calculations are done by the viewer application, not by \TeX\ and
+\pgfname.
+
+Only few viewer applications and formats are currently ``up to the job'' of
+displaying animations. In particular, the popular \textsc{pdf} format does
+\emph{not} allow one to specify animations in this way (one can partly ``fake''
+animations at the high price of including a great number of precomputed
+pictures and using JavaScript in special viewers, but this is really not the
+same thing as what \pgfname\ does). Indeed, currently only the \textsc{svg}
+format allows one to specify animations in a sensible way. Thus, \pgfname's
+animations will only be displayed when \textsc{svg} is used as output format.
+
+Because of the shortcomings of the other formats and, also, for purposes of
+printing and depicting animations in a sequential manner, \pgfname\ also allows
+you to create ``snapshots'' of animations. As an example, the following code
+shows how the same drawing is shown at different ``time snapshots'':
+%
+\begin{codeexample}[
+ width=3.9cm,
+ preamble={\usetikzlibrary{animations}
+\def\pgfname{\textsc{pgf}}
+}]
+\tikz [make snapshot of=0.5s] \scoped :rotate = { 0s = "0", 2s = "90" }
+ \node [draw=blue, very thick] {\pgfname};
+\tikz [make snapshot of=1s] \scoped :rotate = { 0s = "0", 2s = "90" }
+ \node [draw=blue, very thick] {\pgfname};
+\tikz [make snapshot of=1.5s] \scoped :rotate = { 0s = "0", 2s = "90" }
+ \node [draw=blue, very thick] {\pgfname};
+\tikz [make snapshot of=2s] \scoped :rotate = { 0s = "0", 2s = "90" }
+ \node [draw=blue, very thick] {\pgfname};
+\end{codeexample}
+
+
+\subsection{Animating an Attribute}
+
+\subsubsection{The Main Command}
+
+Creating an animation is done using the command |\pgfanimateattribute|, which
+takes a to-be-animated attribute and options specifying the timeline:
+
+\begin{command}{\pgfanimateattribute\marg{attribute}\marg{options}}
+ Adds an animation of the \meta{attribute} of a future \emph{object} to the
+ current graphic. Attributes are things like the ``fill opacity'' or the
+ transformation matrix or the line width.
+
+ The \meta{options} are keys that configure how the attribute changes over
+ time. Using the |entry| key multiple times, you specify which value the
+ chosen attribute should have at different points in time. Unless special
+ keys are used, ``outside'' the specified timeline the animation has no
+ effect:
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0.5,1,1.5,2,2.5},
+]
+\tikz {
+ \pgfanimateattribute{opacity}{
+ whom = node, begin on = {click}, entry = {0s}{1}, entry = {2s}{0} }
+ \node (node) [fill = blue!20, draw = blue, very thick, circle] {Click me!};
+}
+\end{codeexample}
+
+ Other keys, like |repeats|, allow you to specify how the animation behaves
+ ``as a whole''. These keys are documented later in this section.
+
+
+ \medskip
+ \textbf{The Attributes}
+
+ In detail, the |\pgfanimateattribute| command opens a \TeX-scope, looks up
+ the \emph{type} values of the specified \meta{attribute} have (if you wish
+ to animate the |opacity| of an object, the type is ``scalar'' meaning that
+ entries must be scalar numbers; when you animate the |fill| attribute, the
+ type is ``color'' and values must be colors, and so on), and then executes
+ the \meta{options} with the path prefix |/pgf/animation|. Finally, an
+ appropriate system layer command |\pgfsysanimate...| is called to create
+ the actual animation and the scope is closed.
+
+ The following \meta{attributes} are permissible:
+
+ \begin{tabular}{ll}
+ \emph{Attribute} & \emph{Type} \\
+ |draw|, |fill| & color \\
+ |line width| & dimension \\
+ |motion| & scalar \\
+ |opacity|, |fill opacity|, |draw opacity| & scalar \\
+ |path| & path \\
+ |rotate| & scalar \\
+ |scale| & scaling \\
+ |softpath| & softpath \\
+ |translate| & point \\
+ |view| & viewbox \\
+ |visible| & boolean \\
+ |stage| & boolean \\
+ |xskew|, |yskew| & scalar \\
+ \end{tabular}
+
+ These attributes are detailed in Sections
+ \ref{section-base-animation-painting}
+ to~\ref{section-base-animation-views}, but here is a quick overview:
+ %
+ \begin{itemize}
+ \item |draw| and |fill| refer to the color used to draw (stroke) and
+ fill paths in an object, respectively. Typical values for this
+ attribute are |red| or |black!10|.
+ \item |line width| is, of course, the line width used in an object.
+ Typical values are |0.4pt| or |1mm|. Note that you (currently)
+ cannot use keys like |thin| or |thick| here, but this may change in
+ the future.
+ \item |motion| is a slightly special attribute: It allows you to
+ specify a path along which the object should be moved (using the
+ |along| key). The values given to the |entry| key for this
+ attribute refer to a \emph{fraction of the distance along the
+ path}. See the |along| key for details.
+ \item |opacity| and the variants |fill opacity| and |draw opacity|
+ animate the opacity of an object. Allowed values range between 0
+ and 1.
+ \item |path| allows you to animate a path (it will morph). The
+ ``values'' are now paths themselves. See
+ Section~\ref{section-base-animation-paths} for details.
+ \item |rotate| refers to a rotation of the object. Values for the
+ |entry| key are the rotation angles like |0| or |90|.
+ \item |scale| refers to the scaling of the object. Values are either
+ single scalars values (like |1| or |1.5|) or two numbers separated
+ by a comma (like |1,1.5| or |0.5,2|), referring to the $x$-scaling
+ and $y$-scaling.
+ \item |softpath| is a special case of the |path| attribute, see
+ Section~\ref{section-base-animation-paths} once more.
+ \item |translate| shifts the object by a certain vector. Values are
+ points like |\pgfpoint{1cm}{2cm}|.
+ \item |view| allows you to animate the view box of a view, see
+ Section~\ref{section-base-animation-views} for details.
+ \item |visible| refers to the visibility of an object. Allowed values
+ are |true| and |false|.
+ \item |stage| is identical to |visible|, but when the object is not
+ animated, it will be hidden by default.
+ \item |xskew| and |yskew| skew the object. Attributes are angles like
+ |0| or |45| or even |90|.
+ \end{itemize}
+
+
+ \medskip
+ \textbf{The Target Object}
+
+ As stated earlier, the \meta{options} are used to specify the object whose
+ attribute for which an animation should be added to the picture. Indeed,
+ you \emph{must} specify the object explicitly using the |whom| key and you
+ must do so \emph{before} the object is created. Note that, in contrast, in
+ \textsc{svg} you can specify an animation more or less anywhere and then
+ use hyper-references to link the animation to the to-be-animated object;
+ \pgfname\ insists that you specify the animation before the object. This is
+ a bit of a bother in some situations, but it is the only way to ensure that
+ \pgfname\ has a fighting chance to attach some additional code to the
+ object (which is necessary for almost all animations of the transformation
+ matrix).
+
+ \begin{key}{/pgf/animation/whom=\meta{id}\opt{|.|\meta{type}}}
+ You \emph{must} use this key once which each call of the
+ |\pgfanimateattribute| command. The \meta{id} and the optional
+ \meta{type} (which is whatever follows the first dot) will be passed to
+ |\pgfidrefnextuse|, see that command for details.
+ \end{key}
+
+ As explained in the introduction of this chapter, an ``animation'' is just
+ a bit of special text in the output document asking a viewer application to
+ animate the object at some later time. The |\pgfanimateattribute| command
+ inserts this special text immediately, even though it refers to an object
+ created only later on. Normally, this is not a problem, but the special
+ text should be on the same page as the to-be-animated object. To ensure
+ this, it suffices to call |\pgfanimateattribute| no earlier than the
+ beginning of the |pgfpicture| containing the object.
+
+
+ \medskip
+ \textbf{Naming the Animation}
+
+ You can assign a name to an animation for later (or early) reference. In
+ particular, it is possible to begin \emph{another} animation relative to
+ the beginning or end of this animation and for referencing this animation
+ must be assigned a name. See the |of| and |of next| keys for details.
+
+ \begin{key}{/pgf/animation/name=\meta{name}}
+ Assigns a name to the animation by which it can be referenced using the
+ |of| and |of next| keys in another animation.
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={.5,1,1.5,2,2.5,3,3.5,4,4.5,5,5.5,6},
+]
+\tikz [very thick] {
+ \pgfanimateattribute{rotate}{
+ whom = node, begin on = {end, of next = my move animation, delay = 1s},
+ entry = {0s}{0}, entry = {2s}{90}, begin snapshot = 3s, }
+ \pgfanimateattribute{translate}{
+ name = my move animation, whom = node, begin on = {click},
+ entry = {0s}{\pgfpointorigin}, entry = {2s}{\pgfpoint{0cm}{-5mm}} }
+ \node (node) [fill = blue!20, draw = blue, circle] {Here!};
+}
+\end{codeexample}
+ \end{key}
+\end{command}
+
+\begin{command}{\pgfanimateattributecode\marg{attribute}\marg{code}}
+ The command works like |\pgfanimateattribute|, only instead of
+ \meta{options} you specify some \meta{code} whose job is to setup the
+ options.
+\end{command}
+
+
+\subsubsection{Specifying the Timeline}
+
+The core key for specifying how an attribute varies over time is the |entry|
+key:
+%
+\begin{key}{/pgf/animation/entry=\marg{time}\marg{value}}
+ You use this key repeatedly to specify the different values that the
+ \meta{attribute} should have over time. At the \meta{time} specified, the
+ \meta{attribute} will have the value specified as \meta{value}:
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={.5,1,1.5,2},
+]
+\tikz {
+ \pgfanimateattribute{rotate}{
+ whom = node, begin on = {click},
+ entry = {0s}{0}, entry = {1s}{90}, entry = {1.1s}{45}, entry = {2s}{90}
+ }
+ \node (node) [fill = blue!20, draw = blue, very thick, circle] {Click me!};
+}
+\end{codeexample}
+
+ You need to call |entry| once for each time in the timeline for which you
+ want to specify a \meta{value} explicitly. Between these times, the values
+ get interpolated (see below for details). You need to specify the
+ \meta{time}s in non-decreasing order (it is permissible and sometimes also
+ necessary to specify the same time twice, namely to create a ``jump'' of
+ the value of some attribute).
+
+ The \meta{time} is parsed using the command |\pgfparsetime| described
+ later.
+
+
+ \medskip
+ \textbf{Start and end of the timeline.}
+ The first and last times of the timeline are a bit special: The timeline
+ starts on the first time and the duration of the timeline is the difference
+ between the first and last time. ``Starting'' on the start time actually
+ means that any beginnings (see the |begin| and |end| keys) get offset by
+ the start time; similarly end times are offset by this value.
+
+
+ \medskip
+ \textbf{Syntax of the values.}
+ The syntax of the \meta{value} varies according to the type of the
+ \meta{attribute}. In detail, these are:
+
+ \begin{tabular}{lp{12cm}}
+ \emph{Type} & \emph{Syntax} \\
+ color & Standard color syntax like |red| or |black!10| \\
+ scalar & A value parsed using |\pgfmathparse| \\
+ dimension & A dimension parsed using |\pgfmathparse| \\
+ path & A sequence of path construction commands \\
+ softpath & A sequence of soft path construction commands \\
+ scaling & A scalar value or a pair of scalar values separated by a comma \\
+ point & A \pgfname-point like |\pgfpoint{1cm}{5mm}| \\
+ viewbox & Two \pgfname-points \\
+ boolean & |true| or |false| \\
+ \end{tabular}
+
+
+ \medskip
+ \textbf{Interpolation between key times.}
+ You use the |entry| key repeatedly, namely once for each ``key time'',
+ which is a time point for which you specify the value of the attribute
+ explicitly. Between these key times, the attribute's value is interpolated.
+ Normally, this is just a linear interpolation, but you can influence this
+ using the following keys, see Section~\ref{section-anim-smooth} for
+ details.
+
+ \begin{key}{/pgf/animations/exit control=\marg{time fraction}\marg{value fraction}}
+ Same as |/tikz/animate/options/exit control|.
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0.333/\frac{1}{3},0.666/\frac{2}{3},1,1.333/1\frac{1}{3},1.666/1\frac{2}{3}},
+]
+\tikz {
+ \foreach \i in {0,0.125,...,1} \draw (-0.9,.9-\i) -- ++(1.8,0);
+ \pgfanimateattribute{translate}{
+ whom = node, begin on = {click},
+ exit control={1}{0},
+ entry = {0s}{\pgfpointorigin},
+ linear, % revert to default
+ entry = {1s}{\pgfpoint{0cm}{-5mm}},
+ entry control={0}{1},
+ entry = {2s}{\pgfpoint{0cm}{-10mm}} }
+ \node (node) [fill = blue!20, draw = blue, very thick, circle] {Click me!};
+}
+\end{codeexample}
+ \end{key}
+
+ \begin{key}{/pgf/animations/entry control=\marg{time fraction}\marg{value fraction}}
+ Works like |exit control|.
+ \end{key}
+
+ \begin{key}{/pgf/animations/linear}
+ A shorthand for |exit control={0}{0}, entry control={1}{1}|. This will
+ (re)install a linear curve.
+ \end{key}
+
+ \begin{key}{/pgf/animations/stay}
+ Same as |/tikz/animate/options/stay|.
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0.5,1,1.5,2,2.5},
+]
+\tikz {
+ \foreach \i in {0,0.125,...,1} \draw (-0.9,.9-\i) -- ++(1.8,0);
+ \pgfanimateattribute{translate}{
+ whom = node, begin on = {click},
+ entry = {0s}{\pgfpointorigin},
+ stay,
+ entry = {1s}{\pgfpoint{0cm}{-5mm}},
+ linear,
+ entry = {2s}{\pgfpoint{0cm}{-10mm}},
+ entry = {3s}{\pgfpoint{0cm}{-15mm}} }
+ \node (node) [fill = blue!20, draw = blue, very thick, circle] {Click me!};
+}
+\end{codeexample}
+ \end{key}
+
+ \begin{key}{/pgf/animations/jump}
+ Same as |/tikz/animate/options/jump|.
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0.5,1,1.5,2},
+]
+\tikz {
+ \foreach \i in {0,0.125,...,1} \draw (-0.9,.9-\i) -- ++(1.8,0);
+ \pgfanimateattribute{translate}{
+ whom = node, begin on = {click},
+ entry = {0s}{\pgfpointorigin},
+ jump,
+ entry = {1s}{\pgfpoint{0cm}{-1cm}},
+ linear,
+ entry = {2s}{\pgfpoint{0cm}{-2cm}} }
+ \node (node) [fill = blue!20, draw = blue, very thick, circle] {Click me!};
+}
+\end{codeexample}
+ \end{key}
+\end{key}
+
+When the time of an animation lies outside the timeline specified by the
+|entry| keys, no animation is present. This means that the value of the
+attribute is the object's scope is used instead. Using the following key, you
+can set this value directly:
+
+\begin{key}{/tikz/animations/base=\meta{value}}
+ The syntax of the \meta{value} is the same as for the |entry| key. The
+ \meta{value} is installed as the value of the object's attribute whenever
+ the timeline is not active. This makes it easy to specify the value of an
+ attribute when the animation is ``not running''.
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={-1,0,1,2,3},
+]
+\tikz {
+ \pgfanimateattribute{rotate}{
+ whom = node, begin on = {click},
+ entry = {0s}{90}, entry = {2s}{180},
+ base = 45
+ }
+ \node (node) [fill = blue!20, draw = blue, very thick, circle] {Click me!};
+}
+\end{codeexample}
+ %
+\end{key}
+
+It may happen that there is more than one timeline active that is ``trying to
+modify'' a given attribute. In this case, the following rules are used to
+determine, which timeline ``wins'':
+%
+\begin{enumerate}
+ \item If no animation is active at the current time (all animation either
+ have not yet started or they have already ended), then the base value
+ given in the animation encountered last in the code is used. (If there
+ are no base values, the attribute is taken from the surrounding scope.)
+ \item If there are several active animations, the one that has started last
+ is used and the its value is used.
+ \item If there are several active animations that have started at the same
+ time, the one that comes last in the code is used.
+\end{enumerate}
+
+Note that these rules do not apply to transformations of the canvas since these
+are always additive (or, phrased differently, they are always all active and
+the effects accumulate).
+
+\begin{command}{\pgfparsetime\marg{time}}
+ This command works like |\pgfmathparse| (indeed, it calls is internally),
+ but returns the result in the macro |\pgftimeresult| rather than
+ |\pgfmathresult|. Furthermore, the following changes are installed:
+ %
+ \begin{itemize}
+ \item The postfix operator |s| is added, which has no effect.
+ \item The postfix operator |ms| is added, which divides a number by
+ 1000, so |2ms| equals 0.002s.
+ \item The postfix operator |min| is added, which multiplies a number by
+ 60.
+ \item The postfix operator |h| is added, which multiplies a number by
+ 3600.
+ \item The infix operator |:| is redefined, so that it multiplies its
+ first argument by 60 and adds the second. This implies that |1:20|
+ equals 80s and |01:00:00| equals 3600s.
+ \item The parsing of octal numbers is switched off to allow things like
+ |01:08| for 68s.
+ \end{itemize}
+\end{command}
+
+
+\subsubsection{``Anti-Animations'': Snapshots}
+
+There are a number of situations in which you want the ``opposite'' of an
+animation to happen: You want to create a ``still image''. For instance, when
+you want to print an animation you will typically wish to show one or more
+``temporal snapshots'' of the animation. Also, you may wish to specify a value
+for an object when it is \emph{not} being animated.
+
+Let us start with creating a snapshot:
+
+\begin{command}{\pgfsnapshot\marg{time}}
+ When this command is used inside a \TeX\ scope, the behavior of
+ |\pgfanimateattribute| changes: Instead of adding an animation to the
+ object and the attribute, the object's attribute is set to value it would
+ have during the animation at time \meta{time}. Note that when this command
+ is used in a \TeX\ scope, no animation is created and no support by the
+ driver is needed (so, it works with \textsc{pdf}).
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{animations}}]
+\tikz [make snapshot of=1s,
+ animate = { myself: = {
+ :rotate = { 0s = "0", 2s = "90" },
+ :color = { 0s = "red", 2s = "green" },
+ :line width = { 0s = "0mm", 4s = "4mm" }
+ }}]
+ \node [fill=black!20, draw] { Node };
+\end{codeexample}
+
+
+ \medskip\textbf{Timing and Events.}
+ The timeline of an animation normally starts at a ``moment |0s|'' and the
+ \meta{time} is considered relative to this time. For instance, if a
+ timeline contains, say, the settings |entry={2s}{0}| and |entry={3s}{10}|
+ and \marg{time} is set to |2.5s|, then the value the attribute will get is
+ 5.
+
+ It is, however, also possible to specify that animations begin and end at
+ certain times relative to events like a |click| event. \emph{These events
+ are not relevant with respect to snapshots.} However, there is one key that
+ allows you to specify the beginning of the snapshot timeline:
+ %
+ \begin{key}{/tikz/animations/begin snapshot=\meta{begin time}}
+ When this key is used inside the options of |\pgfanimateattribute|,
+ with respect to snapshots, the timeline begins at \meta{begin time}.
+ This means that, if the snapshot time is set to \meta{time} and the
+ beginning of the snapshot's timeline is set to \meta{begin time}, the
+ attribute is set to the value of the timeline at time $\meta{time} -
+ \meta{begin time}$.
+
+ The idea is that when you make a snapshot of several animations and all
+ of them have started at different times because of different events,
+ you use |begin snapshot| with each object and attribute to directly
+ specify when these different events have happened.
+ \end{key}
+
+ Note that the |end| keys have no effect with snapshots, that is, with a
+ snapshot all animations always run till the end of the timeline (which may
+ or may not be ``forever'').
+
+
+ \medskip\textbf{Limitations.}
+ For snapshots, the value an animation has at time \meta{time} must be
+ computed by \TeX. While in many cases this is easy to achieve, in some
+ cases this is not trivial such as a timeline for a path with repeats plus
+ smoothing via splines. An additional complication is the fact that an
+ animation may be specified at a place far removed from the actual
+ to-be-animated object. For these reasons, certain limitations apply to
+ snapshots:
+ %
+ \begin{itemize}
+ \item The |begin| and |begin on| keys have no effect (but
+ |begin snapshot| has one.
+ \item The |end| and |end on| keys have no effect.
+ \item The |current value| may not be used in a timeline (since
+ \pgfname\ cannot really determine this value).
+ \item The |accumulating| specification may not be used with paths,
+ views, or motions.
+ \item Since the timing computations are done using \TeX\ code, they are
+ not necessarily stable. For instance, when a time interval is very
+ small and there are many repeats or when a spline is very
+ complicated, the calculated values may not be fully accurate.
+ \end{itemize}
+\end{command}
+
+\begin{command}{\pgfsnapshotafter\marg{time}}
+ This command works exactly like |\pgfsnapshot| only the ``moment'' that
+ \meta{time} refers to is conceptually $\meta{time} + \epsilon$: When
+ timeline specifies several values for \meta{time}, this command will select
+ the last value at \meta{time}, while |\pgfsnapshot| will select the first
+ value at \meta{time}. Similarly, when a timeline ends at \meta{time},
+ |\pgfsnapshot| will select the last value of the timeline while
+ |\pgfsnapshotafter| will not apply the animation any more:
+ %
+\begin{codeexample}[preamble={\usepgfmodule{animations}}]
+\foreach \t in {0,1,2,3,4} {
+ \pgfsnapshot{\t}
+ \tikz :rotate = { 0s = "0", 2s = "90", 2s = "180", 4s = "270" }
+ \node [draw=blue, very thick] {f}; }
+\end{codeexample}
+ %
+\begin{codeexample}[preamble={\usepgfmodule{animations}}]
+\foreach \t in {0,1,2,3,4} {
+ \pgfsnapshotafter{\t}
+ \tikz :rotate = { 0s = "0", 2s = "90", 2s = "180", 4s = "270" }
+ \node [draw=blue, very thick] {f}; }
+\end{codeexample}
+ %
+\end{command}
+
+
+\subsection{Animating Color, Opacity, Visibility, and Staging}
+\label{section-base-animation-painting}
+
+\begin{animateattribute}{fill}
+ You can animate the color of the target object of an animation using the
+ attributes |fill| or |draw|, which animate the fill color and the drawing
+ (stroking) color, respectively. To animate both the fill and draw color,
+ you need to create two animations, one for each.
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0.5,1,1.5,2},
+]
+\tikz {
+ \pgfanimateattribute{fill}{
+ whom = node.background, begin on = {click},
+ entry = {0s}{white}, entry = {2s}{red} }
+ \node (node) [fill = blue!20, draw = blue, very thick, circle] {Click me!};
+}
+\end{codeexample}
+ %
+\end{animateattribute}
+
+\begin{animateattribute}{draw}
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0.5,1,1.5,2},
+]
+\tikz {
+ \pgfanimateattribute{draw}{
+ whom = node.background, begin on = {click},
+ entry = {0s}{white}, entry = {2s}{red} }
+ \node (node) [fill = blue!20, draw = blue, very thick, circle] {Click me!};
+}
+\end{codeexample}
+\end{animateattribute}
+
+When the target of a color animation is a scope, you animate the color ``used
+in this scope'' for filling or stroking. However, when an object inside the
+scope has its color set explicitly, this color overrules the color of the
+scope:
+%
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0.5,1,1.5,2},
+ animation bb={(1.5,-0.75) rectangle (3,0.75)},
+]
+\tikz {
+ \pgfanimateattribute{fill}{
+ whom = example, begin on = {click, of next=node},
+ entry = {0s}{white}, entry = {2s}{red} }
+ \node (node) [fill = blue!20, draw = blue, very thick, circle] {Click me!};
+ \begin{scope}[name = example]
+ \fill (1.5,-0.75) rectangle ++ (1,1);
+ \fill [blue] (2,-0.25) rectangle ++ (1,1);
+ \end{scope}
+}
+\end{codeexample}
+
+Note that in certain cases, a graphic scope may contain graphic objects with
+their colors set explicitly ``in places where you do not expect it'': In
+particular, a node normally consists at least of a background path and a text.
+For both the text and for the background path, colors will be set for the text
+and also for the path explicitly. This means that when you pick the fill
+attribute of a node as the target of an animation, you will \emph{not} animate
+the color of the background path in case this color has been set explicitly.
+Instead, you must choose the background path of the node as the target of the
+animation. Fortunately, this is easy to achieve since when the background path
+of a node is created, the identifier type is set to |background|, which in turn
+allows you to access it as \meta{node}|.background| through the |whom| key.
+
+The text of a node also gets it color set explicitly, which means that a change
+of the node's scope's color has no effect on the text color. Instead, you must
+choose \meta{name}|.text| as the target (or, if the node has more parts, use
+the name of the part as the identifier type instead of |text|).
+%
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0.5,1,1.5,2},
+ animation bb={(1.1,-0.9) rectangle (2.9,0.9)},
+]
+\tikz {
+ \pgfanimateattribute{fill}{
+ whom = example, begin on = {click, of next=node},
+ entry = {0s}{white}, entry = {2s}{red} }
+ \node (node) [fill = blue!20, draw = blue, very thick, circle] {Click me!};
+ \node at (2,0) (example) [fill = blue!20, circle] {No effect}; }
+\end{codeexample}
+
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0.5,1,1.5,2},
+ animation bb={(1.1,-0.9) rectangle (2.9,0.9)},
+]
+\tikz {
+ \pgfanimateattribute{fill}{
+ whom = example.background, begin on = {click, of next=node},
+ entry = {0s}{white}, entry = {2s}{red} }
+ \node (node) [fill = blue!20, draw = blue, very thick, circle] {Click me!};
+ \node at (2,0) (example) [fill = blue!20, circle] {Effect}; }
+\end{codeexample}
+
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0.5,1,1.5,2},
+ animation bb={(1.1,-0.9) rectangle (2.9,0.9)},
+]
+\tikz {
+ \pgfanimateattribute{fill}{
+ whom = example.text, begin on = {click, of next=node},
+ entry = {0s}{white}, entry = {2s}{red} }
+ \node (node) [fill = blue!20, draw = blue, very thick, circle] {Click me!};
+ \node at (2,0) (example) [fill = blue!20, circle, font=\huge] {Text}; }
+\end{codeexample}
+
+Similarly to the color, you can also set the opacity used for filling and for
+drawing. You specify the opacity using a number between 0 (transparent) and 1
+(opaque).
+
+\begin{animateattribute}{fill opacity}
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0.5,1,1.5,2},
+]
+\tikz {
+ \pgfanimateattribute{fill opacity}{
+ whom = node, begin on = {click}, entry = {0s}{1}, entry = {2s}{0} }
+ \node (node) [fill = blue!20, draw = blue, very thick, circle] {Click me!};
+}
+\end{codeexample}
+\end{animateattribute}
+
+\begin{animateattribute}{draw opacity}
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0.5,1,1.5,2},
+]
+\tikz {
+ \pgfanimateattribute{draw opacity}{
+ whom = node, begin on = {click}, entry = {0s}{1}, entry = {2s}{0} }
+ \node (node) [fill = blue!20, draw = blue, very thick, circle] {Click me!};
+}
+\end{codeexample}
+\end{animateattribute}
+
+\begin{animateattribute}{opacity}
+ Unlike colors, where there is no joint attribute for filling and stroking,
+ there is a single |opacity| attribute in addition to the above two
+ attributes. If supported by the driver, it treats the graphic object to
+ which it is applied as a transparency group. In essence, ``this attribute
+ does what you want'' at least in most situations.
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0.5,1,1.5,2},
+]
+\tikz {
+ \pgfanimateattribute{opacity}{
+ whom = node, begin on = {click}, entry = {0s}{1}, entry = {2s}{0} }
+ \node (node) [fill = blue!20, draw = blue, very thick, circle] {Click me!};
+}
+\end{codeexample}
+ %
+\end{animateattribute}
+
+\begin{animateattribute}{visible}
+ The difference between the |visible| attribute and an opacity of |0| is
+ that an invisible object cannot be clicked and does not need to be
+ rendered. The (only) two possible values for this attribute are |false| and
+ |true|.
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={1,2,3,4},
+]
+\tikz {
+ \pgfanimateattribute{visible}{
+ whom = node, begin on = {click}, entry = {0s}{false}, entry = {2s}{false} }
+ \node (node) [fill = blue!20, draw = blue, very thick, circle] {Click me!};
+}
+\end{codeexample}
+ %
+\end{animateattribute}
+
+\begin{animateattribute}{stage}
+ This attribute is the same as the |visible| attribute, only |base=false| is
+ set by default. This means that the object is \emph{only} visible when you
+ explicitly during the time the entries are set to |true|. The idea behind
+ the name ``stage'' is that the object is normally ``off stage'' and when
+ you explicitly set the ``stage attribute'' to |true| the object ``enters''
+ the stage and ``leaves'' once more when it is no longer ``on stage''.
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={-1,0,1,2,3},
+ animation bb={(1.3,-0.7) rectangle (2.7,0.7)},
+]
+\tikz {
+ \pgfanimateattribute{stage}{
+ whom = example, begin on = {click, of next=node},
+ entry = {0s}{true}, entry = {2s}{true} }
+ \node (node) [fill = blue!20, draw = blue, very thick, circle] {Click me!};
+ \node at (2,0) (example) [fill = blue!20, circle] {Effect}; }
+\end{codeexample}
+ %
+\end{animateattribute}
+
+
+\subsection{Animating Paths and their Rendering}
+\label{section-base-animation-paths}
+
+You can animate the appearance of a path in the following ways:
+
+\begin{animateattribute}{line width}
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0.5,1,1.5,2},
+]
+\tikz [very thick] {
+ \pgfanimateattribute{line width}{
+ whom = node, begin on = {click}, entry = {0s}{1pt}, entry = {2s}{5mm} }
+ \node (node) [fill = blue!20, draw = blue, circle] {Click me!};
+}
+\end{codeexample}
+ %
+ The possible values passed to the |entry| key are, of course, dimensions.
+\end{animateattribute}
+
+\begin{animateattribute}{dash}
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0.5,1,1.5,2},
+]
+\tikz {
+ \pgfanimateattribute{dash}{
+ whom = node, begin on = {click}, entry = {0s}{{{10pt}{1pt}}{0pt}},
+ entry = {2s}{{{1pt}{10pt}}{0pt}} }
+ \node (node) [fill = blue!20, draw = blue, very thick, circle] {Click me!};
+}
+\end{codeexample}
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0.5,1,1.5,2},
+]
+\tikz {
+ \pgfanimateattribute{dash}{
+ whom = node, begin on = {click}, entry = {0s}{{{1cm}{1pt}}{0pt}},
+ entry = {2s}{{{1cm}{1pt}}{1cm}} }
+ \node (node) [fill = blue!20, draw = blue, very thick, circle] {Click me!};
+}
+\end{codeexample}
+ %
+ To specify the dash pattern, you specify a sequence of ``on and off''
+ dimensions; see |\pgfsetdash| for details. Note that you \emph{must}
+ specify the same number of elements in all patterns of a timeline: You
+ cannot specify that the dash pattern for |1s| is |{1pt}{2pt}| and for |2s|
+ is |{1pt}{3pt}{2pt}| since the number of elements would differ. In
+ particular, you cannot (sensibly) use |current value| for the first entry
+ since this corresponds to an empty dash pattern (even when you have
+ specified a dash pattern for the target object: this pattern will not be
+ attached to the to-be-animated scope or object but to a surrounding scope
+ and, thus, the to-be-animated scope will not have any dash pattern
+ installed).
+\end{animateattribute}
+
+\begin{animateattribute}{path}
+ You can animate the path itself:
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0.5,1,1.5,2},
+]
+\tikz {
+ \pgfanimateattribute{path}{
+ whom = node.background.path, begin on = {click, of next=node},
+ entry = {0s}{\pgfpathellipse{\pgfpointorigin}
+ {\pgfpointxy{1}{0}}{\pgfpointxy{0}{1.5}}},
+ entry = {2s}{\pgfpathellipse{\pgfpointxy{.5}{0}}
+ {\pgfpointxy{.5}{.5}}{\pgfpointxy{0.25}{.25}}}}
+ \node (node) [fill = blue!20, draw = blue, very thick, circle] {Click me!};
+}
+\end{codeexample}
+ %
+ The path is specified by giving path construction commands as in the above
+ example. They will be executed in a special protected scope to ensure that
+ they have only little side effects.
+
+ As for the dash pattern, you must ensure that all paths in the timeline
+ have the same structure (same sequence of path construction commands); only
+ the coordinates may differ. In particular, you cannot say that the path at
+ |1s| is a rectangle using |\pgfpathrectangle| and at |2s| is a circle using
+ |\pgfpathcircle|. Instead, you would have to ensure that at both times that
+ path consists of appropriate Bézier curves.
+
+ Unlike the dash pattern, the to-be-animated object is, indeed, the path
+ itself and not some special scope. This means that you can use the
+ |current value| for the start path. However, this also means that you
+ really must pick \emph{the path object} as the target of the animation. In
+ conjunction with \tikzname, this will be an object of type |path| as in the
+ above example.
+
+ When a path is animated, it cannot have ``normal'' arrows attached to it
+ since due to the way \pgfname\ adds arrow tips to paths, these would not
+ ``move along'' with the path (you get an error message if you try).
+ However, it still \emph{is} possible to add arrow tips to an animated path,
+ only you need to use the |arrows| key described next.
+
+ Concerning the bounding box computation of the path, a bounding box for all
+ paths mentioned for any time point is used as the overall bounding box.
+\end{animateattribute}
+
+\begin{key}{/pgf/animation/arrows=\meta{start tip spec}|-|\meta{end tip spec}}
+ This key specifies arrow tips during the animation of the path. The syntax
+ for the arrow tips is the same syntax as the |\pgfsetarrow| command or
+ \tikzname's |arrows| key. The specified start and end arrow tips are
+ rendered as ``markers'', which are added to the path \emph{only} during the
+ animation. The markers are rotated along with the path in exactly the same
+ way as normal arrow tips would be. To be precise, the rules used for the
+ computation of where arrow tips go and in which direction they head is not
+ always the same for ``static'' arrow tips (arrow tips added to a normal
+ path) and the ``dynamic'' arrow tips based on markers; namely when the
+ paths are very short or closed. For this reason, you should add arrow tips
+ to animated paths only when the paths are ``nice and simple'' in the sense
+ that they consist of a single segment whose ends are reasonably long.
+
+ In addition to adding the arrow tips to the path during the animation, the
+ path gets shortened as necessary to compensate for the extend of the arrow
+ tips. However, for this to work, the arrow tips have to be specified before
+ path values are specified (since the shortening is done immediately when a
+ path value is parsed).
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0,1,2,3,4},
+ animation bb={(0.9,-0.1)rectangle(2.1,1.1)},
+]
+\tikz {
+ \pgfanimateattribute{path}{
+ whom = p.path, begin on = {click, of next=node}, arrows = ->,
+ entry = {1s}{\pgfpathmoveto{\pgfpoint{1cm}{0cm}}
+ \pgfpathlineto{\pgfpoint{2cm}{1cm}}},
+ entry = {3s}{\pgfpathmoveto{\pgfpoint{1cm}{1cm}}
+ \pgfpathlineto{\pgfpoint{2cm}{5mm}}}}
+ \node (node) [fill = blue!20, draw = blue, very thick, circle] {Click me!};
+ \draw [very thick, blue, name=p] (1,0.5) -- (2,0.5);
+}
+\end{codeexample}
+
+ Note that the markers that visualize the arrow tips are rendered only once
+ per animation. In consequence, ``bending'' arrow tips cannot be rendered
+ correctly: As a path ``morphs'' a bend arrow tip needs not only to rotate
+ along, but must actually ``bend along'', which is not supported (neither by
+ \pgfname\ nor by \textsc{svg}).
+
+ As pointed out earlier, an animated path cannot have ``static'' arrow tips.
+ However, when you specify a |base| value, which is the path used whenever
+ there is no active animation, \emph{will} use the arrow tips. As a result,
+ you can use this to animate a path with an arrow tip:
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0,1,2,3,4},
+ animation bb={(0.9,-0.1)rectangle(2.1,1.1)},
+]
+\tikz {
+ \pgfanimateattribute{path}{
+ whom = p.path, begin on = {click, of next=node}, arrows = ->,
+ base = {\pgfpathmoveto{\pgfpoint{1cm}{5mm}}
+ \pgfpathlineto{\pgfpoint{2cm}{5mm}}},
+ entry = {1s}{\pgfpathmoveto{\pgfpoint{1cm}{0cm}}
+ \pgfpathlineto{\pgfpoint{2cm}{1cm}}},
+ entry = {3s}{\pgfpathmoveto{\pgfpoint{1cm}{1cm}}
+ \pgfpathlineto{\pgfpoint{2cm}{5mm}}}}
+ \node (node) [fill = blue!20, draw = blue, very thick, circle] {Click me!};
+ \draw [very thick, blue, name=p];
+}
+\end{codeexample}
+ %
+\end{key}
+
+\begin{key}{/pgf/animation/shorten >=\meta{dimension}}
+ Just like the normal \tikzname\ key |shorten >|, this key specifies an
+ extra shortening of to-be-animated paths. Whenever a path is parsed as a
+ value for a path animation, it gets shortened at the end by the
+ \meta{dimension} (and, additionally, by the length of the attached arrow
+ tip). Just like the |arrows| key, this key must be given before the path
+ entries are specified.
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0,1,2,3,4},
+ animation bb={(0.9,-0.1)rectangle(2.1,1.1)},
+]
+\tikz {
+ \pgfanimateattribute{path}{
+ whom = p.path, begin on = {click, of next=node}, arrows = ->,
+ shorten > = 2mm,
+ base = {\pgfpathmoveto{\pgfpoint{1cm}{5mm}}
+ \pgfpathlineto{\pgfpoint{2cm}{5mm}}},
+ entry = {1s}{\pgfpathmoveto{\pgfpoint{1cm}{0cm}}
+ \pgfpathlineto{\pgfpoint{2cm}{1cm}}},
+ entry = {3s}{\pgfpathmoveto{\pgfpoint{1cm}{1cm}}
+ \pgfpathlineto{\pgfpoint{2cm}{5mm}}}}
+ \node (node) [fill = blue!20, draw = blue, very thick, circle] {Click me!};
+ \draw (0.9,-0.1) grid (2.1,1.1);
+ \draw [help lines] (0.9,-0.1) grid[step=1mm] (2.1,1.1);
+ \draw [very thick, blue, name=p];
+}
+\end{codeexample}
+ %
+\end{key}
+
+\begin{key}{/pgf/animation/shorten <=\meta{dimension}}
+ Works like |shorten >|.
+\end{key}
+
+
+\subsection{Animating Transformations and Views}
+\label{section-base-animation-views}
+
+In order to animate the canvas transformation matrix, you do not animate an
+attribute called ``|transform|'' (or something similar). Rather, there are
+several keys that all manipulate the canvas transformation matrix in different
+ways. These keys, taken in appropriate combination, allow you to achieve any
+particular canvas transformation matrix. All keys that animate the
+transformation matrix \emph{always} accumulate.
+
+Some, but not all, of these keys also have an effect on the bounding box
+computation: The |translate| and |motion| attribute change the computation of
+the bounding box in such a way that it is chosen large enough as to include the
+whole picture during all stages of the animation (however, if there are
+multiple transformations active at the same time, the computation may not be
+correct). In contrast, |scale|, |rotate| and |skew| animations change the
+canvas transformation, but are ignored for the bounding box computation. When
+in doubt, please set the bounding box explicitly.
+
+Let us start with the basic keys that allow you to change the canvas
+transformation matrix directly:
+
+\begin{animateattribute}{scale}
+ The |scale| attribute adds an animation of the scaling:
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0.5,1,1.5,2},
+]
+\tikz [very thick] {
+ \pgfanimateattribute{scale}{
+ whom = node, begin on = {click},
+ entry = {0s}{0.5}, entry = {2s}{0.75,1.5} }
+ \node (node) [fill = blue!20, draw = blue, circle] {Click me!};
+}
+\end{codeexample}
+ %
+ The values passed to the |entry| key must either be single scalar values or
+ a pair of such numbers separated by a comma (which then refer to the $x$-
+ and $y$-scaling).
+\end{animateattribute}
+
+\begin{animateattribute}{rotate}
+ The |rotate| key adds an animation of the rotation:
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0.5,1,1.5,2},
+]
+\tikz [very thick] {
+ \pgfanimateattribute{rotate}{
+ whom = node, begin on = {click},
+ entry = {0s}{45}, entry = {2s}{90} }
+ \node (node) [fill = blue!20, draw = blue, circle] {Click me!};
+}
+\end{codeexample}
+ %
+ The values are scalar values representing a rotation in degrees.
+\end{animateattribute}
+
+\begin{animateattribute}{xskew}
+ The |xskew| and |yskew| keys (and also |skew x| and |skew y|, which are
+ aliases) add an animation of the skew (given in degrees, not as a slant):
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0.5,1,1.5,2},
+]
+\tikz [very thick] {
+ \pgfanimateattribute{xskew}{
+ whom = node, begin on = {click}, entry = {0s}{0}, entry = {2s}{45} }
+ \node (node) [fill = blue!20, draw = blue, circle] {Click me!};
+}
+\end{codeexample}
+ %
+ The values are scalar values.
+\end{animateattribute}
+
+\begin{animateattribute}{yskew}
+ See |xskew|.
+\end{animateattribute}
+
+\begin{animateattribute}{skew x}
+ An alias of |xskew|.
+\end{animateattribute}
+
+\begin{animateattribute}{skew y}
+ An alias of |yskew|.
+\end{animateattribute}
+
+\begin{animateattribute}{translate}
+ The |translate| key adds an animation of the translation (shift):
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0.5,1,1.5,2},
+]
+\tikz [very thick] {
+ \pgfanimateattribute{translate}{
+ whom = node, begin on = {click},
+ entry = {0s}{\pgfpointorigin}, entry = {2s}{\pgfpoint{5mm}{-5mm}} }
+ \node (node) [fill = blue!20, draw = blue, circle] {Click me!};
+}
+\end{codeexample}
+ %
+ The values are \pgfname-points.
+
+ Unlike for the previous canvas transformations, for this key the bounding
+ box computation is changed: All points in the to-be-animated scope do not
+ only contribute to the normal bounding box, but they also contribute
+ shifted by all points in the entry list. The effect is that a bounding box
+ is computed that encompasses the animated scope at all stages.
+\end{animateattribute}
+
+For all of these attributes, the following key is of importance:
+%
+\begin{key}{/pgf/animation/origin=\meta{pgf point}}
+ An animation of the canvas transformation is added to all other
+ transformations from surrounding or interior scopes. This means that, in
+ particular, the origin of a canvas transformation is, by default, the
+ origin of the canvas of the scope surrounding the transformation object.
+
+ For some canvas animations, like a rotation or a scaling, you will
+ typically wish to use a different origin (like the center of an object that
+ is to be rotated or scaled). You can achieve this effect by surrounding the
+ object by a scope that shifts the canvas to the desired origin, followed by
+ a scope whose transformation matrix you animate, followed by a scope that
+ shifts back the canvas.
+
+ The |origin| key simplifies this process by allowing you to specify the
+ origin of the transformation directly. Internally, however, all this key
+ does is to create the above-mentioned scopes with the necessary shifts.
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0.5,1,1.5,2},
+]
+\tikz [very thick] {
+ \pgfanimateattribute{rotate}{
+ whom = node, begin on = {click},
+ origin = \pgfpoint{-5mm}{0mm}, entry = {0s}{0}, entry = {2s}{90} }
+ \node (node) [fill = blue!20, draw = blue, circle] {Click me!};
+}
+\end{codeexample}
+ %
+\end{key}
+
+\begin{animateattribute}{motion}
+ A second way of changing the canvas transformation matrix is to use the
+ |motion| attribute:
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0.5,1,1.5,2},
+]
+\tikz [very thick] {
+ \pgfanimateattribute{motion}{
+ whom = node, begin on = {click},
+ along = \pgfpathcircle{\pgfpointorigin}{5mm},
+ entry = {0s}{.25}, entry = {2s}{.5} }
+ \node (node) [fill = blue!20, draw = blue, circle] {Click me!}; }
+\end{codeexample}
+
+ Just like the |translate| attribute, this key also changes the bounding box
+ computation.
+ %
+ \begin{key}{/pgf/animation/along=\meta{path}}
+ This key must be used with |motion| attribute to specify a path along
+ which the transformation matrix will be ``moved'' (that is, a shift
+ transformation will be added to the different points on the path).
+
+ The values passed to the |entry| key specify fractions of the distance
+ along the \meta{path}. That means, when you provide a value of |0|, you
+ reference the start point of the path, a value of |1| references the
+ end of the path and |0.5| referenced the point halfway along the path.
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0.25,0.5,0.75,1,1.25,1.5,1.75,2,2.25,2.5},
+]
+\tikz [very thick] {
+ \pgfanimateattribute{motion}{
+ whom = node, begin on = {click},
+ along = \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathlineto{\pgfpoint{0mm}{5mm}},
+ entry = {0s}{0}, entry = {1s}{0.5}, entry = {2s}{0.25}, entry={3s}{1} }
+ \node (node) [fill = blue!20, draw = blue, circle] {Click me!}; }
+\end{codeexample}
+ \end{key}
+
+ \begin{key}{/pgf/animation/rotate along=\meta{Boolean} (default true)}
+ When set to |true|, the |along| key additionally adds a rotation that
+ varies in such a way that a tangent to the path always points right.
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0.5,1,1.5,2},
+]
+\tikz [very thick] {
+ \pgfanimateattribute{motion}{
+ whom = node, begin on = {click},
+ rotate along = true,
+ along = \pgfpathmoveto {\pgfpointorigin}
+ \pgfpathcurveto{\pgfpoint{5mm}{0cm}}{\pgfpoint{5mm}{0cm}}
+ {\pgfpoint{5mm}{5mm}},
+ entry = {0s}{0}, entry = {2s}{1} }
+ \node (node) [fill = blue!20, draw = blue, circle] {Click me!}; }
+\end{codeexample}
+ \end{key}
+\end{animateattribute}
+
+The final method of changing the transformation matrix is to animate a
+\emph{view.}
+
+\begin{animateattribute}{view}
+ A view is a canvas transformation that shifts and scales the canvas in such
+ a way that a certain rectangle ``matches'' another rectangle: The idea is
+ that you ``look through'' a ``window'' (the view) and ``see'' a certain
+ area of the canvas. View animation do not allow you to do anything that
+ cannot also be done using the |translate| and |scale| keys in combination,
+ but it often much more natural to animate which area of a graphic you wish
+ to see than to compute and animate a scaling and shift explicitly.
+
+ In order to use a view, you first need to create a view, which is done
+ using a |{pgfviewboxscope}|, see Section~\ref{section-base-view}, which is
+ used by the |views| library internally. You can then animate the view using
+ the |view| attribute. The values passed to the |entry| key must be two
+ \pgfname-points, each surrounded by parentheses.
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}
+\usetikzlibrary{views}},
+ animation list={0.5,1,1.5,2},
+ animation bb={(1.1,-0.9) rectangle (2.9,0.9)},
+]
+\tikz [very thick] {
+ \pgfanimateattribute{view}{
+ whom = me.view, begin on = {click, of next=node}, freeze at end,
+ entry = {0s}{{\pgfpoint{0mm}{0mm}}{\pgfpoint{20mm}{20mm}}},
+ entry = {2s}{{\pgfpoint{10mm}{10mm}}{\pgfpoint{15mm}{15mm}}} }
+ \node (node) [fill = blue!20, draw = blue, very thick, circle] {Click me!};
+
+ \draw [green!50!black] (1.2,-0.8) rectangle (2.7,0.8);
+ \begin{scope}[name = me, view = {(0,0) (2,2) at (1.2,-0.8) (2.7,0.8)}]
+ \draw [red] (10mm,10mm) rectangle (15mm,15mm);
+ \node at (10mm,10mm) [circle, fill=red, text=white, font=\tiny] {red};
+ \end{scope}
+}
+\end{codeexample}
+
+\begin{codeexample}[
+ width=2cm,
+ preamble={\usepgfmodule{animations}
+\usetikzlibrary{views}},
+]
+\tikz [very thick] {
+ \pgfanimateattribute{view}{
+ whom = me.view, begin on = {click, of next=n1}, freeze at end,
+ entry = {0s}{\pgfpoint{0mm}{0mm}}{\pgfpoint{2cm}{2cm}},
+ entry = {2s}{{\pgfpoint{5mm}{5mm}}{\pgfpoint{15mm}{20mm}}} }
+ \pgfanimateattribute{view}{
+ whom = me.view, begin on = {click, of next=n2}, freeze at end,
+ entry = {0s}{\pgfpoint{0mm}{0mm}}{\pgfpoint{2cm}{2cm}},
+ entry = {2s}{{\pgfpoint{10mm}{10mm}}{\pgfpoint{15mm}{15mm}}} }
+ \node (n1) at (0,0) [fill = blue!20, draw = blue, circle] {Zoom blue};
+ \node (n2) at (2,0) [fill = blue!20, draw = blue, circle] {Zoom red};
+
+ \draw [green!50!black] (4,0) rectangle (6,2);
+ \begin{scope}[name = me, view = {(0,0) (2,2) at (4,0) (6,2)}]
+ \draw [blue] (5mm,5mm) rectangle (15mm,20mm);
+ \node at (5mm,5mm) [circle, fill=blue, text=white] {blue};
+
+ \draw [red] (10mm,10mm) rectangle (15mm,15mm);
+ \node at (10mm,10mm) [circle, fill=red, text=white, font=\tiny] {red};
+ \end{scope}
+}
+\end{codeexample}
+ %
+\end{animateattribute}
+
+
+\subsection{Commands for Specifying Timing: Beginnings and Endings}
+
+Using the |entry| key repeatedly, you specify a timeline: The \meta{time} used
+with the first use of the |entry| key in a timeline is the start time and the
+\meta{time} in the last |entry| key is the stop time. However, this leaves open
+then question of when the whole timeline is to be started: The moment the
+document is opened? When the page is displayed? When the user scrolls to the
+to-be-animated object? When some other object is clicked? The key |begin|, and
+also the key |end|, allow you to specify answers to these questions.
+
+\begin{key}{/pgf/animation/begin=\meta{time}}
+ This key specifies when the ``moment |0s|'' should be relative to the
+ moment when the current graphic is first displayed. You can use this key
+ multiple times, in this case the timeline is restarted for each of the
+ times specified (if it is already running, it will be reset). If no |begin|
+ key is given at all, the effect is the same as if |begin=0s| had been
+ specified.
+
+ It is permissible to set \meta{time} to a negative value.
+\end{key}
+
+\begin{key}{/pgf/animation/end=\meta{time}}
+ This key will truncate the timeline so that it ends \meta{time} after the
+ display of the graphic, provided the timeline begins before the specified
+ end time. For instance, if you specify a timeline starting at 2\,s and
+ ending at 5\,s and you set |begin| to 1\,s and |end| to 4\,s, the timeline
+ will run, relative to the moment when the graphic is displayed from 3\,s to
+ 4\,s.
+ %
+\begin{codeexample}[preamble={\usepgfmodule{animations}},width=3cm]
+\tikz [very thick] {
+ \pgfanimateattribute{rotate}{
+ whom = node, begin = 2s, end = 4s,
+ entry = {1s}{0}, entry = {2s}{90}, entry = {3s}{180}, entry = {4s}{270} }
+ \node (node) [fill = blue!20, draw = blue, circle] {Turn after 3s!}; }
+\end{codeexample}
+ %
+\end{key}
+
+It is not immediately clear what should happen with the attribute of an object
+when an animation ends: Should it revert to its original value ``as if there
+had never been an animation'' or should it ``stay at the last value''? The
+following key governs what should happen:
+
+\begin{key}{/pgf/animation/freeze at end=\meta{true or false} (default true, initially false)}
+ When set to |true|, whenever a timeline ends (either because the last time
+ of timeline has been reached or because an |end| or |end of| key have ended
+ it prematurely), the last value the attribute had because of the animation
+ ``stays put''. When set to |false|, which is the initial value, once an
+ animation ends, its effect will be removed ``as if it never happened''.
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0,1,2,3,4},
+]
+\tikz [very thick] {
+ \pgfanimateattribute{rotate}{
+ whom = node, begin on = {click}, freeze at end = false,
+ entry = {0s}{0}, entry = {2s}{90} }
+ \node (node) [fill = blue!20, draw = blue, circle] {Here!}; }
+\end{codeexample}
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={0,1,2,3,4},
+]
+\tikz [very thick] {
+ \pgfanimateattribute{rotate}{
+ whom = node, begin on = {click}, freeze at end,
+ entry = {0s}{0}, entry = {2s}{90} }
+ \node (node) [fill = blue!20, draw = blue, circle] {Here!}; }
+\end{codeexample}
+ %
+\end{key}
+
+Instead of specifying the beginning of the timeline relative to the moment to
+to-be-animated graphic is displayed, you can also set the ``moment |0s|'' to
+the moment a specific \emph{event} happens using the following key:
+
+\begin{key}{/pgf/animation/begin on=\meta{options}}
+ Has the same effect as |/tikz/animate/option/begin on|, see
+ Section~\ref{section-anim-begin-end}.
+\end{key}
+
+When you use |begin on| to start an animation when a certain event is
+triggered, it is not clear what should happen when the event is triggered
+\emph{again}. Should this be ignored completely? Should it only be ignored
+while the animation is running? The following key allows you to specify when
+should happen:
+
+\begin{key}{/pgf/animation/restart=\meta{choice} (default true)}
+ Has the same effect as |/tikz/animate/option/restart|, see
+ Section~\ref{section-anim-begin-end}.
+\end{key}
+
+Just like |begin on| specifies when a timeline begins relative to some event,
+the |end on| allows you to stop is early when some event happens:
+
+\begin{key}{/pgf/animation/end on=\meta{options}}
+ Works exactly like |begin on|, one possible end of the timeline is
+ specified using the \meta{options}.
+\end{key}
+
+
+\subsection{Commands for Specifying Timing: Repeats}
+
+Normally, a timeline is displayed once and then ends. You can, however, request
+that the timeline should be repeated a certain number of times or indefinitely.
+
+\begin{key}{/pgf/animation/repeats=\meta{specification}}
+ Use this key to specify that the timeline animation should repeat at the
+ end. The \meta{specification} must consist of two parts, each of which may
+ be empty. The first part is one of the following:
+ %
+ \begin{itemize}
+ \item Empty, in which case the timeline repeats forever.
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={1,2,3,4,5},
+]
+\tikz [very thick] {
+ \pgfanimateattribute{rotate}{
+ whom = node, begin on = {click}, repeats,
+ entry = {0s}{0}, entry = {2s}{90} }
+ \node (node) [fill = blue!20, draw = blue, circle] {Click me!}; }
+\end{codeexample}
+ %
+ \item A \meta{number} (like |2| or |3.25|), in which case the timeline
+ repeats \meta{number} times.
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={1,2,3,4,5},
+]
+\tikz [very thick] {
+ \pgfanimateattribute{rotate}{
+ whom = node, begin on = {click}, repeats = 1.75,
+ entry = {0s}{0}, entry = {2s}{90} }
+ \node (node) [fill = blue!20, draw = blue, circle] {Click me!}; }
+\end{codeexample}
+ %
+ \item The text ``|for| \meta{time}'' (like |for 2s| or |for 300ms|), in
+ which case the timeline repeats however often necessary so that it
+ stops exactly after \meta{time}.
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={1,2,3,4,5},
+]
+\tikz [very thick] {
+ \pgfanimateattribute{rotate}{
+ whom = node, begin on = {click}, repeats = for 3.5s,
+ entry = {0s}{0}, entry = {2s}{90} }
+ \node (node) [fill = blue!20, draw = blue, circle] {Click me!}; }
+\end{codeexample}
+ \end{itemize}
+ %
+ The second part of the specification must be one of the following:
+ %
+ \begin{itemize}
+ \item Empty, in which case each time the timeline is restarted, the
+ attribute's value undergoes the same series of values it did
+ previously.
+ \item The text |accumulating|. This has the effect that each time the
+ timeline is restarted, the attribute values specified by the
+ timeline are \emph{added} to the value from the previous
+ iteration(s). A typical example is an animation that shifts a scope
+ by, say, 1\,cm over a time of 1\,s. Now, if you repeat this five
+ times, normally the scope will shift 1\,cm for 1\,s then ``jump
+ back'', shift again, jump back, and so on for five times. In
+ contrast, when the repeats are accumulating, the scope will move by
+ 5\,cm over 5\,s in total.
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={1,2,3,4,5},
+]
+\tikz [very thick] {
+ \pgfanimateattribute{rotate}{
+ whom = node, begin on = {click}, repeats = accumulating,
+ entry = {0s}{0}, entry = {2s}{90} }
+ \node (node) [fill = blue!20, draw = blue, circle] {Click me!}; }
+\end{codeexample}
+ %
+\begin{codeexample}[
+ preamble={\usepgfmodule{animations}},
+ animation list={1,2,3,4,5},
+]
+\tikz [very thick] {
+ \pgfanimateattribute{rotate}{
+ whom = node, begin on = {click}, repeats = 2 accumulating,
+ entry = {0s}{0}, entry = {2s}{90} }
+ \node (node) [fill = blue!20, draw = blue, circle] {Click me!}; }
+\end{codeexample}
+ \end{itemize}
+\end{key}
+
+\begin{key}{/pgf/animation/repeat=\meta{specification}}
+ This is an alias for |repeats|.
+\end{key}
+
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "pgfmanual"
+%%% End:
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-animations.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-arrows.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-arrows.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-arrows.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,962 @@
+% Copyright 2019 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section{Defining New Arrow Tip Kinds}
+\label{section-arrows}
+
+\subsection{Overview}
+
+In present section we have a look at how you can define new arrow tips for use
+in \pgfname. The low-level commands for selecting which arrow tips are to be
+used have already been described in Section~\ref{section-tips}, the general
+syntax rules for using arrows are detailed in
+Section~\ref{section-tikz-arrows}. Although Section~\ref{section-tikz-arrows}
+describes the use of arrows in \tikzname, in reality, \tikzname\ itself does
+not actually do anything about arrow tips; all of the functionality is
+implemented on the \pgfname\ level in the commands described in
+Section~\ref{section-tikz-arrows}. Indeed, even the |/.tip| key handler
+described in Section~\ref{section-tikz-arrows} is actually implemented on the
+\pgfname\ layer.
+
+What has \emph{not} yet been covered is how you can actually define a complete
+new arrow tip. In \pgfname, arrows are ``meta-arrows'' in the same way that
+fonts in \TeX\ are ``meta-fonts''. When a meta-arrow is resized, it is not
+simply scaled, but a possibly complicated transformation is applied to the
+size.
+
+A meta-font is not one particular font at a specific size with a specific
+stroke width (and with a large number of other parameters being fixed). Rather,
+it is a ``blueprint'' (actually, more like a program) for generating such a
+font at a particular size and width. This allows the designer of a meta-font to
+make sure that, say, the font is somewhat thicker and wider at very small
+sizes. To appreciate the difference: Compare the following texts: ``Berlin''
+and ``\tikz{\node [scale=2,inner sep=0pt,outer sep=0pt]{\tiny Berlin};}''. The
+first is a ``normal'' text, the second is the tiny version scaled by a factor
+of two. Obviously, the first look better. Now, compare ``\tikz{\node
+[scale=.5,inner sep=0pt,outer sep=0pt]{Berlin};}'' and ``{\tiny Berlin}''. This
+time, the normal text was scaled down, while the second text is a ``normal''
+tiny text. The second text is easier to read.
+
+\pgfname's meta-arrows work in a similar fashion: The shape of an arrow tip can
+vary according to a great number of parameters, the line width of the arrow tip
+being one of them. Thus, an arrow tip drawn at a line width of 5pt will
+typically \emph{not} be five times as large as an arrow tip of line width 1pt.
+Instead, the size of the arrow will get bigger only slowly as the line width
+increases.
+
+To appreciate the difference, here are the |Latex| and
+|Classical TikZ Rightarrow| arrows, as drawn by \pgfname\ at four different
+sizes:
+
+\medskip
+\begin{tikzpicture}[1/.tip=Latex, 2/.tip=Classical TikZ Rightarrow]
+ \draw[-1, line width=0.1pt] (0pt,0ex) -- +(3,0) node[thin,right] {line width is 0.1pt};
+ \draw[-1, line width=0.4pt] (0pt,-2em) -- +(3,0) node[thin,right] {line width is 0.4pt};
+ \draw[-1, line width=1.2pt] (0pt,-4em) -- +(3,0) node[thin,right] {line width is 1.2pt};
+ \draw[-1, line width=5pt] (0pt,-6em) -- +(3,0) node[thin,right] {line width is 5pt};
+
+ \draw[-2, line width=0.1pt] (6cm,0ex) -- +(3,0) node[thin,right] {line width is 0.1pt};
+ \draw[-2, line width=0.4pt] (6cm,-2em) -- +(3,0) node[thin,right] {line width is 0.4pt};
+ \draw[-2, line width=1.2pt] (6cm,-4em) -- +(3,0) node[thin,right] {line width is 1.2pt};
+ \draw[-2, line width=5pt] (6cm,-6em) -- +(3,0) node[thin,right] {line width is 5pt};
+\end{tikzpicture}
+
+\medskip
+Here, by comparison, are the same arrows when they are simply ``resized'':
+
+\medskip
+\begin{tikzpicture}[1/.tip=Latex, 2/.tip=Classical TikZ Rightarrow]
+ \draw[-{1[length=1pt]}, line width=0.1pt] (0pt,0ex) -- +(3,0) node[thin,right] {line width is 0.1pt};
+ \draw[-{1[length=4pt]}, line width=0.4pt] (0pt,-2em) -- +(3,0) node[thin,right] {line width is 0.4pt};
+ \draw[-{1[length=12pt]}, line width=1.2pt] (0pt,-4em) -- +(3,0) node[thin,right] {line width is 1.2pt};
+ \draw[-{1[length=32pt]}, line width=5pt] (0pt,-6em) -- +(3,0) node[thin,right] {line width is 5pt};
+
+ \draw[-{2[length=0.455pt]}, line width=0.1pt] (6cm,0ex) -- +(3,0) node[thin,right] {line width is 0.1pt};
+ \draw[-{2[length=1.82pt]}, line width=0.4pt] (6cm,-2em) -- +(3,0) node[thin,right] {line width is 0.4pt};
+ \draw[-{2[length=5.46pt]}, line width=1.2pt] (6cm,-4em) -- +(3,0) node[thin,right] {line width is 1.2pt};
+ \draw[-{2[length=14.56pt]}, line width=5pt] (6cm,-6em) -- +(3,0) node[thin,right] {line width is 5pt};
+\end{tikzpicture}
+
+\bigskip
+As can be seen, simple scaling produces arrow tips that are way too large at
+larger sizes and way too small at smaller sizes.
+
+In addition to the line width, other options may also influence the appearance
+of an arrow tip. In particular, the width of the inner line (the line used to
+create the effect of a double line) influences arrow tips as well as other
+options that are specific to the arrow tip.
+
+
+\subsection{Terminology}
+\label{section-arrow-terminology}
+
+Before we have a look at the exact commands used for defining arrow tips, we
+need to fix some terminology. Consider the following drawing of an arrow tip
+where the arrow tip is drawn transparently so that we can see what is
+``happening behind it'':
+%
+\begin{tikzpicture}
+ \draw [red!50, ,line width=1cm] (0,0) -- (4,0);
+ \path [tips, opacity=.25,line width=1cm, -{Stealth[black,line width=0pt,length=4cm, width=4cm, inset=1cm]}] (0,0) -- (6,0);
+
+ \draw [->,thick] (1,0) -- (8,0) node [right] {$x$-axis};
+ \draw [->,thick] (5,-2.25) -- (5,2.25) node [above] {$y$-axis};
+
+ \foreach \i in {-3,-2,-1,1,2} \draw (\i+5,-1mm) -- (\i+5,1mm) node [above] {\small$\i$};
+ \foreach \i in {-2,-1,1,2} \draw (49mm,\i) -- (51mm,\i) node [right] {\small$\i$};
+\end{tikzpicture}
+
+I have also added a coordinate system. The code for drawing an arrow tip always
+draws it in the way shown above: Pointing right along the $x$-axis.
+
+We will use the following terminology:
+%
+\begin{itemize}
+ \item The point where tip of the arrow ends is called the \emph{tip end}.
+ It is at $(1,0)$ in our example and we always assume it to lie on the
+ $x$-axis, so we just treat it as a distance, 1 in this case. This is
+ the position where the original path was supposed to end (so if the
+ arrow tip had not been added to the red path, it would have ended
+ here).
+ \item The \emph{back end} of the arrow is where a vertical line just to the
+ left of the arrow intersects the $x$-axis. In our case, this is the
+ point $(-3,0)$ and again we treat it as a distance, $-3$ in this case.
+ \item The \emph{line end} is the position where the path now ends. This
+ should be a position inside the arrow head that gets ``covered'' by the
+ path. Note that a path may have a round or a rect head and should still
+ be covered. Clearly, necessary shortening of the path will be the
+ difference between the tip end and the line end.
+ \item The \emph{visual back end} is the position where the path and the the
+ arrow head ``meet last'' on the path. In our case, because of the
+ inset, the visual back end is not the same as the back end: The arrow
+ ends ``visually'' at $(-2,0)$. The difference between the back end and
+ the visual back end is important when the arrow tip is flexed, see
+ Section~\ref{section-arrow-flex} for an explanation of flexing.
+ \item There is also a \emph{visual tip end}, the counterpart of the visual
+ back end for the front. In our case, the visual tip end and the tip end
+ obviously coincide, but if we were to reverse the arrow tip, the visual
+ tip end would be different from the tip end (while the visual back end
+ would then coincide with the new back end).
+ \item There are four points that make up the \emph{convex hull} of the
+ arrow tip: $(1,0)$, $(-3,2)$, and $(-3,-2)$.
+
+ Normally, \pgfname\ automatically keeps track of a bounding box of
+ everything you draw. However, since arrow tips are drawn so often,
+ \pgfname\ caches the code needing for drawing arrow tips internally and
+ because of this cache it cannot determine the size of the arrow tip
+ just based on the drawing commands used for drawing the tip. Instead, a
+ convex hull of the arrow tip must be explicitly provided in the
+ definition.
+\end{itemize}
+
+When you design a new arrow tip, all of the above parameters must be defined.
+
+
+\subsection{Caching and Rendering of Arrows}
+
+As a last preparation for the description of the commands for declaring arrows,
+it is important to understand the exact process by which \pgfname\ draws
+arrows.
+%
+\begin{enumerate}
+ \item First, you have to define an arrow tip kind using
+ |\pgfdeclarearrow{name=foo,...|. This will tell \pgfname\ that |foo| is %}
+ now the name of an arrow tip. In particular, the parser for arrow tip
+ specifications will now treat |foo| as the name of an arrow tip and
+ will not try to consider |f|, |o|, and |o| as the names of single-char
+ shorthands.
+
+ Other than storing the definitions in the declaration internally, this
+ command has little other effect. In particular, no drawing or other
+ processing takes place.
+ \item Now assume that at some point the arrow tip |foo| is actually used.
+ In this case, certain options may have been set, for instance the user
+ may have requested the arrow tip |foo[length=5pt,open]|. What happens
+ next depends on whether it is the first time the arrow tip |foo| is
+ used with \emph{these exact options} or not.
+ \item Assume that is the first time |foo| is requested at a length of 5pt
+ and in an ``open'' version. \pgfname\ now retrieves the definition of
+ the arrow tip kind that it stored in the first step and executes the
+ so-called \emph{setup} code. When this code is executed, all the
+ options will be in force (for instance, |\pgfarrowlength| will equal
+ |5pt| in our case). The job of the setup code is two-fold: First, it
+ needs to compute all of the parameters listed in
+ Section~\ref{section-arrow-terminology}, that is, it has to compute
+ where the tip end will lie in the arrow tip's coordinate system
+ \emph{at the particular size of 5pt}, where the back end will be, where
+ the convex hull points lie, and so on. Second, the setup code should
+ precompute values that will be important for constructing the path of
+ the arrow. In our example, there is little to do in this regard, but
+ for more complicated arrows, all time-consuming preparations are done
+ now.
+
+ It is \emph{not} the job of the setup to actually draw the arrow tip,
+ only to ``prepare'' this as much as possible.
+
+ The setup code will always be executed only once for each arrow tip
+ kind for a given set of options. Thus, when a user uses
+ |foo[length=5pt,open]| once more later anywhere in the document, the
+ setup code will not be executed again.
+ \item The next thing that happens is that we have a look at the
+ \emph{drawing code} stored in the |code| field of the arrow. In our
+ example, the drawing code would consist of creating a filled path with
+ four straight segments.
+
+ In most cases, what happens now is that the drawing code is executed in
+ a special sandbox in which the low-level driver commands that do the
+ actual drawing are intercepted and stored away in a so-called
+ \emph{cache}. Once such a cache has been created, its contents will be
+ reused whenever |foo[length=5pt,open]| is requested by a user and just
+ like the setup code, the drawing code will not be executed again.
+
+ There are, however, two cases in which the drawing code gets executed
+ each time the arrow is used: First, an arrow tip kind can specify that
+ this should always happen by saying |cache=false| in its definition.
+ This is necessary if the drawing code contains low-level drawing
+ commands that cannot be intercepted such as a use of |\pgftext| for
+ arrow tips that ``contain text''. Second, when the |bend| option is
+ used, the same arrow tip will look different each time it is used,
+ namely in dependence on the exact curvature of the path to which it is
+ added.
+
+ Because the drawing code may be executed several times, while the setup
+ code may not, we must find a way to ``communicate'' the values computed
+ by the setup code to the drawing code. This is done by explicitly
+ calling |\pgfarrowssave| inside the setup code. Whatever is ``saved''
+ in this way is restored each time before the drawing code is executed.
+\end{enumerate}
+
+As can be seen, the process is a bit involved, but it leads to a reasonably
+fast arrow tip management.
+
+
+\subsection{Declaring an Arrow Tip Kind}
+
+\begin{command}{\pgfdeclarearrow\marg{config}}
+ This command is both used to define a new arrow tip kind and to to declare
+ a so-called shorthand. We have a look at the case that a complete new arrow
+ tip kind is created and then have a look how the command can be used to
+ create shorthands.
+
+
+ \medskip
+ \noindent\textbf{Defining a Complete New Arrow Tip Kind.}
+ The \meta{config} is a key--value list in which different keys are used to
+ setup the to-be defined arrow. The following keys can be given:
+ %
+ \begin{itemize}
+ \item \declare{|name|}|=|\meta{name} or |name=|\meta{start
+ name}|-|\meta{end name}
+
+ This defines the name of the arrow tip. It is legal to define an
+ arrow tip a second time, in this case the previous definition will
+ be overwritten in the current \TeX\ scope. It is customary to use a
+ name with an uppercase first letter for a ``complete'' arrow tip
+ kind. Short names and lower case names should be used for
+ shorthands that change their meaning inside a document, while arrow
+ tips with uppercase first letters should not be redefined.
+
+ If the name contains a hyphen, the second syntax is assumed and
+ everything before the hyphen will be the name used in start arrow
+ specifications, while the text after the hyphen is the name used in
+ end specifications.
+ \item \declare{|parameters|}|=|\marg{list of macros}
+
+ As explained earlier, an arrow tip typically needs to be redrawn
+ each time an option like |length| or |inset| is changed. However,
+ for some arrow tips, the |inset| has no influence, while for other
+ it is important whether the arrow is reversed or not. (How keys
+ like |length| actually set \TeX\ dimensions like |\pgfarrowlength|
+ is explained in Section~\ref{section-arrow-options}.)
+
+ The job of the |parameters| key is to specify which dependencies
+ the arrow tip has. Everything that will influence any of the
+ parameters computed in the setup code or used in the drawing code
+ should be listed here.
+
+ The \meta{list of macros} will be used inside a
+ |\csname|-|\endcsname| pair and should expand to the current values
+ of the relevant parameters have. For example, if the arrow tip
+ depends on the current value of |\pgfarrowlength| and
+ |\pgfarrowwidth| only, then \meta{list of macros} should be set to
+ |\the\pgfarrowlength,\the\pgfarrowwidth|. (Actually, the comma is
+ optional, the \meta{list of macros} does not really have to be a
+ list, just something that can be expanded unambiguously.)
+
+ Note that the line width (|\pgflinewidth|) and the inner line width
+ (|\pgfinnerlinewidth|) are always parameters and need not be
+ specified in the |parameters|.
+
+ It is important to get this parameter right. Otherwise, arrow tips
+ may look wrong because \pgfname\ thinks that it can reuse some code
+ when, in reality, this code actually depends on a parameter not
+ listed here.
+ \item \declare{|setup code|}|=|\marg{code}
+
+ When an arrow tip is used, the value stored in |parameters| is
+ expanded and it is tested whether the result was encountered
+ before. If not, the \meta{code} gets executed (only this once). The
+ code can now do arbitrarily complicated computations the prepare
+ the later drawing of the arrow tip. Also the \meta{code} must
+ specify the different tip and back ends and the convex hull points.
+ This is done by calling the following macros inside the
+ \meta{code}:
+ %
+ \begin{command}{\pgfarrowssettipend\marg{dimension}}
+ When this command is called inside the setup code of an arrow
+ tip, it specifies that the tip of the drawn arrow will end
+ exactly at \meta{dimension}. For example, for our earlier
+ example of the large arrow tip, where the tip end was at 1cm,
+ we would call
+ %
+\begin{codeexample}[code only]
+\pgfarrowssettipend{1cm}
+\end{codeexample}
+ %
+ Note that for efficiency reasons, the \meta{dimension} is not
+ passed through |\pgfmathsetlength|; rather what happens is that
+ |\pgf at x=|\meta{dimension} gets executed. In particular, you can
+ pack further computations into the \meta{dimension} by simply
+ starting it with a number and then appending some code that
+ modifies |\pgf at x|. Here is an example where instead of 1cm we
+ use $1\mathrm{cm} - \frac12\mathrm{linewidth}$ as the tip end:
+ %
+\begin{codeexample}[code only]
+\pgfarrowssettipend{1cm\advance\pgf at x by-.5\pgflinewidth}
+\end{codeexample}
+ %
+ If the command is not called at all inside the setup code, the
+ tip end is set to |0pt|.
+ \end{command}
+
+ \begin{command}{\pgfarrowssetbackend\marg{dimension}}
+ Works like the command for the tip end, only it sets the back
+ end. In our example we would call
+ %
+\begin{codeexample}[code only]
+\pgfarrowssettipend{-3cm}
+\end{codeexample}
+ %
+ Defaults to |0pt|.
+ \end{command}
+
+ \begin{command}{\pgfarrowssetlineend\marg{dimension}}
+ Sets the line end, so in the example we have
+ |\pgfarrowssettipend{-1cm}|. Default to |0pt|.
+ \end{command}
+
+ \begin{command}{\pgfarrowssetvisualbackend\marg{dimension}}
+ Sets the visual back end, |\pgfarrowssetvisualbackend{-2cm}| in
+ our example. Default to the value of the normal back end.
+ \end{command}
+
+ \begin{command}{\pgfarrowssetvisualtipend\marg{dimension}}
+ Sets the visual tip end. Default to the value of the normal tip
+ end and, thus, we need not set it in our example.
+ \end{command}
+
+ \begin{command}{\pgfarrowshullpoint\marg{x dimension}\marg{y dimension}}
+ Adds a point to the convex hull of the arrow tip. As for the
+ previous commands, no math parsing is done; instead \pgfname\
+ says |\pgf at x=|\meta{x dimension} and then |\pgf at y=|\meta{y
+ dimension}. Thus, both ``dimensions'' can contain code for
+ advancing and thus modifying |\pgf at x| and |\pgf at y|.
+
+ In our example we would write
+ %
+\begin{codeexample}[code only]
+\pgfarrowshullpoint{1cm}{0pt}
+\pgfarrowshullpoint{-3cm}{2cm}
+\pgfarrowshullpoint{-3cm}{-2cm}
+\end{codeexample}
+ \end{command}
+
+ \begin{command}{\pgfarrowsupperhullpoint\marg{x dimension}\marg{y dimension}}
+ This command works like the previous command, only it normally
+ adds \emph{two} points to the convex hull: First, the point
+ $(\meta{x dimension},\meta{y dimension})$ and, secondly, the
+ point $(\meta{x dimension},-\meta{y dimension})$. However, the
+ second point is only added if the arrow is not a harpoon.
+
+ Thus, in our example we could simplify the convex hull to
+ %
+\begin{codeexample}[code only]
+\pgfarrowshullpoint{1cm}{0pt}
+\pgfarrowsupperhullpoint{-3cm}{2cm}
+\end{codeexample}
+ %
+ If the \meta{y dimension} is zero or less, only one point,
+ namely $(\meta{x dimension},\meta{y dimension})$, is added to
+ the hull. Thus, we could also have used the upper convex hull
+ command in the first of the two of the above commands.
+ \end{command}
+
+ \begin{command}{\pgfarrowssave\marg{macro}}
+ As explained earlier, the setup code needs to ``communicate''
+ with the drawing code via ``saved values''. This command get
+ the name of a macro and will store the value this macro had
+ internally. Then, each time drawing code is executed, the value
+ of this macro will be restored.
+ \end{command}
+
+ \begin{command}{\pgfarrowssavethe\marg{register}}
+ Works like |\pgfarrowssave|, only the parameter must be a
+ register and |\the|\meta{register} will be saved. Typically,
+ you will write something like
+ %
+\begin{codeexample}[code only]
+\pgfarrowssavethe{\pgfarrowlength}
+\pgfarrowssavethe{\pgfarrowwidth}
+\end{codeexample}
+ %
+ To ensure that inside the drawing code the the dimension
+ registers |\pgfarrowlength| and |\pgfarrowwidth| are setup with
+ the values they had during the setup.
+ \end{command}
+ \item \declare{|drawing code|}|=|\marg{code}
+
+ This code will be executed at least once for each setting of the
+ parameters when the time arrow tip is actually drawn. Usually, this
+ one execution will be all and the low-level commands generated
+ inside the \meta{code} will we stored in a special cache; but in
+ some cases the \meta{code} gets executed each time the arrow tip is
+ used, so do not assume anything about it. Inside the \meta{code},
+ you have access to all values that were saved in the setup code as
+ well as to the line width.
+
+ The \meta{code} should draw the arrow tip ``going right along the
+ $x$-axis''. \pgfname\ will take care of setting up a canvas
+ transformation beforehand to a rotation such that when the drawing
+ is rendered, the arrow tip that is actually drawn points in the
+ direction of the line. Alternatively, when bending is switched on,
+ even more complicated low-level transformations will be done
+ automatically.
+
+ The are some special considerations concerning the \meta{code}:
+ %
+ \begin{itemize}
+ \item In the \meta{code} you may \emph{not} use |\pgfusepath|
+ since this would try to add arrow tips to the arrow tip and
+ lead to a recursion. Use the ``quick'' versions
+ |\pgfusepathqstroke| and so on instead, which never try to
+ add arrow tips.
+ \item If you stroke the path that you construct, you should
+ first set the dashing to solid and set up fixed joins and
+ caps, as needed. This will ensure that the arrow tip will
+ always look the same.
+ \item When the arrow tip code is executed, it is automatically
+ put inside a low-level scope, so nothing will ``leak out''
+ from the scope.
+ \item The high-level coordinate transformation matrix will be
+ set to the identity matrix when the code is executed for
+ the first time.
+ \end{itemize}
+ \item \declare{|cache|}|=|\meta{true or false}
+
+ When set to |true|, which is the default, the \meta{code} will be
+ executed only once for a particular value of parameters and the
+ low-level commands created by the drawing code (using the system
+ layer protocol subsystem, see Section~\ref{section-protocols}) will
+ be cached and reused later on. However, when the drawing code
+ contains ``uncacheable'' code like a call to |\pgftext|, caching
+ must be switched off by saying |cache=false|.
+ \item \declare{|bending mode|}|=|\meta{mode}
+
+ This key is important only when the |bend| option is used with an
+ arrow, see Section~\ref{section-arrow-flex} for an introduction to
+ this option. The |bend| option asks us to, well, bend the arrow
+ head. For some arrow head this is not possible or leads to very
+ strange drawings (for instance, when the |\pgftext| command is
+ used) and then it is better to switch bending off for the arrow
+ head (|flex| will then be used instead). To achieve this, set
+ \meta{mode} to |none|.
+
+ For most arrow tips it does, however, make sense to bend them.
+ There are (at least) two different mathematical ways of doing so,
+ see Section~\ref{section-library-curvilinear} for details. Which of
+ these ways is use can be configured by setting \meta{mode} to
+ either |orthogonal| or to |polar|. It is best to try simply try out
+ both when designing an arrow tip to see which works better. Since
+ |orthogonal| is quicker and often gives good oder even better
+ results, it is the default. Some arrow tips, however, profit from
+ saying |bending mode=polar|.
+ \item \declare{|defaults|}|=|\meta{arrow keys}
+
+ The \meta{arrow keys} allow you to configure the default values for
+ the parameters on which an arrow tip depends. The \meta{arrow keys}
+ will be executed first before any other arrow tip options are
+ executed, see Section~\ref{section-arrow-scopes} for the exact
+ sequence. Also see Section~\ref{section-arrow-options} below for
+ more details on arrow options.
+ \end{itemize}
+
+ This concludes the description of the keys you provide for the declaration
+ of an arrow. Let us now have a look at a simple example that uses these
+ features: We want to define an arrow tip kind |foo| that produces the arrow
+ tip we used as our running example. However, to make things a bit more
+ interesting, let us make it ``configurable'' insofar as the length of the
+ arrow tip can be configured using the |length| option, which sets the
+ |\pgfarrowlength|. By default, this length should be the gigantic 4cm we
+ say in the example, but uses should be able to set it to anything they
+ like. We will not worry about the arrow width or insets, of arrow line
+ width, or harpoons, or anything else in this example to keep it simple.
+
+ Here is the code:
+ %
+\begin{codeexample}[code only]
+\pgfdeclarearrow{
+ name = foo,
+ parameters = { \the\pgfarrowlength },
+ setup code = {
+ % The different end values:
+ \pgfarrowssettipend{.25\pgfarrowlength}
+ \pgfarrowssetlineend{-.25\pgfarrowlength}
+ \pgfarrowssetvisualbackend{-.5\pgfarrowlength}
+ \pgfarrowssetbackend{-.75\pgfarrowlength}
+ % The hull
+ \pgfarrowshullpoint{.25\pgfarrowlength}{0pt}
+ \pgfarrowshullpoint{-.75\pgfarrowlength}{.5\pgfarrowlength}
+ \pgfarrowshullpoint{-.75\pgfarrowlength}{-.5\pgfarrowlength}
+ % Saves: Only the length:
+ \pgfarrowssavethe\pgfarrowlength
+ },
+ drawing code = {
+ \pgfpathmoveto{\pgfqpoint{.25\pgfarrowlength}{0pt}}
+ \pgfpathlineto{\pgfqpoint{-.75\pgfarrowlength}{.5\pgfarrowlength}}
+ \pgfpathlineto{\pgfqpoint{-.5\pgfarrowlength}{0pt}}
+ \pgfpathlineto{\pgfqpoint{-.75\pgfarrowlength}{-.5\pgfarrowlength}}
+ \pgfpathclose
+ \pgfusepathqfill
+ },
+ defaults = { length = 4cm }
+}
+\end{codeexample}
+ %
+ We can now use it:
+ %
+\pgfdeclarearrow{
+ name = foo,
+ parameters = { \the\pgfarrowlength },
+ setup code = {
+ % The different end values:
+ \pgfarrowssettipend{.25\pgfarrowlength}
+ \pgfarrowssetlineend{-.25\pgfarrowlength}
+ \pgfarrowssetvisualbackend{-.5\pgfarrowlength}
+ \pgfarrowssetbackend{-.75\pgfarrowlength}
+ % The hull
+ \pgfarrowshullpoint{.25\pgfarrowlength}{0pt}
+ \pgfarrowshullpoint{-.75\pgfarrowlength}{.5\pgfarrowlength}
+ \pgfarrowshullpoint{-.75\pgfarrowlength}{-.5\pgfarrowlength}
+ % Saves: Only the length:
+ \pgfarrowssavethe\pgfarrowlength
+ },
+ drawing code = {
+ \pgfpathmoveto{\pgfqpoint{.25\pgfarrowlength}{0pt}}
+ \pgfpathlineto{\pgfqpoint{-.75\pgfarrowlength}{.5\pgfarrowlength}}
+ \pgfpathlineto{\pgfqpoint{-.5\pgfarrowlength}{0pt}}
+ \pgfpathlineto{\pgfqpoint{-.75\pgfarrowlength}{-.5\pgfarrowlength}}
+ \pgfpathclose
+ \pgfusepathqfill
+ },
+ defaults = { length = 4cm }
+}
+\begin{codeexample}[
+ preamble={\usetikzlibrary{arrows.meta}},
+ pre={\pgfdeclarearrow{
+ name = foo,
+ parameters = { \the\pgfarrowlength },
+ setup code = {
+ % The different end values:
+ \pgfarrowssettipend{.25\pgfarrowlength}
+ \pgfarrowssetlineend{-.25\pgfarrowlength}
+ \pgfarrowssetvisualbackend{-.5\pgfarrowlength}
+ \pgfarrowssetbackend{-.75\pgfarrowlength}
+ % The hull
+ \pgfarrowshullpoint{.25\pgfarrowlength}{0pt}
+ \pgfarrowshullpoint{-.75\pgfarrowlength}{.5\pgfarrowlength}
+ \pgfarrowshullpoint{-.75\pgfarrowlength}{-.5\pgfarrowlength}
+ % Saves: Only the length:
+ \pgfarrowssavethe\pgfarrowlength
+ },
+ drawing code = {
+ \pgfpathmoveto{\pgfqpoint{.25\pgfarrowlength}{0pt}}
+ \pgfpathlineto{\pgfqpoint{-.75\pgfarrowlength}{.5\pgfarrowlength}}
+ \pgfpathlineto{\pgfqpoint{-.5\pgfarrowlength}{0pt}}
+ \pgfpathlineto{\pgfqpoint{-.75\pgfarrowlength}{-.5\pgfarrowlength}}
+ \pgfpathclose
+ \pgfusepathqfill
+ },
+ defaults = { length = 4cm }
+}},
+]
+\tikz \draw [-foo] (0,0) -- (8,0);
+\end{codeexample}
+\begin{codeexample}[
+ preamble={\usetikzlibrary{arrows.meta,bending}},
+ pre={\pgfdeclarearrow{
+ name = foo,
+ parameters = { \the\pgfarrowlength },
+ setup code = {
+ % The different end values:
+ \pgfarrowssettipend{.25\pgfarrowlength}
+ \pgfarrowssetlineend{-.25\pgfarrowlength}
+ \pgfarrowssetvisualbackend{-.5\pgfarrowlength}
+ \pgfarrowssetbackend{-.75\pgfarrowlength}
+ % The hull
+ \pgfarrowshullpoint{.25\pgfarrowlength}{0pt}
+ \pgfarrowshullpoint{-.75\pgfarrowlength}{.5\pgfarrowlength}
+ \pgfarrowshullpoint{-.75\pgfarrowlength}{-.5\pgfarrowlength}
+ % Saves: Only the length:
+ \pgfarrowssavethe\pgfarrowlength
+ },
+ drawing code = {
+ \pgfpathmoveto{\pgfqpoint{.25\pgfarrowlength}{0pt}}
+ \pgfpathlineto{\pgfqpoint{-.75\pgfarrowlength}{.5\pgfarrowlength}}
+ \pgfpathlineto{\pgfqpoint{-.5\pgfarrowlength}{0pt}}
+ \pgfpathlineto{\pgfqpoint{-.75\pgfarrowlength}{-.5\pgfarrowlength}}
+ \pgfpathclose
+ \pgfusepathqfill
+ },
+ defaults = { length = 4cm }
+}},
+]
+\tikz \draw [-{foo[length=2cm,bend]}] (0,0) to [bend left] (3,0);
+\end{codeexample}
+
+
+ \medskip
+ \noindent\textbf{Defining a Shorthand.}
+ The |\pgfdeclarearrow| command can also used to define
+ \emph{shorthands}. This works as follows:
+ \begin{itemize}
+ \item First, you must provide a |name| just in the same way as when you
+ define a full-flung new arrow tip kind.
+ \item Second, instead of all of the other options listed above, you
+ just use one more option:
+
+ \smallskip
+ \declare{|means|}|=|\meta{end arrow specification}
+
+ This sets up things so that whenever \meta{name} is now used in an
+ arrow specification, it will be replaced by the \meta{end arrow
+ specification} (the problems resulting form the \meta{name} begin
+ used in a start arrow specification are taken care of
+ automatically). See also Section~\ref{section-arrow-tip-macro} for
+ details on the order in which options get executed in such cases.
+
+ Note that the \meta{end arrow specification} will be executed
+ immediately to build the so-called arrow option caches, a concept
+ explored in more detail in
+ Section~\ref{section-arrow-option-cache}. In practice, this has
+ mainly two effects: First, all arrow tips referred to in the
+ specification must already exist (at least as ``dummy'' versions).
+ Second, all dimensions mentioned in options of the \meta{end arrow
+ specification} will be evaluated immediately. For instance, when
+ you write
+ %
+\begin{codeexample}[code only]
+\pgfdeclarearrow{ name=foo, means = bar[length=2cm+\mydimen] }
+\end{codeexample}
+ %
+ The value |2cm+\mydimen| is evaluated immediately. When |foo| is
+ used later on and |\mydimen| has changed, this has no effect.
+ \end{itemize}
+\end{command}
+
+
+\subsection{Handling Arrow Options}
+\label{section-arrow-options}
+
+When you declare an arrow tip, your drawing code should take into account the
+different arrow keys set for it (like the arrow tip length, width, or
+harpooning). The different arrow keys that are available have been described in
+detail in Section~\ref{section-arrow-config}; but how do we access the values
+set by an option like |length| or |harpoon| or |bend| in the drawing code? In
+the present section we have a look at how this works.
+
+
+\subsubsection{Dimension Options}
+
+Most arrow keys, like |length| or |width'|, simple set a \TeX\ dimension
+register to a certain value. For example, |length| sets the value of the \TeX\
+dimension register |\pgfarrowlength|. Note that |length| takes several values
+as input with a complicated semantics as explained for the |length| key on
+page~\pageref{length-arrow-key}. All of these settings are not important for
+the setup code: When it gets executed, the code behind the |length| key will
+have computed a simple number that is stored in |\pgfarrowlength|. Indeed,
+inside the setup code you do not have access to the exact value given to the
+|length| key; just to the final computed value.
+
+The following \TeX\ dimensions are available to the setup code:
+%
+\begin{itemize}
+ \item |\pgfarrowslength|. It gets set by the arrow keys |length| and
+ |angle|.
+ \item |\pgfarrowswidth|. It gets set by |width|, |width'|, and |angle|.
+ \item |\pgfarrowsinset|. It gets set by |inset| and |inset'|.
+ \item |\pgfarrowslinewidth|. It gets set by |line width| and |line width'|.
+\end{itemize}
+
+If your setup code depends on any of them, add them to the |parameters| key of
+the arrow tip.
+
+
+\subsubsection{True--False Options}
+
+A number of arrow keys just do a yes/no switch, like |reversed|. All of them
+setup a \TeX-if that you can access in the setup code:
+%
+\begin{itemize}
+ \item |\ifpgfarrowreversed| is setup by |reversed|.
+ \item |\ifpgfarrowswap| is setup by |swap| and also |right|.
+ \item |\ifpgfarrowharpoon| is setup by |harpoon| and also |left| and
+ |right|.
+ \item |\ifpgfarrowroundcap| is set to true by |line cap=round| and set to
+ false by |line cap=butt|. It also gets (re)set by |round| and |sharp|.
+ \item |\ifpgfarrowroundjoin| is set to true by |line join=round| and set to
+ false by |line join=miter|. It also gets (re)set by |round| and
+ |sharp|.
+ \item |\ifpgfarrowopen| is set to true by |fill=none| and by |open| (which
+ is a shorthand for |fill=none|) and set to false by |color| and all
+ other |fill=|\meta{color}.
+\end{itemize}
+
+If you code depends on any of these, you must add them to the |parameters| in
+such a way that the parameters are different when the \TeX-if is set from when
+it is not set. An easy way to achieve this is to write something like
+%
+\begin{codeexample}[code only]
+ parameters = { \the\pgfarrowlength,...,
+ \ifpgfarrowharpoon h\fi\
+ \ifpgfarrowroundjoin j\fi}
+\end{codeexample}
+%
+In other words, for each set parameter on which the arrow tip depends, a
+specific letter is added to the parameters, making them unique.
+
+The first two of the above keys are a bit special: Reversing and swapping an
+arrow tip can be done just by fiddling with the transformation matrix: a
+reverse is a ``flip'' along the $y$-axis and a swap is a flip along the
+$x$-axis. This is done automatically by \pgfname.
+
+Nevertheless, you may wish to modify you code in dependence especially of the
+|reverse| key: When |\ifpgfarrowreverse| is true, \pgfname\ will flip the
+coordinate system along the $y$-axis, will negate all end values (like line
+end, tip end, and so on) and will exchange the meaning of back end and tip end
+as well as of visual back end and visual back end. Usually, this is exactly
+what one need; \emph{except} that the line end may no longer be appropriate.
+After all, the line end should be chosen so that it is completely covered by
+the arrow. Now, when the arrow tip is open, a reversed arrow should no longer
+have the line end near the old visual back end, but near to the old visual tip
+end.
+
+For these reasons, you may need to make the computation of the line end
+dependent on whether the arrow is reversed or not. Note that when you specify a
+different line end for a reversed arrow tip, the transformation and inverting
+of the coordinate system will still be done, meaning that if |reverse| is true,
+you need to specify a line end in the ``old'' coordinate system that is at the
+position where, after everything is inverted, it will be at the correct
+position. Usually that means that if the |reverse| option is set, you need to
+\emph{increase} the line end.
+
+
+\subsubsection{Inaccessible Options}
+
+There are some options that influence the way an arrow tip looks, but that you
+cannot access inside the setup code. Handling these options lies entirely with
+\pgfname. If you wish your setup code to handle these options, you have to
+setup your own ``parallel'' options.
+%
+\begin{itemize}
+ \item |quick|, |flex|, |flex'|, and |bend| are all handled automatically.
+ You can, however, set the |bending mode| to avoid bending of your arrow
+ tip.
+ \item The colors set by |color| and |fill|. You can, however, access them
+ indirectly, namely through the current stroke and fill colors.
+ \item |sep|
+\end{itemize}
+
+
+\subsubsection{Defining New Arrow Keys}
+\label{section-arrow-option-cache}
+
+The set of predefined options is already quite long and most arrow tips will
+not need more than the predefined options. However, sometimes an arrow tip may
+need to introduce a new special-purpose option. For instance, suppose we wish
+to introduce a new fictive arrow key |depth|. In such cases, you must do two
+things:
+%
+\begin{enumerate}
+ \item Introduce a new dimension register or macro that will hold the
+ configuration value and which will be accessed by the setup code. The
+ could be achieved by saying
+ %
+\begin{codeexample}[code only]
+\newdimen\pgfarrowdepth
+\end{codeexample}
+ %
+ \item Introduce a new arrow key option |/pgf/arrow keys/depth| that allows
+ users to configure the new macro or register.
+\end{enumerate}
+
+When an arrow is selected via for instance |foo[depth=5pt]|, the key--value
+pairs between the square brackets are executed with the path prefix
+|/pgf/arrow keys|. Thus, in the example, our depth key would get executed.
+Thus, it is tempting to write something like
+%
+\begin{codeexample}[code only]
+\pgfkeys{/pgf/arrow keys/depth/.code = \pgfmathsetlength{\pgfarrowdepth}{#1}}
+\end{codeexample}
+
+Sadly, this will not work. The reason is that there is yet another level of
+caching involved when \pgfname\ processes arrow tips: The option cache! The
+problem is each time an arrow tip is used, even when the drawing code of the
+arrow tip is nicely cached, we still need to process the options in
+|foo[length=5pt]| to find out which version in the cache we would like to
+access. To make matters worse, |foo| might be a shorthand that calls other
+arrow tips, which add more options, and so on. Unfortunately, executing keys is
+quite an expensive operation (\pgfname's key--value parser is powerful, but
+that power comes at a price). So, whenever possible, we do \emph{not} want the
+key--value parser to be started.
+
+For these reasons, when something like |foo[|\meta{options}|]| is encountered
+inside a shorthand, the \meta{options} are executed only once. They should now
+setup the \emph{arrow option cache}, which is some code that, when executed,
+should setup the values that the \meta{options} configure. In our example, the
+|depth| key should add something to the arrow option cache that sets
+|\pgfarrowdepth| to the given value.
+
+Adding something to the arrow option cache is done using the following command:
+
+\begin{command}{\pgfarrowsaddtooptions\marg{code}}
+ This command should be called by keys with the prefix |/pgf/arrow keys| to
+ add code to the arrow option cache. For our |depth| key example, we could
+ use this key as follows:
+ %
+\begin{codeexample}[code only]
+\pgfkeys{/pgf/arrow keys/depth/.code=
+ \pgfarrowsaddtooptions{\pgfmathsetlength{\pgfarrowdepth}{#1}}
+\end{codeexample}
+ %
+ Actually, this is still not optimal since the expensive |\pgfmathsetlength|
+ command is now called each time an arrow tip is used with the |depth|
+ option set. The trick is to do the expensive operation only once and then
+ store only very quick code in the arrow option cache:
+ %
+\begin{codeexample}[code only]
+\pgfkeys{/pgf/arrow keys/depth/.code=
+ \pgfmathsetlength{\somedimen}{#1}
+ \pgfarrowsaddtooptions{\pgfarrowdepth=\somedimen} % buggy
+\end{codeexample}
+ %
+ The above code will not (yet) work since |\somedimen| will surely have a
+ different value when the cache is executed. The trick is to use some
+ |\expandafter|s:
+ %
+\begin{codeexample}[code only]
+\pgfkeys{/pgf/arrow keys/depth/.code=
+ \pgfmathsetlength{\somedimen}{#1}
+ \expandafter\pgfarrowsaddtooptions\expandafter{\expandafter\pgfarrowdepth\expandafter=\the\somedimen}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfarrowsaddtolateoptions\marg{code}}
+ This command works like |\pgfarrowsaddtooptions|, only the \meta{code} will
+ be executed ``later'' than the code added by the normal version of the
+ command. This is useful for keys that depend on the length of an arrow:
+ Keys like |width'| want to define the arrow width as a multiple of the
+ arrow length, but when the |width'| key is given, the length may not yet
+ have been specified. By making the computation of the width a ``late''
+ option, we ensure that |\pgfarrowlength| will have been setup correctly.
+\end{command}
+
+If you define a new option that sets a dimensions and if that dimension should
+change in accordance to the setting of either |scale length| or |scale width|,
+you need to make \pgfname\ ``aware'' of this using the following key:
+
+\begin{command}{\pgfarrowsaddtolengthscalelist\marg{dimension register}}
+ Each time an arrow tip is used, the given \meta{dimension register} will be
+ multiplied by the |scale length| factor prior to the actual drawing. You
+ call this command only once in the preamble somewhere.
+\end{command}
+
+\begin{command}{\pgfarrowsaddtowidthscalelist\marg{dimension register}}
+ Works like |\pgfarrowsaddtolengthscalelist|, only for width parameters.
+\end{command}
+
+
+\begin{command}{\pgfarrowsthreeparameters\marg{line-width dependent size specification}}
+ This command is useful for parsing the values given to keys like |length|
+ or |width| the expect a dimension followed optionally for some numbers.
+ This command converts the \meta{line-width dependent size specification},
+ which may consist of one, two, or three numbers, into a triple of three
+ numbers in curly braces, which gets stored in the macro
+ |\pgfarrowstheparameters|. Here is an example, where |\showvalueofmacro| is
+ used in this example to show the value stored in a macro:
+ %
+\begin{codeexample}[setup code,hidden]
+ \makeatletter
+ \def\showvalueofmacro#1{%
+ \texttt{\expandafter\expandafter\expandafter\expandafter\expandafter\expandafter\expandafter\pgfutil at gobble\expandafter\expandafter\expandafter\string\expandafter\csname#1\endcsname}
+ }%
+\end{codeexample}
+%
+\begin{codeexample}[]
+\pgfarrowsthreeparameters{2pt 1}
+\showvalueofmacro\pgfarrowstheparameters
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfarrowslinewidthdependent\marg{dimension}\marg{line width factor}\marg{outer factor}}
+ This command takes three parameters and does the ``line width dependent
+ computation'' described on page~\pageref{length-arrow-key} for the |length|
+ key. The result is returned in |\pgf at x|.
+
+ The idea is that you can setup line-width dependent keys like |length| or
+ |width| using code like the following:
+ %
+\begin{codeexample}[code only]
+\pgfkeys{/pgf/arrow keys/depth/.code={%
+ \pgfarrowsthreeparameters{#1}%
+ \expandafter\pgfarrowsaddtolateoptions\expandafter{%
+ \expandafter\pgfarrowslinewidthdependent\pgfarrowstheparameters% compute...
+ \pgfarrowdepth\pgf at x% ... and store.
+ }%
+}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfarrowslengthdependent\marg{dimension}\marg{length factor}\marg{dummy}}
+ This command takes three parameters, of which the last one is ignored, and
+ does the ``length dependent computation'' described for the |width'| and
+ |inset'| keys. The result is returned in |\pgf at x|.
+
+ You can setup length dependent keys using code like the following:
+ %
+\begin{codeexample}[code only]
+\pgfkeys{/pgf/arrow keys/depth'/.code={%
+ \pgfarrowsthreeparameters{#1}%
+ \expandafter\pgfarrowsaddtolateoptions\expandafter{%
+ \expandafter\pgfarrowslengthdependent\pgfarrowstheparameters% compute...
+ \pgfarrowdepth\pgf at x% ... and store.
+ }%
+}
+\end{codeexample}
+ %
+\end{command}
+
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "pgfmanual"
+%%% End:
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-arrows.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-decorations.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-decorations.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-decorations.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,979 @@
+% Copyright 2019 by Till Tantau and Mark Wibrow
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section{Decorations}
+\label{section-base-decorations}
+
+\begin{pgfmodule}{decorations}
+ The commands for creating decorations are defined in this module, so you
+ need to load this module to use decorations. This module is automatically
+ loaded by the different decoration libraries.
+\end{pgfmodule}
+
+
+\subsection{Overview}
+
+Decorations are a general way of creating graphics by ``moving along'' a path
+and, while doing so, either drawing something or constructing a new path. This
+could be as simple as extending a path with a ``zigzagged'' line\ldots
+%
+\begin{codeexample}[preamble={\usetikzlibrary{decorations,decorations.pathmorphing}}]
+\tikz \draw decorate[decoration=zigzag] {(0,0) -- (3,0)};
+\end{codeexample}
+%
+\ldots but could also be as complex as typesetting text along a path:
+%
+{\catcode`\|12
+\begin{codeexample}[preamble={\usetikzlibrary{decorations,decorations.text}}]
+\tikz \path decorate [decoration={text along path,
+ text={Some text along a path}}]
+ { (0,2) .. controls (2,2) and (1,0) .. (3,0) };
+\end{codeexample}
+}
+
+The workflow for using decorations is the following:
+%
+\begin{enumerate}
+ \item You define a decoration using the |\pgfdeclaredecoration| command.
+ Different useful decorations are already declared in libraries like
+ |decorations.shapes|.
+ \item You use normal path construction commands like |\pgfpathlineto| to
+ construct a path. Let us call this path the \emph{to-be-decorated}
+ path.
+ \item You place the path construction commands inside the environment
+ |{pgfdecoration}|. This environment takes the name of a previously
+ declared decoration as a parameter. It will then start ``walking
+ along'' the to-be-decorated path. As it does this, a special finite
+ automaton called a \emph{decoration automaton} produces new path
+ commands as its output (or even other outputs). These outputs replace
+ the to-be-decorated path; indeed, after the to-be-decorated path has
+ been fully walked along it is thrown away, only the output of the
+ automaton persists.
+\end{enumerate}
+
+In the present section the process of how decoration automata work is explained
+first. Then the command(s) for declaring decoration automata and for using them
+are covered.
+
+
+\subsection{Decoration Automata}
+
+Decoration automata (and the closely related meta-decoration automata) are a
+general concept for creating graphics ``along paths''. For straight lines, this
+idea was first proposed by Till Tantau in an earlier version of \pgfname, the
+idea to extend this to arbitrary path was proposed and implemented by Mark
+Wibrow. Further versatility is provided by ``meta-decorations''. These are
+automata that decorate a path with decorations.
+
+In the present subsection the different ideas underlying decoration automata
+are presented.
+
+
+\subsubsection{The Different Paths}
+
+In order to prevent confusion with different types of paths, such as those that
+are extended, those that are decorated and those that are created, the
+following conventions will be used:
+%
+\begin{itemize}
+ \item The \emph{preexisting} path refers to the current path in existence
+ before a decoration environment. (Possibly this path has been created
+ by another decoration used earlier, but we will still call this path
+ the preexisting path also in this case.)
+ \item The \emph{input} path refers to the to-be-decorated path that the
+ decoration automaton moves along. The input path may consist of many
+ line and curve input segments (for example, a circle or an ellipse
+ consists of four curves). It is specified inside the decoration
+ environment.
+ \item The \emph{output} path refers to the path that the decoration
+ creates. Depending on the decoration, this path may or may not be empty
+ (a decoration can also choose to use side-effects instead of producing
+ an output path). The input path is always consumed by the decoration
+ automaton, that is, it is no longer available in any way after the
+ decoration automaton has finished.
+\end{itemize}
+
+The effect of a decoration environment is the following: The input path, which
+is specified inside the environment, is constructed and stored. This process
+does not alter the preexisting path in any way. Then the decoration automaton
+is started (as described later) and it produces an output path (possibly
+empty). Whenever part of the output path is produced, it is concatenated with
+the preexisting path. After the environment, the current path will equal the
+original preexisting path followed by the output path.
+
+It is permissible that a decoration issues a |\pgfusepath| command. As usual,
+this causes the current path to be filled or stroked or some other action to be
+taken and the current path is set to the empty path. As described above, when
+the decoration automaton starts, the current path is the preexisting path and
+as the automaton progresses, the current path is constantly being extended by
+the output path. This means that first time a |\pgfusepath| command is used on
+a decoration, the preexisting path is part of the path this command operates
+on; in subsequent calls only the part of the output path constructed since the
+last |\pgfusepath| command will be used.
+
+You can use this mechanism to stroke or fill different parts of the output path
+in different colors, line widths, fills and shades; all within the same
+decoration. Alternatively, a decoration can choose to produce no output path at
+all: the |text| decoration simply typesets text along a path.
+
+
+\subsubsection{Segments and States}
+
+The most common use of a decoration is to ``repeat something along a path''
+(for example, the |zigzag| decoration repeats
+%
+\tikz\draw decorate[decoration=zigzag] {(0,0)--(\pgfdecorationsegmentlength,0)};
+%
+along a path). However, it not necessarily the case that only one thing is
+repeated: a decoration can consist of different parts, or \emph{segments},
+repeated in a particular order.
+
+When you declare a decoration, you provide a description of how their different
+segments will be rendered. The description of each segment should be given in a
+way as if the ``$x$-axis'' of the segment is the tangent to the path at a
+particular point, and that point is the origin of the segment. Thus, for
+example, the segment of the |zigzag| decoration might be defined using the
+following code:
+%
+\begin{codeexample}[code only]
+\pgfpathlineto{\pgfpoint{5pt}{5pt}}
+\pgfpathlineto{\pgfpoint{15pt}{-5pt}}
+\pgfpathlineto{\pgfpoint{20pt}{0pt}}
+\end{codeexample}
+
+\pgfname\ will ensure that an appropriate coordinate transformation is in place
+when the segment is rendered such that the segment actually points in the right
+direction. Also, subsequent segments will be transformed such that they are
+``further along the path'' toward the end of the path. All transformations are
+set up automatically.
+
+Note that we did not use a |\pgfpathmoveto{\pgfpointorigin}| at the beginning
+of the segment code. Doing so would subdivide the path into numerous subpaths.
+Rather, we assume that the previous segment caused the current point to be at
+the origin.
+
+The width of a segment can (and must) be specified explicitly. \pgfname\ will
+use this width to find out the start point of the next segment and the correct
+rotation. The width the you provide need not be the ``real'' width of the
+segment, which allows decoration segments to overlap or to be spaced far apart.
+
+The |zigzag| decoration only has one segment that is repeated again and again.
+However, we might also like to have \emph{different} segments and use rules to
+describe which segment should be used where. For example, we might have special
+segments at the start and at the end.
+
+Decorations use a mechanism known in theoretical in computer science as
+\emph{finite state automata} to describe which segment is used at a particular
+point. The idea is the following: For the first segment we start in a special
+\emph{state} called the \emph{initial state}. In this state, and also in all
+other states later, \pgfname\ first computes how much space is left on the
+input path. That is, \pgfname\ keeps track of the distance to the end of the
+input path. Attached to each state there is a set of rules of the following
+form: ``If the remaining distance on the input path is less than $x$, switch to
+state~$q$.'' \pgfname\ checks for each of these rules whether it applies and,
+if so, immediately switches to state~$q$.
+
+Only if none of the rules tell us to switch to another state, \pgfname\ will
+execute the state's code. This code will (typically) add a segment to the
+output path. In addition to the rules there is also a width parameter attached
+to each state. \pgfname\ then translates the coordinate system by this width
+and reduces the remaining distance on the input path. Then, \pgfname\ either
+stays in the current state or switches to another state, depending on yet
+another property attached of the state.
+
+The whole process stops when a special state called |final| is reached. The
+segment of this state is immediately added to the output path (it is often
+empty, though) and the process ends.
+
+
+\subsection{Declaring Decorations}
+
+The following command is used to declare a decoration. Essentially, this
+command describes the decoration automaton.
+
+\begin{command}{\pgfdeclaredecoration\marg{name}\marg{initial state}\marg{states}}
+ This command declares a new decoration called \meta{name}. The
+ \meta{states} argument contains a description of the decoration automaton's
+ states and the transitions between them. The \meta{initial state} is the
+ state in which the automaton starts.
+
+ When the automaton is later applied to an input path, it keeps track of a
+ certain position on the input path. This current point will ``travel along
+ the path'', each time being moved along by a certain distance. This will
+ also work if the path is not a straight line. That is, it is permissible
+ that the path curves are veers at a sharp angle. It is also permissible
+ that while traveling along the input path, the current input segment ends
+ and a new input segment starts. In this case, the remaining distance on the
+ first input segment is subtracted from the \meta{dimension} and then we
+ travel along the second input segment for the remaining distance. This
+ input segment may also end early, in which case we travel along the next
+ input segment, and so on. Note that it cannot happen that we travel past
+ the end of the input path since this would have caused an immediate switch
+ to the |final| state.
+
+ Note that the computation of the path lengths has only a low accuracy
+ because of \TeX's small math capabilities. Do not expect high accuracy
+ alignments when using decorations (unless the input path consists only of
+ horizontal and vertical lines).
+
+ The \meta{states} argument should consist of |\state| commands, one for
+ each state of the decoration automaton. The |\state| command is defined
+ only when the \meta{states} argument is executed.
+
+ \begin{command}{\state\marg{name}\oarg{options}\marg{code}}
+ This command declares a new state inside the current decoration
+ automaton. The state is named \meta{name}.
+
+ When the decoration automaton is in state \meta{name}, the following
+ things happen:
+ %
+ \begin{enumerate}
+ \item The \meta{options} are parsed. This may lead to a state
+ switch, see below. When this happens, the following steps are
+ not executed. The \meta{options} are executed one after the
+ other in the given order. If an option causes a state switch,
+ the switch is immediate, even if later options might cause a
+ different state switch.
+ \item The \meta{code} is executed in a \TeX-group with the current
+ transformation matrix set up in such a way that the origin is
+ on the input path at the current point (the point at the
+ distance traveled up to now) and the coordinate system is
+ rotated in such a way that the positive $x$-axis points in the
+ direction of the tangent to the input path at the current
+ point, while the positive $y$-axis points to the left of this
+ tangent.
+
+ As described earlier, the \meta{code} can have two different
+ effects: If it just contains path construction commands, the
+ decoration will produce an output path, that is, it extends the
+ preexisting path. Here is an example:
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{decorations}}]
+\pgfdeclaredecoration{example}{initial}
+{
+ \state{initial}[width=10pt]
+ {
+ \pgfpathlineto{\pgfpoint{0pt}{5pt}}
+ \pgfpathlineto{\pgfpoint{5pt}{5pt}}
+ \pgfpathlineto{\pgfpoint{5pt}{-5pt}}
+ \pgfpathlineto{\pgfpoint{10pt}{-5pt}}
+ \pgfpathlineto{\pgfpoint{10pt}{0pt}}
+ }
+ \state{final}
+ {
+ \pgfpathlineto{\pgfpointdecoratedpathlast}
+ }
+}
+\tikz[decoration=example]
+{
+ \draw [decorate] (0,0) -- (3,0);
+ \draw [red,decorate] (0,0) to [out=45,in=135] (3,0);
+}
+\end{codeexample}
+
+ Alternatively, the \meta{code} can also contain the
+ |\pgfusepath| command. This will use the path in the usual
+ manner, where ``the path'' is the preexisting path plus a part
+ of the output path for the first invocation and the different
+ parts of the rest of the output path for the following
+ invocation. Here is an example:
+ %
+\begin{codeexample}[pre={\pgfmathsetseed{1}},preamble={\usetikzlibrary{decorations,shapes.geometric}}]
+\pgfdeclaredecoration{stars}{initial}{
+ \state{initial}[width=15pt]
+ {
+ \pgfmathparse{round(rnd*100)}
+ \pgfsetfillcolor{yellow!\pgfmathresult!orange}
+ \pgfsetstrokecolor{yellow!\pgfmathresult!red}
+ \pgfnode{star}{center}{}{}{\pgfusepath{stroke,fill}}
+ }
+ \state{final}
+ {
+ \pgfpathmoveto{\pgfpointdecoratedpathlast}
+ }
+}
+\tikz\path[decorate, decoration=stars, star point ratio=2, star points=5,
+ inner sep=0, minimum size=rnd*10pt+2pt]
+ (0,0) .. controls (0,2) and (3,2) .. (3,0)
+ .. controls (3,-3) and (0,0) .. (0,-3)
+ .. controls (0,-5) and (3,-5) .. (3,-3);
+\end{codeexample}
+ %
+ \item After the \meta{code} has been executed (possibly more than
+ once, if the |repeat state| option is used), the state switches
+ to whatever state has been specified inside the \meta{options}
+ using the |next state| option. If no |next state| has been
+ specified, the state stays the same.
+ \end{enumerate}
+
+ The \meta{options} are executed with the key path set to
+ |/pgf/decoration automaton|. The following keys are defined:
+ %
+ \begin{key}{/pgf/decoration automaton/switch if less than=\meta{dimension}\texttt{ to }\meta{new state}}
+ When this key is encountered, \pgfname\ checks whether the
+ remaining distance to the end of the input path is less than
+ \meta{dimension}. If so, an immediate state switch to \meta{new
+ state} occurs.
+ \end{key}
+ %
+ \begin{key}{/pgf/decoration automaton/switch if input segment less than=\\\meta{dimension}\texttt{ to }\meta{new state}}
+ When this key is encountered, \pgfname\ checks whether the
+ remaining distance to the end of the current input segment of the
+ input path is less than \meta{dimension}. If so, an immediate state
+ switch to \meta{new state} occurs.
+ \end{key}
+ %
+ \begin{key}{/pgf/decoration automaton/width=\meta{dimension}}
+ First, this option causes an immediate switch to the state |final|
+ if the remaining distance on the input path is less than
+ \meta{dimension}. The effect is the same as if you had said
+ |switch if less than=|\meta{dimension}| to final| just before the
+ |width| option.
+
+ If no switch occurs, this option tells \pgfname\ the width of the
+ segment. The current point will travel along the input path (as
+ described earlier) by this distance.
+ \end{key}
+ %
+ \begin{key}{/pgf/decoration automaton/repeat state=\meta{repetitions} (initially 0)}
+ Tells \pgfname\ how long the automaton stays ``normally'' in the
+ current state. This count is reset to \meta{repetitions} each time
+ one of the |switch if| keys causes a state switch. If no state
+ switches occur, the \meta{code} is executed and the repetition
+ counter is decreased. Then, there is once more a chance of a state
+ change caused by any of the \meta{options}. If no repetition
+ occurs, the \meta{code} is executed once more and the counter is
+ decreased once more. When the counter reaches zero, the \meta{code}
+ is executed once more, but, then, a different state is entered, as
+ specified by the |next state| option.
+
+ Note, that the maximum number of times the state will be executed
+ is $\meta{repetitions}+1$.
+ \end{key}
+ %
+ \begin{key}{/pgf/decoration automaton/next state=\meta{new state}}
+ After the \meta{code} for state has been executed for the last
+ time, a state switch to \meta{new state} is performed. If this
+ option is not given, the next state is the same as the current
+ state.
+ \end{key}
+
+ \begin{key}{/pgf/decoration automaton/if input segment is closepath=\meta{options}}
+ This key checks whether the current input segment is a closepath
+ operation. If so, the \meta{options} get executed; otherwise
+ nothing happens. You can use this option to handle a closepath in
+ some special way, for instance, switching to a new state in which
+ |\pgfpathclose| is executed.
+ \end{key}
+
+ \begin{key}{/pgf/decoration automaton/auto end on length=\meta{dimension}}
+ This key is just included for convenience, it does nothing that
+ cannot be achieved using the previous options. The effect is the
+ following: If the remaining input path's length is at most
+ \meta{dimension}, the decorated path is ended with a straight line
+ to the end of the input path and, possibly, it is closed, namely if
+ the input path ended with a closepath operation. Otherwise, it is
+ checked whether the current input segment is a closepath segment
+ and whether the remaining distance on the current input segment is
+ at most \meta{distance}. If so, then a closepath operation is used
+ to close the decorated path and the automaton continues with the
+ next subpath, remaining in the current state.
+
+ In all other cases, nothing happens.
+ \end{key}
+
+ \begin{key}{/pgf/decoration automaton/auto corner on length=\meta{dimension}}
+ This key has the following effect: Firstly, in case the \TeX-if
+ |\ifpgfdecoratepathhascorners| is false, nothing happens.
+ Otherwise, it is tested whether the remaining distance on the
+ current input segment is at most \meta{dimension}. If so, a
+ |lineto| operation is used to reach the end of this input segment
+ and the automaton continues with the next input segment, but
+ remains in the current state.
+
+ The main idea behind this option is to avoid having decoration
+ segments ``overshoot'' past a corner.
+ \end{key}
+
+ You may sometimes wish to do computations outside the transformational
+ \TeX-group of the current segment, so that these results of these
+ computations are available in the next state. For this, the following
+ two options are useful:
+
+ \begin{key}{/pgf/decoration automaton/persistent precomputation=\meta{precode}}
+ If the \meta{code} of the state is executed, the \meta{precode} is
+ executed first and it is executed outside the \TeX-group of the
+ \meta{code}. Note that when the \meta{precode} is executed, the
+ transformation matrix is not set up.
+ \end{key}
+
+ \begin{key}{/pgf/decoration automaton/persistent postcomputation=\meta{postcode}}
+ Works like the |persistent precomputation| option, only the
+ \meta{postcode} is executed after (and also outside) the \TeX-group
+ of the main \meta{code}.
+ \end{key}
+
+ There are a number of macros and dimensions which may be useful inside
+ a decoration automaton. The following macros are available:
+
+ \begin{command}{\pgfdecoratedpathlength}
+ The length of the input path. If the input path consists of several
+ input segments, this number is the sum of the lengths of the input
+ segments.
+ \end{command}
+
+ \begin{command}{\pgfdecoratedinputsegmentlength}
+ The length of the current input segment of the input path.
+ ``Current input segment'' refers to the input segment on which the
+ current point lies.
+ \end{command}
+
+ \begin{command}{\pgfpointdecoratedpathlast}
+ The final point of the input path.
+ \end{command}
+
+ \begin{command}{\pgfpointdecoratedinputsegmentlast}
+ The final point of the current input segment of the input path.
+ \end{command}
+
+ \begin{command}{\pgfdecoratedangle}
+ The angle of the tangent to the decorated path at the \emph{origin}
+ of the current segment. The transformation matrix applied at the
+ beginning of a state includes a rotation equivalent to this angle.
+ \end{command}
+
+ The following \TeX\ dimension registers are also available inside the
+ automaton:
+
+ \begin{command}{\pgfdecoratedremainingdistance}
+ The remaining distance on the input path.
+ \end{command}
+
+ \begin{command}{\pgfdecoratedcompleteddistance}
+ The completed distance on the input path.
+ \end{command}
+
+ \begin{command}{\pgfdecoratedinputsegmentremainingdistance}
+ The remaining distance on the current input segment of the input path.
+ \end{command}
+
+ \begin{command}{\pgfdecoratedinputsegmentcompleteddistance}
+ The completed distance on the current input segment of the input path.
+ \end{command}
+
+ Further keys and macros are defined and used by the decoration
+ libraries, see Section~\ref{section-library-decorations}.
+
+ The following example shows how these options can be used:
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{decorations}}]
+\pgfdeclaredecoration{complicated example decoration}{initial}
+{
+ \state{initial}[width=5pt,next state=up]
+ { \pgfpathlineto{\pgfpoint{5pt}{0pt}} }
+
+ \state{up}[width=5pt,next state=down]
+ {
+ \ifdim\pgfdecoratedremainingdistance>\pgfdecoratedcompleteddistance
+ % Growing
+ \pgfpathlineto{\pgfpoint{0pt}{\pgfdecoratedcompleteddistance}}
+ \pgfpathlineto{\pgfpoint{5pt}{\pgfdecoratedcompleteddistance}}
+ \pgfpathlineto{\pgfpoint{5pt}{0pt}}
+ \else
+ % Shrinking
+ \pgfpathlineto{\pgfpoint{0pt}{\pgfdecoratedremainingdistance}}
+ \pgfpathlineto{\pgfpoint{5pt}{\pgfdecoratedremainingdistance}}
+ \pgfpathlineto{\pgfpoint{5pt}{0pt}}
+ \fi%
+ }
+ \state{down}[width=5pt,next state=up]
+ {
+ \ifdim\pgfdecoratedremainingdistance>\pgfdecoratedcompleteddistance
+ % Growing
+ \pgfpathlineto{\pgfpoint{0pt}{-\pgfdecoratedcompleteddistance}}
+ \pgfpathlineto{\pgfpoint{5pt}{-\pgfdecoratedcompleteddistance}}
+ \pgfpathlineto{\pgfpoint{5pt}{0pt}}
+ \else
+ % Shrinking
+ \pgfpathlineto{\pgfpoint{0pt}{-\pgfdecoratedremainingdistance}}
+ \pgfpathlineto{\pgfpoint{5pt}{-\pgfdecoratedremainingdistance}}
+ \pgfpathlineto{\pgfpoint{5pt}{0pt}}
+ \fi%
+ }
+ \state{final}
+ {
+ \pgfpathlineto{\pgfpointdecoratedpathlast}
+ }
+}
+\begin{tikzpicture}[decoration=complicated example decoration]
+ \draw decorate{ (0,0) -- (3,0)};
+ \fill [red!50,rounded corners=2pt]
+ decorate {(.5,-2) -- ++(2.5,-2.5)} -- (3,-5) -| (0,-2) -- cycle;
+\end{tikzpicture}
+\end{codeexample}
+ \end{command}
+\end{command}
+
+
+\subsubsection{Predefined Decorations}
+
+The three decorations |moveto|, |lineto|, and |curveto| are predefined and
+``always available''. They are mostly useful in conjunction with
+meta-decorations. They are documented in
+Section~\ref{section-library-decorations} alongside the other decorations.
+
+
+\subsection{Using Decorations}
+
+Once a decoration has been declared, it can be used.
+
+\begin{environment}{{pgfdecoration}\marg{decoration list}}
+ The \meta{environment contents} should contain commands for creating an
+ path. This path is the basis for the \emph{input paths} for the decorations
+ in the \meta{decoration list}. In detail, the following happens:
+ %
+ \begin{enumerate}
+ \item The preexisting unused path is saved.
+ \item The path commands specified in \meta{environment contents} are
+ executed and this resulting path is saved. The path is then divided
+ into different \emph{input paths} as follows: The format for each
+ item in \marg{decoration list} is
+ %
+ \begin{quote}
+ \marg{decoration}\marg{length}\opt{\marg{before code}\marg{after code}}
+ \end{quote}
+ %
+ The \meta{before code} and the \meta{after code} are optional. The
+ input path is divided into input paths as follows: The first input
+ path consists of the first lines of the path specified in the
+ \meta{environment contents} until the \meta{length} of the first
+ element of the \meta{decoration list} is reached. If this length is
+ reached in the middle of a line, the line is broken up at this
+ exact position. Then the second input path has the \meta{length} of
+ the second element in the \meta{decoration list} and consists of
+ the lines making up the following \meta{length} part of the path in
+ the \meta{environment contents}, and so on.
+
+ If the lengths in the \meta{decoration list} do not add up to the
+ total length of the path in the \meta{environment contents}, either
+ some decorations are dropped (if their lengths add up to more than
+ the length of the \meta{environment contents}) or the input path is
+ not fully used (if their lengths add up to less).
+ \item The preexisting path is reinstalled.
+ \item The decoration automata move along the input paths, thus creating
+ (and possibly using) the output paths. These output paths extend
+ the current path (unless they are used).
+ \end{enumerate}
+
+ Some important points should be noted regarding the use of this
+ environment:
+ %
+ \begin{itemize}
+ \item If \meta{environment contents} does not begin with
+ |\pgfpathmoveto|, the last known point on the preexisting path is
+ assumed as the starting point.
+ \item All except the last of any sequence of consecutive move-to
+ commands in \meta{environment contents} are discarded.
+ \item Any move-to commands at the end of \meta{environment contents}
+ are ignored.
+ \item Any close-path commands on the input path are interpreted as
+ straight lines. Internally, something a little more complicated is
+ going on, however, a closed path on the input path has no effect on
+ the output path, other than causing the automaton to travel in a
+ straight line towards the location of the last move-to command on
+ the input path.
+ \item Although tangent computations for the input path work with the
+ last point on the preexisting path, no automatic move-to operations
+ are issued for the output path. If an output path starts with a
+ line-to or curve-to when the existing path is empty, an appropriate
+ move-to command should be inserted before the decoration starts.
+ \item If a decoration uses its own path, the first time this happens
+ the preexisting path is part of the path that is used at this
+ point.
+ \end{itemize}
+
+ Before the automata start to ``work on'' their respective inputs paths,
+ \meta{before code} is executed. After the decoration automaton has
+ finished, \meta{after code} is executed.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{decorations,decorations.pathmorphing}}]
+\begin{tikzpicture}[decoration={segment length=5pt}]
+ \draw [help lines] grid (3,2);
+ \begin{pgfdecoration}{{curveto}{1cm},{zigzag}{2cm},{curveto}{1cm}}
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathcurveto
+ {\pgfpoint{0cm}{2cm}}{\pgfpoint{3cm}{2cm}}{\pgfpoint{3cm}{0cm}}
+ \end{pgfdecoration}
+\pgfusepath{stroke}
+\end{tikzpicture}
+\end{codeexample}
+
+ When the lengths are evaluated, the dimension
+ |\pgfdecoratedremainingdistance| holds the remaining distance on the entire
+ decorated path, and |\pgfdecoratedpathlength| holds the total length of the
+ path. Thus, it is possible to specify lengths like
+ |\pgfdecoratedpathlength/3|.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{decorations,decorations.pathmorphing}}]
+\begin{tikzpicture}[decoration={segment length=5pt}]
+ \draw [help lines] grid (3,2);
+ \begin{pgfdecoration}{
+ {curveto}{\pgfdecoratedpathlength/3},
+ {zigzag}{\pgfdecoratedpathlength/3},
+ {curveto}{\pgfdecoratedremainingdistance}
+ }
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathcurveto
+ {\pgfpoint{0cm}{2cm}}{\pgfpoint{3cm}{2cm}}{\pgfpoint{3cm}{0cm}}
+ \end{pgfdecoration}
+ \pgfusepath{stroke}
+\end{tikzpicture}
+\end{codeexample}
+
+ When \meta{before code} is executed, the following macro is useful:
+ %
+ \begin{command}{\pgfpointdecoratedpathfirst}
+ Returns the point corresponding to the start of the current input path.
+ \end{command}
+ %
+ When \meta{after code} is executed, the following macro can be used:
+ %
+ \begin{command}{\pgfpointdecoratedpathlast}
+ Returns the point corresponding to the end of the current input path.
+ \end{command}
+ %
+ This means that if decorations do not use their own path, it is possible to
+ do something with them and continue from the correct place.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{decorations,decorations.pathmorphing}}]
+\begin{tikzpicture}
+ \draw [help lines] grid (3,2);
+ \begin{pgfdecoration}{
+ {curveto}{\pgfdecoratedpathlength/3}
+ {}
+ {
+ \pgfusepath{stroke}
+ },
+ {zigzag}{\pgfdecoratedpathlength/3}
+ {
+ \pgfpathmoveto{\pgfpointdecoratedpathfirst}
+ \pgfdecorationsegmentlength=5pt
+ }
+ {
+ \pgfsetstrokecolor{red}
+ \pgfusepath{stroke}
+ \pgfpathmoveto{\pgfpointdecoratedpathlast}
+ \pgfsetstrokecolor{black}
+ },
+ {curveto}{\pgfdecoratedremainingdistance}
+ }
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathcurveto
+ {\pgfpoint{0cm}{2cm}}{\pgfpoint{3cm}{2cm}}{\pgfpoint{3cm}{0cm}}
+ \end{pgfdecoration}
+ \pgfusepath{stroke}
+\end{tikzpicture}
+\end{codeexample}
+
+ After the |{decoration}| environment has finished, the following macros are
+ available:
+
+ \begin{command}{\pgfdecorateexistingpath}
+ The preexisting path before the environment was entered.
+ \end{command}
+
+ \begin{command}{\pgfdecoratedpath}
+ The (total) input path (that is, the path created by the environment
+ contents).
+ \end{command}
+
+ \begin{command}{\pgfdecorationpath}
+ The output path. If the path is used, this macro contains only the last
+ unused part of the output path.
+ \end{command}
+
+ \begin{command}{\pgfpointdecoratedpathlast}
+ The final point of the input path.
+ \end{command}
+
+ \begin{command}{\pgfpointdecorationpathlast}
+ The final point of the output path.
+ \end{command}
+
+ The following style is executed each time a decoration is used. You may use
+ it to set up default options for decorations.
+ %
+ \begin{stylekey}{/pgf/every decoration (initially \normalfont empty)}
+ This style is executed for every decoration.
+ \end{stylekey}
+\end{environment}
+
+\begin{plainenvironment}{{pgfdecoration}\marg{name}}
+ The plain-\TeX{} version of the |{pgfdecorate}| environment.
+ \todosp{`pgfdecorate' right or `pgfdecoration'? really no idea}
+\end{plainenvironment}
+
+\begin{contextenvironment}{{pgfdecoration}\marg{name}}
+ The Con\TeX t version of the |{pgfdecoration}| environment.
+\end{contextenvironment}
+
+For convenience, the following macros provide a ``shorthand'' for decorations
+(internally, they all use the |{pgfdecoration}| environment).
+
+\begin{command}{\pgfdecoratepath\marg{name}\marg{path commands}}
+ Decorate the path described by \meta{path commands} with the decoration
+ \meta{name}. This is equivalent to
+ %
+\begin{codeexample}[code only]
+\pgfdecorate{{name}{\pgfdecoratedpathlength}
+ {\pgfdecoratebeforecode}{\pgfdecorateaftercode}}
+ // the path commands.
+\endpgfdecorate
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfdecoratecurrentpath\marg{name}}
+ Decorate the preexisting path with the decoration \meta{name}.
+\end{command}
+
+Both the above commands use the current definitions of the following macros:
+
+\begin{command}{\pgfdecoratebeforecode}
+ Code executed as \meta{before code}, see the description of |\pgfdecorate|.
+\end{command}
+
+\begin{command}{\pgfdecorateaftercode}
+ Code executed as \meta{after code}, see the description of |\pgfdecorate|.
+\end{command}
+
+It may sometimes be useful to add an additional transformation for each segment
+of a decoration. The following command allows you to define such a ``last
+minute transformation''.
+
+\begin{command}{\pgfsetdecorationsegmenttransformation\marg{code}}
+ The \meta{code} will be executed at the very beginning of each segment.
+ Note when applying multiple decorations, this will be reset between
+ decorations, so it needs to be specified for each segment.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{decorations,decorations.pathmorphing}}]
+\begin{tikzpicture}
+ \draw [help lines] grid (3,2);
+ \begin{pgfdecoration}{
+ {curveto}{\pgfdecoratedpathlength/3},
+ {zigzag}{\pgfdecoratedpathlength/3}
+ {
+ \pgfdecorationsegmentlength=5pt
+ \pgfsetdecorationsegmenttransformation{\pgftransformyshift{.5cm}}
+ },
+ {curveto}{\pgfdecoratedremainingdistance}
+ }
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathcurveto
+ {\pgfpoint{0cm}{2cm}}{\pgfpoint{3cm}{2cm}}{\pgfpoint{3cm}{0cm}}
+ \end{pgfdecoration}
+ \pgfusepath{stroke}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+
+\subsection{Meta-Decorations}
+\label{section-base-meta-decorations}
+
+A meta-decoration provides an alternative way to decorate a path with multiple
+decorations. It is, in essence, an automaton that decorates an input path with
+decoration automatons. In general, however, the end effect is still that a path
+is decorated with other paths, and the input path should be thought of as being
+divided into sub-input-paths, each with their own decoration. Like ordinary
+decorations, a meta-decoration must be declared before it can be used.
+
+
+\subsubsection{Declaring Meta-Decorations}
+
+\begin{command}{\pgfdeclaremetadecorate\marg{name}\marg{initial state}\marg{states}}
+ This command declares a new meta-decoration called \meta{name}. The
+ \meta{states} argument contains a description of the meta-decoration
+ automaton's states and the transitions between them. The \meta{initial
+ state} is the state in which the automaton starts.
+
+ The |\state| command is similar to the one found in decoration
+ declarations, and takes the same form:
+
+ \begin{command}{\state\marg{name}\oarg{options}\marg{code}} Declares the
+ state \meta{name} inside the current meta-decoration automaton. Unlike
+ decorations, states in meta-decorations are not executed within a
+ group, which makes the persistent computation options superfluous.
+ Consider using an initial state with |width=0pt| to do precalculations
+ that could speed the execution of the meta-decoration.
+
+ The \meta{options} are executed with the key path set to
+ |/pgf/meta-decorations automaton/|, and the following keys are defined
+ for this path:
+
+ \begin{key}{/pgf/meta-decoration automaton/switch if less than=\meta{dimension}| to |\meta{new state}}
+ This causes \pgfname\ to check whether the remaining distance to
+ the end of the input path is less than \meta{dimension}, and, if
+ so, to immediately switch to the state \meta{new state}. When this
+ key is evaluated, the macro |\pgfmetadecoratedpathlength| will be
+ defined as the total length of the decoration path, allowing for
+ values such as |\pgfmetadecoratedpathlength/8|.
+ \end{key}
+
+ \begin{key}{/pgf/meta-decoration automaton/width=\meta{dimension}}
+ As always, this option will cause an immediate switch to the state
+ |final| if the remaining distance on the input path is less than
+ \meta{dimension}.
+
+ Otherwise, this option tells \pgfname\ the width of the
+ ``meta-segment'', that is, the length of the sub-input-path which
+ the decoration automaton specified in \meta{code} will decorate.
+ \end{key}
+
+ \begin{key}{/pgf/meta-decoration automaton/next state=\meta{new state}}
+ After the code for a state has been executed, a state switch to
+ \meta{new state} is performed. If this option is not given, the
+ next state is the same as the current state.
+ \end{key}
+
+ The code in \meta{code} is quite different from the code in a
+ decoration state. In almost all cases only the following three macros
+ will be required:
+
+ \begin{command}{\decoration\marg{name}}
+ This sets the decoration for the current state to \meta{name}. If
+ this command is omitted, the |moveto| decoration will be used.
+ \end{command}
+
+ \begin{command}{\beforedecoration\marg{before code}}
+ Defines \meta{before code} as (typically) \pgfname{} commands to be
+ executed before the decoration is applied to the current segment.
+ This command can be omitted. If you wish to set up some decoration
+ specific parameters such as segment length, or segment amplitude,
+ then they can be set in \meta{before code}.
+ \end{command}
+
+ \begin{command}{\afterdecoration\marg{after code}}
+ Defines \meta{after code} as commands to be executed after the
+ decoration has been applied to the current segment. This command
+ can be omitted.
+ \end{command}
+
+ There are some macros that may be useful when creating meta-decorations
+ (note that they are all macros):
+
+ \begin{command}{\pgfpointmetadecoratedpathfirst}
+ When the \meta{before code} is executed, this macro stores the
+ first point on the current sub-input-path.
+ \end{command}
+
+ \begin{command}{\pgfpointmetadecoratedpathlast}
+ When the \meta{after code} is executed, this macro stores the last
+ point on the current sub-input-path.
+ \end{command}
+
+ \begin{command}{\pgfmetadecoratedpathlength}
+ The entire length of the entire input path.
+ \end{command}
+
+ \begin{command}{\pgfmetadecoratedcompleteddistance}
+ The completed distance on the entire input path.
+ \end{command}
+
+ \begin{command}{\pgfmetadecoratedremainingdistance}
+ The remaining distance on the entire input path.
+ \end{command}
+
+ \begin{command}{\pgfmetadecoratedinputsegmentcompleteddistance}
+ The completed distance on the current input segment of the entire
+ input path.
+ \end{command}
+
+ \begin{command}{\pgfmetadecoratedinputsegmentremainingdistance}
+ The remaining distance on the current input segment of the entire
+ input path.
+ \end{command}
+ \end{command}
+
+ Here is a complete example of a meta-decoration:
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{decorations,decorations.pathmorphing}}]
+\pgfdeclaremetadecoration{arrows}{initial}{
+ \state{initial}[width=0pt, next state=arrow]
+ {
+ \pgfmathdivide{100}{\pgfmetadecoratedpathlength}
+ \let\factor\pgfmathresult
+ \pgfsetlinewidth{1pt}
+ \pgfset{/pgf/decoration/segment length=4pt}
+ }
+ \state{arrow}[
+ switch if less than=\pgfmetadecorationsegmentlength to final,
+ width=\pgfmetadecorationsegmentlength/3,
+ next state=zigzag]
+ {
+ \decoration{curveto}
+ \beforedecoration
+ {
+ \pgfmathparse{\pgfmetadecoratedcompleteddistance*\factor}
+ \pgfsetcolor{red!\pgfmathresult!yellow}
+ \pgfpathmoveto{\pgfpointmetadecoratedpathfirst}
+ }
+ }
+ \state{zigzag}[width=\pgfmetadecorationsegmentlength/3, next state=end arrow]
+ {
+ \decoration{zigzag}
+ }
+ \state{end arrow}[width=\pgfmetadecorationsegmentlength/3, next state=move]
+ {
+ \decoration{curveto}
+ \beforedecoration{\pgfpathmoveto{\pgfpointmetadecoratedpathfirst}}
+ \afterdecoration
+ {
+ \pgfsetarrowsend{to}
+ \pgfusepath{stroke}
+ }
+ }
+ \state{move}[width=\pgfmetadecorationsegmentlength/2, next state=arrow]{}
+ \state{final}{}
+}
+
+\tikz\draw[decorate,decoration={arrows,meta-segment length=2cm}]
+ (0,0) .. controls (0,2) and (3,2) .. (3,0)
+ .. controls (3,-2) and (0,-2) .. (0,-4)
+ .. controls (0,-6) and (3,-6) .. (3,-8)
+ .. controls (3,-10) and (0,-10) .. (0,-8);
+\end{codeexample}
+ %
+\end{command}
+
+
+\subsubsection{Predefined Meta-decorations}
+
+There are no predefined meta-decorations loaded with \pgfname{}.
+
+
+\subsubsection{Using Meta-Decorations}
+
+Using meta-decorations is ``simpler'' than using decorations, because you can
+only use one meta-decoration per path.
+
+\begin{environment}{{pgfmetadecoration}\marg{name}}
+ This environment decorates the input path described in \meta{environment
+ contents}, with the meta-decoration \meta{name}.
+\end{environment}
+
+\begin{plainenvironment}{{pgfmetadecoration}\marg{name}}
+ The plain \TeX{} version of the |{pgfmetadecoration}| environment.
+\end{plainenvironment}
+
+\begin{contextenvironment}{{pgfmetadecoration}\marg{name}}
+ The Con\TeX t version of the |{pgfmetadecoration}| environment.
+\end{contextenvironment}
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-decorations.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-design.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-design.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-design.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,146 @@
+% Copyright 2018 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section{Design Principles}
+
+This section describes the basic layer of \pgfname. This layer is built on top
+of the system layer. Whereas the system layer just provides the absolute
+minimum for drawing graphics, the basic layer provides numerous commands that
+make it possible to create sophisticated graphics easily and also quickly.
+
+The basic layer does not provide a convenient syntax for describing graphics,
+which is left to frontends like \tikzname. For this reason, the basic layer is
+typically used only by ``other programs''. For example, the \textsc{beamer}
+package uses the basic layer extensively, but does not need a convenient input
+syntax. Rather, speed and flexibility are needed when \textsc{beamer} creates
+graphics.
+
+The following basic design principles underlie the basic layer:
+%
+\begin{enumerate}
+ \item Structuring into a core and modules.
+ \item Consistently named \TeX\ macros for all graphics commands.
+ \item Path-centered description of graphics.
+ \item Coordinate transformation system.
+\end{enumerate}
+
+
+\subsection{Core and Modules}
+
+The basic layer consists of a \emph{core package}, called |pgfcore|, which
+provides the most basic commands, and several \emph{modules} like commands for
+plotting (in the |plot| module). Modules are loaded using the |\usepgfmodule|
+command.
+
+If you say |\usepackage{pgf}| or |\input pgf.tex| or |\usemodule[pgf]|, the
+|plot| and |shapes| modules are preloaded (as well as the core and the system
+layer).
+
+
+\subsection{Communicating with the Basic Layer via Macros}
+
+In order to ``communicate'' with the basic layer you use long sequences of
+commands that start with |\pgf|. You are only allowed to give these commands
+inside a |{pgfpicture}| environment. (Note that |{tikzpicture}| opens a
+|{pgfpicture}| internally, so you can freely mix \pgfname\ commands and
+\tikzname\ commands inside a |{tikzpicture}|.) It is possible to ``do other
+things'' between the commands. For example, you might use one command to move
+to a certain point, then have a complicated computation of the next point, and
+then move there.
+%
+\begin{codeexample}[]
+\newdimen\myypos
+\begin{pgfpicture}
+ \pgfpathmoveto{\pgfpoint{0cm}{\myypos}}
+ \pgfpathlineto{\pgfpoint{1cm}{\myypos}}
+ \advance \myypos by 1cm
+ \pgfpathlineto{\pgfpoint{1cm}{\myypos}}
+ \pgfpathclose
+ \pgfusepath{stroke}
+\end{pgfpicture}
+\end{codeexample}
+
+The following naming conventions are used in the basic layer:
+%
+\begin{enumerate}
+ \item All commands and environments start with |pgf|.
+ \item All commands that specify a point (a coordinate) start with
+ |\pgfpoint|.
+ \item All commands that extend the current path start with |\pgfpath|.
+ \item All commands that set/change a graphics parameter start with
+ |\pgfset|.
+ \item All commands that use a previously declared object (like a path,
+ image or shading) start with |\pgfuse|.
+ \item All commands having to do with coordinate transformations start with
+ |\pgftransform|.
+ \item All commands having to do with arrow tips start with |\pgfarrows|.
+ \item All commands for ``quickly'' extending or drawing a path start with
+ |\pgfpathq| or |\pgfusepathq|.
+ \item All commands having to do with matrices start with |\pgfmatrix|.
+\end{enumerate}
+
+
+\subsection{Path-Centered Approach}
+
+In \pgfname\ the most important entity is the \emph{path}. All graphics are
+composed of numerous paths that can be stroked, filled, shaded, or clipped
+against. Paths can be closed or open, they can self-intersect and consist of
+unconnected parts.
+
+Paths are first \emph{constructed} and then \emph{used}. In order to construct
+a path, you can use commands starting with |\pgfpath|. Each time such a command
+is called, the current path is extended in some way.
+
+Once a path has been completely constructed, you can use it using the command
+|\pgfusepath|. Depending on the parameters given to this command, the path will
+be stroked (drawn) or filled or subsequent drawings will be clipped against
+this path.
+
+
+\subsection{Coordinate Versus Canvas Transformations}
+\label{section-design-transformations}
+
+\pgfname\ provides two transformation systems: \pgfname's own \emph{coordinate}
+transformation matrix and \pdf's or PostScript's \emph{canvas} transformation
+matrix. These two systems are quite different. Whereas a scaling by a factor
+of, say, $2$ of the canvas causes \emph{everything} to be scaled by this factor
+(including the thickness of lines and text), a scaling of two in the coordinate
+system causes only the \emph{coordinates} to be scaled, but not the line width
+nor text.
+
+By default, all transformations only apply to the coordinate transformation
+system. However, using the command |\pgflowlevel| it is possible to apply a
+transformation to the canvas.
+
+Coordinate transformations are often preferable over canvas transformations.
+Text and lines that are transformed using canvas transformations suffer from
+differing sizes and lines whose thickness differs depending on whether the line
+is horizontal or vertical. To appreciate the difference, consider the following
+two ``circles'' both of which have been scaled in the $x$-direction by a factor
+of $3$ and by a factor of $0.5$ in the $y$-direction. The left circle uses a
+canvas transformation, the right uses \pgfname's coordinate transformation
+(some viewers will render the left graphic incorrectly since they do no apply
+the low-level transformation the way they should):
+
+\begin{tikzpicture}[line width=5pt]
+ \useasboundingbox (-1.75,-1) rectangle (14,1);
+
+ \begin{scope}
+ \pgflowlevel{\pgftransformxscale{3}}
+ \pgflowlevel{\pgftransformyscale{.5}}
+
+ \draw (0,0) circle (0.5cm);
+ \draw (.55cm,0pt) node[right] {canvas};
+ \end{scope}
+ \begin{scope}[xshift=9cm,xscale=3,yscale=.5]
+ \draw (0,0) circle (0.5cm);
+ \draw (.55cm,0pt) node[right] {coordinate};
+ \end{scope}
+\end{tikzpicture}
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-design.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-external.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-external.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-external.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,502 @@
+% Copyright 2019 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section{Externalizing Graphics}
+\label{section-external}
+
+\subsection{Overview}
+
+There are two fundamentally different ways of inserting graphics into a
+\TeX-document. First, you can create a graphic using some external program like
+|xfig| or |InDesign| and then include this graphic in your text. This is done
+using commands like |\includegraphics| or |\pgfimage|. In this case, the
+graphic file contains all the low-level graphic commands that describe the
+picture. When such a file is included, all \TeX\ has to worry about is the size
+of the picture; the internals of the picture are unknown to \TeX\ and it does
+not care about them.
+
+The second method of creating graphics is to use a special package that
+transforms \TeX-commands like |\draw| or |\psline| into appropriate low-level
+graphic commands. In this case, \TeX\ has to do all the hard work of
+``typesetting'' the picture and if a picture has a complicated internal
+structure this may take a lot of time.
+
+While \pgfname\ was created to facilitate the second method of creating
+pictures, there are two main reasons why you may need to employ the first
+method of image-inclusion, nevertheless:
+%
+\begin{enumerate}
+ \item Typesetting a picture using \TeX\ can be a very time-consuming
+ process. If \TeX\ needs a minute to typeset a picture, you do not want
+ to wait this minute when you re\TeX\ your document after having changed
+ a single comma.
+ \item Some users, especially journal editors, may not be able to process
+ files that contain \pgfname\ commands -- for the simple reason that the
+ systems of many publishing houses do not have \pgfname\ installed.
+\end{enumerate}
+
+In both cases, the solution is to ``extract'' or ``externalize'' pictures that
+would normally be typeset every time a document is \TeX ed. Once the pictures
+have been extracted into separate graphics files, these graphic files can be
+reinserted into the text using the first method.
+
+Extracting a graphic from a file is not as easy as it may sound at first since
+\TeX\ cannot write parts of its output into different files and a bit of
+trickery is needed. The following macros simplify the workflow:
+%
+\begin{enumerate}
+ \item You have to tell \pgfname\ which files will be used for which
+ pictures. To do so, you enclose each picture that you wish to be
+ ``externalized'' in a pair of |\beginpgfgraphicnamed| and
+ |\endpgfgraphicnamed| macros.
+ \item The next step is to generate the extracted graphics. For this you run
+ \TeX\ with the |\jobname| set to the graphic file's name. This will
+ cause |\pgfname| to behave in a very special way: All of your document
+ will simply be thrown away, \emph{except} for the single graphic having
+ the same name as the current jobname.
+ \item After you have run \TeX\ once for each graphic that your wish to
+ externalize, you can rerun \TeX\ on your document normally. This will
+ have the following effect: Each time a |\beginpgfgraphicnamed| is
+ encountered, \pgfname\ checks whether a graphic file of the given name
+ exists (if you did step 2, it will). If this graphic file exists, it
+ will be input and the text till the corresponding |\endpgfgraphicnamed|
+ will be ignored.
+\end{enumerate}
+
+In the rest of this section, the above workflow is explained in more detail.
+
+
+\subsection{Workflow Step 1: Naming Graphics}
+
+In order to put each graphic in an external file, you first need to tell
+\pgfname\ the names of these files.
+
+\begin{command}{\beginpgfgraphicnamed\marg{file name prefix}}
+ This command indicates that everything up to the next call of
+ |\endpgfgraphicnamed| is part of a graphic that should be placed in a file
+ named \meta{file name prefix}|.|\meta{suffix}, where the \meta{suffix}
+ depends on your backend driver. Typically, \meta{suffix} will be |dvi| or
+ |pdf|.
+
+ Here is a typical example of how this command is used:
+ %
+\begin{codeexample}[code only]
+% In file main.tex:
+...
+As we see in Figure~\ref{fig1}, the world is flat.
+\begin{figure}
+ \beginpgfgraphicnamed{graphic-of-flat-world}
+ \begin{tikzpicture}
+ \fill (0,0) circle (1cm);
+ \end{tikzpicture}
+ \endpgfgraphicnamed
+ \caption{The flat world.}
+ \label{fig1}
+\end{figure}
+\end{codeexample}
+
+ Each graphic to be externalized should have a unique name. Note that this
+ name will be used as the name of a file in the file system, so it should
+ not contain any funny characters.
+
+ This command can have three different effects:
+ %
+ \begin{enumerate}
+ \item The easiest situation arises if there does not yet exist a
+ graphic file called \meta{file name prefix}|.|\meta{suffix}, where
+ the \meta{suffix} is one of the suffixes understood by your current
+ backend driver (so |pdf| or |jpg| if you use |pdftex|, |eps| if you
+ use |dvips|, and so on). In this case, both this command and the
+ |\endpgfgraphicnamed| command simply have no effect.
+ \item A more complex situation arises when a graphic file named
+ \meta{file name prefix}|.|\meta{suffix} \emph{does} exist. In this
+ case, this graphic file is included using the |\includegraphics|
+ command%
+ %
+ \footnote{Actually, the command key \texttt{/pgf/images/include
+ external} is invoked which calls an appropriate
+ \texttt{\textbackslash includegraphics} command.}.
+ %
+ Furthermore, the text between |\beginpgfgraphicnamed| and
+ |\endpgfgraphicnamed| is ignored.
+
+ When the text is ``ignored'', what actually happens is that all
+ text up to the next occurrence of |\endpgfgraphicnamed| is thrown
+ away without any macro expansion. This means, in particular, that
+ (a) you cannot put |\endpgfgraphicnamed| inside a macro and (b) the
+ macros used in the graphics need not be defined at all when the
+ graphic file is included. \item The most complex behavior arises
+ when current the |\jobname| equals the \meta{file name prefix} and,
+ furthermore, the \emph{real job name} has been declared. The
+ behavior for this case is explained later.
+ \end{enumerate}
+
+ Note that the |\beginpgfgraphicnamed| does not really have any effect until
+ you have generated the graphic files named. Till then, this command is
+ simply ignored. Also, if you delete the graphics file later on, the
+ graphics are typeset normally once more.
+\end{command}
+
+\begin{command}{\endpgfgraphicnamed}
+ This command just marks the end of the graphic that should be externalized.
+\end{command}
+
+
+\subsection{Workflow Step 2: Generating the External Graphics}
+
+We have now indicated all the graphics for which we would like graphic files to
+be generated. In order to generate the files, you now need to modify the
+|\jobname| appropriately. This is done in two steps:
+%
+\begin{enumerate}
+ \item You use the following command to tell \pgfname\ the real name of your
+ |.tex| file:
+ %
+ \begin{command}{\pgfrealjobname\marg{name}}
+ Tells \pgfname\ the real name of your job. For instance, if you
+ have a file called |survey.tex| that contains two graphics that you
+ wish to be called |survey-graphic1| and |survey-graphic2|, then you
+ should write the following.
+ %
+\begin{codeexample}[code only]
+% This is file survey.tex
+\documentclass{article}
+...
+\usepackage{tikz}
+\pgfrealjobname{survey}
+\end{codeexample}
+ \end{command}
+ \item You run \TeX\ with the |\jobname| set to the name of the graphic for
+ which you need an external graphic to be generated. To set the
+ |\jobname|, you use the |--jobname=| option of \TeX:
+ %
+\begin{codeexample}[code only, tikz syntax=false]
+bash> latex --jobname=survey-graphic1 survey.tex
+\end{codeexample}
+ %
+\end{enumerate}
+
+The following things will now happen:
+%
+\begin{enumerate}
+ \item |\pgfrealjobname| notices that the |\jobname| is not the ``real''
+ jobname and, thus, must be the name of a graphic that is to be put in
+ an external file.
+ \item At the beginning of the document, \pgfname\ changes the definition of
+ \TeX's internal |\shipout| macro. The new shipout macro simply throws
+ away the output. This means that the document is typeset normally, but
+ no output is produced.
+ \item When the |\beginpgfgraphicnamed{|\meta{name}|}| command is
+ encountered where the \meta{name} is the same as the current
+ |\jobname|, then a \TeX-box is started and \meta{everything} up to the
+ following |\endpgfgraphicnamed| command is stored inside this box.
+
+ Note that, typically, \meta{everything} will contain just a single
+ |{tikzpicture}| or |{pgfpicture}| environment. However, this need not
+ be the case, you can use, say, a |{pspicture}| environment as
+ \meta{everything} or even just some normal \TeX-text.
+ \item At the |\endpgfgraphicnamed|, the box \emph{is} shipped out using the
+ original |\shipout| command. Thus, unlike everything else, the contents
+ of the graphic is made part of the output.
+ \item When the box containing the graphic is shipped out, the paper size is
+ modified such that it is exactly equal to the height and width of the
+ box.
+\end{enumerate}
+
+The net effect of everything described above is that the two commands
+%
+\begin{codeexample}[code only, tikz syntax=false]
+bash> latex --jobname=survey-graphic1 survey.tex
+bash> dvips survey-graphic1
+\end{codeexample}
+%
+\noindent produce a file called |survey-graphic1.ps| that consists of a single
+page that contains exactly the graphic produced by the code between
+|\beginpgfgraphicnamed{survey-graphic1}| and |\endpgfgraphicnamed|.
+Furthermore, the size of this single page is exactly the size of the graphic.
+
+If you use pdf\TeX, producing the graphic is even simpler:
+%
+\begin{codeexample}[code only, tikz syntax=false]
+bash> pdflatex --jobname=survey-graphic1 survey.tex
+\end{codeexample}
+%
+\noindent produces the single-page |pdf|-file |survey-graphic1.pdf|.
+
+
+\subsection{Workflow Step 3: Including the External Graphics}
+
+Once you have produced all the pictures in the text, including them into the
+main document is easy: Simply run \TeX\ again without any modification of the
+|\jobname|. In this case the |\pgfrealjobname| command will notice that the
+main file is, indeed, the main file. The main file will then be typeset
+normally and the |\beginpgfgraphicnamed| commands also behave normally, which
+means that they will try to include the generated graphic files -- which is
+exactly what you want.
+
+Suppose that you wish to send your survey to a journal that does not have
+\pgfname\ installed. In this case, you now have all the necessary external
+graphics, but you still need \pgfname\ to automatically include them instead of
+the executing the picture code! One way to solve this problem is to simply
+delete all of the \pgfname\ or \tikzname\ code from your |survey.tex| and
+instead insert appropriate |\includegraphics| commands ``by hand''. However,
+there is a better way: You input the file |pgfexternal.tex|.
+
+\begin{filedescription}{pgfexternal.tex}
+ This file defines the command |\beginpgfgraphicnamed| and causes it to have
+ the following effect: It includes the graphic file given as a parameter to
+ it and then gobbles everything up to |\endpgfgraphicnamed|.
+
+ Since |\beginpgfgraphicnamed| does not do macro expansion as it searches
+ for |\endpgfgraphicnamed|, it is not necessary to actually include the
+ packages necessary for \emph{creating} the graphics. So the idea is that
+ you comment out things like |\usepackage{tikz}| and instead say
+ |\input pgfexternal.tex|.
+
+ Indeed, the contents of this file is simply the following line:
+ %
+\begin{codeexample}[code only]
+\long\def\beginpgfgraphicnamed#1#2\endpgfgraphicnamed{\includegraphics{#1}}
+\end{codeexample}
+
+ Instead of |\input pgfexternal.tex| you could also include this line in
+ your main file.
+\end{filedescription}
+
+As a final remark, note that the |baseline| option does not work directly with
+pictures written to an external graphic file. The simple reason is that there
+is no way to store this baseline information in an external graphic file. To
+allow the |baseline| option (or any \TeX\ construction with non-zero depth),
+the baseline information is stored into a separate file. This file is named
+\marg{image file}|.dpth| and contains something like |5pt|.
+
+So, if you need baseline information, you will have to keep the external
+graphic file together with its~|.dpth| file. Furthermore, the short command in
+|\input pgfexternal.tex| is no longer enough because it ignores any baseline
+information. You will need to use |\input pgfexternalwithdepth.tex| instead (it
+is shown below). It is slightly longer, but it can be used in the same way as
+|pgfexternal.tex|.
+
+\begin{key}{/pgf/images/include external (initially \textbackslash pgfimage\{\#1\})}
+\label{pgf:includeexternalkey}
+\index{External Graphics!Bounding Box Issues}
+ This key constitutes the public interface to exchange the
+ |\includegraphics| command used for the image inclusion.
+
+ Redefining this key allows to provide bounding box or viewport options:
+ %
+\begin{codeexample}[code only]
+\pgfkeys{/pgf/images/include external/.code={\includegraphics[viewport=0 0 211.28 175.686]{#1}}}
+\end{codeexample}
+ %
+ Do not forget the |.code| here which redefines the command.
+
+ One application could be image externalization and bounding box
+ restrictions: As far as I know, a |.pdf| graphics with restricted bounding
+ box is always cropped (which is not always desired). One solution could be
+ to use |latex| and |dvips| which doesn't have this restriction. Another is
+ to manually provide the |viewport| option as shown above.
+
+ A possible value for |viewport| can be found in the |.pdf| image, search
+ for |/MediaBox = [ ... ]|.
+\end{key}
+
+
+\subsection{A Complete Example}
+
+Let us now have a look at a simple, but complete example. We start out with a
+normal file called |survey.tex| that has the following contents:
+%
+\begin{codeexample}[code only]
+% This is the file survey.tex
+\documentclass{article}
+
+\usepackage{graphics}
+\usepackage{tikz}
+
+\begin{document}
+In the following figure, we see a circle:
+\begin{tikzpicture}
+ \fill (0,0) circle (10pt);
+\end{tikzpicture}
+
+By comparison, in this figure we see a rectangle:
+\begin{tikzpicture}
+ \fill (0,0) rectangle (10pt,10pt);
+\end{tikzpicture}
+\end{document}
+\end{codeexample}
+
+Now our editor tells us that the publisher will need all figures to be provided
+in separate PostScript or |.pdf|-files. For this, we enclose all figures in
+|...graphicnamed|-pairs and we add a call to the |\pgfrealjobname| macro:
+%
+\begin{codeexample}[code only]
+% This is the file survey.tex
+\documentclass{article}
+
+\usepackage{graphics}
+\usepackage{tikz}
+\pgfrealjobname{survey}
+
+\begin{document}
+In the following figure, we see a circle:
+\beginpgfgraphicnamed{survey-f1}
+\begin{tikzpicture}
+ \fill (0,0) circle (10pt);
+\end{tikzpicture}
+\endpgfgraphicnamed
+
+By comparison, in this figure we see a rectangle:
+\beginpgfgraphicnamed{survey-f2}
+\begin{tikzpicture}
+ \fill (0,0) rectangle (10pt,10pt);
+\end{tikzpicture}
+\endpgfgraphicnamed
+\end{document}
+\end{codeexample}
+
+After these changes, typesetting the file will still yield the same output as
+it did before -- after all, we have not yet created any external graphics.
+
+To create the external graphics, we run |pdflatex| twice, once for each
+graphic:
+%
+\begin{codeexample}[code only, tikz syntax=false]
+bash> pdflatex --jobname=survey-f1 survey.tex
+This is pdfTeX, Version 3.141592-1.40.3 (Web2C 7.5.6)
+entering extended mode
+(./survey.tex
+LaTeX2e <2005/12/01>
+...
+) [1] (./survey-f1.aux) )
+Output written on survey-f1.pdf (1 page, 1016 bytes).
+Transcript written on survey-f1.log.
+\end{codeexample}
+
+\begin{codeexample}[code only, tikz syntax=false]
+bash> pdflatex --jobname=survey-f2 survey.tex
+This is pdfTeX, Version 3.141592-1.40.3 (Web2C 7.5.6)
+entering extended mode
+(./survey.tex
+LaTeX2e <2005/12/01>
+...
+(./survey-f2.aux) )
+Output written on survey-f2.pdf (1 page, 1002 bytes).
+Transcript written on survey-f2.log.
+\end{codeexample}
+
+We can now send the two generated graphics (|survey-f1.pdf| and
+|survey-f2.pdf|) to the editor. However, the publisher cannot use our
+|survey.tex| file, yet. The reason is that it contains the command
+|\usepackage{tikz}| and they do not have \pgfname\ installed.
+
+Thus, we modify the main file |survey.tex| as follows:
+%
+\begin{codeexample}[code only]
+% This is the file survey.tex
+\documentclass{article}
+
+\usepackage{graphics}
+\input pgfexternal.tex
+% \usepackage{tikz}
+% \pgfrealjobname{survey}
+
+\begin{document}
+In the following figure, we see a circle:
+\beginpgfgraphicnamed{survey-f1}
+\begin{tikzpicture}
+ \fill (0,0) circle (10pt);
+\end{tikzpicture}
+\endpgfgraphicnamed
+
+By comparison, in this figure we see a rectangle:
+\beginpgfgraphicnamed{survey-f2}
+\begin{tikzpicture}
+ \fill (0,0) rectangle (10pt,10pt);
+\end{tikzpicture}
+\endpgfgraphicnamed
+\end{document}
+\end{codeexample}
+%
+If we now run pdf\LaTeX, then, indeed, \pgfname\ is no longer needed:
+% In the following, we switch off typesetting of listings because the
+% parentheses confuse the pretty printer
+%
+\begin{codeexample}[code only,typeset listing/.code=#1]
+bash> pdflatex survey.tex
+This is pdfTeX, Version 3.141592-1.40.3 (Web2C 7.5.6)
+entering extended mode
+(./survey.tex
+LaTeX2e <2005/12/01>
+Babel <v3.8h> and hyphenation patterns for english, ..., loaded.
+(/usr/local/gwTeX/texmf.texlive/tex/latex/base/article.cls
+Document Class: article 2005/09/16 v1.4f Standard LaTeX document class
+(/usr/local/gwTeX/texmf.texlive/tex/latex/base/size10.clo))
+(/usr/local/gwTeX/texmf.texlive/tex/latex/graphics/graphics.sty
+(/usr/local/gwTeX/texmf.texlive/tex/latex/graphics/trig.sty)
+(/usr/local/gwTeX/texmf.texlive/tex/latex/config/graphics.cfg)
+(/usr/local/gwTeX/texmf.texlive/tex/latex/pdftex-def/pdftex.def))
+(/Users/tantau/Library/texmf/tex/generic/pgf/generic/pgf/utilities/pgfexternal.
+tex) (./survey.aux)
+(/usr/local/gwTeX/texmf.texlive/tex/context/base/supp-pdf.tex
+[Loading MPS to PDF converter (version 2006.09.02).]
+) <survey-f1.pdf, id=1, 23.33318pt x 19.99973pt> <use survey-f1.pdf>
+<survey-f2.pdf, id=2, 13.33382pt x 10.00037pt> <use survey-f2.pdf> [1{/Users/ta
+ntau/Library/texmf/fonts/map/pdftex/updmap/pdftex.map} <./survey-f1.pdf> <./sur
+vey-f2.pdf>] (./survey.aux) )</usr/local/gwTeX/texmf.texlive/fonts/type1/bluesk
+y/cm/cmr10.pfb>
+Output written on survey.pdf (1 page, 10006 bytes).
+Transcript written on survey.log.
+\end{codeexample}
+
+To our editor, we send the following files:
+%
+\begin{itemize}
+ \item The last |survey.tex| shown above.
+ \item The graphic file |survey-f1.pdf|.
+ \item The graphic file |survey-f2.pdf|.
+ \item The file |pgfexternal.tex|, whose contents is simply
+ %
+\begin{codeexample}[code only]
+\long\def\beginpgfgraphicnamed#1#2\endpgfgraphicnamed{\includegraphics{#1}}
+\end{codeexample}
+ %
+ (Alternatively, we can also directly add this line to our |survey.tex|
+ file).
+\end{itemize}
+%
+In case we have used the |baseline| option, we also need to include any |.dpth|
+files and we need to use the file |pgfexternalwithdepth.tex| instead of
+|pgfexternal.tex|. This file also checks for the existence of |.dpth| files
+containing baseline information, its contents is
+%
+\begin{codeexample}[code only]
+\long\def\beginpgfgraphicnamed#1#2\endpgfgraphicnamed{%
+ \begingroup
+ \setbox1=\hbox{\includegraphics{#1}}%
+ \openin1=#1.dpth
+ \ifeof1 \box1
+ \else
+ \read1 to\pgfincludeexternalgraphicsdp\closein1
+ \dimen0=\pgfincludeexternalgraphicsdp\relax
+ \hbox{\lower\dimen0 \box1 }%
+ \fi
+ \endgroup
+}
+\end{codeexample}
+%
+Again, we could simply copy these lines to our |survey.tex| file.
+
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "pgfmanual"
+%%% End:
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-external.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-images.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-images.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-images.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,274 @@
+% Copyright 2019 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section{Declaring and Using Images}
+\label{section-images}
+
+This section describes the commands for creating images.
+
+
+\subsection{Overview}
+
+To be quite frank, \LaTeX's |\includegraphics| is designed better than
+\pgfname's image mechanism. For this reason, \emph{I recommend that you use the
+standard image inclusion mechanism of your format}. Thus, \LaTeX\ users are
+encouraged to use |\includegraphics| to include images.
+
+However, there are reasons why you might need to use the image inclusion
+facilities of \pgfname:
+%
+\begin{itemize}
+ \item There is no standard image inclusion mechanism in your format. For
+ example, plain \TeX\ does not have one, so \pgfname's inclusion
+ mechanism is ``better than nothing''.
+
+ However, this applies only to the |pdftex| backend. For all other
+ backends, \pgfname\ currently maps its commands back to the |graphicx|
+ package. Thus, in plain \TeX, this does not really help. It might be a
+ good idea to fix this in the future such that \pgfname\ becomes
+ independent of \LaTeX, thereby providing a uniform image abstraction
+ for all formats.
+ \item You wish to use masking. This is a feature that is only supported by
+ \pgfname, though I hope that someone will implement this also for the
+ graphics package in \LaTeX\ in the future.
+\end{itemize}
+
+Whatever your choice, you can still use the usual image inclusion facilities of
+the |graphics| package.
+
+The general approach taken by \pgfname\ to including an image is the following:
+First, |\pgfdeclareimage| declares the image. This must be done prior to the
+first use of the image. Once you have declared an image, you can insert it into
+the text using |\pgfuseimage|. The advantage of this two-phase approach is
+that, at least for \textsc{pdf}, the image data will only be included once in
+the file. This can drastically reduce the file size if you use an image
+repeatedly, for example in an overlay. However, there is also a command called
+|\pgfimage| that declares and then immediately uses the image.
+
+To speedup the compilation, you may wish to use the following class option:
+%
+\begin{packageoption}{draft}
+ In draft mode boxes showing the image name replace the images. It is
+ checked whether the image files exist, but they are not read. If either
+ height or width is not given, 1cm is used instead.
+\end{packageoption}
+
+
+\subsection{Declaring an Image}
+
+\begin{command}{\pgfdeclareimage\oarg{options}\marg{image name}\marg{filename}}
+ Declares an image, but does not paint anything. To draw the image, use
+ |\pgfuseimage{|\meta{image name}|}|. The \meta{filename} may not have an
+ extension. For \textsc{pdf}, the extensions |.pdf|, |.jpg|, and |.png|
+ will automatically tried. For PostScript, the extensions |.eps|, |.epsi|,
+ and |.ps| will be tried.
+
+ The following options are possible:
+ %
+ \begin{itemize}
+ \item \declare{|height=|\meta{dimension}} sets the height of the image.
+ If the width is not specified simultaneously, the aspect ratio of
+ the image is kept.
+ \item \declare{|width=|\meta{dimension}} sets the width of the image.
+ If the height is not specified simultaneously, the aspect ratio of
+ the image is kept.
+ \item \declare{|page=|\meta{page number}} selects a given page number
+ from a multipage document. Specifying this option will have the
+ following effect: first, \pgfname\ tries to find a file named
+ %
+ \begin{quote}
+ \meta{filename}|.page|\meta{page number}|.|\meta{extension}
+ \end{quote}
+ %
+ If such a file is found, it will be used instead of the originally
+ specified filename. If not, \pgfname\ inserts the image stored in
+ \meta{filename}|.|\meta{extension} and if a recent version of
+ |pdflatex| is used, only the selected page is inserted. For older
+ versions of |pdflatex| and for |dvips| the complete document is
+ inserted and a warning is printed.
+ \item \declare{|interpolate=|\meta{true or false}} selects whether the
+ image should be ``smoothed'' when zoomed. False by default.
+ \item \declare{|mask=|\meta{mask name}} selects a transparency mask.
+ The mask must previously be declared using |\pgfdeclaremask| (see
+ below). This option only has an effect for |pdf|. Not all viewers
+ support masking.
+ \end{itemize}
+ %
+\begin{codeexample}[code only]
+\pgfdeclareimage[interpolate=true,height=1cm]{image1}{brave-gnu-world-logo}
+\pgfdeclareimage[interpolate=true,width=1cm,height=1cm]{image2}{brave-gnu-world-logo}
+\pgfdeclareimage[interpolate=true,height=1cm]{image3}{brave-gnu-world-logo}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfaliasimage\marg{new image name}\marg{existing image name}}
+ The \marg{existing image name} is ``cloned'' and the \marg{new image name}
+ can now be used whenever the original image is used. This command is useful
+ for creating aliases for alternate extensions and for accessing the last
+ image inserted using |\pgfimage|.
+
+ \example |\pgfaliasimage{image.!30!white}{image.!25!white}|
+\end{command}
+
+
+\subsection{Using an Image}
+
+\begin{command}{\pgfuseimage\marg{image name}}
+ Inserts a previously declared image into the \emph{normal text}. If you
+ wish to use it in a |{pgfpicture}| environment, you must put a |\pgftext|
+ around it.
+
+ If the macro |\pgfalternateextension| expands to some nonempty
+ \meta{alternate extension}, \pgfname\ will first try to use the image named
+ \meta{image name}|.|\meta{alternate extension}. If this image is not
+ defined, \pgfname\ will next check whether \meta{alternate extension}
+ contains a |!| character. If so, everything up to this exclamation mark and
+ including it is deleted from \meta{alternate extension} and the \pgfname\
+ again tries to use the image \meta{image name}|.|\meta{alternate
+ extension}. This is repeated until \meta{alternate extension} no longer
+ contains a~|!|. Then the original image is used.
+
+ The |xxcolor| package sets the alternate extension to the current color
+ mixin.
+ %
+\begin{codeexample}[]
+\pgfdeclareimage[interpolate=true,width=1cm,height=1cm]
+ {image1}{brave-gnu-world-logo}
+\pgfdeclareimage[interpolate=true,width=1cm]{image2}{brave-gnu-world-logo}
+\pgfdeclareimage[interpolate=true,height=1cm]{image3}{brave-gnu-world-logo}
+\begin{pgfpicture}
+ \pgftext[at=\pgfpoint{1cm}{5cm},left,base]{\pgfuseimage{image1}}
+ \pgftext[at=\pgfpoint{1cm}{3cm},left,base]{\pgfuseimage{image2}}
+ \pgftext[at=\pgfpoint{1cm}{1cm},left,base]{\pgfuseimage{image3}}
+
+ \pgfpathrectangle{\pgfpoint{1cm}{5cm}}{\pgfpoint{1cm}{1cm}}
+ \pgfpathrectangle{\pgfpoint{1cm}{3cm}}{\pgfpoint{1cm}{1cm}}
+ \pgfpathrectangle{\pgfpoint{1cm}{1cm}}{\pgfpoint{1cm}{1cm}}
+ \pgfusepath{stroke}
+\end{pgfpicture}
+\end{codeexample}
+
+ The following example demonstrates the effect of using |\pgfuseimage|
+ inside a colormixin environment.
+ %
+\begin{codeexample}[preamble={\usepackage{xxcolor}}]
+\pgfdeclareimage[interpolate=true,width=1cm,height=1cm]
+ {image1.!25!white}{brave-gnu-world-logo.25}
+\pgfdeclareimage[interpolate=true,width=1cm]
+ {image2.25!white}{brave-gnu-world-logo.25}
+\pgfdeclareimage[interpolate=true,height=1cm]
+ {image3.white}{brave-gnu-world-logo.25}
+\begin{colormixin}{25!white}
+\begin{pgfpicture}
+ \pgftext[at=\pgfpoint{1cm}{5cm},left,base]{\pgfuseimage{image1}}
+ \pgftext[at=\pgfpoint{1cm}{3cm},left,base]{\pgfuseimage{image2}}
+ \pgftext[at=\pgfpoint{1cm}{1cm},left,base]{\pgfuseimage{image3}}
+
+ \pgfpathrectangle{\pgfpoint{1cm}{5cm}}{\pgfpoint{1cm}{1cm}}
+ \pgfpathrectangle{\pgfpoint{1cm}{3cm}}{\pgfpoint{1cm}{1cm}}
+ \pgfpathrectangle{\pgfpoint{1cm}{1cm}}{\pgfpoint{1cm}{1cm}}
+ \pgfusepath{stroke}
+\end{pgfpicture}
+\end{colormixin}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfalternateextension}
+ You should redefine this command to install a different alternate
+ extension.
+
+ \example |\def\pgfalternateextension{!25!white}|
+\end{command}
+
+\begin{command}{\pgfimage\oarg{options}\marg{filename}}
+ Declares the image under the name |pgflastimage| and immediately uses it.
+ You can ``save'' the image for later usage by invoking |\pgfaliasimage| on
+ |pgflastimage|.
+ %
+\begin{codeexample}[preamble={\usepackage{xxcolor}}]
+\begin{colormixin}{25!white}
+\begin{pgfpicture}
+ \pgftext[at=\pgfpoint{1cm}{5cm},left,base]
+ {\pgfimage[interpolate=true,width=1cm,height=1cm]{brave-gnu-world-logo}}
+ \pgftext[at=\pgfpoint{1cm}{3cm},left,base]
+ {\pgfimage[interpolate=true,width=1cm]{brave-gnu-world-logo}}
+ \pgftext[at=\pgfpoint{1cm}{1cm},left,base]
+ {\pgfimage[interpolate=true,height=1cm]{brave-gnu-world-logo}}
+
+ \pgfpathrectangle{\pgfpoint{1cm}{5cm}}{\pgfpoint{1cm}{1cm}}
+ \pgfpathrectangle{\pgfpoint{1cm}{3cm}}{\pgfpoint{1cm}{1cm}}
+ \pgfpathrectangle{\pgfpoint{1cm}{1cm}}{\pgfpoint{1cm}{1cm}}
+ \pgfusepath{stroke}
+\end{pgfpicture}
+\end{colormixin}
+\end{codeexample}
+ %
+\end{command}
+
+
+\subsection{Masking an Image}
+
+\begin{command}{\pgfdeclaremask\oarg{options}\marg{mask name}\marg{filename}}
+ Declares a transparency mask named \meta{mask name} (called a \emph{soft
+ mask} in the \textsc{pdf} specification). This mask is read from the file
+ \meta{filename}. This file should contain a grayscale image that is as
+ large as the actual image. A white pixel in the mask will correspond to
+ ``transparent'', a black pixel to ``solid'', and gray values correspond to
+ intermediate values. The mask must have a single ``color channel''. This
+ means that the mask must be a ``real'' grayscale image, not an
+ \textsc{rgb}-image in which all \textsc{rgb}-triples happen to have the
+ same components.
+
+ You can only mask images that are in a ``pixel format''. For drivers with
+ \textsc{pdf} output, these are |.jpg| and |.png| image files; you cannot
+ mask |.pdf| images in this way. Pixel images for the |dvips|+|ps2pdf|
+ workflow must be provided as |.eps| or |.ps| files. Also, again, the mask
+ file and the image file must have the same size.
+
+ The following options may be given:
+ %
+ \begin{itemize}
+ \item |matte=|\marg{color components} sets the so-called \emph{matte}
+ of the actual image (strangely, this has to be specified together
+ with the mask, not with the image itself). The matte is the color
+ that has been used to preblend the image. For example, if the image
+ has been preblended with a red background, then \meta{color
+ components} should be set to |{1 0 0}|. The default is |{1 1 1}|,
+ which is white in the rgb model.
+
+ The matte is specified in terms of the parent's image color space.
+ Thus, if the parent is a grayscale image, the matte has to be set
+ to |{1}|.
+ \end{itemize}
+ %
+ \example
+ %
+\begin{codeexample}[]
+%% Draw a large colorful background
+\pgfdeclarehorizontalshading{colorful}{5cm}{color(0cm)=(red);
+color(2cm)=(green); color(4cm)=(blue); color(6cm)=(red);
+color(8cm)=(green); color(10cm)=(blue); color(12cm)=(red);
+color(14cm)=(green)}
+\hbox{\pgfuseshading{colorful}\hskip-14cm\hskip1cm
+\pgfimage[height=4cm]{brave-gnu-world-logo}\hskip1cm
+\pgfimage[height=4cm]{brave-gnu-world-logo-mask}\hskip1cm
+\pgfdeclaremask{mymask}{brave-gnu-world-logo-mask}
+\pgfimage[mask=mymask,height=4cm,interpolate=true]{brave-gnu-world-logo}}
+\end{codeexample}
+ %
+\end{command}
+
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "pgfmanual"
+%%% End:
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-images.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-internalregisters.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-internalregisters.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-internalregisters.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,127 @@
+% Copyright 2018 by Christian Feuersaenger
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section{Adding libraries to \pgfname: temporary registers}
+\label{section-internal-registers}
+
+This section is intended for those who like to write libraries to extend
+\pgfname. Of course, this requires a good deal of knowledge about
+\TeX-programming and the structure of the \pgfname\ basic layer. Besides, one
+will encounter the need of temporary variables and, especially, temporary \TeX\
+registers. This section describes how to use a set of pre-allocated temporary
+registers of the basic layer without needing to allocate more of them.
+
+A part of these internals are already mentioned in
+section~\ref{section-internal-pointcmds}, but the basic layer provides more
+temporaries than |\pgf at x| and |\pgf at y|.
+
+\begin{internallist}[dimen register]{\pgf at x,\pgf at y}
+ These registers are used to process point coordinates in the basic layer of
+ \pgfname, see section~\ref{section-internal-pointcmds}. After a
+ |\pgfpoint|$\dotsc$ command, they contain the final $x$ and $y$ coordinate,
+ respectively.
+
+ The values of |\pgf at x| and |\pgf at y| are set \emph{globally} in contrast to
+ other available \pgfname\ registers. You should never assume anything about
+ their value unless the context defines them explicitly.
+
+ Please prefer the |\pgf at xa|, |\pgf at xb|, $\dotsc$ registers for temporary
+ dimen registers unless you are writing point coordinate commands.
+\end{internallist}
+
+\begin{internallist}[dimen register]{
+ \pgf at xa,
+ \pgf at xb,
+ \pgf at xc,
+ \pgf at ya,
+ \pgf at yb,
+ \pgf at yc%
+}
+ Temporary registers for \TeX\ dimensions which can be modified freely. Just
+ make sure changes occur only within \TeX\ groups.
+
+ \paragraph{Attention:}
+ %
+ \pgfname\ uses these registers to perform path operations. For reasons of
+ efficiency, path commands do not always guard them. As a consequence, the
+ code
+ %
+\begin{codeexample}[code only]
+\pgfpointadd{\pgfpoint{\pgf at xa}{\pgf at ya}}{\pgfpoint{\pgf at xb}{\pgf at yb}}
+\end{codeexample}
+ %
+ \noindent may fail: Inside |\pgfpointadd|, the |\pgf at xa| and friend
+ registers might be modified. In particular, it might happen that |\pgf at xb|
+ is changed before |\pgfpoint{\pgf at xb}{\pgf at yb}| is evaluated. The right
+ thing to do would be to first expand everything using |\edef| and process
+ the values afterwards, resulting in unnecessary expensive operations. Of
+ course, one can avoid this by simply looking into the source code of
+ |\pgfpointadd| to see which registers are used.
+\end{internallist}
+
+\begin{internallist}[dimen register]{\pgfutil at tempdima,\pgfutil at tempdimb}
+ Further multi-purpose temporary dimen registers. For \LaTeX, these
+ registers are already allocated as |\@tempdima| and |\@tempdimb| and are
+ simply |\let| to the |\pgfutil@|$\dotsc$ names.
+\end{internallist}
+
+\begin{internallist}[count register]{
+ \c at pgf@counta,
+ \c at pgf@countb,
+ \c at pgf@countc,
+ \c at pgf@countd%
+}
+ These multiple-purpose count registers are used throughout \pgfname\ to
+ perform integer computations. Feel free to use them as well, just make sure
+ changes are scoped by local \TeX\ groups.
+\end{internallist}
+
+\begin{internallist}[openout handle]{\w at pgf@writea}
+ An |\openout| handle which is used to generate complete output files within
+ locally scoped parts of \pgfname\ (for example, to interact with
+ |gnuplot|). You should always use |\immediate| in front of output
+ operations involving |\w at pgf@writea| and you should always close the file
+ before returning from your code.
+ %
+\begin{codeexample}[code only]
+\immediate\openout\w at pgf@writea=myfile.dat
+\immediate\write\w at pgf@writea{...}%
+\immediate\write\w at pgf@writea{...}%
+\immediate\closeout\w at pgf@writea%
+\end{codeexample}
+ %
+\end{internallist}
+
+\begin{internallist}[openin handle]{\r at pgf@reada}
+ An |\openin| handle which is used to read files within locally scoped parts
+ of \pgfname, for example to check if a file exists or to read data files.
+ You should always use |\immediate| in front of output operations involving
+ |\r at pgf@writea| and you should always close the file before returning from
+ your code.
+ %
+\begin{codeexample}[code only]
+\immediate\openin\r at pgf@reada=myfile.dat
+% do something with \macro
+\ifeof\r at pgf@reada
+ % end of file or it doesn't exist
+\else
+ % loop or whatever
+ \immediate\read\r at pgf@reada to\macro
+ ...
+\fi
+\immediate\closein\r at pgf@reada
+\end{codeexample}
+ %
+\end{internallist}
+
+\begin{internallist}[box]{\pgfutil at tempboxa}
+ A box for temporary use inside of local \TeX\ scopes. For \LaTeX, this box
+ is the same as the already pre-allocated |\@tempboxa|.
+\end{internallist}
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-internalregisters.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-layers.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-layers.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-layers.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,136 @@
+% Copyright 2018 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section{Layered Graphics}
+\label{section-layers}
+
+\subsection{Overview}
+
+\pgfname\ provides a layering mechanism for composing graphics from multiple
+layers. (This mechanism is not to be confused with the conceptual ``software
+layers'' the \pgfname\ system is composed of.) Layers are often used in graphic
+programs. The idea is that you can draw on the different layers in any order.
+So you might start drawing something on the ``background'' layer, then
+something on the ``foreground'' layer, then something on the ``middle'' layer,
+and then something on the background layer once more, and so on. At the end, no
+matter in which ordering you drew on the different layers, the layers are
+``stacked on top of each other'' in a fixed ordering to produce the final
+picture. Thus, anything drawn on the middle layer would come on top of
+everything of the background layer.
+
+Normally, you do not need to use different layers since you will have little
+trouble ``ordering'' your graphic commands in such a way that layers are
+superfluous. However, in certain situations you only ``know'' what you should
+draw behind something else after the ``something else'' has been drawn.
+
+For example, suppose you wish to draw a yellow background behind your picture.
+The background should be as large as the bounding box of the picture, plus a
+little border. If you know the size of the bounding box of the picture at its
+beginning, this is easy to accomplish. However, in general this is not the case
+and you need to create a ``background'' layer in addition to the standard
+``main'' layer. Then, at the end of the picture, when the bounding box has been
+established, you can add a rectangle of the appropriate size to the picture.
+
+
+\subsection{Declaring Layers}
+
+In \pgfname\ layers are referenced using names. The standard layer, which is a
+bit special in certain ways, is called |main|. If nothing else is specified,
+all graphic commands are added to the |main| layer. You can declare a new layer
+using the following command:
+
+\begin{command}{\pgfdeclarelayer\marg{name}}
+ This command declares a layer named \meta{name} for later use. Mainly, this
+ will set up some internal bookkeeping.
+\end{command}
+
+The next step toward using a layer is to tell \pgfname\ which layers will be
+part of the actual picture and which will be their ordering. Thus, it is
+possible to have more layers declared than are actually used.
+
+\begin{command}{\pgfsetlayers\marg{layer list}}
+ This command tells \pgfname\ which layers will be used in pictures. They
+ are stacked on top of each other in the order given. The layer |main|
+ should always be part of the list. Here is an example:
+ %
+\begin{codeexample}[code only]
+\pgfdeclarelayer{background}
+\pgfdeclarelayer{foreground}
+\pgfsetlayers{background,main,foreground}
+\end{codeexample}
+
+ This command should be given either outside of any picture or ``directly
+ inside'' of a picture. Here, the ``directly inside'' means that there
+ should be no further level of \TeX\ grouping between |\pgfsetlayers| and
+ the matching |\end{pgfpicture}| (no closing braces, no |\end{...}|). It
+ will also work if |\pgfsetlayers| is provided before |\end{tikzpicture}|
+ (with similar restrictions).
+\end{command}
+
+
+\subsection{Using Layers}
+
+Once the layers of your picture have been declared, you can start to ``fill''
+them. As said before, all graphics commands are normally added to the |main|
+layer. Using the |{pgfonlayer}| environment, you can tell \pgfname\ that
+certain commands should, instead, be added to the given layer.
+
+\begin{environment}{{pgfonlayer}\marg{layer name}}
+ The whole \meta{environment contents} is added to the layer with the name
+ \meta{layer name}. This environment can be used anywhere inside a picture.
+ Thus, even if it is used inside a |{pgfscope}| or a \TeX\ group, the
+ contents will still be added to the ``whole'' picture. Using this
+ environment multiple times inside the same picture will cause the
+ \meta{environment contents} to accumulate.
+
+ \emph{Note:} You can \emph{not} add anything to the |main| layer using this
+ environment. The only way to add anything to the main layer is to give
+ graphic commands outside all |{pgfonlayer}| environments.
+ %
+\begin{codeexample}[]
+\pgfdeclarelayer{background layer}
+\pgfdeclarelayer{foreground layer}
+\pgfsetlayers{background layer,main,foreground layer}
+\begin{tikzpicture}
+ % On main layer:
+ \fill[blue] (0,0) circle (1cm);
+
+ \begin{pgfonlayer}{background layer}
+ \fill[yellow] (-1,-1) rectangle (1,1);
+ \end{pgfonlayer}
+
+ \begin{pgfonlayer}{foreground layer}
+ \node[white] {foreground};
+ \end{pgfonlayer}
+
+ \begin{pgfonlayer}{background layer}
+ \fill[black] (-.8,-.8) rectangle (.8,.8);
+ \end{pgfonlayer}
+
+ % On main layer again:
+ \fill[blue!50] (-.5,-1) rectangle (.5,1);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{environment}
+
+\begin{plainenvironment}{{pgfonlayer}\marg{layer name}}
+ This is the plain \TeX\ version of the environment.
+\end{plainenvironment}
+
+\begin{contextenvironment}{{pgfonlayer}\marg{layer name}}
+ This is the Con\TeX t version of the environment.
+\end{contextenvironment}
+
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "pgfmanual"
+%%% End:
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-layers.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-matrices.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-matrices.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-matrices.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,437 @@
+% Copyright 2019 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section{Matrices}
+\label{section-base-matrices}
+
+\begin{pgfmodule}{matrix}
+The present section documents the commands of this module.
+\end{pgfmodule}
+
+\subsection{Overview}
+
+Matrices are a mechanism for aligning several so-called cell pictures
+horizontally and vertically. The resulting alignment is placed in a normal node
+and the command for creating matrices, |\pgfmatrix|, takes options very similar
+to the |\pgfnode| command.
+
+In the following, the basic idea behind the alignment mechanism is explained
+first. Then the command |\pgfmatrix| is explained. At the end of the section,
+additional ways of modifying the width of columns and rows are discussed.
+
+
+\subsection{Cell Pictures and Their Alignment}
+
+A matrix consists of rows of \emph{cells}. Cells are separated using the
+special command |\pgfmatrixnextcell|, rows are ended using the command
+|\pgfmatrixendrow| (the command |\\| is set up to mean the same as
+|\pgfmatrixendrow| by default). Each cell contains a \emph{cell picture},
+although cell pictures are not complete pictures as they lack layers. However,
+each cell picture has its own bounding box like a normal picture does. These
+bounding boxes are important for the alignment as explained in the following.
+
+Each cell picture will have an origin somewhere in the picture (or even outside
+the picture). The position of these origins are important for the alignment: On
+each row the origins will be on the same horizontal line and for each column
+the origins will also be on the same vertical line. These two requirements mean
+that the cell pictures may need to be shifted around so that the origins wind
+up on the same lines. The top of a row is given by the top of the cell picture
+whose bounding box's maximum $y$-position is largest. Similarly, the bottom of
+a row is given by the bottom of the cell picture whose bounding box's minimum
+$y$-position is the most negative. Similarly, the left end of a column is given
+by the left end of the cell whose bounding box's $x$-position is the most
+negative; and similarly for the right end of a column.
+%
+\begin{codeexample}[]
+\begin{tikzpicture}[x=3mm,y=3mm,fill=blue!50]
+ \def\atorig#1{\node[black] at (0,0) {\tiny #1};}
+
+ \pgfmatrix{rectangle}{center}{mymatrix}
+ {\pgfusepath{}}{\pgfpointorigin}{}
+ {
+ \fill (0,-3) rectangle (1,1);\atorig1 \pgfmatrixnextcell
+ \fill (-1,0) rectangle (1,1);\atorig2 \pgfmatrixnextcell
+ \fill (-1,-2) rectangle (0,0);\atorig3 \pgfmatrixnextcell
+ \fill (-1,-1) rectangle (0,3);\atorig4 \\
+ \fill (-1,0) rectangle (4,1);\atorig5 \pgfmatrixnextcell
+ \fill (0,-1) rectangle (1,1);\atorig6 \pgfmatrixnextcell
+ \fill (0,0) rectangle (1,4);\atorig7 \pgfmatrixnextcell
+ \fill (-1,-1) rectangle (0,0);\atorig8 \\
+ }
+\end{tikzpicture}
+\end{codeexample}
+
+
+\subsection{The Matrix Command}
+
+All matrices are typeset using the following command:
+
+\begin{command}{\pgfmatrix\marg{shape}\marg{anchor}\marg{name}\marg{usage}\marg{shift}\marg{pre-code}\marg{matrix cells}}
+ This command creates a node that contains a matrix. The name of the node is
+ \meta{name}, its shape is \meta{shape} and the node is anchored at
+ \meta{anchor}.
+
+ The \meta{matrix cell} parameter contains the cells of the matrix. In each
+ cell drawing commands may be given, which create a so-called cell picture.
+ For each cell picture a bounding box is computed and the cells are aligned
+ according to the rules outlined in the previous section.
+
+ The resulting matrix is used as the |text| box of the node. As for a normal
+ node, the \meta{usage} commands are applied, so that the path(s) of the
+ resulting node is (are) stroked or filled or whatever.
+
+
+ \medskip
+ \textbf{Specifying the cells and rows.\ }
+ Even though this command uses |\halign| internally, there are two special
+ rules for indicating cells:
+ %
+ \begin{enumerate}
+ \item Cells in the same row must be separated using the macro
+ |\pgfmatrixnextcell| rather than |&|. Using |&| will result in an
+ error message.
+
+ However, you can make |&| an active character and have it expand to
+ |\pgfmatrixnextcell|. This way, it will ``look'' as if |&| is used.
+ \item Rows are ended using the command |\pgfmatrixendrow|, but |\\| is
+ set up to mean the same by default. However, some environments like
+ |{minipage}| redefine |\\|, so it is good to have
+ |\pgfmatrixendrow| as a ``fallback''.
+ \item Every row \emph{including the last row} must be ended using the
+ command |\\| or |\pgfmatrixendrow|.
+ \end{enumerate}
+
+ Both |\pgfmatrixnextcell| and |\pgfmatrixendrow| (and, thus, also |\\|)
+ take an optional argument as explained in the
+ Section~\ref{section-matrix-spacing}
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \pgfmatrix{rectangle}{center}{mymatrix}
+ {\pgfusepath{}}{\pgfpointorigin}{}
+ {
+ \node {a}; \pgfmatrixnextcell \node {b}; \pgfmatrixendrow
+ \node {c}; \pgfmatrixnextcell \node {d}; \pgfmatrixendrow
+ }
+\end{tikzpicture}
+\end{codeexample}
+
+
+ \medskip
+ \textbf{Anchoring matrices at nodes inside the matrix.\ }
+ The parameter \meta{shift} is an additional negative shift for the node.
+ Normally, such a shift could be given beforehand (that is, the shift could
+ be preapplied to the current transformation matrix). However, when
+ \meta{shift} is evaluated, you can refer to \emph{temporary} positions of
+ nodes inside the matrix. In detail, the following happens: When the matrix
+ has been typeset, all nodes in the matrix temporarily get assigned their
+ positions in the matrix box. The origin of this coordinate system is at the
+ left baseline end of the matrix box, which corresponds to the |text|
+ anchor. The position \meta{shift} is then interpreted inside this
+ coordinate system and then used for shifting.
+
+ This allows you to use the parameter \meta{shift} in the following way: If
+ you use |text| as the \meta{anchor} and specify
+ |\pgfpointanchor{inner node}{some anchor}| for the parameter \meta{shift},
+ where |inner node| is a node that is created in the matrix, then the whole
+ matrix will be shifted such that |inner node.some anchor| lies at the
+ origin of the whole picture.
+
+
+ \medskip
+ \textbf{Rotations and scaling.\ }
+ The matrix node is never rotated or scaled, because the current coordinate
+ transformation matrix is reset (except for the translational part) at the
+ beginning of |\pgfmatrix|. This is intentional and will not change in the
+ future. If you need to rotate or scale the matrix, you must install an
+ appropriate canvas transformation yourself.
+
+ However, nodes and stuff inside the cell pictures can be rotated and scaled
+ normally.
+
+
+ \medskip
+ \textbf{Callbacks.\ }
+ At the beginning and at the end of each cell the special macros
+ |\pgfmatrixbegincode|, |\pgfmatrixendcode| and possibly
+ |\pgfmatrixemptycode| are called. The effect is explained in
+ Section~\ref{section-matrix-callbacks}.
+
+
+ \medskip
+ \textbf{Executing extra code.\ }
+ The parameter \meta{pre-code} is executed at the beginning of the outermost
+ \TeX-group enclosing the matrix node. It is inside this \TeX-group, but
+ outside the matrix itself. It can be used for different purposes:
+ %
+ \begin{enumerate}
+ \item It can be used to simplify the next cell macro. For example,
+ saying |\let\&=\pgfmatrixnextcell| allows you to use |\&| instead
+ of |\pgfmatrixnextcell|. You can also set the catcode of |&| to
+ active.
+ \item It can be used to issue an |\aftergroup| command. This allows you
+ to regain control after the |\pgfmatrix| command. (If you do not
+ know the |\aftergroup| command, you are probably blessed with a
+ simple and happy life.)
+ \end{enumerate}
+
+
+ \medskip
+ \textbf{Special considerations concerning macro expansion.\ }
+ As said before, the matrix is typeset using |\halign| internally. This
+ command does a lot of strange and magic things like expanding the first
+ macro of every cell in a most unusual manner. Here are some effects you may
+ wish to be aware of:
+ %
+ \begin{itemize}
+ \item It is not necessary to actually mention |\pgfmatrixnextcell| or
+ |\pgfmatrixendrow| inside the \meta{matrix cells}. It suffices that
+ the macros inside \meta{matrix cells} expand to these macros
+ sooner or later.
+ \item In particular, you can define clever macros that insert columns
+ and rows as needed for special effects.
+ \end{itemize}
+\end{command}
+
+
+\subsection{Row and Column Spacing}
+\label{section-matrix-spacing}
+
+It is possible to control the space between columns and rows rather detailedly.
+Two commands are important for the row spacing and two commands for the column
+spacing.
+
+\begin{command}{\pgfsetmatrixcolumnsep\marg{sep list}}
+ This macro sets the default separation list for columns. The details of the
+ format of this list are explained in the description of the next command.
+\end{command}
+
+\begin{command}{\pgfmatrixnextcell\opt{\oarg{additional sep list}}}
+ This command has two purposes: First, it is used to separate cells. Second,
+ by providing the optional argument \meta{additional sep list} you can
+ modify the spacing between the columns that are separated by this command.
+
+ The optional \meta{additional sep list} may only be provided when the
+ |\pgfmatrixnextcell| command starts a new column. Normally, this will only
+ be the case in the first row, but sometimes a later row has more elements
+ than the first row. In this case, the |\pgfmatrixnextcell| commands that
+ start the new columns in the later row may also have the optional argument.
+ Once a column has been started, subsequent uses of this optional argument
+ for the column have no effect.
+
+ To determine the space between the two columns that are separated by
+ |\pgfmatrixnextcell|, the following algorithm is executed:
+ %
+ \begin{enumerate}
+ \item Both the default separation list (as set up by
+ |\pgfsetmatrixcolumnsep|) and the \meta{additional sep list} are
+ processed, in this order. If the \meta{additional sep list}
+ argument is missing, only the default separation list is processed.
+ \item Both lists may contain dimensions, separated by commas, as well
+ as occurrences of the keywords |between origins| and
+ |between borders|.
+ \item All dimensions occurring in either list are added together to
+ arrive at a dimension $d$.
+ \item The last occurrence of either of the keywords is located. If
+ neither keyword is present, we proceed as if |between borders| were
+ present.
+ \end{enumerate}
+ %
+ At the end of the algorithm, a dimension $d$ has been computed and one of
+ the two \emph{modes} |between borders| and |between origins| has been
+ determined. Depending on which mode has been determined, the following
+ happens:
+ %
+ \begin{itemize}
+ \item For the |between borders| mode, an additional horizontal space of
+ $d$ is added between the two columns. Note that $d$ may be
+ negative.
+ \item For the |between origins| mode, the spacing between the two
+ columns is computed differently: Recall that the origins of the
+ cell pictures in both pictures lie on two vertical lines. The
+ spacing between the two columns is set up such that the horizontal
+ distance between these two lines is exactly $d$.
+
+ This mode may only be used between columns \emph{already introduced
+ in the first row}.
+ \end{itemize}
+ %
+ All of the above rules boil down to the following effects:
+ %
+ \begin{itemize}
+ \item A default spacing between columns should be set up using
+ |\pgfsetmatrixcolumnsep|. For example, you might say
+ |\pgfsetmatrixcolumnsep{5pt}| to have columns spaced apart by
+ |5pt|. You could say
+ %
+\begin{verbatim}
+\pgfsetmatrixcolumnsep{1cm,between origins}
+\end{verbatim}
+ %
+ to specify that horizontal space between the origins of cell
+ pictures in adjacent columns should be 1cm by default -- regardless
+ of the actual size of the cell pictures.
+ \item You can now use the optional argument of |\pgfmatrixnextcell| to
+ locally overrule the spacing between two columns. By saying
+ |\pgfmatrixnextcell[5pt]| you \emph{add} 5pt to the space between
+ of the two columns, regardless of the mode.
+
+ You can also (locally) change the spacing mode for these two
+ columns. For example, even if the normal spacing mode is
+ |between origins|, you can say
+ %
+\begin{verbatim}
+\pgfmatrixnextcell[5pt,between borders]
+\end{verbatim}
+ %
+ to locally change the mode for these columns to |between borders|.
+ \end{itemize}
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}[every node/.style=draw]
+ \pgfsetmatrixcolumnsep{1mm}
+ \pgfmatrix{rectangle}{center}{mymatrix}
+ {\pgfusepath{}}{\pgfpointorigin}{\let\&=\pgfmatrixnextcell}
+ {
+ \node {8}; \&[2mm] \node{1}; \&[-1mm] \node {6}; \\
+ \node {3}; \& \node{5}; \& \node {7}; \\
+ \node {4}; \& \node{9}; \& \node {2}; \\
+ }
+\end{tikzpicture}
+\end{codeexample}
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}[every node/.style=draw]
+ \pgfsetmatrixcolumnsep{1mm}
+ \pgfmatrix{rectangle}{center}{mymatrix}
+ {\pgfusepath{}}{\pgfpointorigin}{\let\&=\pgfmatrixnextcell}
+ {
+ \node {8}; \&[2mm] \node(a){1}; \&[1cm,between origins] \node(b){6}; \\
+ \node {3}; \& \node {5}; \& \node {7}; \\
+ \node {4}; \& \node {9}; \& \node {2}; \\
+ }
+ \draw [<->,red,thick,every node/.style=] (a.center) -- (b.center)
+ node [above,midway] {11mm};
+\end{tikzpicture}
+\end{codeexample}
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}[every node/.style=draw]
+ \pgfsetmatrixcolumnsep{1cm,between origins}
+ \pgfmatrix{rectangle}{center}{mymatrix}
+ {\pgfusepath{}}{\pgfpointorigin}{\let\&=\pgfmatrixnextcell}
+ {
+ \node (a) {8}; \& \node (b) {1}; \&[between borders] \node (c) {6}; \\
+ \node {3}; \& \node {5}; \& \node {7}; \\
+ \node {4}; \& \node {9}; \& \node {2}; \\
+ }
+ \begin{scope}[every node/.style=]
+ \draw [<->,red,thick] (a.center) -- (b.center) node [above,midway] {10mm};
+ \draw [<->,red,thick] (b.east) -- (c.west) node [above,midway]
+ {10mm};
+ \end{scope}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+The mechanism for the between-row-spacing is the same, only the commands are
+called differently.
+
+\begin{command}{\pgfsetmatrixrowsep\marg{sep list}}
+ This macro sets the default separation list for rows.
+\end{command}
+
+\begin{command}{\pgfmatrixendrow\opt{\oarg{additional sep list}}}
+ This command ends a line. The optional \meta{additional sep list} is used
+ to determine the spacing between the row being ended and the next row. The
+ modes and the computation of $d$ is done in the same way as for columns.
+ For the last row the optional argument has no effect.
+
+ Inside matrices (and only there) the command |\\| is set up to mean the
+ same as this command.
+\end{command}
+
+
+\subsection{Callbacks}
+\label{section-matrix-callbacks}
+
+There are three macros that get called at the beginning and end of cells. By
+redefining these macros, which are empty by default, you can change the
+appearance of cells in a very general manner.
+
+\begin{command}{\pgfmatrixemptycode}
+ This macro is executed for empty cells. This means that \pgfname\ uses some
+ macro magic to determine whether a cell is empty (it immediately ends with
+ |\pgfmatrixemptycode| or |\pgfmatrixendrow|) and, if so, put this macro
+ inside the cell.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \def\pgfmatrixemptycode{\node{empty};}
+ \pgfmatrix{rectangle}{center}{mymatrix}
+ {\pgfusepath{}}{\pgfpointorigin}{\let\&=\pgfmatrixnextcell}
+ {
+ \node {a}; \& \& \node {b}; \\
+ \& \node{c}; \& \node {d}; \& \\
+ }
+\end{tikzpicture}
+\end{codeexample}
+ %
+ As can be seen, the macro is not executed for empty cells at the end of row
+ when columns are added only later on.
+\end{command}
+
+\begin{command}{\pgfmatrixbegincode}
+ This macro is executed at the beginning of non-empty cells.
+ Correspondingly, |\pgfmatrixendcode| is added at the end of every non-empty
+ cell.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \def\pgfmatrixbegincode{\node[draw]\bgroup}
+ \def\pgfmatrixendcode{\egroup;}
+ \pgfmatrix{rectangle}{center}{mymatrix}
+ {\pgfusepath{}}{\pgfpointorigin}{\let\&=\pgfmatrixnextcell}
+ {
+ a \& b \& c \\
+ d \& \& e \\
+ }
+\end{tikzpicture}
+\end{codeexample}
+ %
+ Note that between |\pgfmatrixbegincode| and |\pgfmatrixendcode| there will
+ \emph{not} only be the contents of the cell. Rather, \pgfname\ will add
+ some (invisible) commands for book-keeping purposes that involve |\let| and
+ |\gdef|. In particular, it is not a good idea to have |\pgfmatrixbegincode|
+ end with |\csname| and |\pgfmatrixendcode| start with |\endcsname|.
+\end{command}
+
+\begin{command}{\pgfmatrixendcode}
+ See the explanation above.
+\end{command}
+
+The following two counters allow you to access the current row and current
+column in a callback:
+
+\begin{command}{\pgfmatrixcurrentrow}
+ This counter stores the current row of the current cell of the matrix. Do
+ not even think about changing this counter.
+\end{command}
+
+\begin{command}{\pgfmatrixcurrentcolumn}
+ This counter stores the current column of the current cell of the matrix.
+\end{command}
+
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "pgfmanual"
+%%% End:
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-matrices.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-nodes.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-nodes.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-nodes.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,1305 @@
+% Copyright 2019 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section{Nodes and Shapes}
+
+\label{section-shapes}
+
+This section describes the |shapes| module.
+
+\begin{pgfmodule}{shapes}
+ This module defines commands both for creating nodes and for creating
+ shapes. The package is loaded automatically by |pgf|, but you can load it
+ manually if you have only included |pgfcore|.
+\end{pgfmodule}
+
+
+\subsection{Overview}
+
+\pgfname\ comes with a sophisticated set of commands for creating \emph{nodes}
+and \emph{shapes}. A \emph{node} is a graphical object that consists
+(typically) of (one or more) text labels and some additional stroked or filled
+paths. Each node has a certain \emph{shape}, which may be something simple like
+a |rectangle| or a |circle|, but it may also be something complicated like a
+|uml class diagram| (this shape is currently not implemented, though).
+Different nodes that have the same shape may look quite different, however,
+since shapes (need not) specify whether the shape path is stroked or filled.
+
+
+\subsubsection{Creating and Referencing Nodes}
+
+You create a node by calling the macro |\pgfnode| or the more general
+|\pgfmultipartnode|. This macro takes several parameters and draws the
+requested shape at a certain position. In addition, it will ``remember'' the
+node's position within the current |{pgfpicture}|. You can then, later on,
+refer to the node's position. Coordinate transformations are ``fully
+supported'', which means that if you used coordinate transformations to shift
+or rotate the shape of a node, the node's position will still be correctly
+determined by \pgfname. This is \emph{not} the case if you use canvas
+transformations instead.
+
+
+\subsubsection{Anchors}
+
+An important property of a node or a shape in general are its \emph{anchors}.
+Anchors are ``important'' positions in a shape. For example, the |center|
+anchor lies at the center of a shape, the |north| anchor is usually ``at the
+top, in the middle'' of a shape, the |text| anchor is the lower left corner of
+the shape's text label (if present), and so on.
+
+Anchors are important both when you create a node and when you reference it.
+When you create a node, you specify the node's ``position'' by asking \pgfname\
+to place the shape in such a way that a certain anchor lies at a certain point.
+For example, you might ask that the node is placed such that the |north| anchor
+is at the origin. This will effectively cause the node to be placed below the
+origin.
+
+When you reference a node, you always reference an anchor of the node. For
+example, when you request the ``|north| anchor of the node just placed'' you
+will get the origin. However, you can also request the ``|south| anchor of this
+node'', which will give you a point somewhere below the origin. When a
+coordinate transformation was in force at the time of creation of a node, all
+anchors are also transformed accordingly.
+
+
+\subsubsection{Layers of a Shape}
+
+The simplest shape, the |coordinate|, has just one anchor, namely the |center|,
+and a label (which is usually empty). More complicated shapes like the
+|rectangle| shape also have a \emph{background path}. This is a \pgfname-path
+that is defined by the shape. The shape does not prescribe what should happen
+with the path: When a node is created, this path may be stroked (resulting in a
+frame around the label), filled (resulting in a background color for the text),
+or just discarded.
+
+Although most shapes consist just of a background path plus some label text,
+when a shape is drawn, up to seven different layers are drawn:
+%
+\begin{enumerate}
+ \item The ``behind the background layer''. Unlike the background path,
+ which can be used in different ways by different nodes, the graphic
+ commands given for this layer will always stroke or always fill the
+ path they construct. They might also insert some text that is ``behind
+ everything''.
+ \item The background path layer. How this path is used depends on the
+ arguments of the |\pgfnode| command.
+ \item The ``before the background path layer''. This layer works like the
+ first one, only the commands of this layer are executed after the
+ background path has been used (in whatever way the creator of the node
+ chose).
+ \item The label layer. This layer inserts the node's text box(es).
+ \item The ``behind the foreground layer''. This layer, like the first
+ layer, once more contains graphic commands that are ``simply
+ executed''.
+ \item The foreground path layer. This path is treated in the same way as
+ the background path, only it is drawn after the label text has been
+ drawn.
+ \item The ``before the foreground layer''.
+\end{enumerate}
+
+Which of these layers are actually used depends on the shape.
+
+
+\subsubsection{Node Parts}
+
+A shape typically does not consist only of different background and foreground
+paths, but it may also have text labels. Indeed, for many shapes the text
+labels are the more important part of the shape.
+
+Most shapes will have only one text label. In this case, this text label is
+simply passed as a parameter to the |\pgfnode| command. When the node is drawn,
+the text label is shifted around such that its lower left corner is at the
+|text| anchor of the node.
+
+More complicated shapes may have more than one text label. Nodes of such shapes
+are called \emph{multipart nodes}. The different \emph{node parts} are simply
+the different text labels. For example, a |uml class| shape might have a
+|class name| part, a |method| part and an |attributes| part. Indeed, single
+part nodes are a special case of multipart nodes: They only have one part named
+|text|.
+
+When a shape is declared, you must specify the node parts. There is a simple
+command called |\nodeparts| that takes a list of the part names as input. When
+you create a node of a multipart shape, for each part of the node you must have
+set up a \TeX-box containing the text of the part. For a part named |XYZ| you
+must set up the box |\pgfnodepartXYZbox|. The box will be placed at the anchor
+|XYZ|. See the description of |\pgfmultipartnode| for more details.
+
+
+\subsection{Creating Nodes}
+
+\subsubsection{Creating Simple Nodes}
+
+\begin{command}{\pgfnode\marg{shape}\marg{anchor}\marg{label text}\marg{name}\marg{path usage command}}
+ This command creates a new node. The \meta{shape} of the node must have
+ been declared previously using |\pgfdeclareshape|.
+
+ The shape is shifted such that the \meta{anchor} is at the origin. In order
+ to place the shape somewhere else, use the coordinate transformation prior
+ to calling this command.
+
+ The \meta{name} is a name for later reference. If no name is given, nothing
+ will be ``saved'' for the node, it will just be drawn.
+
+ The \meta{path usage command} is executed for the background and the
+ foreground path (if the shape defines them).
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (4,3);
+ {
+ \pgftransformshift{\pgfpoint{1.5cm}{1cm}}
+ \pgfnode{rectangle}{north}{Hello World}{hellonode}{\pgfusepath{stroke}}
+ }
+ {
+ \color{red!20}
+ \pgftransformrotate{10}
+ \pgftransformshift{\pgfpoint{3cm}{1cm}}
+ \pgfnode{rectangle}{center}
+ {\color{black}Hello World}{hellonode}{\pgfusepath{fill}}
+ }
+\end{tikzpicture}
+\end{codeexample}
+
+ As can be seen, all coordinate transformations are also applied to the text
+ of the shape. Sometimes, it is desirable that the transformations are
+ applied to the point where the shape will be anchored, but you do not wish
+ the shape itself to be transformed. In this case, you should call
+ |\pgftransformresetnontranslations| prior to calling the |\pgfnode|
+ command.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (4,3);
+ {
+ \color{red!20}
+ \pgftransformrotate{10}
+ \pgftransformshift{\pgfpoint{3cm}{1cm}}
+ \pgftransformresetnontranslations
+ \pgfnode{rectangle}{center}
+ {\color{black}Hello World}{hellonode}{\pgfusepath{fill}}
+ }
+\end{tikzpicture}
+\end{codeexample}
+
+ The \meta{label text} is typeset inside the \TeX-box |\pgfnodeparttextbox|.
+ This box is shown at the |text| anchor of the node, if the node has a
+ |text| part. See the description of |\pgfmultipartnode| for details.
+\end{command}
+
+
+\subsubsection{Creating Multi-Part Nodes}
+
+\begin{command}{\pgfmultipartnode\marg{shape}\marg{anchor}\marg{name}\marg{path usage command}}
+ This command is the more general (and less user-friendly) version of the
+ |\pgfnode| command. While the |\pgfnode| command can only be used for
+ shapes that have a single part (which is the case for most shapes), this
+ command can also be used with multi-part nodes.
+
+ When this command is called, for each node part of the node you must have
+ set up one \TeX-box. Suppose the shape has two parts: The |text| part and
+ the |lower| part. Then, prior to calling |\pgfmultipartnode|, you must have
+ set up the boxes |\pgfnodeparttextbox| and |\pgfnodepartlowerbox|. These
+ boxes may contain any \TeX-text. The shape code will then compute the
+ positions of the shape's anchors based on the sizes of the these shapes.
+ Finally, when the node is drawn, the boxes are placed at the anchor
+ positions |text| and |lower|.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{shapes}}]
+\setbox\pgfnodeparttextbox=\hbox{$q_1$}
+\setbox\pgfnodepartlowerbox=\hbox{01}
+\begin{pgfpicture}
+ \pgfmultipartnode{circle split}{center}{my state}{\pgfusepath{stroke}}
+\end{pgfpicture}
+\end{codeexample}
+
+ \emph{Note:} Be careful when using the |\setbox| command inside a
+ |{pgfpicture}| command. You will have to use |\pgfinterruptpath| at the
+ beginning of the box and |\endpgfinterruptpath| at the end of the box to
+ make sure that the box is typeset correctly. In the above example this
+ problem was sidestepped by moving the box construction outside the
+ environment.
+
+ \emph{Note:} It is not necessary to use |\newbox| for every node part
+ name. Although you need a different box for each part of a single shape,
+ two different shapes may very well use the same box even when the names of
+ the parts are different. Suppose you have a |circle split| shape that has a
+ |lower| part and you have a |uml class| shape that has a |methods| part.
+ Then, in order to avoid exhausting \TeX's limited number of box registers,
+ you can say
+ %
+\begin{codeexample}[code only]
+\newbox\pgfnodepartlowerbox
+\let\pgfnodepartmethodsbox=\pgfnodepartlowerbox
+\end{codeexample}
+ %
+ Also, when you have a node part name with spaces like |class name|, it may
+ be useful to create an alias:
+ %
+\begin{codeexample}[code only]
+\newbox\mybox
+\expandafter\let\csname pgfnodepartclass namebox\endcsname=\mybox
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfcoordinate\marg{name}\marg{coordinate}}
+ This command creates a node of shape |coordinate| at the given
+ \meta{coordinate}. Exactly the same effect can be achieved using first a
+ shift of the coordinate system to \meta{coordinate}, followed by creating a
+ node of shape |coordinate| named \meta{name}. However, this command is
+ easier and more natural to use and, more importantly, it is much faster.
+\end{command}
+
+\begin{command}{\pgfnodealias\marg{new name}\marg{existing node}}
+ This command does not actually create a new node. Rather, it allows you to
+ subsequently access the node \meta{existing node} using the name \meta{new
+ name}.
+\end{command}
+
+\begin{command}{\pgfnoderename\marg{new name}\marg{existing node}}
+ This command renames an existing node.
+\end{command}
+
+There are a number of values that have an influence on the size of a node.
+These values are stored in the following keys.
+
+\begin{key}{/pgf/minimum width=\meta{dimension} (initially 1pt)}
+\keyalias{tikz}
+ This key stores the \emph{recommended} minimum width of a shape. Thus, when
+ a shape is drawn and when the shape's width would be smaller than
+ \meta{dimension}, the shape's width is enlarged by adding some empty space.
+
+ Note that this value is just a recommendation. A shape may choose to ignore
+ this key.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (-2,0) grid (2,1);
+
+ \pgfset{minimum width=3cm}
+ \pgfnode{rectangle}{center}{Hello World}{}{\pgfusepath{stroke}}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{key}
+
+\begin{key}{/pgf/minimum height=\meta{dimension} (initially 1pt)}
+\keyalias{tikz}
+ Works like |/pgf/minimum width|.
+\end{key}
+
+\begin{key}{/pgf/minimum size=\meta{dimension}}
+\keyalias{tikz}
+ This style both |/pgf/minimum width| and |/pgf/minimum height| to \meta{dimension}.
+\end{key}
+
+\begin{key}{/pgf/inner xsep=\meta{dimension} (initially 0.3333em)}
+\keyalias{tikz}
+ This key stores the \emph{recommended} horizontal inner separation between
+ the label text and the background path. As before, this value is just a
+ recommendation and a shape may choose to ignore this key.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (-2,0) grid (2,1);
+
+ \pgfset{inner xsep=1cm}
+ \pgfnode{rectangle}{center}{Hello World}{}{\pgfusepath{stroke}}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{key}
+
+\begin{key}{/pgf/inner ysep=\meta{dimension} (initially 0.3333em)}
+\keyalias{tikz}
+ Works like |/pgf/inner xsep|.
+\end{key}
+
+\begin{key}{/pgf/inner sep=\meta{dimension}}
+\keyalias{tikz}
+ This style sets both |/pgf/inner xsep| and |/pgf/inner ysep| to
+ \meta{dimension}.
+\end{key}
+
+\begin{key}{/pgf/outer xsep=\meta{dimension} (initially .5\string\pgflinewidth)}
+\keyalias{tikz}
+ This key stores the recommended horizontal separation between the
+ background path and the ``outer anchors''. For example, if \meta{dimension}
+ is |1cm| then the |east| anchor will be 1cm to the right of the right
+ border of the background path. As before, this value is just a
+ recommendation.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (-2,0) grid (2,1);
+
+ \pgfset{outer xsep=.5cm}
+ \pgfnode{rectangle}{center}{Hello World}{x}{\pgfusepath{stroke}}
+
+ \pgfpathcircle{\pgfpointanchor{x}{north}}{2pt}
+ \pgfpathcircle{\pgfpointanchor{x}{south}}{2pt}
+ \pgfpathcircle{\pgfpointanchor{x}{east}}{2pt}
+ \pgfpathcircle{\pgfpointanchor{x}{west}}{2pt}
+ \pgfpathcircle{\pgfpointanchor{x}{north east}}{2pt}
+ \pgfusepath{fill}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{key}
+
+\begin{key}{/pgf/outer ysep=\meta{dimension} (initially .5\string\pgflinewidth)}
+\keyalias{tikz}
+ Works like |/pgf/outer xsep|.
+\end{key}
+
+\begin{key}{/pgf/outer sep=\meta{dimension}}
+\keyalias{tikz}
+ This style sets both |/pgf/outer xsep| and |/pgf/outer ysep| to
+ \meta{dimension}.
+\end{key}
+
+
+\subsubsection{Deferred Node Positioning}
+\label{section-shapes-deferred-node-positioning}
+
+Normally, when a node is created using a command like |\pgfnode|, the node is
+immediately inserted into the current picture. In particular, you have no
+chance to change the position of a created node after it has been created.
+Using |\pgfpositionnodelater| in concert with |\pgfpositionnodenow|, you can
+create a node whose position is determined only at some later time.
+
+\begin{command}{\pgfpositionnodelater\marg{macro name}}
+ This command is not a replacement for |\pgfnode|. Rather, when this command
+ is used in a scope, all subsequent node creations in this scope will be
+ affected in the following way: When a node is created, it is not inserted
+ into the current picture. Instead, it is stored in the box
+ |\pgfpositionnodelaterbox|. Furthermore, the node is not relevant for the
+ picture's bounding box, but a bounding box for the node is computed and
+ stored in the macros |\pgfpositionnodelaterminx| to
+ |\pgfpositionnodelatermaxy|. Then, the \meta{macro name} is called with the
+ following macros set up:
+
+ \begin{command}{\pgfpositionnodelaterbox}
+ A box register number (|0| currently) that stores the node's paths and
+ texts. You should move the contents of this box to a box of your choice
+ inside \meta{macro name}.
+ \end{command}
+
+ \begin{command}{\pgfpositionnodelatername}
+ The name of the just-created-node. This name will be the originally
+ ``desired'' name of the box plus the fixed prefix
+ |not yet positionedPGFINTERNAL|. The idea is to ensure that the
+ original name is not inadvertently used before the node is actually
+ positioned. When |\pgfpositionnodenow| is called, it will change the
+ name to the
+ original name.
+ \end{command}
+
+ \begin{command}{\pgfpositionnodelaterminx}
+ The minimal $x$-position of a bounding box of the node. This bounding
+ box refers to the node when it is positioned with the anchor at the
+ origin. It is guaranteed, that this macro will contain a dimension in
+ the format \meta{number}|pt|.
+ \end{command}
+ %
+ \begin{command}{\pgfpositionnodelaterminy}
+ \end{command}
+ %
+ \begin{command}{\pgfpositionnodelatermaxx}
+ \end{command}
+ %
+ \begin{command}{\pgfpositionnodelatermaxy}
+ \end{command}
+
+ Once a late node has been created, you can add arbitrary code in the same
+ picture. Then, at some later point, you call |\pgfpositionnodenow| to
+ finally position the node at a given position. At this point, the above
+ macros must have the exact same values they had when \meta{macro name} was
+ called. Note that the above macros are local to a scope that ends right
+ after the call to \meta{macro name}, so it is your job to copy the values
+ to safety inside \meta{macro name}.
+
+ The following two macros will also be set inside the call to \meta{macro
+ name}, but they are only ``informative'' in the sense that you need
+ \emph{not} restore these macros when |\pgfpositionnodenow| is called.
+
+ \begin{command}{\pgfpositionnodelaterpath}
+ This macro stores the path of the background of the node. See
+ Section~\ref{section-soft-paths} for an overview of how these paths are
+ encode.
+ \end{command}
+
+ By setting \meta{macro name} to |\relax| (which is the default), you can
+ switch off the whole mechanism. When a picture is interrupted, this is done
+ automatically.
+\end{command}
+
+\begin{command}{\pgfpositionnodenow\marg{coordinate}}
+ This command is used to position a node that has previously been created
+ using the command |\pgfpositionnodelater|. When |\pgfpositionnodenow| is
+ called, the macros and boxes mentioned in the description of
+ |\pgfpositionnodenow| must be set to the value they had when the
+ \meta{macro name} was called. Provided this is the case, this command will
+ insert the box into the current picture, shifted by \meta{coordinate}.
+ Then, the late code (see below) is called. Subsequently, you can refer to
+ the node with its original name as if it had just been created.
+ %
+\begin{codeexample}[]
+\newbox\mybox
+
+\def\mysaver{
+ \global\setbox\mybox=\box\pgfpositionnodelaterbox
+ \global\let\myname=\pgfpositionnodelatername
+ \global\let\myminx=\pgfpositionnodelaterminx
+ \global\let\myminy=\pgfpositionnodelaterminy
+ \global\let\mymaxx=\pgfpositionnodelatermaxx
+ \global\let\mymaxy=\pgfpositionnodelatermaxy
+}
+
+\begin{tikzpicture}
+ {
+ \pgfpositionnodelater{\mysaver}
+ \node [fill=blue!20,below,rotate=30] (hi) {Hello world};
+ }
+ \draw [help lines] (0,0) grid (3,2);
+
+ \let\pgfpositionnodelatername=\myname
+ \let\pgfpositionnodelaterminx=\myminx
+ \let\pgfpositionnodelaterminy=\myminy
+ \let\pgfpositionnodelatermaxx=\mymaxx
+ \let\pgfpositionnodelatermaxy=\mymaxy
+ \setbox\pgfpositionnodelaterbox=\box\mybox
+ \pgfpositionnodenow{\pgfqpoint{2cm}{2cm}}
+
+ \draw (hi) -- (0,0);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfnodepostsetupcode\marg{node name}\marg{code}}
+ When you call this macro inside a scope for which the
+ |\pgfpositionnodelater| has been called, the \meta{code} will be stored
+ internally. Later, when the node named \meta{node name} is actually
+ positioned using |\pgfpositionnodenow|, the \meta{code} will be executed.
+ When this macro is called multiple times with the same \meta{node name},
+ the \meta{code} accumulates. However, When |\pgfpositionnodenow| is called,
+ the code stored for the node is cleared.
+
+ The main purpose of this mechanism is to allow \tikzname\ to store
+ so-called ``late options'' with a node that will be positioned only later.
+\end{command}
+
+
+\subsection{Using Anchors}
+
+Each shape defines a set of anchors. We saw already that the anchors are used
+when the shape is drawn: the shape is placed in such a way that the given
+anchor is at the origin (which in turn is typically translated somewhere else).
+
+One has to look up the set of anchors of each shape, there is no ``default''
+set of anchors, except for the |center| anchor, which should always be present.
+Also, most shapes will declare anchors like |north| or |east|, but this is not
+guaranteed.
+
+
+\subsubsection{Referencing Anchors of Nodes in the Same Picture}
+
+Once a node has been defined, you can refer to its anchors using the following
+commands:
+
+\begin{command}{\pgfpointanchor\marg{node}\marg{anchor}}
+ This command is another ``point command'' like the commands described in
+ Section~\ref{section-points}. It returns the coordinate of the given
+ \meta{anchor} in the given \meta{node}. The command can be used in commands
+ like |\pgfpathmoveto|.
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgftransformrotate{30}
+ \pgfnode{rectangle}{center}{Hello World!}{x}{\pgfusepath{stroke}}
+
+ \pgfpathcircle{\pgfpointanchor{x}{north}}{2pt}
+ \pgfpathcircle{\pgfpointanchor{x}{south}}{2pt}
+ \pgfpathcircle{\pgfpointanchor{x}{east}}{2pt}
+ \pgfpathcircle{\pgfpointanchor{x}{west}}{2pt}
+ \pgfpathcircle{\pgfpointanchor{x}{north east}}{2pt}
+ \pgfusepath{fill}
+\end{pgfpicture}
+\end{codeexample}
+
+ In the above example, you may have noticed something curious: The rotation
+ transformation is still in force when the anchors are invoked, but it does
+ not seem to have an effect. You might expect that the rotation should apply
+ to the already rotated points once more.
+
+ However, |\pgfpointanchor| returns a point that takes the current
+ transformation matrix into account: \emph{The inverse transformation to the
+ current coordinate transformation is applied to an anchor point before
+ returning it.}
+
+ This behavior may seem a bit strange, but you will find it very natural in
+ most cases. If you really want to apply a transformation to an anchor point
+ (for example, to ``shift it away'' a little bit), you have to invoke
+ |\pgfpointanchor| without any transformations in force. Here is an example:
+ %
+\makeatletter
+\begin{codeexample}[pre={\makeatletter}]
+\begin{pgfpicture}
+ \pgftransformrotate{30}
+ \pgfnode{rectangle}{center}{Hello World!}{x}{\pgfusepath{stroke}}
+
+ {
+ \pgftransformreset
+ \pgfpointanchor{x}{east}
+ \xdef\mycoordinate{\noexpand\pgfpoint{\the\pgf at x}{\the\pgf at y}}
+ }
+
+ \pgfpathcircle{\mycoordinate}{2pt}
+ \pgfusepath{fill}
+\end{pgfpicture}
+\end{codeexample}
+
+ A special situation arises when the \meta{node} lies in a picture different
+ from the current picture. In this case, if you have not told \pgfname\ that
+ the picture should be ``remembered'', the \meta{node} will be treated as if
+ it lay in the current picture. For example, if the \meta{node} was at
+ position $(3,2)$ in the original picture, it is treated as if it lay at
+ position $(3,2)$ in the current picture. However, if you have told
+ \pgfname\ to remember the picture position of the node's picture and also
+ of the current picture, then |\pgfpointanchor| will return a coordinate
+ that corresponds to the position of the node's anchor on the page,
+ transformed into the current coordinate system. For examples and more
+ details see Section~\ref{section-cross-pictures-pgf}.
+\end{command}
+
+\begin{command}{\pgfpointshapeborder\marg{node}\marg{point}}
+ This command returns the point on the border of the shape that lies on a
+ straight line from the center of the node to \meta{point}. For complex
+ shapes it is not guaranteed that this point will actually lie on the
+ border, it may be on the border of a ``simplified'' version of the shape.
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \begin{pgfscope}
+ \pgftransformrotate{30}
+ \pgfnode{rectangle}{center}{Hello World!}{x}{\pgfusepath{stroke}}
+ \end{pgfscope}
+ \pgfpathcircle{\pgfpointshapeborder{x}{\pgfpoint{2cm}{1cm}}}{2pt}
+ \pgfpathcircle{\pgfpoint{2cm}{1cm}}{2pt}
+ \pgfpathcircle{\pgfpointshapeborder{x}{\pgfpoint{-1cm}{1cm}}}{2pt}
+ \pgfpathcircle{\pgfpoint{-1cm}{1cm}}{2pt}
+ \pgfusepath{fill}
+\end{pgfpicture}
+\end{codeexample}
+ %
+ \emph{Remark:} If the given \meta{point} is almost identical to the center
+ of \meta{node}, the node center is returned and a warning message will be
+ printed.
+\end{command}
+
+
+\subsubsection{Referencing Anchors of Nodes in Different Pictures}
+\label{section-cross-pictures-pgf}
+
+As a picture is typeset, \pgfname\ keeps track of the positions of all nodes
+inside the picture. What \pgfname\ does not remember is the position of the
+picture \emph{itself} on the page. Thus, if you define a node in one picture
+and then try to reference this node while another picture is typeset, \pgfname\
+will only know the position of the nodes that you try to typeset inside the
+original picture, but it will not know where this picture lies. What is missing
+is the relative positioning of the two pictures.
+
+To overcome this problem, you need to tell \pgfname\ that it should remember
+the position of pictures on a page. If these positions are remembered, then
+\pgfname\ can compute the offset between the pictures and make nodes in
+different pictures accessible.
+
+Determining the positions of pictures on the page is, alas, not-so-easy.
+Because of this, \pgfname\ does not do so automatically. Rather, you have to
+proceed as follows:
+%
+\begin{enumerate}
+ \item You have to use a backend driver that supports position tracking.
+ pdf\TeX\ is one such driver, |dvips| currently is not.
+ \item You have to say |\pgfrememberpicturepositiononpagetrue| somewhere
+ before or inside every picture
+ %
+ \begin{itemize}
+ \item in which you wish to reference a node and
+ \item from which you wish to reference a node in another picture.
+ \end{itemize}
+ %
+ The second item is important since \pgfname\ does not only need to know
+ the position of the picture in which the node you wish to reference
+ lies, but it also needs to know where the current picture lies.
+ \item You typically have to run \TeX\ twice (depending on the backend
+ driver) since the position information typically gets written into an
+ external file on the first run and is available only on the second run.
+ \item You have to switch off automatic bounding bound computations. The
+ reason is that the node in the other picture should not influence the
+ size of the bounding box of the current picture. You should say
+ |\pgfusepath{use as bounding box}| before using a coordinate in another
+ picture.
+\end{enumerate}
+
+
+\subsection{Special Nodes}
+
+There are several special nodes that are always defined and which you should
+not attempt to redefine.
+
+\begin{predefinednode}{current bounding box}
+ This node is of shape |rectangle|. Unlike normal nodes, its size changes
+ constantly and always reflects the size of the bounding box of the current
+ picture. This means that, for instance, that
+ %
+\begin{codeexample}[code only]
+\pgfpointanchor{current bounding box}{south east}
+\end{codeexample}
+ %
+ returns the lower left corner of the bounding box of the current picture.
+\end{predefinednode}
+
+\begin{predefinednode}{current path bounding box}
+ This node is also of shape |rectangle|. Its size is the size of the
+ bounding box of the current path.
+\end{predefinednode}
+
+\begin{predefinednode}{current subpath start}
+ This node is of shape |coordinate| and is at the beginning of the current
+ subpath. This is the position of the last move-to operation.
+\end{predefinednode}
+
+\begin{predefinednode}{current page}
+ This node is inside a virtual remembered picture. The size of this node is
+ the size of the current page. This means that if you create a remembered
+ picture and inside this picture you reference an anchor of this node, you
+ reference an absolute position on the page. To demonstrate the effect, the
+ following code puts some text in the lower left corner of the current page.
+ Note that this works only if the backend driver supports it, otherwise the
+ text is inserted right here.
+ %
+{%
+\pgfrememberpicturepositiononpagetrue%
+\begin{pgfpicture}
+ \pgfusepath{use as bounding box}
+ \pgftransformshift{\pgfpointanchor{current page}{south west}}
+ \pgftransformshift{\pgfpoint{1cm}{1cm}}
+ \pgftext[left,base]{
+ \textcolor{red}{
+ Text absolutely positioned in
+ the lower left corner.}
+ }
+\end{pgfpicture}
+}%
+\begin{codeexample}[code only]
+\pgfrememberpicturepositiononpagetrue
+\begin{pgfpicture}
+ \pgfusepath{use as bounding box}
+ \pgftransformshift{\pgfpointanchor{current page}{south west}}
+ \pgftransformshift{\pgfpoint{1cm}{1cm}}
+ \pgftext[left,base]{
+ \textcolor{red}{
+ Text absolutely positioned in
+ the lower left corner.}
+ }
+\end{pgfpicture}
+\end{codeexample}
+ %
+\end{predefinednode}
+
+There is also an option that allows you to create new special nodes quite
+similar to the above:
+%
+\begin{key}{/pgf/local bounding box=\meta{node name}}
+\keyalias{tikz}
+ This defines a new node \meta{node name} whose size is the bounding box
+ around all objects in the current scope starting at the position where this
+ option was given. After the end of the scope, the \meta{node name} is still
+ available. You can use this option to keep track of the size of a certain
+ area. Note that excessive use of this option (keeping track of dozens of
+ bounding boxes at the same time) will slow things down.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{scopes}}]
+\begin{tikzpicture}
+ \draw [help lines] (0,0) grid (3,2);
+ { [local bounding box=outer box]
+ \draw (1,1) circle (.5) [local bounding box=inner box] (2,2) circle (.5);
+ }
+ \draw (outer box.south west) rectangle (outer box.north east);
+ \draw[red] (inner box.south west) rectangle (inner box.north east);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{key}
+
+
+\subsection{Declaring New Shapes}
+
+There are only three predefined shapes, see
+Section~\ref{section-predefined-shapes}, so there must be some way of defining
+new shapes. Defining a shape is, unfortunately, a not-quite-trivial process.
+The reason is that shapes need to be both very flexible (their size will vary
+greatly according to circumstances) and they need to be constructed reasonably
+``fast''. \pgfname\ must be able to handle pictures with several hundreds of
+nodes and documents with thousands of nodes in total. It would not do if
+\pgfname\ had to compute and store, say, dozens of anchor positions for every
+node.
+
+
+\subsubsection{What Must Be Defined For a Shape?}
+
+In order to define a new shape, you must provide:
+%
+\begin{itemize}
+ \item a \emph{shape name},
+ \item code for computing the \emph{saved anchors} and \emph{saved
+ dimensions},
+ \item code for computing \emph{anchor} positions in terms of the saved
+ anchors,
+ \item optionally code for the \emph{background path} and \emph{foreground
+ path},
+ \item optionally code for \emph{things to be drawn before or behind} the
+ background and foreground paths.
+ \item optionally a list of node parts.
+\end{itemize}
+
+
+\subsubsection{Normal Anchors Versus Saved Anchors}
+
+Anchors are special places in a shape. For example, the |north east| anchor,
+which is a normal anchor, lies at the upper right corner of the |rectangle|
+shape, as does |\northeast|, which is a saved anchor. The difference is the
+following: \emph{saved anchors are computed and stored for each node, anchors
+are only computed as needed.} The user only has access to the normal anchors,
+but a normal anchor can just ``copy'' or ``pass through'' the location of a
+saved anchor.
+
+The idea behind all this is that a shape can declare a very large number of
+normal anchors, but when a node of this shape is created, these anchors are not
+actually computed. However, this causes a problem: When we wish to reference an
+anchor of a node at some later time, we must still be able to compute the
+position of the anchor. For this, we may need a lot of information: What was
+the transformation matrix that was in force when the node was created? What was
+the size of the text box? What were the values of the different separation
+dimensions? And so on.
+
+To solve this problem, \pgfname\ will always compute the locations of all
+\emph{saved anchors} and store these positions. Then, when an normal anchor
+position is requested later on, the anchor position can be given just from
+knowing where the locations of the saved anchors are.
+
+As an example, consider the |rectangle| shape. For this shape two anchors are
+saved: The |\northeast| corner and the |\southwest| corner. A normal anchor
+like |north west| can now easily be expressed in terms of these coordinates:
+Take the $x$-position of the |\southwest| point and the $y$-position of the
+|\northeast| point. The |rectangle| shape currently defines 13 normal anchors,
+but needs only two saved anchors. Adding new anchors like a |south south east|
+anchor would not increase the memory and computation requirements of pictures.
+
+All anchors (both saved and normal) are specified in a local \emph{shape
+coordinate space}. This is also true for the background and foreground paths.
+The |\pgfnode| macro will automatically apply appropriate transformations to
+the coordinates so that the shape is shifted to the right anchor or otherwise
+transformed.
+
+
+\subsubsection{Command for Declaring New Shapes}
+
+The following command declares a new shape:
+%
+\begin{command}{\pgfdeclareshape\marg{shape name}\marg{shape specification}}
+ This command declares a new shape named \meta{shape name}. The shape name
+ can later be used in commands like |\pgfnode|.
+
+ The \meta{shape specification} is some \TeX\ code containing calls to
+ special commands that are only defined inside the \meta{shape
+ specification} (similarly to commands like |\draw| that are only available
+ inside the |{tikzpicture}| environment).
+
+ \example Here is the code of the |coordinate| shape:
+ %
+\begin{codeexample}[code only]
+\pgfdeclareshape{coordinate}
+{
+ \savedanchor\centerpoint{%
+ \pgf at x=.5\wd\pgfnodeparttextbox%
+ \pgf at y=.5\ht\pgfnodeparttextbox%
+ \advance\pgf at y by -.5\dp\pgfnodeparttextbox%
+ }
+ \anchor{center}{\centerpoint}
+ \anchorborder{\centerpoint}
+}
+\end{codeexample}
+
+ The special commands are explained next. In the examples given for the
+ special commands a new shape will be constructed, which we might call
+ |simple rectangle|. It should behave like the normal rectangle shape, only
+ without bothering about the fine details like inner and outer separations.
+ The skeleton for the shape is the following.
+ %
+\begin{codeexample}[code only]
+\pgfdeclareshape{simple rectangle}{
+ ...
+}
+\end{codeexample}
+
+ \begin{command}{\nodeparts\marg{list of node parts}}
+ This command declares which parts make up nodes of this shape. A
+ \emph{node part} is a (possibly empty) text label that is drawn when a
+ node of the shape is created.
+
+ By default, a shape has just one node part called |text|. However,
+ there can be several node parts. For example, the |circle split| shape
+ has two parts: the |text| part, which shows that the upper text, and a
+ |lower| part, which shows the lower text. For the |circle split| shape
+ the |\nodeparts| command was called with the argument |{text,lower}|.
+
+ When a multipart node is created, the text labels are drawn in the
+ sequences listed in the \meta{list of node parts}. For each node part,
+ you must have declared one anchor and the \TeX-box of the part is
+ placed at this anchor. For a node part called |XYZ| the \TeX-box
+ |\pgfnodepartXYZbox| is placed at anchor |XYZ|.
+ \end{command}
+
+ \begin{command}{\savedanchor\marg{command}\marg{code}}
+ This command declares a saved anchor. The argument \meta{command}
+ should be a \TeX\ macro name like |\centerpoint|.
+
+ The \meta{code} will be executed each time |\pgfnode| (or
+ |\pgfmultipartnode|) is called to create a node of the shape
+ \meta{shape name}. When the \meta{code} is executed, the \TeX-boxes of
+ the node parts will contain the text labels of the node. Possibly,
+ these box are void. For example, if there is just a |text| part, the
+ node |\pgfnodeparttextbox| will be set up when the \meta{code} is
+ executed.
+
+ The \meta{code} can use the width, height, and depth of the box(es) to
+ compute the location of the saved anchor. In addition, the \meta{code}
+ can take into account the values of dimensions like |\pgfshapeminwidth|
+ or |\pgfshapeinnerxsep|. Furthermore, the \meta{code} can take into
+ consideration the values of any further shape-specific variables that
+ are set at the moment when |\pgfnode| is called.
+
+ The net effect of the \meta{code} should be to set the two \TeX\
+ dimensions |\pgf at x| and |\pgf at y|. One way to achieve this is to say
+ |\pgfpoint{|\meta{x value}|}{|\meta{y value}|}| at the end of the
+ \meta{code}, but you can also just set these variables. The values that
+ |\pgf at x| and |\pgf at y| have after the code has been executed, let us
+ call them $x$ and $y$, will be recorded and stored together with the
+ node that is created by the command |\pgfnode|.
+
+ The macro \meta{command} is defined to be |\pgfpoint{|$x$|}{|$y$|}|.
+ However, the \meta{command} is only locally defined while anchor
+ positions are being computed. Thus, it is possible to use very simple
+ names for \meta{command}, like |\center| or |\a|, without causing a
+ name-clash. (To be precise, very simple \meta{command} names will clash
+ with existing names, but only locally inside the computation of anchor
+ positions; and we do not need the normal |\center| command during these
+ computations.)
+
+ For our |simple rectangle| shape, we will need only one saved anchor:
+ The upper right corner. The lower left corner could either be the
+ origin or the ``mirrored'' upper right corner, depending on whether we
+ want the text label to have its lower left corner at the origin or
+ whether the text label should be centered on the origin. Either will be
+ fine, for the final shape this will make no difference since the shape
+ will be shifted anyway. So, let us assume that the text label is
+ centered on the origin (this will be specified later on using the
+ |text| anchor). We get the following code for the upper right corner:
+ %
+\begin{codeexample}[code only]
+\savedanchor{\upperrightcorner}{
+ \pgf at y=.5\ht\pgfnodeparttextbox % height of the box, ignoring the depth
+ \pgf at x=.5\wd\pgfnodeparttextbox % width of the box
+}
+\end{codeexample}
+
+ If we wanted to take, say, the |\pgfshapeminwidth| into account, we
+ could use the following code:
+ %
+\begin{codeexample}[code only]
+\savedanchor{\upperrightcorner}{
+ \pgf at y=.\ht\pgfnodeparttextbox % height of the box
+ \pgf at x=.\wd\pgfnodeparttextbox % width of the box
+ \setlength{\pgf at xa}{\pgfshapeminwidth}
+ \ifdim\pgf at x<.5\pgf at xa
+ \pgf at x=.5\pgf at xa
+ \fi
+}
+\end{codeexample}
+ %
+ Note that we could not have written |.5\pgfshapeminwidth| since the
+ minimum width is stored in a ``plain text macro'', not as a real
+ dimension. So if |\pgfshapeminwidth| depth were 2cm, writing
+ |.5\pgfshapeminwidth| would yield the same as |.52cm|.
+
+ In the ``real'' |rectangle| shape the code is somewhat more complex,
+ but you get the basic idea.
+ \end{command}
+ %
+ \begin{command}{\saveddimen\marg{command}\marg{code}}
+ This command is similar to |\savedanchor|, only instead of setting
+ \meta{command} to |\pgfpoint{|$x$|}{|$y$|}|, the \meta{command} is set
+ just to (the value of) $x$.
+
+ In the |simple rectangle| shape we might use a saved dimension to store
+ the depth of the shape box.
+ %
+\begin{codeexample}[code only]
+\saveddimen{\depth}{
+ \pgf at x=\dp\pgfnodeparttextbox
+}
+\end{codeexample}
+ \end{command}
+ %
+ \begin{command}{\savedmacro\marg{command}\marg{code}}
+ This command is similar to |\saveddimen|, only at some point in
+ \meta{code}, \meta{command} should be defined appropriately, (this
+ could be a value, or some text).
+
+ In the |regular polygon| shape, a saved macro is used to store the
+ number of sides of the polygon.
+ %
+\begin{codeexample}[code only]
+\savedmacro{\sides}{\let\sides\pgfpolygonsides}
+\end{codeexample}
+ \end{command}
+ %
+ \begin{command}{\anchor\marg{name}\marg{code}}
+ This command declares an anchor named \meta{name}. Unlike for saved
+ anchors, the \meta{code} will not be executed each time a node is
+ declared. Rather, the \meta{code} is only executed when the anchor is
+ specifically requested; either for anchoring the node during its
+ creation or as a position in the shape referenced later on.
+
+ The \meta{name} is a quite arbitrary string that is not ``passed down''
+ to the system level. Thus, names like |south| or |1| or |::| would all
+ be fine.
+
+ A saved anchor is not automatically also a normal anchor. If you wish
+ to give the users access to a saved anchor you must declare a normal
+ anchor that just returns the position of the saved anchor.
+
+ When the \meta{code} is executed, all saved anchor macros will be
+ defined. Thus, you can reference them in your \meta{code}. The effect
+ of the \meta{code} should be to set the values of |\pgf at x| and |\pgf at y|
+ to the coordinates of the anchor.
+
+ Let us consider some example for the |simple rectangle| shape. First,
+ we would like to make the upper right corner publicly available, for
+ example as |north east|:
+ %
+\begin{codeexample}[code only]
+\anchor{north east}{\upperrightcorner}
+\end{codeexample}
+
+ The |\upperrightcorner| macro will set |\pgf at x| and |\pgf at y| to the
+ coordinates of the upper right corner. Thus, |\pgf at x| and |\pgf at y| will
+ have exactly the right values at the end of the anchor's code.
+
+ Next, let us define a |north west| anchor. For this anchor, we can
+ negate the |\pgf at x| variable:
+ %
+\begin{codeexample}[code only]
+\anchor{north west}{
+ \upperrightcorner
+ \pgf at x=-\pgf at x
+}
+\end{codeexample}
+
+ Finally, it is a good idea to always define a |center| anchor, which
+ will be the default location for a shape.
+ %
+\begin{codeexample}[code only]
+\anchor{center}{\pgfpointorigin}
+\end{codeexample}
+
+ You might wonder whether we should not take into consideration that the
+ node is not placed at the origin, but has been shifted somewhere.
+ However, the anchor positions are always specified in the shape's
+ ``private'' coordinate system. The ``outer'' transformation that has
+ been applied to the shape upon its creation is applied automatically to
+ the coordinates returned by the anchor's \meta{code}.
+
+ Our |simple rectangle| only has one text label (node part) called
+ |text|. This is the default situation, so we do not need to do
+ anything. For the |text| node part we must set up a |text| anchor. Upon
+ creation of a node, this anchor will be made to coincide with the left
+ endpoint of the baseline of the text label (within the private
+ coordinate system of the shape). By default, the |text| anchor is at
+ the origin, but you may change this. For example, we would say
+ %
+\begin{codeexample}[code only]
+\anchor{text}{%
+ \upperrightcorner%
+ \pgf at x=-\pgf at x%
+ \pgf at y=-\pgf at y%
+}
+\end{codeexample}
+ to center the text label on the origin in the shape coordinate space.
+ Note that we could \emph{not} have written the following:
+ %
+\begin{codeexample}[code only]
+\anchor{text}{\pgfpoint{-.5\wd\pgfnodeparttextbox}{-.5\ht\pgfnodeparttextbox}}
+\end{codeexample}
+ %
+ Do you see why this is wrong? The problem is that the box
+ |\pgfnodeparttextbox| will most likely not have the correct size when
+ the anchor is computed. After all, the anchor position might be
+ recomputed at a time when several other nodes have been created.
+
+ If a shape has several node parts, we would have to define an anchor
+ for each part.
+ \end{command}
+
+ \begin{command}{\deferredanchor\marg{name}\marg{code}}
+ This command declares an anchor named \meta{name}. It works like
+ |\anchor|. However, unlike for anchors declared by |\anchor|,
+ \meta{name} will \emph{not} be expanded during the shape declaration
+ (i.e.\ not during |\pgfdeclareshape|). Rather, the \meta{name} is
+ expanded when the \emph{node} is actually used (with |\pgfnode| or more
+ likely with |\node|). This may be useful if the anchor name is context
+ dependent (depending, for example, on the value of a key).
+ %
+\begin{codeexample}[code only]
+\makeatletter
+\def\foo{foo}
+\pgfdeclareshape{simple shape}{%
+ \savedanchor{\center}{%
+ \pgfpointorigin}
+ \anchor{center}{\center}
+ \savedanchor{\anchorfoo}{%
+ \pgf at x=1cm
+ \pgf at y=0cm}
+ \deferredanchor{anchor \foo}{\anchorfoo}}
+
+\begin{tikzpicture}
+ \node[simple shape] (Test1) at (0,0) {};
+ \fill (Test1.anchor foo) circle (2pt) node[below] {anchor foo anchor};
+ %
+ \def\foo{bar}
+ \node[simple shape] (Test2) at (2,2) {};
+ \fill (Test2.anchor bar) circle (2pt) node[below] {anchor bar anchor};
+\end{tikzpicture}
+\end{codeexample}
+ \end{command}
+ %
+ \begin{command}{\anchorborder\marg{code}}
+ A \emph{border anchor} is an anchor point on the border of the shape.
+ What exactly is considered as the ``border'' of the shape depends on
+ the shape.
+
+ When the user requests a point on the border of the shape using the
+ |\pgfpointshapeborder| command, the \meta{code} will be executed to
+ discern this point. When the execution of the \meta{code} starts, the
+ dimensions |\pgf at x| and |\pgf at y| will have been set to a location $p$
+ in the shape's coordinate system, and relative to the anchor |center|.
+ Note that |\pgfpointshapeborder| will produce an error if the shape does
+ not contain the |center| anchor.
+
+ It is now the job of the \meta{code} to set up |\pgf at x| and |\pgf at y|
+ such that they specify the point on the shape's border that lies on a
+ straight line from the shape's center to the point $p$. Usually, this is
+ a somewhat complicated computation, involving many case distinctions and
+ some basic math. Note that the output coordinates must be returned in the
+ shape's coordinate system, \emph{no longer} relative to the |center|
+ anchor. While these different points of reference are only noticeable if
+ the |center| anchor is not at the origin of the shape's coordinate system,
+ it implies that ``doing nothing'' as a border anchor, i.e., returning the
+ point that was fed to |\pgfpointshapeborder| requires adding the |center|
+ anchor to the input coordinates.
+
+ For our |simple rectangle| we must compute a point on the border of a
+ rectangle whose one corner is the origin (ignoring the depth for
+ simplicity) and whose other corner is |\upperrightcorner|. The
+ following code might be used:
+ %
+\begin{codeexample}[code only]
+\anchorborder{%
+ % Call a function that computes a border point. Since this
+ % function will modify dimensions like \pgf at x, we must move them to
+ % other dimensions.
+ \@tempdima=\pgf at x
+ \@tempdimb=\pgf at y
+ \pgfpointborderrectangle{\pgfpoint{\@tempdima}{\@tempdimb}}{\upperrightcorner}
+}
+\end{codeexample}
+ \end{command}
+ %
+ \begin{command}{\backgroundpath\marg{code}}
+ This command specifies the path that ``makes up'' the background of the
+ shape. Note that the shape cannot prescribe what is going to happen
+ with the path: It might be drawn, shaded, filled, or even thrown away.
+ If you want to specify that something should ``always'' happen when
+ this shape is drawn (for example, if the shape is a stop-sign, we
+ \emph{always} want it to be filled with a red color), you can use
+ commands like |\beforebackgroundpath|, explained below.
+
+ When the \meta{code} is executed, all saved anchors will be in effect.
+ The \meta{code} should contain path construction commands.
+
+ For our |simple rectangle|, the following code might be used:
+ %
+\begin{codeexample}[code only]
+\backgroundpath{
+ \pgfpathrectanglecorners
+ {\upperrightcorner}
+ {\pgfpointscale{-1}{\upperrightcorner}}
+}
+\end{codeexample}
+ %
+ As the name suggests, the background path is used ``behind'' the text
+ labels. Thus, this path is used first, then the text labels are drawn,
+ possibly obscuring part of the path.
+ \end{command}
+ %
+ \begin{command}{\foregroundpath\marg{code}}
+ This command works like |\backgroundpath|, only it is invoked after the
+ text labels have been drawn. This means that this path can possibly
+ obscure (part of) the text labels.
+ \end{command}
+ %
+ \begin{command}{\behindbackgroundpath\marg{code}}
+ Unlike the previous two commands, \meta{code} should not only construct
+ a path, it should also use this path in whatever way is appropriate.
+ For example, the \meta{code} might fill some area with a uniform color.
+
+ Whatever the \meta{code} does, it does it first. This means that any
+ drawing done by \meta{code} will be even behind the background path.
+
+ Note that the \meta{code} is protected with a |{pgfscope}|.
+ \end{command}
+ %
+ \begin{command}{\beforebackgroundpath\marg{code}}
+ This command works like |\behindbackgroundpath|, only the \meta{code}
+ is executed after the background path has been used, but before the
+ texts label are drawn.
+ \end{command}
+ %
+ \begin{command}{\behindforegroundpath\marg{code}}
+ The \meta{code} is executed after the text labels have been drawn, but
+ before the foreground path is used.
+ \end{command}
+ %
+ \begin{command}{\beforeforegroundpath\marg{code}}
+ This \meta{code} is executed at the very end.
+ \end{command}
+ %
+ \begin{command}{\inheritsavedanchors|[from=|\marg{another shape name}|]|}
+ This command allows you to inherit the code for saved anchors from
+ \meta{another shape name}. The idea is that if you wish to create a new
+ shape that is just a small modification of a another shape, you can
+ recycle the code used for \meta{another shape name}.
+
+ The effect of this command is the same as if you had called
+ |\savedanchor| and |\saveddimen| for each saved anchor or saved
+ dimension declared in \meta{another shape name}. Thus, it is not
+ possible to ``selectively'' inherit only some saved anchors, you always
+ have to inherit all saved anchors from another shape. However, you can
+ inherit the saved anchors of more than one shape by calling this
+ command several times.
+ \end{command}
+ %
+ \begin{command}{\inheritbehindbackgroundpath|[from=|\marg{another shape name}|]|}
+ This command can be used to inherit the code used for the drawings
+ behind the background path from \meta{another shape name}.
+ \end{command}
+ %
+ \begin{command}{\inheritbackgroundpath|[from=|\marg{another shape name}|]|}
+ Inherits the background path code from \meta{another shape name}.
+ \end{command}
+ %
+ \begin{command}{\inheritbeforebackgroundpath|[from=|\marg{another shape name}|]|}
+ Inherits the before background path code from \meta{another shape
+ name}.
+ \end{command}
+ %
+ \begin{command}{\inheritbehindforegroundpath|[from=|\marg{another shape name}|]|}
+ Inherits the behind foreground path code from \meta{another shape
+ name}.
+ \end{command}
+ %
+ \begin{command}{\inheritforegroundpath|[from=|\marg{another shape name}|]|}
+ Inherits the foreground path code from \meta{another shape name}.
+ \end{command}
+ %
+ \begin{command}{\inheritbeforeforegroundpath|[from=|\marg{another shape name}|]|}
+ Inherits the before foreground path code from \meta{another shape
+ name}.
+ \end{command}
+ %
+ \begin{command}{\inheritanchor|[from=|\marg{another shape name}|]|\marg{name}}
+ Inherits the code of one specific anchor named \meta{name} from
+ \meta{another shape name}. Thus, unlike saved anchors, which must be
+ inherited collectively, normal anchors can and must be inherited
+ individually.
+ \end{command}
+ %
+ \begin{command}{\inheritanchorborder|[from=|\marg{another shape name}|]|}
+ Inherits the border anchor code from \meta{another shape name}.
+ \end{command}
+
+ The following example shows how a shape can be defined that relies heavily
+ on inheritance:
+ %
+\makeatletter
+\begin{codeexample}[
+ preamble={\usetikzlibrary{shapes.geometric}},
+ pre={\makeatletter},
+]
+\pgfdeclareshape{document}{
+ \inheritsavedanchors[from=rectangle] % this is nearly a rectangle
+ \inheritanchorborder[from=rectangle]
+ \inheritanchor[from=rectangle]{center}
+ \inheritanchor[from=rectangle]{north}
+ \inheritanchor[from=rectangle]{south}
+ \inheritanchor[from=rectangle]{west}
+ \inheritanchor[from=rectangle]{east}
+ % ... and possibly more
+ \backgroundpath{% this is new
+ % store lower right in xa/ya and upper right in xb/yb
+ \southwest \pgf at xa=\pgf at x \pgf at ya=\pgf at y
+ \northeast \pgf at xb=\pgf at x \pgf at yb=\pgf at y
+ % compute corner of ``flipped page''
+ \pgf at xc=\pgf at xb \advance\pgf at xc by-5pt % this should be a parameter
+ \pgf at yc=\pgf at yb \advance\pgf at yc by-5pt
+ % construct main path
+ \pgfpathmoveto{\pgfpoint{\pgf at xa}{\pgf at ya}}
+ \pgfpathlineto{\pgfpoint{\pgf at xa}{\pgf at yb}}
+ \pgfpathlineto{\pgfpoint{\pgf at xc}{\pgf at yb}}
+ \pgfpathlineto{\pgfpoint{\pgf at xb}{\pgf at yc}}
+ \pgfpathlineto{\pgfpoint{\pgf at xb}{\pgf at ya}}
+ \pgfpathclose
+ % add little corner
+ \pgfpathmoveto{\pgfpoint{\pgf at xc}{\pgf at yb}}
+ \pgfpathlineto{\pgfpoint{\pgf at xc}{\pgf at yc}}
+ \pgfpathlineto{\pgfpoint{\pgf at xb}{\pgf at yc}}
+ \pgfpathlineto{\pgfpoint{\pgf at xc}{\pgf at yc}}
+ }
+}\hskip-1.2cm
+\begin{tikzpicture}
+ \node[shade,draw,shape=document,inner sep=2ex] (x) {Remark};
+ \node[fill=yellow!80!black,draw,ellipse,double]
+ at ([shift=(-80:3cm)]x) (y) {Use Case};
+
+ \draw[dashed] (x) -- (y);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "pgfmanual"
+%%% End:
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-nodes.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-paths.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-paths.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-paths.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,876 @@
+% Copyright 2018 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section{Constructing Paths}
+
+\subsection{Overview}
+
+The ``basic entity of drawing'' in \pgfname\ is the \emph{path}. A path
+consists of several parts, each of which is either a closed or open curve. An
+open curve has a starting point and an end point and, in between, consists of
+several \emph{segments}, each of which is either a straight line or a Bézier
+curve. Here is an example of a path (in red) consisting of two parts, one open,
+one closed:
+%
+\begin{codeexample}[]
+\begin{tikzpicture}[scale=2]
+ \draw[thick,red]
+ (0,0) coordinate (a)
+ -- coordinate (ab) (1,.5) coordinate (b)
+ .. coordinate (bc) controls +(up:1cm) and +(left:1cm) .. (3,1) coordinate (c)
+ (0,1) -- (2,1) -- coordinate (x) (1,2) -- cycle;
+
+ \draw (a) node[below] {start part 1}
+ (ab) node[below right] {straight segment}
+ (b) node[right] {end first segment}
+ (c) node[right] {end part 1}
+ (x) node[above right] {part 2 (closed)};
+\end{tikzpicture}
+\end{codeexample}
+
+A path, by itself, has no ``effect'', that is, it does not leave any marks on
+the page. It is just a set of points on the plane. However, you can \emph{use}
+a path in different ways. The most natural actions are \emph{stroking} (also
+known as \emph{drawing}) and \emph{filling}. Stroking can be imagined as
+picking up a pen of a certain diameter and ``moving it along the path''.
+Filling means that everything ``inside'' the path is filled with a uniform
+color. Naturally, the open parts of a path must first be closed before a path
+can be filled.
+
+In \pgfname, there are numerous commands for constructing paths, all of which
+start with |\pgfpath|. There are also commands for \emph{using} paths, though
+most operations can be performed by calling |\pgfusepath| with an appropriate
+parameter.
+
+As a side-effect, the path construction commands keep track of two bounding
+boxes. One is the bounding box for the current path, the other is a bounding
+box for all paths in the current picture. See Section~\ref{section-bb} for more
+details.
+
+Each path construction command extends the current path in some way. The
+``current path'' is a global entity that persists across \TeX\ groups. Thus,
+between calls to the path construction commands you can perform arbitrary
+computations and even open and close \TeX\ groups. The current path only gets
+``flushed'' when the |\pgfusepath| command is called (or when the soft-path
+subsystem is used directly, see Section~\ref{section-soft-paths}).
+
+
+\subsection{The Move-To Path Operation}
+
+The most basic operation is the move-to operation. It must be given at the
+beginning of paths, though some path construction command (like
+|\pgfpathrectangle|) generate move-tos implicitly. A move-to operation can also
+be used to start a new part of a path.
+
+\begin{command}{\pgfpathmoveto\marg{coordinate}}
+ This command expects a \pgfname-coordinate like |\pgfpointorigin| as its
+ parameter. When the current path is empty, this operation will start the
+ path at the given \meta{coordinate}. If a path has already been partly
+ constructed, this command will end the current part of the path and start a
+ new one.
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathlineto{\pgfpoint{1cm}{1cm}}
+ \pgfpathlineto{\pgfpoint{2cm}{1cm}}
+ \pgfpathlineto{\pgfpoint{3cm}{0.5cm}}
+ \pgfpathlineto{\pgfpoint{3cm}{0cm}}
+ \pgfsetfillcolor{yellow!80!black}
+ \pgfusepath{fill,stroke}
+\end{pgfpicture}
+\end{codeexample}
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathlineto{\pgfpoint{1cm}{1cm}}
+ \pgfpathlineto{\pgfpoint{2cm}{1cm}}
+ \pgfpathmoveto{\pgfpoint{2cm}{1cm}} % New part
+ \pgfpathlineto{\pgfpoint{3cm}{0.5cm}}
+ \pgfpathlineto{\pgfpoint{3cm}{0cm}}
+ \pgfsetfillcolor{yellow!80!black}
+ \pgfusepath{fill,stroke}
+\end{pgfpicture}
+\end{codeexample}
+ %
+ The command will apply the current coordinate transformation matrix to
+ \meta{coordinate} before using it.
+
+ It will update the bounding box of the current path and picture, if
+ necessary.
+\end{command}
+
+
+\subsection{The Line-To Path Operation}
+
+\begin{command}{\pgfpathlineto\marg{coordinate}}
+ This command extends the current path in a straight line to the given
+ \meta{coordinate}. If this command is given at the beginning of path
+ without any other path construction command given before (in particular
+ without a move-to operation), the \TeX\ file may compile without an error
+ message, but a viewer application may display an error message when trying
+ to render the picture.
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathlineto{\pgfpoint{1cm}{1cm}}
+ \pgfpathlineto{\pgfpoint{2cm}{1cm}}
+ \pgfsetfillcolor{yellow!80!black}
+ \pgfusepath{fill,stroke}
+\end{pgfpicture}
+\end{codeexample}
+ %
+ The command will apply the current coordinate transformation matrix to
+ \meta{coordinate} before using it.
+
+ It will update the bounding box of the current path and picture, if
+ necessary.
+\end{command}
+
+
+\subsection{The Curve-To Path Operations}
+
+\begin{command}{\pgfpathcurveto\marg{support 1}\marg{support 2}\marg{coordinate}}
+ This command extends the current path with a Bézier curve from the last
+ point of the path to \meta{coordinate}. The \meta{support 1} and
+ \meta{support 2} are the first and second support point of the Bézier
+ curve. For more information on Bézier curves, please consult a standard
+ textbook on computer graphics.
+
+ Like the line-to command, this command may not be the first path
+ construction command in a path.
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathcurveto
+ {\pgfpoint{1cm}{1cm}}{\pgfpoint{2cm}{1cm}}{\pgfpoint{3cm}{0cm}}
+ \pgfsetfillcolor{yellow!80!black}
+ \pgfusepath{fill,stroke}
+\end{pgfpicture}
+\end{codeexample}
+ %
+ The command will apply the current coordinate transformation matrix to
+ \meta{coordinate} before using it.
+
+ It will update the bounding box of the current path and picture, if
+ necessary. However, the bounding box is simply made large enough such that
+ it encompasses all of the support points and the \meta{coordinate}. This
+ will guarantee that the curve is completely inside the bounding box, but
+ the bounding box will typically be quite a bit too large. It is not clear
+ (to me) how this can be avoided without resorting to ``some serious math''
+ in order to calculate a precise bounding box.
+\end{command}
+
+\begin{command}{\pgfpathquadraticcurveto\marg{support}\marg{coordinate}}
+ This command works like |\pgfpathcurveto|, only it uses a quadratic Bézier
+ curve rather than a cubic one. This means that only one support point is
+ needed.
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathquadraticcurveto
+ {\pgfpoint{1cm}{1cm}}{\pgfpoint{2cm}{0cm}}
+ \pgfsetfillcolor{yellow!80!black}
+ \pgfusepath{fill,stroke}
+\end{pgfpicture}
+\end{codeexample}
+ %
+ Internally, the quadratic curve is converted into a cubic curve. The only
+ noticeable effect of this is that the points used for computing the
+ bounding box are the control points of the converted curve rather than
+ \meta{support}. The main effect of this is that the bounding box will be a
+ bit tighter than might be expected. In particular, \meta{support} will not
+ always be part of the bounding box.
+\end{command}
+
+There exist two commands to draw only part of a cubic Bézier curve:
+
+\begin{command}{\pgfpathcurvebetweentime\marg{time $t_1$}\marg{time $t_2$}\marg{point p}\marg{point $s_1$}\marg{point $s_2$}\marg{point q}}
+ This command draws the part of the curve described by $p$, $s_1$, $s_2$ and
+ $q$ between the times $t_1$ and $t_2$. A time value of 0 indicates the
+ point $p$ and a time value of 1 indicates point $q$. This command includes
+ a moveto operation to the first point.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw [thin] (0,0) .. controls (0,2) and (3,0) .. (3,2);
+ \pgfpathcurvebetweentime{0.25}{0.9}{\pgfpointxy{0}{0}}{\pgfpointxy{0}{2}}
+ {\pgfpointxy{3}{0}}{\pgfpointxy{3}{2}}
+ \pgfsetstrokecolor{red}
+ \pgfsetstrokeopacity{0.5}
+ \pgfsetlinewidth{2pt}
+ \pgfusepath{stroke}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfpathcurvebetweentimecontinue\marg{time $t_1$}\marg{time $t_2$}\marg{point p}\marg{point $s_1$}\marg{point $s_2$}\marg{point q}}
+ This command works like |\pgfpathcurvebetweentime|, except that a moveto
+ operation is \emph{not} made to the first point.
+\end{command}
+
+
+\subsection{The Close Path Operation}
+
+\begin{command}{\pgfpathclose}
+ This command closes the current part of the path by appending a straight
+ line to the start point of the current part. Note that there \emph{is} a
+ difference between closing a path and using the line-to operation to add a
+ straight line to the start of the current path. The difference is
+ demonstrated by the upper corners of the triangles in the following
+ example:
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgfsetlinewidth{5pt}
+ \pgfpathmoveto{\pgfpoint{1cm}{1cm}}
+ \pgfpathlineto{\pgfpoint{0cm}{-1cm}}
+ \pgfpathlineto{\pgfpoint{1cm}{-1cm}}
+ \pgfpathclose
+ \pgfpathmoveto{\pgfpoint{2.5cm}{1cm}}
+ \pgfpathlineto{\pgfpoint{1.5cm}{-1cm}}
+ \pgfpathlineto{\pgfpoint{2.5cm}{-1cm}}
+ \pgfpathlineto{\pgfpoint{2.5cm}{1cm}}
+ \pgfusepath{stroke}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+
+\subsection{Arc, Ellipse and Circle Path Operations}
+
+The path construction commands that we have discussed up to now are sufficient
+to create all paths that can be created ``at all''. However, it is useful to
+have special commands to create certain shapes, like circles, that arise often
+in practice.
+
+In the following, the commands for adding (parts of) (transformed) circles to a
+path are described.
+
+\begin{command}{\pgfpatharc\marg{start angle}\marg{end angle}{\ttfamily\char`\{}\meta{radius}\opt{| and |\meta{y-radius}}{\ttfamily\char`\}}}
+ This command appends a part of a circle (or an ellipse) to the current
+ path. Imagine the curve between \meta{start angle} and \meta{end angle} on
+ a circle of radius \meta{radius} (if $\meta{start angle} < \meta{end
+ angle}$, the curve goes around the circle counterclockwise, otherwise
+ clockwise). This curve is now moved such that the point where the curve
+ starts is the previous last point of the path. Note that this command will
+ \emph{not} start a new part of the path, which is important for example for
+ filling purposes.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathlineto{\pgfpoint{0cm}{1cm}}
+ \pgfpatharc{180}{90}{.5cm}
+ \pgfpathlineto{\pgfpoint{3cm}{1.5cm}}
+ \pgfpatharc{90}{-45}{.5cm}
+ \pgfusepath{fill}
+\end{tikzpicture}
+\end{codeexample}
+
+ Saying |\pgfpatharc{0}{360}{1cm}| ``nearly'' gives you a full circle. The
+ ``nearly'' refers to the fact that the circle will not be closed. You can
+ close it using |\pgfpathclose|.
+
+ If the optional \meta{y-radius} is given, the \meta{radius} is the
+ $x$-radius and the \meta{y-radius} the $y$-radius of the ellipse from which
+ the curve is taken:
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpatharc{180}{45}{2cm and 1cm}
+ \pgfusepath{draw}
+\end{tikzpicture}
+\end{codeexample}
+
+ The axes of the circle or ellipse from which the arc is ``taken'' always
+ point up and right. However, the current coordinate transformation matrix
+ will have an effect on the arc. This can be used to, say, rotate an arc:
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgftransformrotate{30}
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpatharc{180}{45}{2cm and 1cm}
+ \pgfusepath{draw}
+\end{tikzpicture}
+\end{codeexample}
+
+ The command will update the bounding box of the current path and picture,
+ if necessary. Unless rotation or shearing transformations are applied, the
+ bounding box will be tight.
+\end{command}
+
+\begin{command}{\pgfpatharcaxes\marg{start angle}\marg{end angle}\marg{first axis}\marg{second axis}}
+ This command is similar to |\pgfpatharc|. The main difference is how the
+ ellipse or circle is specified from which the arc is taken. The two
+ parameters \meta{first axis} and \meta{second axis} are the $0^\circ$-axis
+ and the $90^\circ$-axis of the ellipse from which the path is taken. Thus,
+ |\pgfpatharc{0}{90}{1cm and 2cm}| has the same effect as
+ %
+\begin{verbatim}
+\pgfpatharcaxes{0}{90}{\pgfpoint{1cm}{0cm}}{\pgfpoint{0cm}{2cm}}
+\end{verbatim}
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \draw (0,0) -- (2cm,5mm) (0,0) -- (0cm,1cm);
+
+ \pgfpathmoveto{\pgfpoint{2cm}{5mm}}
+ \pgfpatharcaxes{0}{90}{\pgfpoint{2cm}{5mm}}{\pgfpoint{0cm}{1cm}}
+ \pgfusepath{draw}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfpatharcto\marg{x-radius}\marg{y-radius}\marg{rotation} \marg{large arc flag}\marg{counterclockwise flag}\\\marg{target point}}
+ This command (which directly corresponds to the arc-path command of
+ \textsc{svg}) is used to add an arc to the path that starts at the current
+ point and ends at \meta{target point}. This arc is part of an ellipse that
+ is determined in the following way: Imagine an ellipse with radii
+ \meta{x-radius} and \meta{y-radius} that is rotated around its center by
+ \meta{rotation} degrees. When you move this ellipse around in the plane,
+ there will be exactly two positions such that the two current point and the
+ target point lie on the border of the ellipse (excluding pathological
+ cases). The flags \meta{large arc flag} and \meta{clockwise flag} are then
+ used to decide which of these ellipses should be picked and which arc on
+ the picked ellipsis should be used.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+
+ \pgfpathmoveto{\pgfpoint{0mm}{20mm}}
+ \pgfpatharcto{3cm}{1cm}{0}{0}{0}{\pgfpoint{3cm}{1cm}}
+ \pgfusepath{draw}
+\end{tikzpicture}
+\end{codeexample}
+ %
+ Both flags are considered to be false exactly if they evaluate to |0|,
+ otherwise they are true. If the \meta{large arc flag} is true, then the
+ angle spanned by the arc will be greater than $180^\circ$, otherwise it
+ will be less than $180^\circ$. The \meta{clockwise flag} is used to
+ determine which of the two ellipses should be used: if the flag is true,
+ then the arc goes from the current point to the target point in a
+ counterclockwise direction, otherwise in a clockwise fashion.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \pgfsetlinewidth{2pt}
+ % Flags 0 0: red
+ \pgfsetstrokecolor{red}
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpatharcto{20pt}{10pt}{0}{0}{0}{\pgfpoint{20pt}{10pt}}
+ \pgfusepath{stroke}
+ % Flags 0 1: blue
+ \pgfsetstrokecolor{blue}
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpatharcto{20pt}{10pt}{0}{0}{1}{\pgfpoint{20pt}{10pt}}
+ \pgfusepath{stroke}
+ % Flags 1 0: orange
+ \pgfsetstrokecolor{orange}
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpatharcto{20pt}{10pt}{0}{1}{0}{\pgfpoint{20pt}{10pt}}
+ \pgfusepath{stroke}
+ % Flags 1 1: black
+ \pgfsetstrokecolor{black}
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpatharcto{20pt}{10pt}{0}{1}{1}{\pgfpoint{20pt}{10pt}}
+ \pgfusepath{stroke}
+\end{tikzpicture}
+\end{codeexample}
+ %
+ \emph{Warning:} The internal computations necessary for this command are
+ numerically very unstable. In particular, the arc will not always really
+ end at the \meta{target coordinate}, but may be off by up to several
+ points. A more precise positioning is currently infeasible due to \TeX's
+ numerical weaknesses. The only case it works quite nicely is when the
+ resulting angle is a multiple of~$90^\circ$.
+\end{command}
+
+\begin{command}{\pgfpatharctoprecomputed\marg{center point}\marg{start angle}\marg{end angle}\marg{end point}\\\marg{x-radius}\marg{y-radius}\marg{ratio x-radius/y-radius}\marg{ratio y-radius/x-radius}}
+ A specialized arc operation which is fast and numerically stable, provided
+ a lot of information is given in advance.
+
+ In contrast to |\pgfpatharc|, it explicitly interpolates start and end
+ points.
+
+ In contrast to |\pgfpatharcto|, this routine is numerically stable and
+ quite fast since it relies on a lot of available information.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+
+ \def\cx{1.5cm}% center x
+ \def\cy{1cm}% center y
+ \def\startangle{0}%
+ \def\endangle{270}%
+ \def\a{1.5cm}% xradius
+ \def\b{0.5cm}% yradius
+ \pgfmathparse{\a/\b}\let\abratio=\pgfmathresult
+ \pgfmathparse{\b/\a}\let\baratio=\pgfmathresult
+ %
+ % start point:
+ \pgfpathmoveto{\pgfpoint{\cx+\a*cos(\startangle)}{\cy+\b*sin(\startangle)}}%
+ \pgfpatharctoprecomputed
+ {\pgfpoint{\cx}{\cy}}
+ {\startangle}
+ {\endangle}
+ {\pgfpoint{\cx+\a*cos(\endangle)}{\cy+\b*sin(\endangle)}}% end point
+ {\a}
+ {\b}
+ {\abratio}
+ {\baratio}
+ \pgfusepath{draw}
+\end{tikzpicture}
+\end{codeexample}
+
+ \begin{command}{\pgfpatharctomaxstepsize}
+ The quality of arc approximation taken by |\pgfpatharctoprecomputed| by
+ means of Bézier splines is controlled by a mesh width, which is
+ initially
+
+ |\def\pgfpatharctoprecomputed{45}|.
+
+ The mesh width is provided in (full!) degrees. The smaller the mesh
+ width, the more precise the arc approximation.
+
+ Use an empty value to disable spline approximation (uses a single cubic
+ polynomial for the complete arc).
+
+ The value must be an integer!
+ \end{command}
+\end{command}
+
+\begin{command}{\pgfpathellipse\marg{center}\marg{first axis}\marg{second axis}}
+ The effect of this command is to append an ellipse to the current path (if
+ the path is not empty, a new part is started). The ellipse's center will be
+ \meta{center} and \meta{first axis} and \meta{second axis} are the axis
+ \emph{vectors}. The same effect as this command can also be achieved using
+ an appropriate sequence of move-to, arc, and close operations, but this
+ command is easier and faster.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgfpathellipse{\pgfpoint{1cm}{0cm}}
+ {\pgfpoint{1.5cm}{0cm}}
+ {\pgfpoint{0cm}{1cm}}
+ \pgfusepath{draw}
+ \color{red}
+ \pgfpathellipse{\pgfpoint{1cm}{0cm}}
+ {\pgfpoint{1cm}{1cm}}
+ {\pgfpoint{-0.5cm}{0.5cm}}
+ \pgfusepath{draw}
+\end{tikzpicture}
+\end{codeexample}
+
+ The command will apply coordinate transformations to all coordinates of the
+ ellipse. However, the coordinate transformations are applied only after the
+ ellipse is ``finished conceptually''. Thus, a transformation of 1cm to the
+ right will simply shift the ellipse one centimeter to the right; it will
+ not add 1cm to the $x$-coordinates of the two axis vectors.
+
+ The command will update the bounding box of the current path and picture,
+ if necessary.
+\end{command}
+
+\begin{command}{\pgfpathcircle\marg{center}\marg{radius}}
+ A shorthand for |\pgfpathellipse| applied to \meta{center} and the two axis
+ vectors $(\meta{radius},0)$ and $(0,\meta{radius})$.
+\end{command}
+
+
+\subsection{Rectangle Path Operations}
+
+Another shape that arises frequently is the rectangle. Two commands can be used
+to add a rectangle to the current path. Both commands will start a new part of
+the path.
+
+\begin{command}{\pgfpathrectangle\marg{corner}\marg{diagonal vector}}
+ Adds a rectangle to the path whose one corner is \meta{corner} and whose
+ opposite corner is given by $\meta{corner} + \meta{diagonal vector}$.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgfpathrectangle{\pgfpoint{1cm}{0cm}}{\pgfpoint{1.5cm}{1cm}}
+ \pgfpathrectangle{\pgfpoint{1.5cm}{0.25cm}}{\pgfpoint{1.5cm}{1cm}}
+ \pgfpathrectangle{\pgfpoint{2cm}{0.5cm}}{\pgfpoint{1.5cm}{1cm}}
+ \pgfusepath{draw}
+\end{tikzpicture}
+\end{codeexample}
+ %
+ The command will apply coordinate transformations and update the bounding
+ boxes tightly.
+\end{command}
+
+\begin{command}{\pgfpathrectanglecorners\marg{corner}\marg{opposite corner}}
+ Adds a rectangle to the path whose two opposing corners are \meta{corner}
+ and \meta{opposite corner}.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgfpathrectanglecorners{\pgfpoint{1cm}{0cm}}{\pgfpoint{1.5cm}{1cm}}
+ \pgfusepath{draw}
+\end{tikzpicture}
+\end{codeexample}
+ %
+ The command will apply coordinate transformations and update the bounding
+ boxes tightly.
+\end{command}
+
+
+\subsection{The Grid Path Operation}
+
+\begin{command}{\pgfpathgrid\oarg{options}\marg{first corner}\marg{second corner}}
+ Appends a grid to the current path. That is, a (possibly large) number of
+ parts are added to the path, each part consisting of a single horizontal or
+ vertical straight line segment.
+
+ Conceptually, the origin is part of the grid and the grid is clipped to the
+ rectangle specified by the \meta{first corner} and the \meta{second
+ corner}. However, no clipping occurs (this command just adds parts to the
+ current path) and the points where the lines enter and leave the ``clipping
+ area'' are computed and used to add simple lines to the current path.
+
+ The following keys influence the grid:
+ %
+ \begin{key}{/pgf/stepx=\meta{dimension} (initially 1cm)}
+ The horizontal stepping.
+ \end{key}
+ %
+ \begin{key}{/pgf/stepy=\meta{dimension} (initially 1cm)}
+ The vertical stepping.
+ \end{key}
+ %
+ \begin{key}{/pgf/step=\meta{vector}}
+ Sets the horizontal stepping to the $x$-coordinate of \meta{vector} and
+ the vertical stepping to its $y$-coordinate.
+ \end{key}
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgfsetlinewidth{0.8pt}
+ \pgfpathgrid[step={\pgfpoint{1cm}{1cm}}]
+ {\pgfpoint{-3mm}{-3mm}}{\pgfpoint{33mm}{23mm}}
+ \pgfusepath{stroke}
+ \pgfsetlinewidth{0.4pt}
+ \pgfpathgrid[stepx=1mm,stepy=1mm]
+ {\pgfpoint{-1.5mm}{-1.5mm}}{\pgfpoint{31.5mm}{21.5mm}}
+ \pgfusepath{stroke}
+\end{pgfpicture}
+\end{codeexample}
+ %
+ The command will apply coordinate transformations and update the bounding
+ boxes. As for ellipses, the transformations are applied to the
+ ``conceptually finished'' grid.
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgftransformrotate{10}
+ \pgfpathgrid[stepx=1mm,stepy=2mm]{\pgfpoint{0mm}{0mm}}{\pgfpoint{30mm}{30mm}}
+ \pgfusepath{stroke}
+\end{pgfpicture}
+\end{codeexample}
+ %
+\end{command}
+
+
+\subsection{The Parabola Path Operation}
+
+\begin{command}{\pgfpathparabola\marg{bend vector}\marg{end vector}}
+ This command appends two half-parabolas to the current path. The first
+ starts at the current point and ends at the current point plus \meta{bend
+ vector}. At this point, it has its bend. The second half parabola starts at
+ that bend point and ends at point that is given by the bend plus \meta{end
+ vector}.
+
+ If you set \meta{end vector} to the null vector, you append only a half
+ parabola that goes from the current point to the bend; by setting
+ \meta{bend vector} to the null vector, you append only a half parabola that
+ goes through the current point and \meta{end vector} and has its bend at
+ the current point.
+
+ It is not possible to use this command to draw a part of a parabola that
+ does not contain the bend.
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ % Half-parabola going ``up and right''
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathparabola{\pgfpointorigin}{\pgfpoint{2cm}{4cm}}
+ \color{red}
+ \pgfusepath{stroke}
+
+ % Half-parabola going ``down and right''
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathparabola{\pgfpoint{-2cm}{4cm}}{\pgfpointorigin}
+ \color{blue}
+ \pgfusepath{stroke}
+
+ % Full parabola
+ \pgfpathmoveto{\pgfpoint{-2cm}{2cm}}
+ \pgfpathparabola{\pgfpoint{1cm}{-1cm}}{\pgfpoint{2cm}{4cm}}
+ \color{orange}
+ \pgfusepath{stroke}
+\end{pgfpicture}
+\end{codeexample}
+ %
+ The command will apply coordinate transformations and update the bounding
+ boxes.
+\end{command}
+
+
+\subsection{Sine and Cosine Path Operations}
+
+Sine and cosine curves often need to be drawn and the following commands may
+help with this. However, they only allow you to append sine and cosine curves
+in intervals that are multiples of $\pi/2$.
+
+\begin{command}{\pgfpathsine\marg{vector}}
+ This command appends a sine curve in the interval $[0,\pi/2]$ to the
+ current path. The sine curve is squeezed or stretched such that the curve
+ starts at the current point and ends at the current point plus
+ \meta{vector}.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,1);
+ \pgfpathmoveto{\pgfpoint{1cm}{0cm}}
+ \pgfpathsine{\pgfpoint{1cm}{1cm}}
+ \pgfusepath{stroke}
+
+ \color{red}
+ \pgfpathmoveto{\pgfpoint{1cm}{0cm}}
+ \pgfpathsine{\pgfpoint{-2cm}{-2cm}}
+ \pgfusepath{stroke}
+\end{tikzpicture}
+\end{codeexample}
+ %
+ The command will apply coordinate transformations and update the bounding
+ boxes.
+\end{command}
+
+\begin{command}{\pgfpathcosine\marg{vector}}
+ This command appends a cosine curve in the interval $[0,\pi/2]$ to the
+ current path. The curve is squeezed or stretched such that the curve starts
+ at the current point and ends at the current point plus \meta{vector}.
+ Using several sine and cosine operations in sequence allows you to produce
+ a complete sine or cosine curve
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgfpathmoveto{\pgfpoint{0cm}{0cm}}
+ \pgfpathsine{\pgfpoint{1cm}{1cm}}
+ \pgfpathcosine{\pgfpoint{1cm}{-1cm}}
+ \pgfpathsine{\pgfpoint{1cm}{-1cm}}
+ \pgfpathcosine{\pgfpoint{1cm}{1cm}}
+ \pgfsetfillcolor{yellow!80!black}
+ \pgfusepath{fill,stroke}
+\end{pgfpicture}
+\end{codeexample}
+ %
+ The command will apply coordinate transformations and update the bounding
+ boxes.
+\end{command}
+
+
+\subsection{Plot Path Operations}
+
+There exist several commands for appending plots to a path. These commands are
+available through the module |plot|. They are documented in
+Section~\ref{section-plots}.
+
+
+\subsection{Rounded Corners}
+
+Normally, when you connect two straight line segments or when you connect two
+curves that end and start ``at different angles'', you get ``sharp corners''
+between the lines or curves. In some cases it is desirable to produce ``rounded
+corners'' instead. Thus, the lines or curves should be shortened a bit and then
+connected by arcs.
+
+\pgfname\ offers an easy way to achieve this effect, by calling the following
+two commands.
+
+\begin{command}{\pgfsetcornersarced\marg{point}}
+ This command causes all subsequent corners to be replaced by little
+ arcs. The effect of this command lasts till the end of the current
+ \TeX\ scope.
+
+ The \meta{point} dictates how large the corner arc will be. Consider a
+ corner made by two lines $l$ and~$r$ and assume that the line $l$ comes
+ first on the path. The $x$-dimension of the \meta{point} decides by how
+ much the line~$l$ will be shortened, the $y$-dimension of \meta{point}
+ decides by how much the line $r$ will be shortened. Then, the shortened
+ lines are connected by an arc.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+
+ \pgfsetcornersarced{\pgfpoint{5mm}{5mm}}
+ \pgfpathrectanglecorners{\pgfpointorigin}{\pgfpoint{3cm}{2cm}}
+ \pgfusepath{stroke}
+\end{tikzpicture}
+\end{codeexample}
+
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+
+ \pgfsetcornersarced{\pgfpoint{10mm}{5mm}}
+ % 10mm entering,
+ % 5mm leaving.
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathlineto{\pgfpoint{0cm}{2cm}}
+ \pgfpathlineto{\pgfpoint{3cm}{2cm}}
+ \pgfpathcurveto
+ {\pgfpoint{3cm}{0cm}}
+ {\pgfpoint{2cm}{0cm}}
+ {\pgfpoint{1cm}{0cm}}
+ \pgfusepath{stroke}
+\end{tikzpicture}
+\end{codeexample}
+
+ If the $x$- and $y$-coordinates of \meta{point} are the same and the corner
+ is a right angle, you will get a perfect quarter circle (well, not quite
+ perfect, but perfect up to six decimals). When the angle is not $90^\circ$,
+ you only get a fair approximation.
+
+ More or less ``all'' corners will be rounded, even the corner generated by
+ a |\pgfpathclose| command. (The author is a bit proud of this feature.)
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgfsetcornersarced{\pgfpoint{4pt}{4pt}}
+ \pgfpathmoveto{\pgfpointpolar{0}{1cm}}
+ \pgfpathlineto{\pgfpointpolar{72}{1cm}}
+ \pgfpathlineto{\pgfpointpolar{144}{1cm}}
+ \pgfpathlineto{\pgfpointpolar{216}{1cm}}
+ \pgfpathlineto{\pgfpointpolar{288}{1cm}}
+ \pgfpathclose
+ \pgfusepath{stroke}
+\end{pgfpicture}
+\end{codeexample}
+
+ To return to normal (unrounded) corners, use
+ |\pgfsetcornersarced{\pgfpointorigin}|.
+
+ Note that the rounding will produce strange and undesirable effects if the
+ lines at the corners are too short. In this case the shortening may cause
+ the lines to ``suddenly extend over the other end'' which is rarely
+ desirable.
+\end{command}
+
+
+\subsection{Internal Tracking of Bounding Boxes for Paths and Pictures}
+\label{section-bb}
+
+\makeatletter
+
+The path construction commands keep track of two bounding boxes: One for the
+current path, which is reset whenever the path is used and thereby flushed, and
+a bounding box for the current |{pgfpicture}|.
+
+\begin{command}{\pgfresetboundingbox}
+ Resets the picture's bounding box. The picture will simply forget any
+ previous bounding box updates and start collecting from scratch.
+
+ You can use this together with |\pgfusepath{use as bounding box}| to
+ replace the bounding box by the one of a particular path (ignoring
+ subsequent paths).
+\end{command}
+
+The bounding boxes are not accessible by ``normal'' macros. Rather, two sets of
+four dimension variables are used for this, all of which contain the
+letter~|@|.
+
+\begin{textoken}{\pgf at pathminx}
+ The minimum $x$-coordinate ``mentioned'' in the current path. Initially,
+ this is set to $16000$pt.
+\end{textoken}
+
+\begin{textoken}{\pgf at pathmaxx}
+ The maximum $x$-coordinate ``mentioned'' in the current path. Initially,
+ this is set to $-16000$pt.
+\end{textoken}
+
+\begin{textoken}{\pgf at pathminy}
+ The minimum $y$-coordinate ``mentioned'' in the current path. Initially,
+ this is set to $16000$pt.
+\end{textoken}
+
+\begin{textoken}{\pgf at pathmaxy}
+ The maximum $y$-coordinate ``mentioned'' in the current path. Initially,
+ this is set to $-16000$pt.
+\end{textoken}
+
+\begin{textoken}{\pgf at picminx}
+ The minimum $x$-coordinate ``mentioned'' in the current picture. Initially,
+ this is set to $16000$pt.
+\end{textoken}
+
+\begin{textoken}{\pgf at picmaxx}
+ The maximum $x$-coordinate ``mentioned'' in the current picture. Initially,
+ this is set to $-16000$pt.
+\end{textoken}
+
+\begin{textoken}{\pgf at picminy}
+ The minimum $y$-coordinate ``mentioned'' in the current picture. Initially,
+ this is set to $16000$pt.
+\end{textoken}
+
+\begin{textoken}{\pgf at picmaxy}
+ The maximum $y$-coordinate ``mentioned'' in the current picture. Initially,
+ this is set to $-16000$pt.
+\end{textoken}
+
+
+Each time a path construction command is called, the above variables are
+(globally) updated. To facilitate this, you can use the following command:
+
+\begin{command}{\pgf at protocolsizes\marg{x-dimension}\marg{y-dimension}}
+ Updates all of the above dimensions in such a way that the point specified
+ by the two arguments is inside both bounding boxes. For the picture's
+ bounding box this updating occurs only if |\ifpgf at relevantforpicturesize|
+ is true, see below.
+\end{command}
+
+For the bounding box of the picture it is not always desirable that every path
+construction command affects this bounding box. For example, if you have just
+used a clip command, you do not want anything outside the clipping area to
+affect the bounding box. For this reason, there exists a special ``\TeX\ if''
+that (locally) decides whether updating should be applied to the picture's
+bounding box. Clipping will set this if to false, as will certain other
+commands.
+
+\begin{command}{\pgf at relevantforpicturesizefalse}
+ Suppresses updating of the picture's bounding box.
+\end{command}
+
+\begin{command}{\pgf at relevantforpicturesizetrue}
+ Causes updating of the picture's bounding box.
+\end{command}
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-paths.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-patterns.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-patterns.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-patterns.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,261 @@
+% Copyright 2019 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section{Patterns}
+\label{section-patterns}
+
+\subsection{Overview}
+
+There are many ways of filling a path. First, you can fill it using a solid
+color and this is also the fastest method. Second, you can also fill it using a
+shading, which means that the color changes smoothly between two (or more)
+different colors. Third, you can fill it using a tiling pattern and it is
+explained in the following how this is done.
+
+A tiling pattern can be imagined as a rectangular tile (hence the name) on
+which a small picture is painted. There is not a single tile, but
+(conceptually) an infinite number of tiles, all showing the same picture, and
+these tiles are arranged horizontally and vertically to fill the plane. When
+you use a tiling pattern to fill a path, what happens is that the path clips
+out a ``window'' through which we see part of this infinite plane.
+
+Patterns come in two versions: \emph{inherently colored patterns} and
+\emph{form-only patterns}. (These are often called ``color patterns'' and
+``uncolored patterns'', but these names are misleading since uncolored patterns
+do have a color and the color changes. As I said, the name is misleading\dots)
+An inherently colored pattern is just a colored tile like, say, a red star with
+a black outline. A form-only pattern can be imagined as a tile that is a kind
+of rubber stamp. When this pattern is used, the stamp is used to print copies
+of the stamp picture onto the plane, but we can use a different stamp color
+each time we use a form-only pattern.
+
+\pgfname\ provides a special support for patterns. You can declare a pattern
+and then use it very much like a fill color. \pgfname\ directly maps patterns
+to the pattern facilities of the underlying graphic languages (PostScript,
+\textsc{pdf}, and \textsc{svg}). This means that filling a path using a pattern
+will be nearly as fast as if you used a uniform color.
+
+There are a number of pitfalls and restrictions when using patterns. First,
+once a pattern has been declared, you cannot change it anymore. In particular,
+it is not possible to enlarge it or change the line width. Such flexibility
+would require that the repeating of the pattern were not done by the graphic
+language, but on the \pgfname\ level. This would make patterns orders of
+magnitude slower to produce and to render. However, \pgfname{} does provide a
+more-or-less successful emulation of ``mutable'' patterns, although internally,
+a new (fixed) instance of a pattern is declared when the parameters of a
+pattern change.
+
+Second, the phase of patterns is not well-defined, that is, it is not clear
+where the origin of the ``first'' tile is. To be more precise, PostScript and
+\textsc{pdf} on the one hand and \textsc{svg} on the other hand define the
+origin differently. PostScript and \textsc{pdf} define a fixed origin that is
+independent of where the path lies. This has the highly desirable effect that
+if you use the same pattern to fill multiple paths, the outcome is the same as
+if you had filled a single path consisting of the union of all these paths. By
+comparison, \textsc{svg} uses the upper-left (?) corner of the path to be
+filled as the origin. However, the \textsc{svg} specification is a bit vague on
+this question.
+
+
+\subsection{Declaring a Pattern}
+
+Before a pattern can be used, it must be declared. The following command is
+used for this:
+
+\begin{command}{\pgfdeclarepatternformonly%
+ \opt{\oarg{variables}}%
+ \marg{name}%
+ \marg{bottom left}%
+ \marg{top right}%
+ \marg{tile size}%
+ \marg{code}%
+}
+ This command declares a new form-only pattern. The \meta{name} is a name
+ for later reference. The two parameters \meta{lower left} and \meta{upper
+ right} must describe a bounding box that is large enough to encompass the
+ complete tile.
+
+ The size of a tile is given by \meta{tile size}, that is, a tile is a
+ rectangle whose lower left corner is the origin and whose upper right
+ corner is given by \meta{tile size}. This might make you wonder why the
+ second and third parameters are needed. First, the bounding box might be
+ smaller than the tile size if the tile is larger than the picture on the
+ tile. Second, the bounding box might be bigger, in which case the picture
+ will ``bleed'' over the tile.
+
+ The \meta{code} should be \pgfname\ code than can be protocolled. It should
+ not contain any color code.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{patterns}}]
+\pgfdeclarepatternformonly{stars}
+{\pgfpointorigin}{\pgfpoint{1cm}{1cm}}
+{\pgfpoint{1cm}{1cm}}
+{
+ \pgftransformshift{\pgfpoint{.5cm}{.5cm}}
+ \pgfpathmoveto{\pgfpointpolar{0}{4mm}}
+ \pgfpathlineto{\pgfpointpolar{144}{4mm}}
+ \pgfpathlineto{\pgfpointpolar{288}{4mm}}
+ \pgfpathlineto{\pgfpointpolar{72}{4mm}}
+ \pgfpathlineto{\pgfpointpolar{216}{4mm}}
+ \pgfpathclose%
+ \pgfusepath{fill}
+}
+\begin{tikzpicture}
+ \filldraw[pattern=stars] (0,0) rectangle (1.5,2);
+ \filldraw[pattern=stars,pattern color=red]
+ (1.5,0) rectangle (3,2);
+\end{tikzpicture}
+\end{codeexample}
+
+ The optional argument \meta{variables} consists of a comma separated list
+ of macros, registers or keys, representing the parameters of the pattern
+ that may vary. If a variable is a key, then the full path name must be used
+ (specifically, it must start with |/|). As an example, a list might look
+ like the following: |\mymacro,\mydimen,/pgf/my key|. Note that macros and
+ keys should be ``simple''. They should only store values in themselves.
+
+ The effect of \meta{variables}, is the following: Normally, when this
+ argument is empty, once a pattern has been declared, it becomes ``frozen''.
+ This means that it is not possible to enlarge the pattern or change the
+ line width later on. By specifying \meta{variables}, no pattern is actually
+ created. Instead, the arguments are stored away (so the macros, registers
+ or keys do not have to be defined in advance).
+
+ When the fill pattern is set, \pgfname{} checks if the pattern has already
+ been created with the \meta{variables} set to their current values
+ (\pgfname{} is usually ``smart enough'' to distinguish between macros,
+ registers and keys). If so, this already-declared-pattern is used as the
+ fill pattern. If not, a new instance of the pattern (which will have a
+ unique internal name) is declared using the current values of
+ \meta{variables}. These values are then saved and the fill pattern set
+ accordingly.
+
+ The following shows an example of a pattern which varies according to the
+ values of the macro |\size|, the key |/tikz/radius|, and the \TeX{}
+ dimension |\thickness|.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{patterns}}]
+\pgfdeclarepatternformonly[/tikz/radius,\thickness,\size]{rings}
+{\pgfpoint{-0.5*\size}{-0.5*\size}}
+{\pgfpoint{0.5*\size}{0.5*\size}}
+{\pgfpoint{\size}{\size}}
+{
+ \pgfsetlinewidth{\thickness}
+ \pgfpathcircle\pgfpointorigin{\pgfkeysvalueof{/tikz/radius}}
+ \pgfusepath{stroke}
+}
+\newdimen\thickness
+\tikzset{
+ radius/.initial=4pt,
+ size/.store in=\size, size=20pt,
+ thickness/.code={\thickness=#1},
+ thickness=0.75pt
+}
+\begin{tikzpicture}[rings/.style={pattern=rings}]
+ \filldraw [rings, radius=2pt, size=6pt] (0,0) rectangle +(1.5,2);
+ \filldraw [rings, radius=2pt, size=8pt] (2,0) rectangle +(1.5,2);
+ \filldraw [rings, radius=6pt, thickness=2pt] (0,2.5) rectangle +(1.5,2);
+ \filldraw [rings, radius=8pt, thickness=4pt] (2,2.5) rectangle +(1.5,2);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfdeclarepatterninherentlycolored
+ \opt{\oarg{variables}}
+ \marg{name}
+ \marg{lower left}
+ \marg{upper right}
+ \marg{tile size}
+ \marg{code}%
+}
+ This command works like |\pgfdeclarepatternuncolored|, only the pattern
+ will have an inherent color. To set the color, you should use \pgfname's
+ color commands, not the |\color| command, since this fill is not
+ protocolled.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{patterns}}]
+\pgfdeclarepatterninherentlycolored{green stars}
+{\pgfpointorigin}{\pgfpoint{1cm}{1cm}}
+{\pgfpoint{1cm}{1cm}}
+{
+ \pgfsetfillcolor{green!50!black}
+ \pgftransformshift{\pgfpoint{.5cm}{.5cm}}
+ \pgfpathmoveto{\pgfpointpolar{0}{4mm}}
+ \pgfpathlineto{\pgfpointpolar{144}{4mm}}
+ \pgfpathlineto{\pgfpointpolar{288}{4mm}}
+ \pgfpathlineto{\pgfpointpolar{72}{4mm}}
+ \pgfpathlineto{\pgfpointpolar{216}{4mm}}
+ \pgfpathclose%
+ \pgfusepath{stroke,fill}
+}
+\begin{tikzpicture}
+ \filldraw[pattern=green stars] (0,0) rectangle (3,2);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+
+\subsection{Setting a Pattern}
+
+Once a pattern has been declared, it can be used.
+
+\begin{command}{\pgfsetfillpattern\marg{name}\marg{color}}
+ This command specifies that paths that are filled should be filled with the
+ ``color'' by the pattern \meta{name}. For an inherently colored pattern,
+ the \meta{color} parameter is ignored. For form-only patterns, the
+ \meta{color} parameter specifies the color to be used for the pattern.
+ %
+\begin{codeexample}[
+ preamble={\usetikzlibrary{patterns}
+\pgfdeclarepatternformonly{stars}
+{\pgfpointorigin}{\pgfpoint{1cm}{1cm}}
+{\pgfpoint{1cm}{1cm}}
+{
+ \pgftransformshift{\pgfpoint{.5cm}{.5cm}}
+ \pgfpathmoveto{\pgfpointpolar{0}{4mm}}
+ \pgfpathlineto{\pgfpointpolar{144}{4mm}}
+ \pgfpathlineto{\pgfpointpolar{288}{4mm}}
+ \pgfpathlineto{\pgfpointpolar{72}{4mm}}
+ \pgfpathlineto{\pgfpointpolar{216}{4mm}}
+ \pgfpathclose%
+ \pgfusepath{fill}
+}
+\pgfdeclarepatterninherentlycolored{green stars}
+{\pgfpointorigin}{\pgfpoint{1cm}{1cm}}
+{\pgfpoint{1cm}{1cm}}
+{
+ \pgfsetfillcolor{green!50!black}
+ \pgftransformshift{\pgfpoint{.5cm}{.5cm}}
+ \pgfpathmoveto{\pgfpointpolar{0}{4mm}}
+ \pgfpathlineto{\pgfpointpolar{144}{4mm}}
+ \pgfpathlineto{\pgfpointpolar{288}{4mm}}
+ \pgfpathlineto{\pgfpointpolar{72}{4mm}}
+ \pgfpathlineto{\pgfpointpolar{216}{4mm}}
+ \pgfpathclose%
+ \pgfusepath{stroke,fill}
+}}]
+\begin{tikzpicture}
+ \pgfsetfillpattern{stars}{red}
+ \filldraw (0,0) rectangle (1.5,2);
+
+ \pgfsetfillpattern{green stars}{red}
+ \filldraw (1.5,0) rectangle (3,2);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "pgfmanual"
+%%% End:
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-patterns.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-plots.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-plots.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-plots.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,587 @@
+% Copyright 2018 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section{Creating Plots}
+\label{section-plots}
+
+This section describes the |plot| module.
+
+\begin{pgfmodule}{plot}
+ This module provides a set of commands that are intended to make it
+ reasonably easy to plot functions using \pgfname. It is loaded
+ automatically by |pgf|, but you can load it manually if you have only
+ included |pgfcore|.
+\end{pgfmodule}
+
+
+\subsection{Overview}
+
+There are different reasons for using \pgfname\ for creating plots rather than
+some more powerful program such as \textsc{gnuplot} or \textsc{mathematica}, as
+discussed in Section~\ref{section-why-pgname-for-plots}. So, let us assume that
+-- for whatever reason -- you wish to use \pgfname\ for generating a plot.
+
+\pgfname\ (conceptually) uses a two-stage process for generating plots. First,
+a \emph{plot stream} must be produced. This stream consists (more or less) of a
+large number of coordinates. Second a \emph{plot handler} is applied to the
+stream. A plot handler ``does something'' with the stream. The standard handler
+will issue line-to operations to the coordinates in the stream. However, a
+handler might also try to issue appropriate curve-to operations in order to
+smooth the curve. A handler may even do something else entirely, like writing
+each coordinate to another stream, thereby duplicating the original stream.
+
+Both for the creation of streams and the handling of streams different sets of
+commands exist. The commands for creating streams start with |\pgfplotstream|,
+the commands for setting the handler start with |\pgfplothandler|.
+
+
+\subsection{Generating Plot Streams}
+
+\subsubsection{Basic Building Blocks of Plot Streams}
+
+A \emph{plot stream} is a (long) sequence of the following commands:
+%
+\begin{enumerate}
+ \item |\pgfplotstreamstart|,
+ \item |\pgfplotstreampoint|,
+ \item |\pgfplotstreampointoutlier|,
+ \item |\pgfplotstreampointundefined|,
+ \item |\pgfplotstreamnewdataset|,
+ \item |\pgfplotstreamspecial|, and
+ \item |\pgfplotstreamend|.
+\end{enumerate}
+%
+Between calls of these commands arbitrary other code may be called. Obviously,
+the stream should start with the first command and end with the last command.
+Here is an example of a plot stream:
+%
+\begin{codeexample}[code only]
+\pgfplotstreamstart
+\pgfplotstreampoint{\pgfpoint{1cm}{1cm}}
+\newdimen\mydim
+\mydim=2cm
+\pgfplotstreampoint{\pgfpoint{\mydim}{2cm}}
+\advance \mydim by 3cm
+\pgfplotstreampoint{\pgfpoint{\mydim}{2cm}}
+\pgfplotstreamend
+\end{codeexample}
+
+Streams are \emph{global}, meaning that they are not influenced by \TeX\
+groups.
+
+\begin{command}{\pgfplotstreamstart}
+ This command signals that a plot stream starts. The effect of this command
+ is to call the internal command |\pgf at plotstreamstart|, which is set by the
+ current plot handler to do whatever needs to be done at the beginning of
+ the plot. It will also reset the meaning of the internal commands like
+ |\pgf at plotstreampoint| to the initial setting for the plot handler (what
+ this means will be explained in a moment).
+\end{command}
+
+\begin{command}{\pgfplotstreampoint\marg{point}}
+ This command adds a \meta{point} to the current plot stream. The effect of
+ this command is to call the internal command |\pgf at plotstreampoint|, which
+ is also set by the current plot handler. This command should now ``handle''
+ the point in some sensible way. For example, a line-to command might be
+ issued for the point.
+
+ When a plot handler is installed, it will setup the internal command
+ |\pgf at plotstreampoint| in some way. It is permissible to change the meaning
+ of this internal command during a stream. For instance, a handler might
+ setup |\pgf at plotstreampoint| in some sensible way for the first point and
+ then redefine it so that subsequent points are handled in some other way.
+
+ As mentioned earlier, the |\pgfplotstreamstart| will always reset the
+ definition of the internal command to the initial meaning it had when the
+ handler was installed. This is true for the other commands mentioned in the
+ following.
+\end{command}
+
+\begin{command}{\pgfplotstreampointoutlier\marg{point}}
+ An \emph{outlier} is a point that is ``out of bounds'' in some way. For
+ instance, it might have very large coordinates or the coordinates might
+ just be outside some specified range. Nevertheless, an outlier is still a
+ well-defined point. This command is issued, for instance, by
+ \textsc{gnuplot} when a value is outside the specified range.
+
+ You can configure how outliers are treated using the following key:
+ %
+ \begin{key}{/pgf/handle outlier points in plots=\meta{how} (initially jump)}
+ \keyalias{tikz}
+ You can set \meta{how} to one of the following values:
+ %
+ \begin{itemize}
+ \item |plot| This will cause the outlier to be drawn normally, just
+ as if |\pgfplotstreampoint| had been used rather than this
+ command.
+ \item |ignore| The outlier will be completely ignored, just as if
+ the command had not been used at all.
+ \item |jump| This causes the internal macro |\pgf at plotstreamjump|
+ to be called. A ``jump'' in a stream is a position where a
+ ``gap'' is introduced. For instance, a simple line-to plot
+ handler will stop the current subpath at a jump position and
+ begin with a move-to operation at the next normal point of the
+ stream.
+
+ The net effect of this setting is that at outlier points plots
+ get interrupted and ``restarted'' when the points are no longer
+ outliers. This is usually the behavior you will be looking for.
+ \end{itemize}
+ \end{key}
+\end{command}
+
+\begin{command}{\pgfplotstreampointundefined}
+ This command indicated that the stream contains an ``undefined'' point like
+ a point where some coordinate results for a division by zero. Such a point
+ cannot be plotted, which is why it is not given as a parameter. However,
+ such a point \emph{can} result in a jump in the plot, depending on the
+ setting of the following key:
+ %
+ \begin{key}{/pgf/handle undefined points in plots=\meta{how} (initially jump)}
+ \keyalias{tikz}
+ You can set \meta{how} to one of the following values:
+ %
+ \begin{itemize}
+ \item |ignore| The undefined point will be completely ignored, just
+ as if the command had not been used at all.
+ \item |jump| This causes the internal macro |\pgf at plotstreamjump|
+ to be called.
+ \end{itemize}
+ \end{key}
+\end{command}
+
+\begin{command}{\pgfplotstreamnewdataset}
+ This command indicated that in the stream a ``new data set'' starts. So,
+ the stream does not end, but there is a logical break in the data. For
+ example, when a table is read from a file, empty lines are interpreted as
+ indicating new data sets. What happens when a new data set is encountered
+ is governed by the following key:
+ %
+ \begin{key}{/pgf/handle new data sets in plots=\meta{how} (initially jump)}
+ \keyalias{tikz}
+ You can set \meta{how} to one of the following values:
+ %
+ \begin{itemize}
+ \item |ignore| The command will be completely ignored, just as if
+ the command had not been used at all.
+ \item |jump| This causes the internal macro |\pgf at plotstreamjump|
+ to be called.
+ \end{itemize}
+ \end{key}
+\end{command}
+
+\begin{command}{\pgfplotstreamspecial\marg{text}}
+ This command causes |\pgf at plotstreamspecial| to be called with \meta{text}
+ as its parameter. This allows handler-specific information to be passed to
+ the handler. All normal handlers ignore this command.
+\end{command}
+
+\begin{command}{\pgfplotstreamend}
+ This command signals that a plot stream ends. It calls
+ |\pgf at plotstreamend|, which should now do any necessary ``cleanup''.
+\end{command}
+
+Note that plot streams are not buffered, that is, the different points are
+handled immediately. However, using the recording handler, it is possible to
+record a stream.
+
+
+\subsubsection{Commands That Generate Plot Streams}
+\label{section-plot-jumps}
+
+Plot streams can be created ``by hand'' as in the earlier example. However,
+most of the time the coordinates will be produced internally by some command.
+For example, the |\pgfplotxyfile| reads a file and converts it into a plot
+stream.
+
+\begin{command}{\pgfplotxyfile\marg{filename}}
+ This command will try to open the file \meta{filename}. If this succeeds,
+ it will convert the file contents into a plot stream as follows: A
+ |\pgfplotstreamstart| is issued. Then, for each empty line a
+ |\pgfplotstreamnewdataset| is produced. Other lines in the file should
+ start with two numbers separated by a space, such as |0.1 1| or |100 -.3|.
+ The numbers may be followed by some text, which will be ignore
+ \emph{except} if it is exactly ``|u|'' or ``|o|''. For ``|u|'' the point
+ is considered to be undefined and |\pgfplotstreampointundefined| is called.
+ For ``|o|'' the point is considered to be an outlier and
+ |\pgfplotstreampointoutlier| is called. Otherwise, each pair \meta{x} and
+ \meta{y} of numbers is converted into one plot stream point in the
+ $xy$-coordinate system. Thus, a line like
+ %
+\begin{codeexample}[code only, tikz syntax=false]
+0 Nan u
+1 1 some text
+2 4
+3 9
+
+4 16 o
+5 25 oo
+\end{codeexample}
+ %
+ is turned into
+ %
+\begin{codeexample}[code only]
+\pgfplotstreamstart
+\pgfplotstreampointundefined
+\pgfplotstreampoint{\pgfpointxy{1}{1}}
+\pgfplotstreampoint{\pgfpointxy{2}{4}}
+\pgfplotstreampoint{\pgfpointxy{3}{9}}
+\pgfplotstreamnewdataset
+\pgfplotstreampointoutlier{\pgfpointxy{4}{16}}
+\pgfplotstreampoint{\pgfpointxy{5}{25}}
+\pgfplotstreamend
+\end{codeexample}
+ %
+ (Note that the last line is not an outlier because |oo| is not the same as
+ |o|).
+
+ The two characters |%| and |#| are also allowed in a file and they are both
+ treated as comment characters. Thus, a line starting with either of them is
+ treated as empty.
+
+ When the file has been read completely, |\pgfplotstreamend| is called.
+\end{command}
+
+\begin{command}{\pgfplotxyzfile\marg{filename}}
+ This command works like |\pgfplotxyfile|, only \emph{three} numbers are
+ expected on each non-empty line. They are converted into points in the
+ $xyz$-coordinate system. Consider, the following file:
+ %
+\begin{codeexample}[code only, tikz syntax=false]
+% Some comments
+# more comments
+2 -5 1 first entry
+2 -.2 2 o
+2 -5 2 third entry
+\end{codeexample}
+ %
+ It is turned into the following stream:
+ %
+\begin{codeexample}[code only]
+\pgfplotstreamstart
+\pgfplotstreamnewdataset
+\pgfplotstreamnewdataset
+\pgfplotstreampoint{\pgfpointxyz{2}{-5}{1}}
+\pgfplotstreampointoutlier{\pgfpointxyz{2}{-.2}{2}}
+\pgfplotstreampoint{\pgfpointxyz{2}{-5}{2}}
+\pgfplotstreamend
+\end{codeexample}
+ %
+\end{command}
+
+Currently, there is no command that can decide automatically whether the
+$xy$-coordinate system should be used or whether the $xyz$-system should be
+used. However, it would not be terribly difficult to write a ``smart file
+reader'' that parses coordinate files a bit more intelligently.
+
+\begin{command}{\pgfplotfunction\marg{variable}\marg{sample list}\marg{point}}
+ This command will produce coordinates by iterating the \meta{variable} over
+ all values in \meta{sample list}, which should be a list in the |\foreach|
+ syntax. For each value of \meta{variable}, the \meta{point} is evaluated
+ and the resulting coordinate is inserted into the plot stream.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}[x=3.8cm/360]
+ \pgfplothandlerlineto
+ \pgfplotfunction{\x}{0,5,...,360}{\pgfpointxy{\x}{sin(\x)+sin(3*\x)}}
+ \pgfusepath{stroke}
+\end{tikzpicture}
+\end{codeexample}
+
+\begin{codeexample}[]
+\begin{tikzpicture}[y=3cm/360]
+ \pgfplothandlerlineto
+ \pgfplotfunction{\y}{0,5,...,360}{\pgfpointxyz{sin(2*\y)}{\y}{cos(2*\y)}}
+ \pgfusepath{stroke}
+\end{tikzpicture}
+\end{codeexample}
+
+ Be warned that if the expressions that need to evaluated for each point are
+ complex, then this command can be very slow.
+\end{command}
+
+\begin{command}{\pgfplotgnuplot\oarg{prefix}\marg{function}}
+ This command will ``try'' to call the \textsc{gnuplot} program to generate
+ the coordinates of the \meta{function}. In detail, the following happens:
+
+ This command works with two files: \meta{prefix}|.gnuplot| and
+ \meta{prefix}|.table|. If the optional argument \meta{prefix} is not
+ given, it is set to |\jobname|.
+
+ Let us start with the situation where none of these files exists. Then
+ \pgfname\ will first generate the file \meta{prefix}|.gnuplot|. In this
+ file it writes
+ %
+\begin{codeexample}[code only, tikz syntax=false]
+set table "#1.table"; set format "%.5f"
+\end{codeexample}
+ %
+ where |#1| is replaced by \meta{prefix}. Then, in a second line, it writes
+ the text \meta{function}.
+
+ Next, \pgfname\ will try to invoke the program |gnuplot| with the argument
+ \meta{prefix}|.gnuplot|. This call may or may not succeed, depending on
+ whether the |\write18| mechanism (also known as shell escape) is switched
+ on and whether the |gnuplot| program is available.
+
+ Assuming that the call succeeded, the next step is to invoke
+ |\pgfplotxyfile| on the file \meta{prefix}|.table|; which is exactly the
+ file that has just been created by |gnuplot|.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,-1) grid (4,1);
+ \pgfplothandlerlineto
+ \pgfplotgnuplot[plots/pgfplotgnuplot-example]{plot [x=0:3.5] x*sin(x)}
+ \pgfusepath{stroke}
+\end{tikzpicture}
+\end{codeexample}
+
+ The more difficult situation arises when the |.gnuplot| file exists, which
+ will be the case on the second run of \TeX\ on the \TeX\ file. In this case
+ \pgfname\ will read this file and check whether it contains exactly what
+ \pgfname\ ``would have written'' into this file. If this is not the case,
+ the file contents is overwritten with what ``should be there'' and, as
+ above, |gnuplot| is invoked to generate a new |.table| file. However, if
+ the file contents is ``as expected'', the external |gnuplot| program is
+ \emph{not} called. Instead, the \meta{prefix}|.table| file is immediately
+ read.
+
+ As explained in Section~\ref{section-tikz-gnuplot}, the net effect of the
+ above mechanism is that |gnuplot| is called as seldom as possible and that
+ when you pass along the |.gnuplot| and |.table| files with your |.tex| file
+ to someone else, that person can \TeX\ the |.tex| file without having
+ |gnuplot| installed and without having the |\write18| mechanism switched
+ on.
+
+ \begin{key}{/pgf/plot/gnuplot call=\meta{gnuplot invocation} (initially gnuplot)}
+ This key can be used to change the way gnuplot is called.
+
+ Some portable MiK\TeX{} distribution needs something like the
+ following.
+ %
+\begin{codeexample}[code only]
+ \pgfkeys{/pgf/plot/gnuplot call="/Programs/gnuplot/binary/gnuplot"}
+\end{codeexample}
+ \end{key}
+\end{command}
+
+
+\subsection{Plot Handlers}
+\label{section-plot-handlers}
+
+A \emph{plot handler} determines what ``should be done'' with a plot stream.
+You must set the plot handler before the stream starts. The following commands
+install the most basic plot handlers; more plot handlers are defined in the
+file |pgflibraryplothandlers|, which is documented in
+Section~\ref{section-library-plothandlers}.
+
+All plot handlers work by setting or redefining the following three macros:
+|\pgf at plotstreamstart|, |\pgf at plotstreampoint|, and |\pgf at plotstreamend|.
+
+\begin{command}{\pgfplothandlerlineto}
+ This handler will issue a |\pgfpathlineto| command for each point of the
+ plot, \emph{except} possibly for the first. What happens with the first
+ point can be specified using the two commands described below.
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfplothandlerlineto
+ \pgfplotstreamstart
+ \pgfplotstreampoint{\pgfpoint{1cm}{0cm}}
+ \pgfplotstreampoint{\pgfpoint{2cm}{1cm}}
+ \pgfplotstreampoint{\pgfpoint{3cm}{2cm}}
+ \pgfplotstreampoint{\pgfpoint{1cm}{2cm}}
+ \pgfplotstreamend
+ \pgfusepath{stroke}
+\end{pgfpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfsetmovetofirstplotpoint}
+ Specifies that the line-to plot handler (and also some other plot handlers)
+ should issue a move-to command for the first point of the plot instead of a
+ line-to. This will start a new part of the current path, which is not
+ always, but often, desirable. This is the default.
+\end{command}
+
+\begin{command}{\pgfsetlinetofirstplotpoint}
+ Specifies that plot handlers should issue a line-to command for the first
+ point of the plot.
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfsetlinetofirstplotpoint
+ \pgfplothandlerlineto
+ \pgfplotstreamstart
+ \pgfplotstreampoint{\pgfpoint{1cm}{0cm}}
+ \pgfplotstreampoint{\pgfpoint{2cm}{1cm}}
+ \pgfplotstreampoint{\pgfpoint{3cm}{2cm}}
+ \pgfplotstreampoint{\pgfpoint{1cm}{2cm}}
+ \pgfplotstreamend
+ \pgfusepath{stroke}
+\end{pgfpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfplothandlerpolygon}
+ This handler works like the line-to plot handler, only the line is closed
+ at the end using |\pgfpathclose|, resulting in a polygon.
+\end{command}
+
+\begin{command}{\pgfplothandlerdiscard}
+ This handler will simply throw away the stream.
+\end{command}
+
+\begin{command}{\pgfplothandlerrecord\marg{macro}}
+ When this handler is installed, each time a plot stream command is called,
+ this command will be appended to \meta{macro}. Thus, at the end of the
+ stream, \meta{macro} will contain all the commands that were issued on the
+ stream. You can then install another handler and invoke \meta{macro} to
+ ``replay'' the stream (possibly many times).
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgfplothandlerrecord{\mystream}
+ \pgfplotstreamstart
+ \pgfplotstreampoint{\pgfpoint{1cm}{0cm}}
+ \pgfplotstreampoint{\pgfpoint{2cm}{1cm}}
+ \pgfplotstreampoint{\pgfpoint{3cm}{1cm}}
+ \pgfplotstreampoint{\pgfpoint{1cm}{2cm}}
+ \pgfplotstreamend
+ \pgfplothandlerlineto
+ \mystream
+ \pgfplothandlerclosedcurve
+ \mystream
+ \pgfusepath{stroke}
+\end{pgfpicture}
+\end{codeexample}
+ %
+\end{command}
+
+
+\subsection{Defining New Plot Handlers}
+
+You can define new plot handlers using the following command:
+
+\begin{command}{\pgfdeclareplothandler\marg{macro}\marg{arguments}\marg{configuration}}
+ This command creates a new plot handler that can subsequently be called
+ using the macro \meta{macro}. This macro take the arguments given in
+ \meta{arguments}, which can be a list like |#1#2| if \meta{macro} should be
+ invoked with two arguments. Here is a typical example:
+ %
+\begin{codeexample}[code only]
+\pgfdeclareplothandler{\myhandler}{#1}{...}
+...
+\myhandler{foo}
+\pgfplotstreamstart
+...
+\pgfplotstreamend
+\end{codeexample}
+
+ The \meta{configuration} is used to define the behavior of the handler. It
+ is a list of key--value pairs, where the following keys are allowed:
+ %
+ \begin{itemize}
+ \item |start=|\meta{code}. The \meta{code} will be executed whenever
+ |\pgfplotstreamstart| is used while the handler \meta{macro} is
+ selected. Inside the \meta{code}, you can use |#1|, |#2|, and so on
+ to refer to the parameters that were given to \meta{macro}:
+ %
+\begin{codeexample}[width=6cm]
+\pgfdeclareplothandler{\myhandler}{#1}{
+ start = Hi #1.,
+ end = Bye #1.,
+}
+\myhandler{foo}
+\pgfplotstreamstart
+\pgfplotstreamend
+\myhandler{bar}
+\pgfplotstreamstart
+\pgfplotstreamend
+\end{codeexample}
+ %
+ \item |end=|\meta{code} Works just like |start|.
+ \item |point=|\meta{code}. The \meta{code} will be executed whenever
+ |\pgfplotstreampoint| is used while the handler \meta{macro} is in
+ force. Inside the \meta{code}, you can use |#1|, |#2|, and so on to
+ refer to the arguments give to \meta{macro}, while you can use
+ |##1| to refer to the argument given to |\pgfplotstreampoint|
+ itself (this will be the coordinate).
+ %
+\begin{codeexample}[]
+\pgfdeclareplothandler{\myhandler}{#1}{
+ point=\pgfpathcircle{##1}{#1} % ##1 is the coordinate,
+ % #1 the parameter for \myhandler
+}
+\begin{pgfpicture}
+ \myhandler{1pt}
+ \pgfplotstreamstart
+ \pgfplotstreampoint{\pgfpoint{0pt}{0pt}}
+ \pgfplotstreampoint{\pgfpoint{3pt}{3pt}}
+ \pgfplotstreampoint{\pgfpoint{6pt}{3pt}}
+ \pgfplotstreampoint{\pgfpoint{9pt}{0pt}}
+ \pgfplotstreamend
+ \pgfusepath{stroke}
+ \myhandler{3pt}
+ \pgfplotstreamstart
+ \pgfplotstreampoint{\pgfpoint{0pt}{0pt}}
+ \pgfplotstreampoint{\pgfpoint{9pt}{0pt}}
+ \pgfplotstreamend
+ \pgfusepath{stroke}
+\end{pgfpicture}
+\end{codeexample}
+ %
+ The \meta{code} will also be called for
+ |\pgfplotstreampointoutlier| when this command has been configured
+ to |plot| the outliers.
+ \item |jump=|\meta{code} The \meta{code} will be called whenever a jump
+ has been requested indirectly via an outlier point, and undefined
+ point, or a new data set (for each of which the command needs to be
+ configured to |jump|). As always, inside the \meta{code} you can
+ access |#1| and so on.
+ \item |special=|\meta{code} Causes \meta{code} to be executed whenever
+ |\pgfplotstreamspecial|\marg{something} is used. Inside the
+ \meta{code}, you can access \meta{something} via |##1| and the
+ parameters of \meta{macro} as |#1|, |#2|, and so on.
+ \end{itemize}
+
+ In addition to the above keys, there exist also ``code macro versions'' of
+ them:
+ %
+ \begin{itemize}
+ \item |point macro=|\meta{some macro}. Causes |\pgfplotstreampoint| to
+ call \meta{some macro} directly (actually, |\pgf at plotstreampoint|
+ is set to be equal to \meta{some macro}). Inside the \meta{some
+ macro} you can use |#1| to access the coordinate passed to
+ |\pgfplotstreampoint| and you can no longer access the parameters
+ passed to the original call to \meta{macro} that installed the
+ handler. So, \meta{some macro} must take exactly one argument,
+ namely |#1|.
+ \item |special macro=|\meta{some macro}. As |point macro|, only for
+ specials.
+ \item |start macro=|\meta{some macro}. Causes \meta{some macro} to be
+ executed at the start. This macro, like the below ones, may not
+ take any parameters and will not have access to the parameters
+ passed to the original \meta{macro}.
+ \item |end macro=|\meta{some macro}. As above.
+ \item |jump macro=|\meta{some macro}. As above.
+ \end{itemize}
+\end{command}
+
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "pgfmanual"
+%%% End:
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-plots.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-points.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-points.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-points.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,683 @@
+% Copyright 2019 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section{Specifying Coordinates}
+\label{section-points}
+
+\subsection{Overview}
+
+Most \pgfname\ commands expect you to provide the coordinates of a \emph{point}
+(also called \emph{coordinate}) inside your picture. Points are always
+``local'' to your picture, that is, they never refer to an absolute position on
+the page, but to a position inside the current |{pgfpicture}| environment. To
+specify a coordinate you can use commands that start with |\pgfpoint|.
+
+
+\subsection{Basic Coordinate Commands}
+
+The following commands are the most basic for specifying a coordinate.
+
+\begin{command}{\pgfpoint\marg{x coordinate}\marg{y coordinate}}
+ Yields a point location. The coordinates are given as \TeX\ dimensions.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgfpathcircle{\pgfpoint{1cm}{1cm}} {2pt}
+ \pgfpathcircle{\pgfpoint{2cm}{5pt}} {2pt}
+ \pgfpathcircle{\pgfpoint{0pt}{.5in}}{2pt}
+ \pgfusepath{fill}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfpointorigin}
+ Yields the origin. Same as |\pgfpoint{0pt}{0pt}|.
+\end{command}
+
+\begin{command}{\pgfpointpolar\marg{degree}{\ttfamily\char`\{}\meta{radius}\opt{|/|\meta{y-radius}}{\ttfamily\char`\}}}
+ Yields a point location given in polar coordinates. You can specify the
+ angle only in degrees, radians are not supported, currently.
+
+ If the optional \meta{y-radius} is given, the polar coordinate is actually
+ a coordinate on an ellipse whose $x$-radius is given by \meta{radius} and
+ whose $y$-radius is given by \meta{y-radius}.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+
+ \foreach \angle in {0,10,...,90}
+ {\pgfpathcircle{\pgfpointpolar{\angle}{1cm}}{2pt}}
+ \pgfusepath{fill}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+
+ \foreach \angle in {0,10,...,90}
+ {\pgfpathcircle{\pgfpointpolar{\angle}{1cm and 2cm}}{2pt}}
+ \pgfusepath{fill}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+
+\subsection{Coordinates in the XY-Coordinate System}
+
+Coordinates can also be specified as multiples of an $x$-vector and a
+$y$-vector. Normally, the $x$-vector points one centimeter in the $x$-direction
+and the $y$-vector points one centimeter in the $y$-direction, but using the
+commands |\pgfsetxvec| and |\pgfsetyvec| they can be changed. Note that the
+$x$- and $y$-vector do not necessarily point ``horizontally'' and
+``vertically''.
+
+\begin{command}{\pgfpointxy\marg{$s_x$}\marg{$s_y$}}
+ Yields a point that is situated at $s_x$ times the $x$-vector plus $s_y$
+ times the $y$-vector.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgfpathmoveto{\pgfpointxy{1}{0}}
+ \pgfpathlineto{\pgfpointxy{2}{2}}
+ \pgfusepath{stroke}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfsetxvec\marg{point}}
+ Sets that current $x$-vector for usage in the $xyz$-coordinate system.
+ \example
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+
+ \pgfpathmoveto{\pgfpointxy{1}{0}}
+ \pgfpathlineto{\pgfpointxy{2}{2}}
+ \pgfusepath{stroke}
+
+ \color{red}
+ \pgfsetxvec{\pgfpoint{0.75cm}{0cm}}
+ \pgfpathmoveto{\pgfpointxy{1}{0}}
+ \pgfpathlineto{\pgfpointxy{2}{2}}
+ \pgfusepath{stroke}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfsetyvec\marg{point}}
+ Works like |\pgfsetxvec|.
+\end{command}
+
+\begin{command}{\pgfpointpolarxy\marg{degree}{\ttfamily\char`\{}\meta{radius}\opt{|/|\meta{y-radius}}{\ttfamily\char`\}}}
+ This command is similar to the |\pgfpointpolar| command, but the
+ \meta{radius} is now a factor to be interpreted in the $xy$-coordinate
+ system. This means that a degree of |0| is the same as the $x$-vector of
+ the $xy$-coordinate system times \meta{radius} and a degree of |90| is the
+ $y$-vector times \meta{radius}. As for |\pgfpointpolar|, a \meta{radius}
+ can also be a pair separated by a slash. In this case, the $x$- and
+ $y$-vectors are multiplied by different factors.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+
+ \begin{scope}[x={(1cm,-5mm)},y=1.5cm]
+ \foreach \angle in {0,10,...,90}
+ {\pgfpathcircle{\pgfpointpolarxy{\angle}{1}}{2pt}}
+ \pgfusepath{fill}
+ \end{scope}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+
+\subsection{Three Dimensional Coordinates}
+
+It is also possible to specify a point as a multiple of three vectors, the
+$x$-, $y$-, and $z$-vector. This is useful for creating simple three
+dimensional graphics.
+
+\begin{command}{\pgfpointxyz\marg{$s_x$}\marg{$s_y$}\marg{$s_z$}}
+ Yields a point that is situated at $s_x$ times the $x$-vector plus $s_y$
+ times the $y$-vector plus $s_z$ times the $z$-vector.
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgfsetarrowsend{to}
+
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathlineto{\pgfpointxyz{0}{0}{1}}
+ \pgfusepath{stroke}
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathlineto{\pgfpointxyz{0}{1}{0}}
+ \pgfusepath{stroke}
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathlineto{\pgfpointxyz{1}{0}{0}}
+ \pgfusepath{stroke}
+\end{pgfpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfsetzvec\marg{point}}
+ Works like |\pgfsetxvec|.
+\end{command}
+
+Inside the $xyz$-coordinate system, you can also specify points using spherical
+and cylindrical coordinates.
+
+\begin{command}{\pgfpointcylindrical\marg{degree}\marg{radius}\marg{height}}
+ This command yields the same as
+ %
+\begin{verbatim}
+\pgfpointadd{\pgfpointpolarxy{degree}{radius}}{\pgfpointxyz{0}{0}{height}}
+\end{verbatim}
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw [->] (0,0) -- (1,0,0) node [right] {$x$};
+ \draw [->] (0,0) -- (0,1,0) node [above] {$y$};
+ \draw [->] (0,0) -- (0,0,1) node [below left] {$z$};
+
+ \pgfpathcircle{\pgfpointcylindrical{80}{1}{.5}}{2pt}
+ \pgfusepath{fill}
+
+ \draw[red] (0,0) -- (0,0,.5) -- +(80:1);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfpointspherical\marg{longitude}\marg{latitude}\marg{radius}}
+ This command yields a point ``on the surface of the earth'' specified by
+ the \meta{longitude} and the \meta{latitude}. The radius of the earth is
+ given by \meta{radius}. The equator lies in the $xy$-plane.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \pgfsetfillcolor{lightgray}
+
+ \foreach \latitude in {-90,-75,...,30}
+ {
+ \foreach \longitude in {0,20,...,360}
+ {
+ \pgfpathmoveto{\pgfpointspherical{\longitude}{\latitude}{1}}
+ \pgfpathlineto{\pgfpointspherical{\longitude+20}{\latitude}{1}}
+ \pgfpathlineto{\pgfpointspherical{\longitude+20}{\latitude+15}{1}}
+ \pgfpathlineto{\pgfpointspherical{\longitude}{\latitude+15}{1}}
+ \pgfpathclose
+ }
+ \pgfusepath{fill,stroke}
+ }
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+
+\subsection{Building Coordinates From Other Coordinates}
+
+Many commands allow you to construct a coordinate in terms of other
+coordinates.
+
+
+\subsubsection{Basic Manipulations of Coordinates}
+
+\begin{command}{\pgfpointadd\marg{$v_1$}\marg{$v_2$}}
+ Returns the sum vector $\meta{$v_1$} + \meta{$v_2$}$.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgfpathcircle{\pgfpointadd{\pgfpoint{1cm}{0cm}}{\pgfpoint{1cm}{1cm}}}{2pt}
+ \pgfusepath{fill}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfpointscale\marg{factor}\marg{coordinate}}
+ Returns the vector $\meta{factor}\meta{coordinate}$.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgfpathcircle{\pgfpointscale{1.5}{\pgfpoint{1cm}{0cm}}}{2pt}
+ \pgfusepath{fill}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfpointdiff\marg{start}\marg{end}}
+ Returns the difference vector $\meta{end} - \meta{start}$.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgfpathcircle{\pgfpointdiff{\pgfpoint{1cm}{0cm}}{\pgfpoint{1cm}{1cm}}}{2pt}
+ \pgfusepath{fill}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfpointnormalised\marg{point}}
+ This command returns a normalised version of \meta{point}, that is, a
+ vector of length 1pt pointing in the direction of \meta{point}. If
+ \meta{point} is the $0$-vector or extremely short, a vector of length 1pt
+ pointing upwards is returned.
+
+ This command is \emph{not} implemented by calculating the length of the
+ vector, but rather by calculating the angle of the vector and then using
+ (something equivalent to) the |\pgfpointpolar| command. This ensures that
+ the point will really have length 1pt, but it is not guaranteed that the
+ vector will \emph{precisely} point in the direction of \meta{point} due to
+ the fact that the polar tables are accurate only up to one degree.
+ Normally, this is not a problem.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgfpathcircle{\pgfpoint{2cm}{1cm}}{2pt}
+ \pgfpathcircle{\pgfpointscale{20}
+ {\pgfpointnormalised{\pgfpoint{2cm}{1cm}}}}{2pt}
+ \pgfusepath{fill}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+
+\subsubsection{Points Traveling along Lines and Curves}
+\label{section-pointsattime}
+
+The commands in this section allow you to specify points on a line or a curve.
+Imagine a point ``traveling'' along a curve from some point $p$ to another
+point $q$. At time $t=0$ the point is at $p$ and at time $t=1$ it is at $q$ and
+at time, say, $t=1/2$ it is ``somewhere in the middle''. The exact location at
+time $t=1/2$ will not necessarily be the ``halfway point'', that is, the point
+whose distance on the curve from $p$ and $q$ is equal. Rather, the exact
+location will depend on the ``speed'' at which the point is traveling, which in
+turn depends on the lengths of the support vectors in a complicated manner. If
+you are interested in the details, please see a good book on Bézier curves.
+
+\begin{command}{\pgfpointlineattime\marg{time $t$}\marg{point $p$}\marg{point $q$}}
+ Yields a point that is the $t$th fraction between $p$ and~$q$, that is, $p
+ + t(q-p)$. For $t=1/2$ this is the middle of $p$ and $q$.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathlineto{\pgfpoint{2cm}{2cm}}
+ \pgfusepath{stroke}
+ \foreach \t in {0,0.25,...,1.25}
+ {\pgftext[at=
+ \pgfpointlineattime{\t}{\pgfpointorigin}{\pgfpoint{2cm}{2cm}}]{\t}}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfpointlineatdistance\marg{distance}\marg{start point}\marg{end point}}
+ Yields a point that is located \meta{distance} many units away from the
+ start point in the direction of the end point. In other words, this is the
+ point that results if we travel \meta{distance} steps from \meta{start
+ point} towards \meta{end point}.
+ %
+ \example
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathlineto{\pgfpoint{3cm}{2cm}}
+ \pgfusepath{stroke}
+ \foreach \d in {0pt,20pt,40pt,70pt}
+ {\pgftext[at=
+ \pgfpointlineatdistance{\d}{\pgfpointorigin}{\pgfpoint{3cm}{2cm}}]{\d}}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfpointarcaxesattime\marg{time $t$}\marg{center}\marg{0-degree axis}\marg{90-degree axis}\marg{start angle}\\\marg{end angle}}
+ Yields a point on the arc between \meta{start angle} and \meta{end angle}
+ on an ellipse whose center is at \meta{center} and whose two principal axes
+ are \meta{0-degree axis} and \meta{90-degree axis}. For $t=0$ the point at
+ the \meta{start angle} is returned and for $t=1$ the point at the \meta{end
+ angle}.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgfpathmoveto{\pgfpoint{2cm}{1cm}}
+ \pgfpatharcaxes{0}{60}{\pgfpoint{2cm}{0cm}}{\pgfpoint{0cm}{1cm}}
+ \pgfusepath{stroke}
+ \foreach \t in {0,0.25,0.5,0.75,1}
+ {\pgftext[at=\pgfpointarcaxesattime{\t}{\pgfpoint{0cm}{1cm}}
+ {\pgfpoint{2cm}{0cm}}{\pgfpoint{0cm}{1cm}}{0}{60}]{\t}}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfpointcurveattime\marg{time $t$}\marg{point $p$}\marg{point $s_1$}\marg{point $s_2$}\marg{point $q$}}
+ Yields a point that is on the Bézier curve from $p$ to $q$ with the support
+ points $s_1$ and $s_2$. The time $t$ is used to determine the location,
+ where $t=0$ yields $p$ and $t=1$ yields $q$.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathcurveto
+ {\pgfpoint{0cm}{2cm}}{\pgfpoint{0cm}{2cm}}{\pgfpoint{3cm}{2cm}}
+ \pgfusepath{stroke}
+ \foreach \t in {0,0.25,0.5,0.75,1}
+ {\pgftext[at=\pgfpointcurveattime{\t}{\pgfpointorigin}
+ {\pgfpoint{0cm}{2cm}}
+ {\pgfpoint{0cm}{2cm}}
+ {\pgfpoint{3cm}{2cm}}]{\t}}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+
+\subsubsection{Points on Borders of Objects}
+
+The following commands are useful for specifying a point that lies on the
+border of special shapes. They are used, for example, by the shape mechanism to
+determine border points of shapes.
+
+\begin{command}{\pgfpointborderrectangle\marg{direction point}\marg{corner}}
+ This command returns a point that lies on the intersection of a line
+ starting at the origin and going towards the point \meta{direction point}
+ and a rectangle whose center is in the origin and whose upper right corner
+ is at \meta{corner}.
+
+ The \meta{direction point} should have length ``about 1pt'', but it will be
+ normalized automatically. Nevertheless, the ``nearer'' the length is to
+ 1pt, the less rounding errors.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (2,1.5);
+ \pgfpathrectanglecorners{\pgfpoint{-1cm}{-1.25cm}}{\pgfpoint{1cm}{1.25cm}}
+ \pgfusepath{stroke}
+
+ \pgfpathcircle{\pgfpoint{5pt}{5pt}}{2pt}
+ \pgfpathcircle{\pgfpoint{-10pt}{5pt}}{2pt}
+ \pgfusepath{fill}
+ \color{red}
+ \pgfpathcircle{\pgfpointborderrectangle
+ {\pgfpoint{5pt}{5pt}}{\pgfpoint{1cm}{1.25cm}}}{2pt}
+ \pgfpathcircle{\pgfpointborderrectangle
+ {\pgfpoint{-10pt}{5pt}}{\pgfpoint{1cm}{1.25cm}}}{2pt}
+ \pgfusepath{fill}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfpointborderellipse\marg{direction point}\marg{corner}}
+ This command works like the corresponding command for rectangles, only this
+ time the \meta{corner} is the corner of the bounding rectangle of an
+ ellipse.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (2,1.5);
+ \pgfpathellipse{\pgfpointorigin}{\pgfpoint{1cm}{0cm}}{\pgfpoint{0cm}{1.25cm}}
+ \pgfusepath{stroke}
+
+ \pgfpathcircle{\pgfpoint{5pt}{5pt}}{2pt}
+ \pgfpathcircle{\pgfpoint{-10pt}{5pt}}{2pt}
+ \pgfusepath{fill}
+ \color{red}
+ \pgfpathcircle{\pgfpointborderellipse
+ {\pgfpoint{5pt}{5pt}}{\pgfpoint{1cm}{1.25cm}}}{2pt}
+ \pgfpathcircle{\pgfpointborderellipse
+ {\pgfpoint{-10pt}{5pt}}{\pgfpoint{1cm}{1.25cm}}}{2pt}
+ \pgfusepath{fill}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+
+\subsubsection{Points on the Intersection of Lines}
+
+\begin{command}{\pgfpointintersectionoflines\marg{$p$}\marg{$q$}\marg{$s$}\marg{$t$}}
+ This command returns the intersection of a line going through $p$ and $q$
+ and a line going through $s$ and $t$. If the lines do not intersection, an
+ arithmetic overflow will occur.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (2,2);
+ \draw (.5,0) -- (2,2);
+ \draw (1,2) -- (2,0);
+ \pgfpathcircle{%
+ \pgfpointintersectionoflines
+ {\pgfpointxy{.5}{0}}{\pgfpointxy{2}{2}}
+ {\pgfpointxy{1}{2}}{\pgfpointxy{2}{0}}}
+ {2pt}
+ \pgfusepath{stroke}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+
+\subsubsection{Points on the Intersection of Two Circles}
+
+\begin{command}{\pgfpointintersectionofcircles\marg{$p_1$}\marg{$p_2$}\marg{$r_1$}\marg{$r_2$}\marg{solution}}
+ This command returns the intersection of the two circles centered at $p_1$
+ and $p_2$ with radii $r_1$ and $r_2$. If \meta{solution} is |1|, the first
+ intersection is returned, otherwise the second one is returned.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (2,2);
+ \draw (0.5,0) circle (1);
+ \draw (1.5,1) circle (.8);
+ \pgfpathcircle{%
+ \pgfpointintersectionofcircles
+ {\pgfpointxy{.5}{0}}{\pgfpointxy{1.5}{1}}
+ {1cm}{0.8cm}{1}}
+ {2pt}
+ \pgfusepath{stroke}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+
+\subsubsection{Points on the Intersection of Two Paths}
+
+\begin{pgflibrary}{intersections}
+ This library defines the below command and allows you to calculate the
+ intersections of two arbitrary paths. However, due to the low accuracy of
+ \TeX, the paths should not be ``too complicated''. In particular, you
+ should not try to intersect paths consisting of lots of very small segments
+ such as plots or decorated paths.
+\end{pgflibrary}
+
+\begin{command}{\pgfintersectionofpaths\marg{path 1}\marg{path 2}}
+ This command finds the intersection points on the paths \meta{path 1} and
+ \meta{path 2}. The number of intersection points (``solutions'') that are
+ found will be stored, and each point can be accessed afterward. The code
+ for \meta{path 1} and \meta{path 2} is executed within a \TeX{} group and
+ so can contain transformations (which will be in addition to any existing
+ transformations). The code should not use the path in any way, unless the
+ path is saved first and restored afterward. \pgfname{} will regard
+ solutions as ``a bit special'', in that the points returned will be
+ ``absolute'' and unaffected by any further transformations.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{intersections}}]
+\begin{pgfpicture}
+\pgfintersectionofpaths
+{
+ \pgfpathellipse{\pgfpointxy{0}{0}}{\pgfpointxy{1}{0}}{\pgfpointxy{0}{2}}
+ \pgfgetpath\temppath
+ \pgfusepath{stroke}
+ \pgfsetpath\temppath
+}
+{
+ \pgftransformrotate{-30}
+ \pgfpathrectangle{\pgfpointorigin}{\pgfpointxy{2}{2}}
+ \pgfgetpath\temppath
+ \pgfusepath{stroke}
+ \pgfsetpath\temppath
+}
+\foreach \s in {1,...,\pgfintersectionsolutions}
+ {\pgfpathcircle{\pgfpointintersectionsolution{\s}}{2pt}}
+\pgfusepath{stroke}
+\end{pgfpicture}
+\end{codeexample}
+
+ \begin{command}{\pgfintersectionsolutions}
+ After using the |\pgfintersectionofpaths| command, this \TeX-macro will
+ indicate the number of solutions found.
+ \end{command}
+
+ \begin{command}{\pgfpointintersectionsolution\marg{number}}
+ After using the |\pgfintersectionofpaths| command, this command will
+ return the point for solution \meta{number} or the origin if this
+ solution was not found. By default, the intersections are simply
+ returned in the order that the intersection algorithm finds them.
+ Unfortunately, this is not necessarily a ``helpful'' ordering. However
+ the following two commands can be used to order the solutions more
+ helpfully.
+ \end{command}
+
+ \let\ifpgfintersectionsortbyfirstpath=\relax
+ \begin{command}{\pgfintersectionsortbyfirstpath}
+ Using this command will mean the solutions will be sorted along
+ \meta{path 1}.
+ \end{command}
+
+ \let\ifpgfintersectionsortbysecondpath=\relax
+ \begin{command}{\pgfintersectionsortbysecondpath}
+ Using this command will mean the solutions will be sorted along
+ \meta{path 2}.
+ \end{command}
+\end{command}
+
+
+\subsection{Extracting Coordinates}
+
+There are two commands that can be used to ``extract'' the $x$- or
+$y$-coordinate of a coordinate.
+
+\begin{command}{\pgfextractx\marg{dimension}\marg{point}}
+ Sets the \TeX-\meta{dimension} to the $x$-coordinate of the point.
+ %
+\begin{codeexample}[code only]
+\newdimen\mydim
+\pgfextractx{\mydim}{\pgfpoint{2cm}{4pt}}
+%% \mydim is now 2cm
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfextracty\marg{dimension}\marg{point}}
+ Like |\pgfextractx|, except for the $y$-coordinate.
+\end{command}
+
+\begin{command}{\pgfgetlastxy\marg{macro for $x$}\marg{macro for $y$}}
+ Stores the most recently used $(x,y)$ coordinates into two macros.
+ %
+\begin{codeexample}[]
+\pgfpoint{2cm}{4cm}
+\pgfgetlastxy{\macrox}{\macroy}
+Macro $x$ is `\macrox' and macro $y$ is `\macroy'.
+\end{codeexample}
+ %
+ Since $(x,y)$ coordinates are usually assigned globally, it is safe to use
+ this command after path operations.
+\end{command}
+
+
+\subsection{Internals of How Point Commands Work}
+\label{section-internal-pointcmds}
+
+As a normal user of \pgfname\ you do not need to read this section. It is
+relevant only if you need to understand how the point commands work internally.
+
+When a command like |\pgfpoint{1cm}{2pt}| is called, all that happens is that
+the two \TeX-dimension variables |\pgf at x| and |\pgf at y| are set to |1cm| and
+|2pt|, respectively. These variables belong to the set of internal \pgfname\
+registers, see section~\ref{section-internal-registers} for details. A command
+like |\pgfpathmoveto| that takes a coordinate as parameter will just execute
+this parameter and then use the values of |\pgf at x| and |\pgf at y| as the
+coordinates to which it will move the pen on the current path.
+
+Since commands like |\pgfpointnormalised| modify other variables besides
+|\pgf at x| and |\pgf at y| during the computation of the final values of |\pgf at x|
+and |\pgf at y|, it is a good idea to enclose a call of a command like |\pgfpoint|
+in a \TeX-scope and then make the changes of |\pgf at x| and |\pgf at y| global as in
+the following example:
+ %
+\begin{codeexample}[code only]
+...
+{ % open scope
+ \pgfpointnormalised{\pgfpoint{1cm}{1cm}}
+ \global\pgf at x=\pgf at x % make the change of \pgf at x persist past the scope
+ \global\pgf at y=\pgf at y % make the change of \pgf at y persist past the scope
+}
+% \pgf at x and \pgf at y are now set correctly, all other variables are
+% unchanged
+\end{codeexample}
+
+\makeatletter
+Since this situation arises very often, the macro |\pgf at process| can
+be used to perform the above code:
+ %
+\begin{command}{\pgf at process\marg{code}}
+ Executes the \meta{code} in a scope and then makes |\pgf at x| and |\pgf at y|
+ global.
+\end{command}
+
+Note that this macro is used often internally. For this reason, it is not a
+good idea to keep anything important in the variables |\pgf at x| and |\pgf at y|
+since they will be overwritten and changed frequently. Instead, intermediate
+values can be stored in the \TeX-dimensions |\pgf at xa|, |\pgf at xb|, |\pgf at xc| and
+their |y|-counterparts |\pgf at ya|, |\pgf at yb|, |\pgf at yc|. For example, here is the
+code of the command |\pgfpointadd|:
+%
+\begin{codeexample}[code only]
+\def\pgfpointadd#1#2{%
+ \pgf at process{#1}%
+ \pgf at xa=\pgf at x%
+ \pgf at ya=\pgf at y%
+ \pgf at process{#2}%
+ \advance\pgf at x by\pgf at xa%
+ \advance\pgf at y by\pgf at ya}
+\end{codeexample}
+
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "pgfmanual"
+%%% End:
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-points.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-quick.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-quick.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-quick.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,189 @@
+% Copyright 2019 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section{Quick Commands}
+
+This section explains the ``quick'' commands of \pgfname. These commands are
+executed more quickly than the normal commands of \pgfname, but offer less
+functionality. You should use these commands only if you either have a very
+large number of commands that need to be processed or if you expect your
+commands to be executed very often.
+
+
+\subsection{Quick Coordinate Commands}
+
+\begin{command}{\pgfqpoint\marg{x}\marg{y}}
+ This command does the same as |\pgfpoint|, but \meta{x} and \meta{y} must
+ be simple dimensions like |1pt| or |1cm|. Things like |2ex| or |2cm+1pt|
+ are not allowed.
+\end{command}
+
+\begin{command}{\pgfqpointxy\marg{$s_x$}\marg{$s_y$}}
+ This command does the same as |\pgfpointxy|, but \meta{$s_x$} and
+ \meta{$s_y$} must be simple numbers without unit, like |1.234| or |5.0|.
+ Mathematical expressions or units are not allowed.
+\end{command}
+
+\begin{command}{\pgfqpointxyz\marg{$s_x$}\marg{$s_y$}\marg{$s_z$}}
+ As |\pgfqpointxy|, but for three-dimensional coordinates. Any argument
+ needs to be a number without unit.
+\end{command}
+
+\begin{command}{\pgfqpointscale\marg{factor}\marg{coordinate}}
+ As |\pgfpointscale|, but \marg{factor} must be a simple number without
+ unit, as for the other ``quick'' commands.
+\end{command}
+
+
+\subsection{Quick Path Construction Commands}
+
+The difference between the quick and the normal path commands is that the quick
+path commands
+%
+\begin{itemize}
+ \item do not keep track of the bounding boxes,
+ \item do not allow you to arc corners,
+ \item do not apply coordinate transformations.
+\end{itemize}
+
+However, they do use the soft-path subsystem (see
+Section~\ref{section-soft-paths} for details), which allows you to mix quick
+and normal path commands arbitrarily.
+
+All quick path construction commands start with |\pgfpathq|.
+
+\begin{command}{\pgfpathqmoveto\marg{x dimension}\marg{y dimension}}
+ Either starts a path or starts a new part of a path at the coordinate
+ $(\meta{x dimension},\meta{y dimension})$. The coordinate is \emph{not}
+ transformed by the current coordinate transformation matrix. However, any
+ low-level transformations apply.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgftransformxshift{1cm}
+ \pgfpathqmoveto{0pt}{0pt} % not transformed
+ \pgfpathqlineto{1cm}{1cm} % not transformed
+ \pgfpathlineto{\pgfpoint{2cm}{0cm}}
+ \pgfusepath{stroke}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfpathqlineto\marg{x dimension}\marg{y dimension}}
+ The quick version of the line-to operation.
+\end{command}
+
+\begin{command}{\pgfpathqcurveto\marg{$s^1_x$}\marg{$s^1_y$}\marg{$s^2_x$}\marg{$s^2_y$}\marg{$t_x$}\marg{$t_y$}}
+ The quick version of the curve-to operation. The first support point is
+ $(s^1_x,s^1_y)$, the second support point is $(s^2_x,s^2_y)$, and the
+ target is $(t_x,t_y)$.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgfpathqmoveto{0pt}{0pt}
+ \pgfpathqcurveto{1cm}{1cm}{2cm}{1cm}{3cm}{0cm}
+ \pgfusepath{stroke}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfpathqcircle\marg{radius}}
+ Adds a radius around the origin of the given \meta{radius}. This command is
+ orders of magnitude faster than |\pgfcircle{\pgfpointorigin}{|\meta{radius}|}|.
+ %
+\begin{codeexample}[]
+\colorlet{examplefill}{yellow!80!black}
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (1,1);
+ \pgfpathqcircle{10pt}
+ \pgfsetfillcolor{examplefill}
+ \pgfusepath{stroke,fill}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+
+\subsection{Quick Path Usage Commands}
+
+The quick path usage commands perform similar tasks as |\pgfusepath|, but they
+%
+\begin{itemize}
+ \item do not add arrows,
+ \item do not modify the path in any way, in particular,
+ \item ends are not shortened,
+ \item corners are not replaced by arcs.
+\end{itemize}
+
+Note that you \emph{have to} use the quick versions in the code of arrow tip
+definitions since, inside these definition, you obviously do not want arrows to
+be drawn.
+
+\begin{command}{\pgfusepathqstroke}
+ Strokes the path without further ado. No arrows are drawn, no corners are
+ arced.
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgfpathqcircle{5pt}
+ \pgfusepathqstroke
+\end{pgfpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfusepathqfill}
+ Fills the path without further ado.
+\end{command}
+
+\begin{command}{\pgfusepathqfillstroke}
+ Fills and then strokes the path without further ado.
+\end{command}
+
+\begin{command}{\pgfusepathqclip}
+ Clips all subsequent drawings against the current path. The path is not
+ processed.
+\end{command}
+
+
+\subsection{Quick Text Box Commands}
+
+\begin{command}{\pgfqbox\marg{box number}}
+ This command inserts a \TeX\ box into a |{pgfpicture}| by ``escaping'' to
+ \TeX, inserting the box number \meta{box number} at the origin, and then
+ returning to the typesetting the picture.
+\end{command}
+
+\begin{command}{\pgfqboxsynced\marg{box number}}
+ This command works similarly to the |\pgfqbox| command. However, before
+ inserting the text in \meta{box number}, the current coordinate
+ transformation matrix is applied to the current canvas transformation
+ matrix (is it ``synced'' with this matrix, hence the name).
+
+ Thus, this command basically has the same effect as if you first called
+ |\pgflowlevelsynccm| followed by |\pgfqbox|. However, this command will use
+ |\hskip| and |\raise| commands for the ``translational part'' of the
+ coordinate transformation matrix, instead of adding the translational part
+ to the current canvas transformation matrix directly. Both methods have the
+ same effect (box \meta{box number} is translated to where it should be),
+ but the method used by |\pgfqboxsynced| ensures that hyperlinks are placed
+ correctly. Note that scaling and rotation will not (cannot, even) apply to
+ hyperlinks.
+\end{command}
+
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "pgfmanual"
+%%% End:
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-quick.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-scopes.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-scopes.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-scopes.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,1027 @@
+% Copyright 2019 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section[Hierarchical Structures: Package, Environments, Scopes, and Text]
+ {Hierarchical Structures:\\
+ Package, Environments, Scopes, and Text}
+
+\subsection{Overview}
+
+\pgfname\ uses two kinds of hierarchical structuring: First, the package itself
+is structured hierarchically, consisting of different packages that are built
+on top of each other. Second, \pgfname\ allows you to structure your graphics
+hierarchically using environments and scopes.
+
+
+\subsubsection{The Hierarchical Structure of the Package}
+
+The \pgfname\ system consists of several layers:
+%
+\begin{description}
+ \item[System layer.]
+ The lowest layer is called the \emph{system layer}, though it might
+ also be called ``driver layer'' or perhaps ``backend layer''. Its job
+ is to provide an abstraction of the details of which driver is used to
+ transform the |.dvi| file. The system layer is implemented by the
+ package |pgfsys|, which will load appropriate driver files as needed.
+
+ The system layer is documented in Part~\ref{part-system}.
+ \item[Basic layer.]
+ The basic layer is loaded by the package |pgfcore| and subsequent use
+ of the command |\usepgfmodule| to load additional modules of the basic
+ layer.
+
+ The basic layer is documented in the present part.
+ \item[Frontend layer.]
+ The frontend layer is not loaded by a single package. Rather, different
+ packages, like \tikzname\ or \textsc{pgfpict2e}, are different
+ frontends to the basic layer.
+
+ The \tikzname\ frontend is documented in Part~\ref{part-tikz}.
+\end{description}
+
+Each layer will automatically load the necessary files of the layers below it.
+
+In addition to the packages of these layers, there are also some library
+packages. These packages provide additional definitions of things like new
+arrow tips or new plot handlers.
+
+The library packages are documented in Part~\ref{part-libraries}.
+
+
+\subsubsection{The Hierarchical Structure of Graphics}
+
+Graphics in \pgfname\ are typically structured hierarchically. Hierarchical
+structuring can be used to identify groups of graphical elements that are to be
+treated ``in the same way''. For example, you might group together a number of
+paths, all of which are to be drawn in red. Then, when you decide later on that
+you like them to be drawn in, say, blue, all you have to do is to change the
+color once.
+
+The general mechanism underlying hierarchical structuring is known as
+\emph{scoping} in computer science. The idea is that all changes to the general
+``state'' of the graphic that are done inside a scope are local to that scope.
+So, if you change the color inside a scope, this does not affect the color used
+outside the scope. Likewise, when you change the line width in a scope, the
+line width outside is not changed, and so on.
+
+There are different ways of starting and ending scopes of graphic parameters.
+Unfortunately, these scopes are sometimes ``in conflict'' with each other and
+it is sometimes not immediately clear which scopes apply. In essence, the
+following scoping mechanisms are available:
+%
+\begin{enumerate}
+ \item The ``outermost'' scope supported by \pgfname\ is the |{pgfpicture}|
+ environment. All changes to the graphic state done inside a
+ |{pgfpicture}| are local to that picture.
+
+ In general, it is \emph{not} possible to set graphic parameters
+ globally outside any |{pgfpicture}| environments. Thus, you can
+ \emph{not} say |\pgfsetlinewidth{1pt}| at the beginning of your
+ document to have a default line width of one point. Rather, you have to
+ (re)set all graphic parameters inside each |{pgfpicture}|. (If this is
+ too bothersome, try defining some macro that does the job for you.)
+ \item Inside a |{pgfpicture}| you can use a |{pgfscope}| environment to
+ keep changes of the graphic state local to that environment.
+
+ The effect of commands that change the graphic state are local to the
+ current |{pgfscope}|, but not always to the current \TeX\ group. Thus,
+ if you open a \TeX\ group (some text in curly braces) inside a
+ |{pgfscope}|, and if you change, for example, the dash pattern, the
+ effect of this changed dash pattern will persist till the end of the
+ |{pgfscope}|.
+
+ Unfortunately, this is not always the case. \emph{Some} graphic
+ parameters only persist till the end of the current \TeX\ group. For
+ example, when you use |\pgfsetarrows| to set the arrow tip inside a
+ \TeX\ group, the effect lasts only till the end of the current \TeX\
+ group.
+ \item Some graphic parameters are not scoped by |{pgfscope}| but
+ ``already'' by \TeX\ groups. For example, the effect of coordinate
+ transformation commands is always local to the current \TeX\ group.
+
+ Since every |{pgfscope}| automatically creates a \TeX\ group, all
+ graphic parameters that are local to the current \TeX\ group are also
+ local to the current |{pgfscope}|.
+ \item Some graphic parameters can only be scoped using \TeX\ groups, since
+ in some situations it is not possible to introduce a |{pgfscope}|. For
+ example, a path always has to be completely constructed and used in the
+ same |{pgfscope}|. However, we might wish to have different coordinate
+ transformations apply to different points on the path. In this case, we
+ can use \TeX\ groups to keep the effect local, but we could not use
+ |{pgfscope}|.
+ \item The |\pgftext| command can be used to create a scope in which \TeX\
+ ``escapes back'' to normal \TeX\ mode. The text passed to the
+ |\pgftext| is ``heavily guarded'' against having any effect on the
+ scope in which it is used. For example, it is possible to use another
+ |{pgfpicture}| environment inside the argument of |\pgftext|.
+\end{enumerate}
+
+Most of the complications can be avoided if you stick to the following
+rules:
+%
+\begin{itemize}
+ \item Give graphic commands only inside |{pgfpicture}| environments.
+ \item Use |{pgfscope}| to structure graphics.
+ \item Do not use \TeX\ groups inside graphics, \emph{except} for keeping
+ the effect of coordinate transformations local.
+\end{itemize}
+
+
+\subsection{The Hierarchical Structure of the Package}
+
+Before we come to the structuring commands provided by \pgfname\ to structure
+your graphics, let us first have a look at the structure of the package itself.
+
+
+\subsubsection{The Core Package}
+
+To use \pgfname, include the following package:
+
+\begin{package}{pgfcore}
+ This package loads the complete core of the ``basic layer'' of \pgfname,
+ but not any modules. That is, it will load all of the commands described in
+ the current part of this manual, but it will not load frontends like
+ \tikzname. It will also load the system layer. To load additional modules,
+ use the |\usepgfmodule| command explained below.
+\end{package}
+
+The following package is just a convenience.
+
+\begin{package}{pgf}
+ This package loads the |pgfcore| and the two modules |shapes| and |plot|.
+
+ In \LaTeX, the package takes two options:
+ %
+ \begin{packageoption}{draft}
+ When this option is set, all images will be replaced by empty
+ rectangles. This can speedup compilation.
+ \end{packageoption}
+
+ \begin{packageoption}{version=\meta{version}}
+ Indicates that the commands of version \meta{version} need to be
+ defined. If you set \meta{version} to |0.65|, then a large bunch of
+ ``compatibility commands'' are loaded. If you set \meta{version} to
+ |0.96|, then these compatibility commands will not be loaded.
+
+ If this option is not given at all, then the commands of all versions
+ are defined.
+ \end{packageoption}
+\end{package}
+
+
+\subsubsection{The Modules}
+
+\begin{command}{\usepgfmodule\marg{module names}}
+ Once the core has been loaded, you can use this command to load further
+ modules. The modules in the \meta{module names} list should be separated by
+ commas. Instead of curly braces, you can also use square brackets, which is
+ something Con\TeX t users will like. If you try to load a module a second
+ time, nothing will happen.
+
+ \example |\usepgfmodule{matrix,shapes}|
+
+ What this command does is to load the file
+ |pgfmodule|\meta{module}|.code.tex| for each \meta{module} in the list of
+ \meta{module names}. Thus, to write your own module, all you need to do is
+ to place a file of the appropriate name somewhere \TeX\ can find it.
+ \LaTeX, plain \TeX, and Con\TeX t users can then use your library.
+\end{command}
+
+The following modules are available for use with |pgfcore|: \todosp{In the
+meantime there are some more modules. Also mention them here?}
+%
+\begin{itemize}
+ \item The |plot| module provides commands for plotting functions. The
+ commands are explained in Section~\ref{section-plots}.
+ \item The |shapes| module provides commands for drawing shapes and nodes.
+ These commands are explained in Section~\ref{section-shapes}.
+ \item The |decorations| module provides commands for adding decorations to
+ paths. These commands are explained in
+ Section~\ref{section-base-decorations}.
+ \item The |matrix| module provides the |\pgfmatrix| command. The commands
+ are documented in Section~\ref{section-base-matrices}.
+\end{itemize}
+
+
+\subsubsection{The Library Packages}
+
+There is a special command for loading library packages. The difference between
+a library and module is the following: A library just defines additional
+objects using the basic layer, whereas a module adds completely new
+functionality. For instance, a |decorations| library defines additional
+decorations, while a decoration module defines the whole code for handling
+decorations.
+
+\begin{command}{\usepgflibrary\marg{list of libraries}}
+ Use this command to load further libraries. The list of libraries should
+ contain the names of libraries separated by commas. Instead of curly
+ braces, you can also use square brackets. If you try to load a library a
+ second time, nothing will happen.
+
+ \example |\usepgflibrary{arrows}|
+
+ This command causes the file |pgflibrary|\meta{library}|.code.tex| to be
+ loaded for each \meta{library} in the \meta{list of libraries}. This means
+ that in order to write your own library file, place a file of the
+ appropriate name somewhere where \TeX\ can find it. \LaTeX, plain \TeX, and
+ Con\TeX t users can then use your library.
+
+ You should also consider adding a \tikzname\ library that simply includes
+ your \pgfname\ library.
+\end{command}
+
+
+\subsection{The Hierarchical Structure of the Graphics}
+
+\subsubsection{The Main Environment}
+
+Most, but not all, commands of the \pgfname\ package must be given within a
+|{pgfpicture}| environment. The only commands that (must) be given outside are
+commands having to do with including images (like |\pgfuseimage|) and with
+inserting complete shadings (like |\pgfuseshading|). However, just to keep life
+entertaining, the |\pgfshadepath| command must be given \emph{inside} a
+|{pgfpicture}| environment.
+
+\begin{environment}{{pgfpicture}}
+ This environment will insert a \TeX\ box containing the graphic drawn by
+ the \meta{environment contents} at the current position.
+
+
+ \medskip
+ \textbf{The size of the bounding box.}
+ The size of the box is determined in the following manner: While \pgfname\
+ parses the \meta{environment contents}, it keeps track of a bounding box
+ for the graphic. Essentially, this bounding box is the smallest box that
+ contains all coordinates mentioned in the graphics. Some coordinates may be
+ ``mentioned'' by \pgfname\ itself; for example, when you add circle to the
+ current path, the support points of the curve making up the circle are also
+ ``mentioned'' despite the fact that you will not ``see'' them in your code.
+
+ Once the \meta{environment contents} have been parsed completely, a \TeX\
+ box is created whose size is the size of the computed bounding box and this
+ box is inserted at the current position.
+ %
+\begin{codeexample}[]
+Hello \begin{pgfpicture}
+ \pgfpathrectangle{\pgfpointorigin}{\pgfpoint{2ex}{1ex}}
+ \pgfusepath{stroke}
+\end{pgfpicture} World!
+\end{codeexample}
+
+ Sometimes, you may need more fine-grained control over the size of the
+ bounding box. For example, the computed bounding box may be too large or
+ you intensionally wish the box to be ``too small''. In these cases, you can
+ use the command |\pgfusepath{use as bounding box}|, as described in
+ Section~\ref{section-using-bb}.
+
+
+ \medskip
+ \textbf{The baseline of the bounding box.}
+ When the box containing the graphic is inserted into the normal text, the
+ baseline of the graphic is normally at the bottom of the graphic. For this
+ reason, the following two sets of code lines have the same effect, despite
+ the fact that the second graphic uses ``higher'' coordinates than the
+ first:
+ %
+\begin{codeexample}[]
+Rectangles \begin{pgfpicture}
+ \pgfpathrectangle{\pgfpointorigin}{\pgfpoint{2ex}{1ex}}
+ \pgfusepath{stroke}
+\end{pgfpicture} and \begin{pgfpicture}
+ \pgfpathrectangle{\pgfpoint{0ex}{1ex}}{\pgfpoint{2ex}{1ex}}
+ \pgfusepath{stroke}
+\end{pgfpicture}.
+\end{codeexample}
+
+ You can change the baseline using the |\pgfsetbaseline| command, see below.
+ %
+\begin{codeexample}[]
+Rectangles \begin{pgfpicture}
+ \pgfpathrectangle{\pgfpointorigin}{\pgfpoint{2ex}{1ex}}
+ \pgfusepath{stroke}
+ \pgfsetbaseline{0pt}
+\end{pgfpicture} and \begin{pgfpicture}
+ \pgfpathrectangle{\pgfpoint{0ex}{1ex}}{\pgfpoint{2ex}{1ex}}
+ \pgfusepath{stroke}
+ \pgfsetbaseline{0pt}
+\end{pgfpicture}.
+\end{codeexample}
+
+
+ \medskip
+ \textbf{Including text and images in a picture.}
+ You cannot directly include text and images in a picture. Thus, you should
+ \emph{not} simply write some text in a |{pgfpicture}| or use a command like
+ |\includegraphics| or even |\pgfimage|. In all these cases, you need to
+ place the text inside a |\pgftext| command. This will ``escape back'' to
+ normal \TeX\ mode, see Section~\ref{section-text-command} for details.
+
+
+ \medskip
+ \textbf{Remembering a picture position for later reference.}
+ After a picture has been typeset, its position on the page is normally
+ forgotten by \pgfname\ and also by \TeX. This means that is not possible to
+ reference a node in this picture later on. In particular, it is normally
+ impossible to draw lines between nodes in different pictures automatically.
+
+ In order to make \pgfname\ ``remember'' a picture, the \TeX-if
+ |\ifpgfrememberpicturepositiononpage| should be set to |true|. It is only
+ important that this \TeX-if is |true| at the end of the
+ |{pgfpicture}|-en\-vi\-ron\-ment, so you can switch it on inside the
+ environment. However, you can also just switch it on globally, then the
+ positions of all pictures are remembered.
+
+ There are several reasons why the remembering is not switched on by
+ default. First, it does not work for all backend drivers (currently, it
+ works only for pdf\TeX). Second, it requires two passes of \TeX\ over the
+ file; on the first pass all positions will be wrong. Third, for every
+ remembered picture a line is added to the |.aux|-file, which may result in
+ a large number of extra lines.
+
+ Despite all these ``problems'', for documents that are processed with
+ pdf\TeX\ and in which there is only a small number of pictures (less than a
+ hundred or so), you can switch on this option globally, it will not cause
+ any significant slowing of \TeX.
+\end{environment}
+
+\begin{plainenvironment}{{pgfpicture}}
+ The plain \TeX\ version of the environment. Note that in this version,
+ also, a \TeX\ group is created around the environment.
+\end{plainenvironment}
+
+\begin{contextenvironment}{{pgfpicture}}
+ This is the Con\TeX t version of the environment.
+\end{contextenvironment}
+
+{\let\ifpgfrememberpicturepositiononpage=\relax
+\begin{command}{\ifpgfrememberpicturepositiononpage}
+ Determines whether the position of pictures on the page should be recorded.
+ The value of this \TeX-if at the end of a |{pgfpicture}| environment is
+ important, not the value at the beginning.
+
+ If this option is set to true of a picture, \pgfname\ will attempt to
+ record the position of the picture on the page. (This attempt will fail
+ with most drivers and when it works, it typically requires two runs of
+ \TeX.) The position is not directly accessible. Rather, the nodes mechanism
+ will use this position if you access a node from another picture. See
+ Sections~\ref{section-cross-pictures-pgf}
+ and~\ref{section-cross-picture-tikz} for more details.
+\end{command}
+}
+
+\makeatletter
+\begin{command}{\pgfsetbaseline\marg{dimension}}
+ This command specifies a $y$-coordinate of the picture that should be used
+ as the baseline of the whole picture. When a \pgfname\ picture has been
+ typeset completely, \pgfname\ must decide at which height the baseline of
+ the picture should lie. Normally, the baseline is set to the $y$-coordinate
+ of the bottom of the picture, but it is often desirable to use a different
+ height.
+ %
+\begin{codeexample}[]
+Text
+\begin{pgfpicture}
+ \pgfpathcircle{\pgfpointorigin}{1ex}\pgfusepath{stroke}
+\end{pgfpicture},
+\begin{pgfpicture}
+ \pgfsetbaseline{0pt}
+ \pgfpathcircle{\pgfpointorigin}{1ex}\pgfusepath{stroke}
+\end{pgfpicture},
+\begin{pgfpicture}
+ \pgfsetbaseline{.5ex}
+ \pgfpathcircle{\pgfpointorigin}{1ex}\pgfusepath{stroke}
+\end{pgfpicture},
+\begin{pgfpicture}
+ \pgfsetbaseline{-1ex}
+ \pgfpathcircle{\pgfpointorigin}{1ex}\pgfusepath{stroke}
+\end{pgfpicture}.
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfsetbaselinepointnow\marg{point}}
+ This command specifies the baseline indirectly, namely as the
+ $y$-coordinate that the given \meta{point} has when the command is called.
+\end{command}
+
+\begin{command}{\pgfsetbaselinepointlater\marg{point}}
+ This command also specifies the baseline indirectly, but the $y$-coordinate
+ of the given \meta{point} is only computed at the end of the picture.
+ %
+\begin{codeexample}[]
+Hello
+\begin{pgfpicture}
+ \pgfsetbaselinepointlater{\pgfpointanchor{X}{base}}
+ % Note: no shape X, yet
+ \pgfnode{cross out}{center}{world.}{X}{\pgfusepath{stroke}}
+\end{pgfpicture}
+\end{codeexample}
+ %
+\end{command}
+
+
+\subsubsection{Graphic Scope Environments}
+
+Inside a |{pgfpicture}| environment you can substructure your picture using the
+following environment:
+
+\begin{environment}{{pgfscope}}
+ All changes to the graphic state done inside this environment are
+ local to the environment. The graphic state includes the following:
+ %
+ \begin{itemize}
+ \item The line width.
+ \item The stroke and fill colors.
+ \item The dash pattern.
+ \item The line join and cap.
+ \item The miter limit.
+ \item The canvas transformation matrix.
+ \item The clipping path.
+ \end{itemize}
+ %
+ Other parameters may also influence how graphics are rendered, but they are
+ \emph{not} part of the graphic state. For example, the arrow tip kind is
+ not part of the graphic state and the effect of commands setting the arrow
+ tip kind are local to the current \TeX\ group, not to the current
+ |{pgfscope}|. However, since |{pgfscope}| starts and ends a \TeX\ group
+ automatically, a |{pgfscope}| can be used to limit the effect of, say,
+ commands that set the arrow tip kind.
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \begin{pgfscope}
+ {
+ \pgfsetlinewidth{2pt}
+ \pgfpathrectangle{\pgfpointorigin}{\pgfpoint{2ex}{2ex}}
+ \pgfusepath{stroke}
+ }
+ \pgfpathrectangle{\pgfpoint{3ex}{0ex}}{\pgfpoint{2ex}{2ex}}
+ \pgfusepath{stroke}
+ \end{pgfscope}
+ \pgfpathrectangle{\pgfpoint{6ex}{0ex}}{\pgfpoint{2ex}{2ex}}
+ \pgfusepath{stroke}
+\end{pgfpicture}
+\end{codeexample}
+
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \begin{pgfscope}
+ {
+ \pgfsetarrows{->}
+ \pgfpathmoveto{\pgfpointorigin}\pgfpathlineto{\pgfpoint{2ex}{2ex}}
+ \pgfusepath{stroke}
+ }
+ \pgfpathmoveto{\pgfpoint{3ex}{0ex}}\pgfpathlineto{\pgfpoint{5ex}{2ex}}
+ \pgfusepath{stroke}
+ \end{pgfscope}
+ \pgfpathmoveto{\pgfpoint{6ex}{0ex}}\pgfpathlineto{\pgfpoint{8ex}{2ex}}
+ \pgfusepath{stroke}
+\end{pgfpicture}
+\end{codeexample}
+
+ At the start of the scope, the current path must be empty, that is, you
+ cannot open a scope while constructing a path.
+
+ It is usually a good idea \emph{not} to introduce \TeX\ groups inside a
+ |{pgfscope}| environment.
+\end{environment}
+
+\begin{plainenvironment}{{pgfscope}}
+ Plain \TeX\ version of the |{pgfscope}| environment.
+\end{plainenvironment}
+
+\begin{contextenvironment}{{pgfscope}}
+ This is the Con\TeX t version of the environment.
+\end{contextenvironment}
+
+The following scopes also encapsulate certain properties of the graphic state.
+However, they are typically not used directly by the user.
+
+\begin{environment}{{pgfinterruptpath}}
+ This environment can be used to temporarily interrupt the construction of
+ the current path. The effect will be that the path currently under
+ construction will be ``stored away'' and restored at the end of the
+ environment. Inside the environment you can construct a new path and do
+ something with it.
+
+ An example application of this environment is the arrow tip caching.
+ Suppose you ask \pgfname\ to use a specific arrow tip kind. When the arrow
+ tip needs to be rendered for the first time, \pgfname\ will ``cache'' the
+ path that makes up the arrow tip. To do so, it interrupts the current path
+ construction and then protocols the path of the arrow tip. The
+ |{pgfinterruptpath}| environment is used to ensure that this does not
+ interfere with the path to which the arrow tips should be attached.
+
+ This command does \emph{not} install a |{pgfscope}|. In particular, it does
+ not call any |\pgfsys@| commands at all, which would, indeed, be dangerous
+ in the middle of a path construction.
+\end{environment}
+
+\begin{plainenvironment}{{pgfinterruptpath}}
+ Plain \TeX\ version of the environment.
+\end{plainenvironment}
+
+\begin{contextenvironment}{{pgfinterruptpath}}
+ Con\TeX t version of the environment.
+\end{contextenvironment}
+
+\begin{environment}{{pgfinterruptpicture}}
+ This environment can be used to temporarily interrupt a |{pgfpicture}|.
+ However, the environment is intended only to be used at the beginning and
+ end of a box that is (later) inserted into a |{pgfpicture}| using
+ |\pgfqbox|. You cannot use this environment directly inside a
+ |{pgfpicture}|.
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgfpathmoveto{\pgfpoint{0cm}{0cm}} % In the middle of path, now
+ \newbox\mybox
+ \setbox\mybox=\hbox{
+ \begin{pgfinterruptpicture}
+ Sub-\begin{pgfpicture} % a subpicture
+ \pgfpathmoveto{\pgfpoint{1cm}{0cm}}
+ \pgfpathlineto{\pgfpoint{1cm}{1cm}}
+ \pgfusepath{stroke}
+ \end{pgfpicture}-picture.
+ \end{pgfinterruptpicture}
+ }
+ \pgfqbox{\mybox}%
+ \pgfpathlineto{\pgfpoint{0cm}{1cm}}
+ \pgfusepath{stroke}
+\end{pgfpicture}\hskip3.9cm
+\end{codeexample}
+ %
+\end{environment}
+
+\begin{plainenvironment}{{pgfinterruptpicture}}
+ Plain \TeX\ version of the environment.
+\end{plainenvironment}
+
+\begin{contextenvironment}{{pgfinterruptpicture}}
+ Con\TeX t version of the environment.
+\end{contextenvironment}
+
+\begin{environment}{{pgfinterruptboundingbox}}
+ This environment temporarily interrupts the computation of the bounding box
+ and sets up a new bounding box. At the beginning of the environment the old
+ bounding box is saved and an empty bounding box is installed. After the
+ environment the original bounding box is reinstalled as if nothing has
+ happened.
+\end{environment}
+
+\begin{plainenvironment}{{pgfinterruptboundingbox}}
+ Plain \TeX\ version of the environment.
+\end{plainenvironment}
+
+\begin{contextenvironment}{{pgfinterruptboundingbox}}
+ Con\TeX t version of the environment.
+\end{contextenvironment}
+
+
+\subsubsection{Inserting Text and Images}
+\label{section-text-command}
+
+Often, you may wish to add normal \TeX\ text at a certain point inside a
+|{pgfpicture}|. You cannot do so ``directly'', that is, you cannot simply write
+this text inside the |{pgfpicture}| environment. Rather, you must pass the text
+as an argument to the |\pgftext| command.
+
+You must \emph{also} use the |\pgftext| command to insert an image or a shading
+into a |{pgfpicture}|.
+
+\begin{command}{\pgftext\opt{\oarg{options}}\marg{text}}
+ This command will typeset \meta{text} in normal \TeX\ mode and insert the
+ resulting box into the |{pgfpicture}|. The bounding box of the graphic will
+ be updated so that all of the text box is inside. By default, the text box
+ is centered at the origin, but this can be changed either by giving
+ appropriate \meta{options} or by applying an appropriate coordinate
+ transformation beforehand.
+
+ The \meta{text} may contain verbatim text. (In other words, the \meta{text}
+ ``argument'' is not a normal argument, but is put in a box and some
+ |\aftergroup| hackery is used to find the end of the box.)
+
+ \pgfname's current (high-level) coordinate transformation is synchronized
+ with the canvas transformation matrix temporarily when the text box is
+ inserted. The effect is that if there is currently a high-level rotation
+ of, say, 30 degrees, the \meta{text} will also be rotated by thirty
+ degrees. If you do not want this effect, you have to (possibly temporarily)
+ reset the high-level transformation matrix.
+
+ The \meta{options} keys are used with the path |/pgf/text/|. The following
+ keys are defined for this path:
+ %
+ \begin{key}{/pgf/text/left}
+ The key causes the text box to be placed such that its left border is
+ on the origin.
+ %
+\begin{codeexample}[]
+\tikz{\draw[help lines] (-1,-.5) grid (1,.5);
+ \pgftext[left] {lovely}}
+\end{codeexample}
+ \end{key}
+ %
+ \begin{key}{/pgf/text/right}
+ The key causes the text box to be placed such that its right border is
+ on the origin.
+ %
+\begin{codeexample}[]
+\tikz{\draw[help lines] (-1,-.5) grid (1,.5);
+ \pgftext[right] {lovely}}
+\end{codeexample}
+ \end{key}
+ %
+ \begin{key}{/pgf/text/top}
+ This key causes the text box to be placed such that its top is on the
+ origin. This option can be used together with the |left| or |right|
+ option.
+ %
+\begin{codeexample}[]
+\tikz{\draw[help lines] (-1,-.5) grid (1,.5);
+ \pgftext[top] {lovely}}
+\end{codeexample}
+ %
+\begin{codeexample}[]
+\tikz{\draw[help lines] (-1,-.5) grid (1,.5);
+ \pgftext[top,right] {lovely}}
+\end{codeexample}
+ \end{key}
+ %
+ \begin{key}{/pgf/text/bottom}
+ This key causes the text box to be placed such that its bottom is on
+ the origin.
+ %
+\begin{codeexample}[]
+\tikz{\draw[help lines] (-1,-.5) grid (1,.5);
+ \pgftext[bottom] {lovely}}
+\end{codeexample}
+ %
+\begin{codeexample}[]
+\tikz{\draw[help lines] (-1,-.5) grid (1,.5);
+ \pgftext[bottom,right] {lovely}}
+\end{codeexample}
+ \end{key}
+ %
+ \begin{key}{/pgf/text/base}
+ This key causes the text box to be placed such that its baseline is on
+ the origin.
+ %
+\begin{codeexample}[]
+\tikz{\draw[help lines] (-1,-.5) grid (1,.5);
+ \pgftext[base] {lovely}}
+\end{codeexample}
+ %
+\begin{codeexample}[]
+\tikz{\draw[help lines] (-1,-.5) grid (1,.5);
+ \pgftext[base,right] {lovely}}
+\end{codeexample}
+ \end{key}
+ %
+ \begin{key}{/pgf/text/at=\meta{point}}
+ Translates the origin (that is, the point where the text is shown) to
+ \meta{point}.
+ %
+\begin{codeexample}[]
+\tikz{\draw[help lines] (-1,-.5) grid (1,.5);
+ \pgftext[base,at={\pgfpoint{1cm}{0cm}}] {lovely}}
+\end{codeexample}
+ \end{key}
+ %
+ \begin{key}{/pgf/text/x=\meta{dimension}}
+ Translates the origin by \meta{dimension} along the $x$-axis.
+ %
+\begin{codeexample}[]
+\tikz{\draw[help lines] (-1,-.5) grid (1,.5);
+ \pgftext[base,x=1cm,y=-0.5cm] {lovely}}
+\end{codeexample}
+ \end{key}
+ %
+ \begin{key}{/pgf/text/y=\meta{dimension}}
+ This key works like the |x| option.
+ \end{key}
+ %
+ \begin{key}{/pgf/text/rotate=\meta{degree}}
+ Rotates the coordinate system by \meta{degree}. This will also rotate
+ the text box.
+ %
+\begin{codeexample}[]
+\tikz{\draw[help lines] (-1,-.5) grid (1,.5);
+ \pgftext[base,x=1cm,y=-0.5cm,rotate=30] {lovely}}
+\end{codeexample}
+ \end{key}
+\end{command}
+
+
+\subsection{Object Identifiers}
+
+Graphical objects can have an \emph{identifier,} which allows you to reference
+the object later on. For instance, you could reference the object as the target
+of a hyperlink (although this capability is not necessarily implemented by
+drivers) or as the target of an animation; indeed, animations always need an
+object identifier to identify the to-be-animated object.
+
+Attaching an identifier to an object is a two-step process:
+%
+\begin{enumerate}
+ \item You call |\pgfuseid{|\meta{id}|}| to choose an id, which is a normal
+ string.
+ \item Next, you call one of several commands like |\pgfidscope| or
+ |\pgftext|, which create an object. This object will have then have the
+ id.
+\end{enumerate}
+
+
+\subsubsection{Commands for Creating Graphic Objects}
+
+The following system level commands create an object with an id:
+%
+\begin{enumerate}
+ \item |\pgfsys at begin@idscope|, which creates a graphic scope.
+ \item |\pgfsys at viewboxmeet| or |\pgfsys at viewboxslice|, which create view
+ boxes,
+ \item |\pgfsys at fill|, |\pgfsys at stroke|, and all other path usage command,
+ \item |\pgfsys at hbox| or |\pgfsys at hboxsynced|, which create text boxes, and
+ \item |\pgfsys at animate...|, which create animations.
+\end{enumerate}
+
+These system layer commands are, in turn, called by the following basic layer
+commands (and, also, by the commands that call them, in turn):
+%
+\begin{itemize}
+ \item |\pgfidscope|, which creates an id scope (see below).
+ \item |\pgfviewboxscope|, which creates a view box.
+ \item |\pgfusepath|, which creates a path.
+ \item |\pgftext| and |\pgfnode| and |\pgfmultipartnode|, which create text
+ boxes and nodes, and
+ \item |\pgfanimateattribute|, which creates an animation.
+\end{itemize}
+
+\begin{environment}{{pgfidscope}}
+ Creates a graphic scope that will have the id last used with |\pgfuseid|
+ attached to, provided such an id was set and was not already used with
+ another object. In the latter cases, no graphic scope is created. Thus, if
+ you wish to ensure that a graphic scope is created, you must (additionally)
+ call |\pgfscope| inside or outside the id scope.
+\end{environment}
+
+The Plain\TeX\ and Con\TeX t versions of the environment are:
+%
+\begin{plainenvironment}{{pgfidscope}}
+\end{plainenvironment}
+
+\begin{contextenvironment}{{pgfidscope}}
+\end{contextenvironment}
+
+
+\subsubsection{Settings and Querying Identifiers}
+
+In order to attach an identifier to an object, you first use the following
+command:
+
+\begin{command}{\pgfuseid\marg{name}}
+ The \meta{name} is a string by which the object will be referenced (see
+ |\pgfidrefnextuse|). The next time a graphic object is created in the
+ current \TeX\ scope, the name will be attached to it (actually, it will get
+ a system layer identifier attached to it that is automatically created
+ using |\pgfsys at new@id|, the \meta{name} is bound to that identifier and it
+ can be retrieved using |\pgfidrefnextuse|). This holds true only for the
+ next object: If a second object is created, it will not get the name
+ attached to it. This does not mean, however, that you cannot attach the
+ same name to different objects; you just need to call |\pgfuseid| again
+ before each object.
+
+ Besides the \meta{name} (or, more precisely, besides the system layer
+ identifier it refers to), the current \emph{identifier type} is also
+ important: Actually, a graphic object is not referenced by a system layer
+ identifier, but by the combination of the identifier and a type. You can
+ use the following commands for modifying the type used for the creation of
+ objects:
+
+ \begin{command}{\pgfusetype\marg{type}}
+ Sets the type used for the referencing of graphic objects for the
+ current scope to \meta{type} or, if \meta{type} starts with a dot,
+ appends \meta{type} to the current type.
+
+ You use this command with compound graphic objects: Before each part of
+ a graphic object, set the type to an appropriate value. Now, if the
+ object is named using |\pgfuseid|, you can later on access all parts of
+ the compound object using the combination of the \meta{name} used with
+ |\pgfuseid| and the type of the part.
+
+ As an example, this system is used to give you access to the different
+ parts of a node: When you say |\pgfuseid{mynode}| and then create a
+ node, you can use |mynode| with the empty type to reference the
+ graphics scope that encompasses the whole node, but also |mynode|
+ together with the type |background| to access the background path of
+ the node.
+
+ In detail, \pgfname\ uses this command to set the following types:
+ %
+ \begin{itemize}
+ \item Inside the command |\pgfviewboxscope|, the type |.view| is
+ used for the view object.
+ \item Inside the command |\pgfmultipartnode|, the type
+ |.behind background| is used for the scope of drawings behind
+ the background. Similarly, |.before background| and
+ |.behind foreground| and finally |.before foreground| are used
+ with the respective parts of a node.
+ \item Also inside a node, |.background| and |.foreground| are used
+ as types of the background and foreground paths, respectively.
+ \item Finally, inside a node, for each text part, the text part's
+ name is used as a type (so |.text| is used for the main part).
+ \end{itemize}
+
+ In addition, \tikzname\ uses this command in the following
+ situations:
+ %
+ \begin{itemize}
+ \item The type |.path| is used with a named path (named using the
+ |name| key). This is the graphic object you need to reference
+ when you wish to morph a path.
+ \item The type |.path picture| is used with the scope of the
+ optional path picture.
+ \item The type |.path fill| is used with the path used for filling.
+ This is not the same as the normal path in case the path is
+ filled and patterned, for instance.
+ \item The type |.path shade| is used with the path used for shading
+ a path.
+ \end{itemize}
+ \end{command}
+
+ \begin{command}{\pgfpushtype}
+ Pushes the current type on an internal global stack. The idea is to
+ allow you to temporarily change the current type without having to open
+ a \TeX\ scope.
+ \end{command}
+
+ \begin{command}{\pgfpoptype}
+ Restores the most recent type from the internal global stack of types.
+ \end{command}
+\end{command}
+
+\begin{command}{\pgfclearid}
+ Clears the current id (and type) for the local scope.
+\end{command}
+
+\begin{command}{\pgfidrefnextuse\marg{macro}\marg{name}}
+ This command assigns a system layer identifier (the identifier returned by
+ |\pgfsys at new@id|) to the \meta{macro}, namely the one that will be used the
+ \emph{next} time |\pgfuseid| is used. You use this command for ``forward
+ referencing''.
+
+ A typical use case is the following: A key like |whom| for animations uses
+ this command to get the system identifier that will be used for a future
+ object. Then, this identifier can be passed to system layer commands like
+ |\pgfsys at animation@whom|.
+
+ Note that the ``next'' use need not be on the same page (or there may not
+ even be any use at all), in which case the reference will not refer to any
+ object.
+\end{command}
+
+\begin{command}{\pgfidrefprevuse\marg{macro}\marg{name}}
+ Works like |\pgfidrefnextuse|, only it references the most recent
+ \emph{previous} use of the \meta{name}. As for |\pgfidrefnextuse|, the most
+ recent use need not be on the same page.
+\end{command}
+
+\begin{command}{\pgfaliasid\marg{alias}\marg{name}}
+ Creates an alias of a name inside the current \TeX\ scope. After calling
+ this command, you can use \meta{alias} anywhere where you would normally
+ use \meta{name}. Note that the binding between \meta{alias} and \meta{name}
+ is not kept when |\pgfuseid| is used on the \meta{name} (or the
+ \meta{alias}).
+\end{command}
+
+\begin{command}{\pgfgaliasid\marg{1}\marg{2}}
+ Like |\pgfaliasid|, only the alias is set globally.
+\end{command}
+
+\begin{command}{\pgfifidreferenced\marg{name}\marg{then code}\marg{else code}}
+ If \meta{name} has been referenced, \meta{then code} is executed, otherwise
+ \meta{else code}.
+\end{command}
+
+
+\subsection{Resource Description Framework Annotations (RDFa)}
+\label{section-base-rdf}
+
+With certain output formats (in particular, with \textsc{svg}) you can insert
+annotations into the output file following the standard set by the
+\emph{resource description framework} (known as ``\textsc{rdf}'', please
+consult the literature on \textsc{rdf} and \textsc{rdf}a for an introduction to
+resource descriptions and ontologies and their purpose in general). To do so,
+you call one (or several) of the following commands before you call
+|\pgfidscope|. The attributes and values you specify using the commands will
+then be added to the resulting scope (if the driver supports this, which is
+only the case for \textsc{svg} at the moment). As an example, when you write
+%
+\begin{codeexample}[code only]
+\pgfrdfresource{/fruits/apple}
+\pgfidscope
+...
+\pgfendidscope
+\end{codeexample}
+
+in the resulting \textsc{svg} file you get
+%
+\begin{codeexample}[code only]
+<g resource="/fruits/apple">
+ ...
+</g>
+\end{codeexample}
+
+Most of the following commands just set a single attribute for the next id
+scope. In some cases, however, repeated calling of these commands makes sense
+and causes the passed values to accumulate as in the following example:
+%
+\begin{codeexample}[code only]
+\pgfrdfresource{/fruits/apple}
+\pgfrdfproperty{http://foo.com/props/juicy}
+\pgfrdfproperty{http://foo.com/props/green}
+\pgfidscope
+...
+\pgfendidscope
+\end{codeexample}
+
+Now you get:
+%
+\begin{codeexample}[code only]
+<g resource="/fruits/apple"
+ property="http://foo.com/props/juicy http://foo.com/props/green">
+ ...
+</g>
+\end{codeexample}
+
+The following commands ``accumulate'': |\pgfrdfproperty|, |\pgfrdfrel|,
+|\pgfrdfrev| and also the command |\pgfrdftypeof|.
+
+\begin{command}{\pgfrdfabout\marg{text}}
+ Adds the \textsc{rdf} attribute |about="|\meta{text}|"| to the next id
+ scope (please see the \textsc{rdf}a specification for details on the
+ semantics of |about| in the context of the resource description framework).
+\end{command}
+
+The following commands work the same way.
+
+\begin{command}{\pgfrdfcontent\marg{text}}
+\end{command}
+
+\begin{command}{\pgfrdfdatatype\marg{text}}
+\end{command}
+
+\begin{command}{\pgfrdfhref\marg{text}}
+\end{command}
+
+\begin{command}{\pgfrdfinlist}
+\end{command}
+
+\begin{command}{\pgfrdfprefix\marg{text}}
+\end{command}
+
+\begin{command}{\pgfrdfproperty\marg{text}}
+\end{command}
+
+\begin{command}{\pgfrdfrel\marg{text}}
+\end{command}
+
+\begin{command}{\pgfrdfresource\marg{text}}
+\end{command}
+
+\begin{command}{\pgfrdfrev\marg{text}}
+\end{command}
+
+\begin{command}{\pgfrdfsrc\marg{text}}
+\end{command}
+
+\begin{command}{\pgfrdftypeof\marg{text}}
+\end{command}
+
+\begin{command}{\pgfrdfvocab\marg{text}}
+\end{command}
+
+
+\subsection{Error Messages and Warnings}
+
+Sometimes, a command inside \pgfname\ may fail. In this case, two commands are
+useful to communicate with the author:
+
+\begin{command}{\pgferror\marg{message}}
+ Stops the processing of the current document and prints out the
+ \meta{message}. In \LaTeX, this will be done using |\PackageError|,
+ otherwise |\errmessage| is used directly.
+\end{command}
+
+\begin{command}{\pgfwarning\marg{message}}
+ Prints the \meta{message} on the output, but does not interrupt the
+ processing. In \LaTeX, this will be done using |\PackageWarning|, otherwise
+ a write to stream $17$ is used.
+\end{command}
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-scopes.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-shadings.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-shadings.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-shadings.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,762 @@
+% Copyright 2019 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section{Shadings}
+\label{section-shadings}
+
+\subsection{Overview}
+
+A shading is an area in which the color changes smoothly between different
+colors. Similarly to an image, a shading must first be declared before it can
+be used. Also similarly to an image, a shading is put into a \TeX-box. Hence,
+in order to include a shading in a |{pgfpicture}|, you have to use |\pgftext|
+around it.
+
+There are different kinds of shadings: horizontal, vertical, radial, and
+functional shadings. However, you can rotate and clip shadings like any other
+graphics object, which allows you to create more complicated shadings.
+Horizontal shadings could be created by rotating a vertical shading by 90
+degrees, but explicit commands for creating both horizontal and vertical
+shadings are included for convenience.
+
+Once you have declared a shading, you can insert it into the text using the
+command |\pgfuseshading|. This command cannot be used directly in a
+|{pgfpicture}|, you have to put a |\pgftext| around it. The second command for
+using shadings, |\pgfshadepath|, on the other hand, can only be used inside
+|{pgfpicture}| environments. It will ``fill'' the current path with the
+shading.
+
+A horizontal shading is a horizontal bar of a certain height whose color
+changes smoothly. You must at least specify the colors at the left and at the
+right end of the bar, but you can also add color specifications for points in
+between. For example, suppose you wish to create a bar that is red at the left
+end, green in the middle, and blue at the end, and you would like the bar to be
+4cm long. This could be specified as follows:
+%
+\begin{codeexample}[code only]
+rgb(0cm)=(1,0,0); rgb(2cm)=(0,1,0); rgb(4cm)=(0,0,1)
+\end{codeexample}
+%
+This line means that at 0cm (the left end) of the bar, the color should be red,
+which has red-green-blue (rgb) components (1,0,0). At 2cm, the bar should be
+green, and at 4cm it should be blue. Instead of |rgb|, you can currently also
+specify |cmyk| as color model, in which case four values are needed,
+|gray| as color model, in which case only one value is needed, or
+|color|, in which case you must provide the name of a color in parentheses. In
+a color specification the individual specifications must be separated using a
+semicolon, which may be followed by a whitespace (like a space or a newline).
+Individual specifications must be given in increasing order.
+
+\subsubsection{Color models}
+
+\noindent\emph{by David Purton}
+
+An attempt is made to produce shadings consistent with the currently selected
+|xcolor| package color model. The |rgb|, |cmyk|, and |gray| color models from
+the |xcolor| package are supported.
+
+\textbf{Note:} The color model chosen for a shading is based on the |xcolor|
+color model \emph{at the time the shading is created}. This is either when
+|\pgfdeclare*shading| is called with no optional argument or when
+|\pgfuseshading| is called if |\pgfdeclare*shading| was called with an
+optional argument.
+
+If the |xcolor| package |natural| color model is in use then the shading color
+model will be \textsc{rgb} by default. In practice this means that if you are
+using the |natural| color model of the |xcolor| package you can get mismatched
+colors if you, for example, create a shading from green (which is defined as
+\textsc{rgb}) to magenta (which is defined as \textsc{cmyk}). The shading will
+finish with \textsc{rgb} magenta which will look different to the
+\textsc{cmyk} magenta used in solid colors.
+
+You can avoid mismatched colors by loading the |xcolor| package first with an
+explicit color model (|rgb|, |cmyk|, or |gray|).
+
+\begin{codeexample}[code only]
+\begin{tikzpicture}
+ \fill[green] (0,0) rectangle (1,1);
+ \shade[left color=green, right color=magenta] (1.25,0) rectangle (3.75,1);
+ \fill[magenta] (4,0) rectangle (5,1);
+\end{tikzpicture}
+\end{codeexample}
+
+\begin{center}
+ \begin{minipage}{5cm}
+ |xcolor| |natural| color model:\medskip
+
+ \begin{tikzpicture}
+ \fill[green] (0,0) rectangle (1,1);
+ \shade[left color=green, right color=magenta] (1.25,0) rectangle (3.75,1);
+ \fill[magenta] (4,0) rectangle (5,1);
+ \end{tikzpicture}
+ \end{minipage}\hspace{2cm}%
+ \begin{minipage}{5cm}
+ |xcolor| |cmyk| color model:\medskip
+
+ \selectcolormodel{cmyk}
+ \begin{tikzpicture}
+ \fill[green] (0,0) rectangle (1,1);
+ \shade[left color=green, right color=magenta] (1.25,0) rectangle (3.75,1);
+ \fill[magenta] (4,0) rectangle (5,1);
+ \end{tikzpicture}
+ \end{minipage}\medskip
+
+ \begin{minipage}{5cm}
+ |xcolor| |rgb| color model:\medskip
+
+ \selectcolormodel{rgb}
+ \begin{tikzpicture}
+ \fill[green] (0,0) rectangle (1,1);
+ \shade[left color=green, right color=magenta] (1.25,0) rectangle (3.75,1);
+ \fill[magenta] (4,0) rectangle (5,1);
+ \end{tikzpicture}
+ \end{minipage}\hspace{2cm}%
+ \begin{minipage}{5cm}
+ |xcolor| |gray| color model:\medskip
+
+ \selectcolormodel{gray}
+ \begin{tikzpicture}
+ \fill[green] (0,0) rectangle (1,1);
+ \shade[left color=green, right color=magenta] (1.25,0) rectangle (3.75,1);
+ \fill[magenta] (4,0) rectangle (5,1);
+ \end{tikzpicture}
+ \end{minipage}
+\end{center}
+
+\subsection{Declaring Shadings}
+
+\subsubsection{Horizontal and Vertical Shadings}
+
+\begin{command}{\pgfdeclarehorizontalshading\oarg{color list}\marg{shading name}\marg{shading height}\marg{color specification}}
+ Declares a horizontal shading named \meta{shading name} of the specified
+ \meta{height} with the specified colors. The width of the bar is deduced
+ automatically from the maximum dimension in the specification.
+ %
+\begin{codeexample}[]
+\pgfdeclarehorizontalshading{myshadingA}
+ {1cm}{rgb(0cm)=(1,0,0); color(2cm)=(green); color(4cm)=(blue)}
+\pgfuseshading{myshadingA}
+\end{codeexample}
+
+ The effect of the \meta{color list}, which is a comma-separated list of
+ colors, is the following: Normally, when this list is empty, once a shading
+ has been declared, it becomes ``frozen''. This means that even if you
+ change a color that was used in the declaration of the shading later on,
+ the shading will not change. By specifying a \meta{color list} you can
+ specify that the shading should be recalculated whenever one of the colors
+ listed in the list changes (this includes effects like color mixins and
+ |xcolor| color models). Thus, when you specify a \meta{color list},
+ whenever the shading is used, \pgfname\ first converts the colors in the
+ list to tuples in the current |xcolor| color model using the current
+ values of the colors and taking any mixins and blends into account. If the
+ resulting tuples have not yet been used,
+ a new shading is internally created and used. Note that if the option
+ \meta{color list} is used, then no shading is created until the first use
+ of |\pgfuseshading|. In particular, the colors mentioned in the shading
+ need not be defined when the declaration is given.
+
+ When a shading is recalculated because of a change in the colors mentioned
+ in \meta{color list}, the complete shading is recalculated. Thus even
+ colors not mentioned in the list will be used with their current values,
+ not with the values they had upon declaration.
+ %
+\begin{codeexample}[]
+\pgfdeclarehorizontalshading[mycolor]{myshadingB}
+ {1cm}{rgb(0cm)=(1,0,0); color(2cm)=(mycolor)}
+\colorlet{mycolor}{green}
+\pgfuseshading{myshadingB}
+\colorlet{mycolor}{blue}
+\pgfuseshading{myshadingB}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfdeclareverticalshading\oarg{color list}\marg{shading name}\marg{shading width}\marg{color specification}}
+ Declares a vertical shading named \meta{shading name} of the specified
+ \meta{width}. The height of the bar is deduced automatically. The effect of
+ \meta{color list} is the same as for horizontal shadings.
+ %
+\begin{codeexample}[]
+\pgfdeclareverticalshading{myshadingC}
+ {4cm}{rgb(0cm)=(1,0,0); rgb(1.5cm)=(0,1,0); rgb(2cm)=(0,0,1)}
+\pgfuseshading{myshadingC}
+\end{codeexample}
+ %
+\end{command}
+
+
+\subsubsection{Radial Shadings}
+
+\begin{command}{\pgfdeclareradialshading\oarg{color list}\marg{shading name}\marg{center point}\marg{color specification}}
+ Declares a radial shading. A radial shading is a circle whose inner color
+ changes as specified by the color specification. Assuming that the center
+ of the shading is at the origin, the color of the center will be the color
+ specified for 0cm and the color of the border of the circle will be the
+ color for the maximum dimension given in the \meta{color specified}. This
+ maximum will also be the radius of the circle. If the \meta{center point}
+ is not at the origin, the whole shading inside the circle (whose size
+ remains exactly the same) will be distorted such that the given center now
+ has the color specified for 0cm. The effect of \meta{color list} is the
+ same as for horizontal shadings.
+ %
+\begin{codeexample}[]
+\pgfdeclareradialshading{sphere}{\pgfpoint{0.5cm}{0.5cm}}%
+ {rgb(0cm)=(0.9,0,0);
+ rgb(0.7cm)=(0.7,0,0);
+ rgb(1cm)=(0.5,0,0);
+ rgb(1.05cm)=(1,1,1)}
+\pgfuseshading{sphere}
+\end{codeexample}
+ %
+\end{command}
+
+
+\subsubsection{General (Functional) Shadings}
+
+\begin{command}{\pgfdeclarefunctionalshading\oarg{color list}\marg{shading
+ name}\marg{lower left corner}\marg{upper right corner}\\
+ \marg{init code}\marg{type 4 function}%
+}
+ \emph{Warning: These shadings are the least portable of all and they put
+ the heaviest burden of the renderer. They are slow and, possibly, will not
+ print correctly!}
+
+ This command creates a \emph{functional shading}. For such a shading, the
+ color of each point is calculated by calling a function that takes the
+ coordinates of the point as input and yields the color as an output. Note
+ that the function is evaluated by the \emph{renderer}, not by \pgfname\ or
+ \TeX\ or someone else at compile-time. This means that the evaluation of
+ this function has to be done \emph{extremely quickly} and the function
+ should be \emph{very simple}. For this reason, only a very restricted set
+ of operations are possible in the function and functions should be kept
+ small. Any errors in the function will only be noticed by the renderer.
+
+ The syntax for specifying functions is the following: You use a simplified
+ form of a subset of the PostScript language. This subset will be understood
+ by the PDF-renderer (yes, PDF-renderers do have a basic understanding of
+ PostScript) and also by PostScript renders. This subset is detailed in
+ Section~3.9.4 of the PDF-specification (version~1.7). In essence, the
+ specification states that these functions may contain ``expressions
+ involving integers, real numbers, and boolean values only. There are no
+ composite data structures such as strings or arrays, no procedures, and no
+ variables or names.'' The allowed operators are (exactly) the following:
+ \texttt{abs}, \texttt{add}, \texttt{atan}, \texttt{ceiling}, \texttt{cos},
+ \texttt{cvi}, \texttt{cvr}, \texttt{div}, \texttt{exp}, \texttt{floor},
+ \texttt{idiv}, \texttt{ln}, \texttt{log}, \texttt{mod}, \texttt{mul},
+ \texttt{neg}, \texttt{round}, \texttt{sin}, \texttt{sqrt}, \texttt{sub},
+ \texttt{truncate}, \texttt{and}, \texttt{bitshift}, \texttt{eq},
+ \texttt{false}, \texttt{ge}, \texttt{gt}, \texttt{le}, \texttt{lt},
+ \texttt{ne}, \texttt{not}, \texttt{or}, \texttt{true}, \texttt{xor},
+ \texttt{if}, \texttt{ifelse}, \texttt{copy}, \texttt{dup}, \texttt{exch},
+ \texttt{index}, \texttt{pop}.
+
+ When the function is evaluated, the top two stack elements are the
+ coordinates of the point for which the color should be computed. The
+ coordinates are dimensionless and given in big points, so for the
+ coordinate $(50bp, 72.27pt)$ the top two stack elements would be
+ \texttt{50.0} and \texttt{72.0}. Otherwise, the (virtual) stack is empty
+ (or should be treated as if it were empty). The function should then
+ replace these two values by three values, representing the red, green, and
+ blue color of the point for an \textsc{rgb} shading, four colors,
+ representing the cyan, magenta, yellow, and black color of the point for a
+ \textsc{cmyk} shading, or one value representing the gray color for a
+ grayscale shading. The numbers should be real values, not integers
+ since, Apple's PDF renderer is broken in this regard (use \texttt{cvr} at
+ the end if necessary).
+
+ Conceptually, the function will be evaluated once for each point of the
+ rectangle \meta{lower left corner} to \meta{upper right corner}, which
+ should be a \pgfname-point expression like |\pgfpoint{100bp}{100bp}|. A
+ renderer may choose to evaluate the function at less points, but, in
+ principle, the function will be evaluated for each pixel independently.
+
+ Because of the rather difficult PostScript syntax, use this macro only
+ \emph{if you know what you are doing} (or if you are adventurous, of
+ course).
+
+ As for other shadings, the optional \meta{color list} is used to determine
+ whether a shading needs to be recalculated when a color has changed.
+
+ The \meta{init code} is executed each time a shading is (re)calculated.
+ Typically, it will contain code to extract coordinates from colors.
+ %
+\begin{codeexample}[]
+\pgfdeclarefunctionalshading{twospots}
+ {\pgfpointorigin}{\pgfpoint{4cm}{4cm}}{}{
+ % Save coordinates for later
+ 2 copy
+ % Compute distance from (40bp,45bp), with x doubled
+ 45 sub dup mul exch
+ 40 sub dup mul 0.5 mul add sqrt
+ % exponential decay
+ dup mul neg 1.0005 exch exp 1.0 exch sub
+ % Compute distance from (70bp,70bp) from stored coordinate, scaled
+ 3 1 roll
+ 70 sub dup mul .5 mul exch
+ 70 sub dup mul add sqrt
+ % Decay
+ dup mul neg 1.002 exch exp 1.0 exch sub
+ % red component
+ 1.0 3 1 roll
+}
+\pgfuseshading{twospots}
+\end{codeexample}
+
+ Inside the PostScript function \meta{type 4 function} you cannot use colors
+ directly. Rather, you must push the color components on the stack. For
+ this, it is useful to call one of |\pgfshadecolortorgb|,
+ |\pgfshadecolortocmyk|, or |\pgfshadecolortogray| in the \meta{init code}:
+
+ \begin{command}{\pgfshadecolortorgb\marg{color name}\marg{macro}}
+ This command takes \meta{color name} as input, converts it to
+ \textsc{rgb} and stores the color's
+ red/green/blue components real numbers between 0.0 and 1.0 separated by
+ spaces (which is exactly what you need if you want to push it on a
+ stack) in \meta{macro}. This macro can then be used inside the
+ \meta{type 4 function} argument for |\pgfdeclarefunctionalshading|.
+ %
+\begin{codeexample}[]
+\pgfdeclarefunctionalshading[mycol]{sweep}{\pgfpoint{-1cm}{-1cm}}
+{\pgfpoint{1cm}{1cm}}{\pgfshadecolortorgb{mycol}{\myrgb}}{
+ 2 copy % whirl
+ % Calculate "safe" atan of position
+ 2 copy abs exch abs add 0.0001 ge { atan } { pop } ifelse
+ 3 1 roll
+ dup mul exch
+ dup mul add sqrt
+ 30 mul
+ add
+ sin
+ 1 add 2 div
+ dup
+ \myrgb % push mycol
+ 5 4 roll % multiply all components by calculated value
+ mul
+ 3 1 roll
+ 3 index
+ mul
+ 3 1 roll
+ 4 3 roll
+ mul
+ 3 1 roll
+}
+\colorlet{mycol}{white}%
+\pgfuseshading{sweep}%
+\colorlet{mycol}{red}%
+\pgfuseshading{sweep}
+\end{codeexample}
+
+ In addition, three macros suffixed with |red|, |green| and |blue| are
+ defined, which store the individual components of \meta{color name}.
+ These can also be used in the \meta{type 4 function} argument.
+ %
+\begin{codeexample}[]
+\pgfshadecolortorgb{orange}{\mycol}
+|\mycol|=\mycol |\mycolred|=\mycolred |\mycolgreen|=\mycolgreen |\mycolblue|=\mycolblue
+\end{codeexample}
+ \end{command}
+
+\begin{codeexample}[]
+\pgfdeclarefunctionalshading[col1,col2,col3,col4]{bilinear interpolation}
+{\pgfpointorigin}{\pgfpoint{100bp}{100bp}}
+{
+\pgfshadecolortorgb{col1}{\first}\pgfshadecolortorgb{col2}{\second}
+\pgfshadecolortorgb{col3}{\third}\pgfshadecolortorgb{col4}{\fourth}
+}{
+ 100 div exch 100 div 2 copy % Calculate y/100 x/100.
+ neg 1 add exch neg 1 add % Calculate 1-y/100 1-x/100.
+ 3 1 roll 2 copy exch 5 2 roll 6 copy 6 copy % Set up stack.
+ \firstred mul exch \secondred mul add mul % Process red component.
+ 4 1 roll
+ \thirdred mul exch \fourthred mul add mul
+ add
+ 13 1 roll
+ \firstgreen mul exch \secondgreen mul add mul % Process green component.
+ 4 1 roll
+ \thirdgreen mul exch \fourthgreen mul add mul
+ add
+ 7 1 roll
+ \firstblue mul exch \secondblue mul add mul % Process blue component.
+ 4 1 roll
+ \thirdblue mul exch \fourthblue mul add mul
+ add
+}
+
+\colorlet{col1}{blue}
+\colorlet{col2}{yellow}
+\colorlet{col3}{red}
+\colorlet{col4}{green}
+\pgfuseshading{bilinear interpolation}
+\end{codeexample}
+
+ \begin{command}{\pgfshadecolortocmyk\marg{color name}\marg{macro}}
+ This command takes \meta{color name} as input, converts it to
+ \textsc{cmyk} and stores the color's cyan/magenta/yellow/black
+ components real numbers between 0.0 and 1.0 separated by spaces.
+
+ In addition, four macros suffixed with |cyan|, |magenta|, |yellow| and
+ |black| are defined, which store the individual components of
+ \meta{color name}.
+ %
+ \end{command}
+
+ \begin{command}{\pgfshadecolortogray\marg{color name}\marg{macro}}
+ This command takes \meta{color name} as input converts it to grayscale
+ and stores the color's value as a real number between 0.0 and 1.0.
+
+ Although it's not needed, for consistency a second macro suffixed with
+ |gray| is also defined.
+ %
+ \end{command}
+ %
+\end{command}
+
+\paragraph{Color model independent functional shadings.}
+
+By nature, the PostScript code used in functional shadings must output one of
+\textsc{rgb}, \textsc{cmyk}, or grayscale data. Therefore,
+|\pgfdeclarefunctionalshading| is \emph{not} portable across color models.
+
+Take particular care that the same color model is in use at declaration time
+and use time for functional shadings declared with an optional argument as
+otherwise the PostScript data will not match the declared color space and
+you will end up with a malformed PDF.
+
+Having said this, it \emph{is} possible to create portable functional shadings
+by providing conditional code to append color transformations to the
+PostScript data. A variety of |\pgffuncshading*to*| (e.g.,
+|\pgffuncshadingrgbtocmyk|) macros along with |\ifpgfshadingmodel*| (e.g.,
+|\ifpgfshadingmodelcmyk|) conditionals are provided to assist with these
+transformations. Obviously, this will make the PostScript code less efficient
+than if you work in your intended color model.
+
+\pgfdeclarefunctionalshading[black]{portabletwospots}
+ {\pgfpointorigin}{\pgfpoint{3.5cm}{3.5cm}}{}{
+ 2 copy
+ 45 sub dup mul exch
+ 40 sub dup mul 0.5 mul add sqrt
+ dup mul neg 1.0005 exch exp 1.0 exch sub
+ 3 1 roll
+ 70 sub dup mul .5 mul exch
+ 70 sub dup mul add sqrt
+ dup mul neg 1.002 exch exp 1.0 exch sub
+ 1.0 3 1 roll
+ \ifpgfshadingmodelcmyk
+ \pgffuncshadingrgbtocmyk
+ \fi
+ \ifpgfshadingmodelgray
+ \pgffuncshadingrgbtogray
+ \fi
+}
+\begin{center}
+ \begin{minipage}{3.5cm}
+ |xcolor| |rgb| model:\medskip
+
+ \selectcolormodel{rgb}
+ \pgfuseshading{portabletwospots}
+ \end{minipage}\hspace{2cm}
+ \begin{minipage}{3.5cm}
+ |xcolor| |cmyk| model:\medskip
+
+ \selectcolormodel{cmyk}
+ \pgfuseshading{portabletwospots}
+ \end{minipage}\hspace{2cm}
+ \begin{minipage}{3.5cm}
+ |xcolor| |gray| model:\medskip
+
+ \selectcolormodel{gray}
+ \pgfuseshading{portabletwospots}
+ \end{minipage}
+\end{center}
+
+\begin{codeexample}[code only]
+\pgfdeclarefunctionalshading[black]{portabletwospots}{\pgfpointorigin}{\pgfpoint{3.5cm}{3.5cm}}{}{
+ 2 copy
+ 45 sub dup mul exch
+ 40 sub dup mul 0.5 mul add sqrt
+ dup mul neg 1.0005 exch exp 1.0 exch sub
+ 3 1 roll
+ 70 sub dup mul .5 mul exch
+ 70 sub dup mul add sqrt
+ dup mul neg 1.002 exch exp 1.0 exch sub
+ 1.0 3 1 roll
+ \ifpgfshadingmodelcmyk
+ \pgffuncshadingrgbtocmyk
+ \fi
+ \ifpgfshadingmodelgray
+ \pgffuncshadingrgbtogray
+ \fi
+}
+\end{codeexample}
+
+\begin{command}{\pgffuncshadingrgbtocmyk}
+ Within the \meta{type 4 function} argument of
+ |\pgfdeclarefunctionalshading|, this command can be used to convert the
+ top 3 elements on the stack from \textsc{rgb} to \textsc{cmyk}. In
+ combination with the |\ifpgfshadingmodelcmyk| conditional this macro can
+ be used to make functional shading declarations more portable across color
+ models.
+\end{command}
+
+\begin{command}{\pgffuncshadingrgbtogray}
+ Within the \meta{type 4 function} argument of
+ |\pgfdeclarefunctionalshading|, this command can be used to convert the
+ top 3 elements on the stack from \textsc{rgb} to grayscale. In combination
+ with the |\ifpgfshadingmodelgray| conditional this macro can be used to
+ make functional shading declarations more portable across color models.
+\end{command}
+
+\begin{command}{\pgffuncshadingcmyktorgb}
+ Within the \meta{type 4 function} argument of
+ |\pgfdeclarefunctionalshading|, this command can be used to convert the
+ top 4 elements on the stack from \textsc{cmyk} to \textsc{rgb}. In
+ combination with the |\ifpgfshadingmodelrgb| conditional this macro can be
+ used to make functional shading declarations more portable across color
+ models.
+\end{command}
+
+\begin{command}{\pgffuncshadingcmyktogray}
+ Within the \meta{type 4 function} argument of
+ |\pgfdeclarefunctionalshading|, this command can be used to convert the
+ top 4 elements on the stack from \textsc{cmyk} to grayscale. In combination
+ with the |\ifpgfshadingmodelgray| conditional this macro can be used to
+ make functional shading declarations more portable across color models.
+\end{command}
+
+\begin{command}{\pgffuncshadinggraytorgb}
+ Within the \meta{type 4 function} argument of
+ |\pgfdeclarefunctionalshading|, this command can be used to convert the
+ top element on the stack from grayscale to \textsc{rgb}. In combination with
+ the |\ifpgfshadingmodelrgb| conditional this macro can be used to make
+ functional shading declarations more portable across color models.
+\end{command}
+
+\begin{command}{\pgffuncshadinggraytocmyk}
+ Within the \meta{type 4 function} argument of
+ |\pgfdeclarefunctionalshading|, this command can be used to convert the
+ top element on the stack from grayscale to \textsc{cmyk}. In combination
+ with the |\ifpgfshadingmodelcmyk| conditional this macro can be used to
+ make functional shading declarations more portable across color models.
+\end{command}
+
+{\let\ifpgfshadingmodelrgb=\relax
+ \let\ifpgfshadingmodelcmyk=\relax
+ \let\ifpgfshadingmodelgray=\relax
+ \begin{command}{\ifpgfshadingmodelrgb}
+ Within the \meta{type 4 function} argument of
+ |\pgfdeclarefunctionalshading|, this command can be used to test if the
+ |xcolor| color model is |rgb| \emph{at the time the shading is created}.
+ This can be used to ensure that the data output in the \meta{type 4
+ function} correctly matches the active color model.
+ \end{command}
+
+ \begin{command}{\ifpgfshadingmodelcmyk}
+ Within the \meta{type 4 function} argument of
+ |\pgfdeclarefunctionalshading|, this command can be used to test if the
+ |xcolor| color model is |cmyk| \emph{at the time the shading is created}.
+ This can be used to ensure that the data output in the \meta{type 4
+ function} correctly matches the active color model.
+ \end{command}
+
+ \begin{command}{\ifpgfshadingmodelgray}
+ Within the \meta{type 4 function} argument of
+ |\pgfdeclarefunctionalshading|, this command can be used to test if the
+ |xcolor| color model is |gray| \emph{at the time the shading is created}.
+ This can be used to ensure that the data output in the \meta{type 4
+ function} correctly matches the active color model.
+ \end{command}
+}
+
+\subsection{Using Shadings}
+\label{section-shading-a-path}
+
+\begin{command}{\pgfuseshading\marg{shading name}}
+ Inserts a previously declared shading into the text. If you wish to use it
+ in a |pgfpicture| environment, you should put a |\pgftext| around it.
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgfdeclareverticalshading{myshadingD}
+ {20pt}{color(0pt)=(red); color(20pt)=(blue)}
+ \pgftext[at=\pgfpoint{1cm}{0cm}] {\pgfuseshading{myshadingD}}
+ \pgftext[at=\pgfpoint{2cm}{0.5cm}]{\pgfuseshading{myshadingD}}
+\end{pgfpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfshadepath\marg{shading name}\marg{angle}}
+ This command must be used inside a |{pgfpicture}| environment. The effect
+ is a bit complex, so let us go over it step by step.
+
+ First, \pgfname\ will set up a local scope.
+
+ Second, it uses the current path to clip everything inside this scope.
+ However, the current path is once more available after the scope, so it can
+ be used, for example, to stroke it.
+
+ Now, the \meta{shading name} should be a shading whose width and height are
+ 100\,bp, that is, 100 big points. \pgfname\ has a look at the bounding box
+ of the current path. This bounding box is computed automatically when a
+ path is computed; however, it can sometimes be (quite a bit) too large,
+ especially when complicated curves are involved.
+
+ Inside the scope, the low-level transformation matrix is modified. The
+ center of the shading is translated (moved) such that it lies on the center
+ of the bounding box of the path. The low-level coordinate system is also
+ scaled such that the shading ``covers'' the path (the details are a bit
+ more complex, see below). Then, the coordinate system is rotated by
+ \meta{angle}. Finally, if the macro |\pgfsetadditionalshadetransform| has
+ been used, an additional transformation is applied.
+
+ After everything has been set up, the shading is inserted. Due to the
+ transformations and clippings, the effect will be that the shading seems
+ to ``fill'' the path.
+
+ If both the path and the shadings were always rectangles and if rotations
+ were never involved, it would be easy to scale shadings such they always
+ cover the path. However, when a vertical shading is rotated, it must
+ obviously be ``magnified'' so that it still covers the path. Things get
+ worse when the path is not a rectangle itself.
+
+ For these reasons, things work slightly differently ``in reality''. The
+ shading is scaled and translated such that the point
+ $(50\mathrm{bp},50\mathrm{bp})$, which is the middle of the shading, is at
+ the middle of the path and such that the point
+ $(25\mathrm{bp},25\mathrm{bp})$ is at the lower left corner of the path and
+ that $(75\mathrm{bp},75\mathrm{bp})$ is at upper right corner.
+
+ In other words, only the center quarter of the shading will actually
+ ``survive the clipping'' if the path is a rectangle. If the path is not a
+ rectangle, but, say, a circle, even less is seen of the shading. Here is an
+ example that demonstrates this effect:
+ %
+\begin{codeexample}[]
+\pgfdeclareverticalshading{myshadingE}{100bp}
+ {color(0bp)=(red); color(25bp)=(green); color(75bp)=(blue); color(100bp)=(black)}
+\pgfuseshading{myshadingE}
+\hskip 1cm
+\begin{pgfpicture}
+ \pgfpathrectangle{\pgfpointorigin}{\pgfpoint{2cm}{1cm}}
+ \pgfshadepath{myshadingE}{0}
+ \pgfusepath{stroke}
+ \pgfpathrectangle{\pgfpoint{3cm}{0cm}}{\pgfpoint{1cm}{2cm}}
+ \pgfshadepath{myshadingE}{0}
+ \pgfusepath{stroke}
+ \pgfpathrectangle{\pgfpoint{5cm}{0cm}}{\pgfpoint{2cm}{2cm}}
+ \pgfshadepath{myshadingE}{45}
+ \pgfusepath{stroke}
+ \pgfpathcircle{\pgfpoint{9cm}{1cm}}{1cm}
+ \pgfshadepath{myshadingE}{45}
+ \pgfusepath{stroke}
+\end{pgfpicture}
+\end{codeexample}
+
+ As can be seen above in the last case, the ``hidden'' part of the shading
+ actually \emph{can} become visible if the shading is rotated. The reason is
+ that it is scaled as if no rotation took place, then the rotation is done.
+
+ The following graphics show which part of the shading are actually shown:
+ %
+\begin{codeexample}[]
+\pgfdeclareverticalshading{myshadingF}{100bp}
+ {color(0bp)=(red); color(25bp)=(green); color(75bp)=(blue); color(100bp)=(black)}
+\begin{tikzpicture}
+ \draw (50bp,50bp) node {\pgfuseshading{myshadingF}};
+ \draw[white,thick] (25bp,25bp) rectangle (75bp,75bp);
+ \draw (50bp,0bp) node[below] {first two applications};
+
+ \begin{scope}[xshift=5cm]
+ \draw (50bp,50bp) node{\pgfuseshading{myshadingF}};
+ \draw[rotate around={45:(50bp,50bp)},white,thick] (25bp,25bp) rectangle (75bp,75bp);
+ \draw (50bp,0bp) node[below] {third application};
+ \end{scope}
+
+ \begin{scope}[xshift=10cm]
+ \draw (50bp,50bp) node{\pgfuseshading{myshadingF}};
+ \draw[white,thick] (50bp,50bp) circle (25bp);
+ \draw (50bp,0bp) node[below] {fourth application};
+ \end{scope}
+\end{tikzpicture}
+\end{codeexample}
+
+ An advantage of this approach is that when you rotate a radial shading, no
+ distortion is introduced:
+ %
+\begin{codeexample}[]
+\pgfdeclareradialshading{ballshading}{\pgfpoint{-10bp}{10bp}}
+ {color(0bp)=(red!15!white); color(9bp)=(red!75!white);
+ color(18bp)=(red!70!black); color(25bp)=(red!50!black); color(50bp)=(black)}
+\pgfuseshading{ballshading}
+\hskip 1cm
+\begin{pgfpicture}
+ \pgfpathrectangle{\pgfpointorigin}{\pgfpoint{1cm}{1cm}}
+ \pgfshadepath{ballshading}{0}
+ \pgfusepath{}
+ \pgfpathcircle{\pgfpoint{3cm}{0cm}}{1cm}
+ \pgfshadepath{ballshading}{0}
+ \pgfusepath{}
+ \pgfpathcircle{\pgfpoint{6cm}{0cm}}{1cm}
+ \pgfshadepath{ballshading}{45}
+ \pgfusepath{}
+\end{pgfpicture}
+\end{codeexample}
+
+ If you specify a rotation of $90^\circ$ and if the path is not a square,
+ but an elongated rectangle, the ``desired'' effect results: The shading
+ will exactly vary between the colors at the 25bp and 75bp boundaries. Here
+ is an example:
+ %
+\begin{codeexample}[]
+\pgfdeclareverticalshading{myshadingG}{100bp}
+ {color(0bp)=(red); color(25bp)=(green); color(75bp)=(blue); color(100bp)=(black)}
+\begin{pgfpicture}
+ \pgfpathrectangle{\pgfpointorigin}{\pgfpoint{2cm}{1cm}}
+ \pgfshadepath{myshadingG}{0}
+ \pgfusepath{stroke}
+ \pgfpathrectangle{\pgfpoint{3cm}{0cm}}{\pgfpoint{2cm}{1cm}}
+ \pgfshadepath{myshadingG}{90}
+ \pgfusepath{stroke}
+ \pgfpathrectangle{\pgfpoint{6cm}{0cm}}{\pgfpoint{2cm}{1cm}}
+ \pgfshadepath{myshadingG}{45}
+ \pgfusepath{stroke}
+\end{pgfpicture}
+\end{codeexample}
+
+ As a final example, let us define a ``rainbow spectrum'' shading for use
+ with \tikzname.
+ %
+\begin{codeexample}[]
+\pgfdeclareverticalshading{rainbow}{100bp}
+ {color(0bp)=(red); color(25bp)=(red); color(35bp)=(yellow);
+ color(45bp)=(green); color(55bp)=(cyan); color(65bp)=(blue);
+ color(75bp)=(violet); color(100bp)=(violet)}
+\begin{tikzpicture}[shading=rainbow]
+ \shade (0,0) rectangle node[white] {\textsc{pride}} (2,1);
+ \shade[shading angle=90] (3,0) rectangle +(1,2);
+\end{tikzpicture}
+\end{codeexample}
+
+ Note that rainbow shadings are \emph{way} too colorful in almost all
+ applications.
+\end{command}
+
+\begin{command}{\pgfsetadditionalshadetransform\marg{transformation}}
+ This command allows you to specify an additional transformation that should
+ be applied to shadings when the |\pgfshadepath| command is used. The
+ \meta{transformation} should be transformation code like
+ |\pgftransformrotate{20}|.
+\end{command}
+
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "pgfmanual"
+%%% End:
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-shadings.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-transformations.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-transformations.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-transformations.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,1246 @@
+% Copyright 2019 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section{Coordinate, Canvas, and Nonlinear Transformations}
+
+\subsection{Overview}
+
+\pgfname\ offers different ways of scaling, shifting, and rotating (these
+operations are generally known as \emph{transformations}) graphics: You can
+apply \emph{coordinate transformations} to all coordinates, you can apply
+\emph{canvas transformations} to the canvas on which you draw, and you can
+apply \emph{additional nonlinear transformations}. (The names ``coordinate''
+and ``canvas'' transformations are not standard, I introduce them only for the
+purposes of this manual.)
+
+The differences are the following:
+%
+\begin{itemize}
+ \item As the name ``coordinate transformation'' suggests, coordinate
+ transformations apply only to coordinates. For example, when you
+ specify a coordinate like |\pgfpoint{1cm}{2cm}| and you wish to ``use''
+ this coordinate -- for example as an argument to a |\pgfpathmoveto|
+ command -- then the coordinate transformation matrix is applied to the
+ coordinate, resulting in a new coordinate. Continuing the example, if
+ the current coordinate transformation is ``scale by a factor of two'',
+ the coordinate |\pgfpoint{1cm}{2cm}| actually designates the point
+ $(2\mathrm{cm},4\mathrm{cm})$.
+
+ Note that coordinate transformations apply \emph{only} to coordinates.
+ They do not apply to, say, line width or shadings or text.
+ \item The effect of a ``canvas transformation'' like ``scale by a factor of
+ two'' can be imagined as follows: You first draw your picture on a
+ ``rubber canvas'' normally. Then, once you are done, the whole canvas
+ is transformed, in this case stretched by a factor of two. In the
+ resulting image \emph{everything} will be larger: Text, lines,
+ coordinates, and shadings.
+ \item Nonlinear transformations are a special form of coordinate
+ transformations that are, as the name suggests, not linear. The support
+ for nonlinear transformations is quite different from the support for
+ linear coordinate transformations, the main reason being speed: While
+ linear coordinate transformations can be applied very quickly
+ (\pgfname\ does so almost constantly), nonlinear transformations are
+ much harder to apply and also to use. For this reason, nonlinear
+ transformations are implemented in a special module
+ |nonlineartransformations| that has to be loaded explicitly. By
+ default, they are not available.
+\end{itemize}
+
+In many cases, it is preferable that you use coordinate transformations and not
+canvas transformations. When canvas transformations are used, \pgfname\ looses
+track of the coordinates of nodes and shapes. Also, canvas transformations
+often cause undesirable effects like changing text size. For these reasons,
+\pgfname\ makes it easy to setup the coordinate transformation, but a bit
+harder to change the canvas transformation. Because of the speed penalties
+caused by nonlinear transformations, they are even harder to set up.
+
+
+\subsection{Coordinate Transformations}
+\label{section-linear-coordinate-transformations}
+
+\subsubsection{How PGF Keeps Track of the Coordinate Transformation Matrix}
+\label{section-transform-cm}
+
+\pgfname\ has an internal coordinate transformation matrix. This matrix is
+applied to coordinates ``in certain situations''. This means that the matrix is
+not always applied to every coordinate ``no matter what''. Rather, \pgfname\
+tries to be reasonably smart at when and how this matrix should be applied. The
+most prominent examples are the path construction commands, which apply the
+coordinate transformation matrix to their inputs.
+
+The coordinate transformation matrix consists of four numbers $a$, $b$, $c$,
+and $d$, and two dimensions $s$ and $t$. When the coordinate transformation
+matrix is applied to a coordinate $(x,y)$, the new coordinate
+$(ax+cy+s,bx+dy+t)$ results. For more details on how transformation matrices
+work in general, please see, for example, the \textsc{pdf} or PostScript
+reference or a textbook on computer graphics.
+
+The coordinate transformation matrix is equal to the identity matrix at the
+beginning. More precisely, $a=1$, $b=0$, $c=0$, $d=1$, $s=0\mathrm{pt}$, and
+$t=0\mathrm{pt}$.
+
+The different coordinate transformation commands will modify the matrix by
+concatenating it with another transformation matrix. This way the effect of
+applying several transformation commands will \emph{accumulate}.
+
+The coordinate transformation matrix is local to the current \TeX\ group
+(unlike the canvas transformation matrix, which is local to the current
+|{pgfscope}|). Thus, the effect of adding a coordinate transformation to the
+coordinate transformation matrix will last only till the end of the current
+\TeX\ group.
+
+
+\subsubsection{Commands for Relative Coordinate Transformations}
+
+The following commands add a basic coordinate transformation to the current
+coordinate transformation matrix. For all commands, the transformation is
+applied \emph{in addition} to any previous coordinate transformations.
+
+\begin{command}{\pgftransformshift\marg{point}}
+ Shifts coordinates by \meta{point}.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \draw (0,0) -- (2,1) -- (1,0);
+ \pgftransformshift{\pgfpoint{1cm}{1cm}}
+ \draw[red] (0,0) -- (2,1) -- (1,0);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgftransformxshift\marg{dimensions}}
+ Shifts coordinates by \meta{dimension} along the $x$-axis.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \draw (0,0) -- (2,1) -- (1,0);
+ \pgftransformxshift{.5cm}
+ \draw[red] (0,0) -- (2,1) -- (1,0);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgftransformyshift\marg{dimensions}}
+ Like |\pgftransformxshift|, only for the $y$-axis.
+\end{command}
+
+\begin{command}{\pgftransformscale\marg{factor}}
+ Scales coordinates by \meta{factor}.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \draw (0,0) -- (2,1) -- (1,0);
+ \pgftransformscale{.75}
+ \draw[red] (0,0) -- (2,1) -- (1,0);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgftransformxscale\marg{factor}}
+ Scales coordinates by \meta{factor} in the $x$-direction.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \draw (0,0) -- (2,1) -- (1,0);
+ \pgftransformxscale{.75}
+ \draw[red] (0,0) -- (2,1) -- (1,0);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgftransformyscale\marg{factor}}
+ Like |\pgftransformxscale|, only for the $y$-axis.
+\end{command}
+
+\begin{command}{\pgftransformxslant\marg{factor}}
+ Slants coordinates by \meta{factor} in the $x$-direction. Here, a factor of
+ |1| means $45^\circ$.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \draw (0,0) -- (2,1) -- (1,0);
+ \pgftransformxslant{.5}
+ \draw[red] (0,0) -- (2,1) -- (1,0);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgftransformyslant\marg{factor}}
+ Slants coordinates by \meta{factor} in the $y$-direction.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \draw (0,0) -- (2,1) -- (1,0);
+ \pgftransformyslant{-1}
+ \draw[red] (0,0) -- (2,1) -- (1,0);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+
+\begin{command}{\pgftransformrotate\marg{angles}}
+ Rotates coordinates counterclockwise by \meta{angles} given in degrees.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \draw (0,0) -- (2,1) -- (1,0);
+ \pgftransformrotate{30}
+ \draw[red] (0,0) -- (2,1) -- (1,0);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgftransformtriangle\marg{a}\marg{b}\marg{c}}
+ This command transforms the coordinate system in such a way that the
+ triangle given by the points \meta{a}, \meta{b} and \meta{c} lies at the
+ coordinates $(0,0)$, $(1\mathrm{pt},0\mathrm{pt})$ and
+ $(0\mathrm{pt},1\mathrm{pt})$.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgftransformtriangle
+ {\pgfpoint{1cm}{0cm}}
+ {\pgfpoint{0cm}{2cm}}
+ {\pgfpoint{3cm}{1cm}}
+
+ \draw (0,0) -- (1pt,0pt) -- (0pt,1pt) -- cycle;
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgftransformcm\marg{a}\marg{b}\marg{c}\marg{d}\marg{point}}
+ Applies the transformation matrix given by $a$, $b$, $c$, and $d$ and the
+ shift \meta{point} to coordinates (in addition to any previous
+ transformations already in force).
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \draw (0,0) -- (2,1) -- (1,0);
+ \pgftransformcm{1}{1}{0}{1}{\pgfpoint{.25cm}{.25cm}}
+ \draw[red] (0,0) -- (2,1) -- (1,0);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgftransformarrow\marg{start}\marg{end}}
+ Shifts coordinates to the end of the line going from \meta{start} to
+ \meta{end} with the correct rotation.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \draw (0,0) -- (3,1);
+ \pgftransformarrow{\pgfpointorigin}{\pgfpoint{3cm}{1cm}}
+ \pgftext{tip}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgftransformlineattime\marg{time}\marg{start}\marg{end}}
+ Shifts coordinates by a specific point on a line at a specific time. The
+ point by which the coordinate is shifted is calculated by calling
+ |\pgfpointlineattime|, see Section~\ref{section-pointsattime}.
+
+ In addition to shifting the coordinate, a rotation \emph{may} also be
+ applied. Whether this is the case depends on whether the \TeX\ if
+ |\ifpgfslopedattime| is set to true or not.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \draw (0,0) -- (2,1);
+ \pgftransformlineattime{.25}{\pgfpointorigin}{\pgfpoint{2cm}{1cm}}
+ \pgftext{Hi!}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \draw (0,0) -- (2,1);
+ \pgfslopedattimetrue
+ \pgftransformlineattime{.25}{\pgfpointorigin}{\pgfpoint{2cm}{1cm}}
+ \pgftext{Hi!}
+\end{tikzpicture}
+\end{codeexample}
+ %
+ If |\ifpgfslopedattime| is true, another \TeX\ |\if| is important:
+ |\ifpgfallowupsidedowattime|. If this is false, \pgfname\ will ensure that
+ the rotation is done in such a way that text is never ``upside down''.
+
+ There is another \TeX\ |\if| that influences this command. If you set
+ |\ifpgfresetnontranslationattime| to true, then, between shifting the
+ coordinate and (possibly) rotating/sloping the coordinate, the command
+ |\pgftransformresetnontranslations| is called. See the description of this
+ command for details.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgftransformscale{1.5}
+ \draw (0,0) -- (2,1);
+ \pgfslopedattimetrue
+ \pgfresetnontranslationattimefalse
+ \pgftransformlineattime{.25}{\pgfpointorigin}{\pgfpoint{2cm}{1cm}}
+ \pgftext{Hi!}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgftransformscale{1.5}
+ \draw (0,0) -- (2,1);
+ \pgfslopedattimetrue
+ \pgfresetnontranslationattimetrue
+ \pgftransformlineattime{.25}{\pgfpointorigin}{\pgfpoint{2cm}{1cm}}
+ \pgftext{Hi!}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgftransformcurveattime\marg{time}\marg{start}\marg{first support}\marg{second support}\marg{end}}
+ Shifts coordinates by a specific point on a curve at a specific time, see
+ Section~\ref{section-pointsattime} once more.
+
+ As for the line-at-time transformation command, |\ifpgfslopedattime|
+ decides whether an additional rotation should be applied. Again, the value
+ of |\ifpgfallowupsidedowattime| is also considered.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \draw (0,0) .. controls (0,2) and (1,2) .. (2,1);
+ \pgftransformcurveattime{.25}{\pgfpointorigin}
+ {\pgfpoint{0cm}{2cm}}{\pgfpoint{1cm}{2cm}}{\pgfpoint{2cm}{1cm}}
+ \pgftext{Hi!}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \draw (0,0) .. controls (0,2) and (1,2) .. (2,1);
+ \pgfslopedattimetrue
+ \pgftransformcurveattime{.25}{\pgfpointorigin}
+ {\pgfpoint{0cm}{2cm}}{\pgfpoint{1cm}{2cm}}{\pgfpoint{2cm}{1cm}}
+ \pgftext{Hi!}
+\end{tikzpicture}
+\end{codeexample}
+ %
+ The value of |\ifpgfresetnontranslationsattime| is also taken into account.
+\end{command}
+
+\begin{command}{\pgftransformarcaxesattime\marg{time
+ $t$}\marg{center}\marg{0-degree axis}\marg{90-degree
+ axis}\marg{start angle}\marg{end angle}%
+}
+ Shifts coordinates by a specific point on an arc at a specific time, see
+ Section~\ref{section-pointsattime} once more.
+
+ As for the previous commands, |\ifpgfslopedattime| decides whether an
+ additional rotation should be applied and |\ifpgfallowupsidedowattime| is
+ also considered.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgfpathmoveto{\pgfpoint{2cm}{1cm}}
+ \pgfpatharcaxes{0}{60}{\pgfpoint{2cm}{0cm}}{\pgfpoint{0cm}{1cm}}
+ \pgfusepath{stroke}
+ \pgfslopedattimetrue
+ \pgftransformarcaxesattime{.25}
+ {\pgfpoint{0cm}{1cm}}
+ {\pgfpoint{2cm}{0cm}}{\pgfpoint{0cm}{1cm}}
+ {0}{60}
+ \pgftext{Hi!}
+\end{tikzpicture}
+\end{codeexample}
+ %
+ The value of |\ifpgfresetnontranslationsattime| is also taken into account.
+\end{command}
+
+{
+ \let\ifpgfslopedattime=\relax
+ \begin{textoken}{\ifpgfslopedattime}
+ Decides whether the ``at time'' transformation commands also rotate
+ coordinates or not.
+ \end{textoken}
+}
+{
+ \let\ifpgfallowupsidedowattime=\relax
+ \begin{textoken}{\ifpgfallowupsidedowattime}
+ Decides whether the ``at time'' transformation commands should allow
+ the rotation be done in such a way that ``upside-down text'' can
+ result.
+ \end{textoken}
+}
+{
+ \let\ifpgfresetnontranslationsattime=\relax
+ \begin{textoken}{\ifpgfresetnontranslationsattime}
+ Decides whether the ``at time'' transformation commands should reset
+ the non-translations between shifting and rotating.
+ \end{textoken}
+}
+
+
+\subsubsection{Commands for Absolute Coordinate Transformations}
+
+The coordinate transformation commands introduced up to now are always applied
+in addition to any previous transformations. In contrast, the commands
+presented in the following can be used to change the transformation matrix ``in
+absolute terms''. Note that this is, in general, dangerous and will often
+produce unexpected effects. You should use these commands only if you really
+know what you are doing.
+
+\begin{command}{\pgftransformreset}
+ Resets the coordinate transformation matrix to the identity matrix. Thus,
+ once this command is given no transformations are applied till the end of
+ the scope.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgftransformrotate{30}
+ \draw (0,0) -- (2,1) -- (1,0);
+ \pgftransformreset
+ \draw[red] (0,0) -- (2,1) -- (1,0);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgftransformresetnontranslations}
+ This command sets the $a$, $b$, $c$, and $d$ part of the coordinate
+ transformation matrix to $a=1$, $b=0$, $c=0$, and $d=1$. However, the
+ current shifting of the matrix is not modified.
+
+ The effect of this command is that any rotation/scaling/slanting is undone
+ in the current \TeX\ group, but the origin is not ``moved back''.
+
+ This command is mostly useful directly before a |\pgftext| command to
+ ensure that the text is not scaled or rotated.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgftransformscale{2}
+ \pgftransformrotate{30}
+ \pgftransformxshift{1cm}
+ {\color{red}\pgftext{rotated}}
+ \pgftransformresetnontranslations
+ \pgftext{shifted only}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgftransforminvert}
+ Replaces the coordinate transformation matrix by a coordinate
+ transformation matrix that ``exactly undoes the original transformation''.
+ For example, if the original transformation was ``scale by 2 and then shift
+ right by 1cm'' the new one is ``shift left by 1cm and then scale by
+ $1/2$''.
+
+ This command will produce an error if the determinant of the matrix is too
+ small, that is, if the matrix is near-singular.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgftransformrotate{30}
+ \draw (0,0) -- (2,1) -- (1,0);
+ \pgftransforminvert
+ \draw[red] (0,0) -- (2,1) -- (1,0);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+
+\subsubsection{Saving and Restoring the Coordinate Transformation Matrix}
+
+There are two commands for saving and restoring coordinate transformation
+matrices.
+
+\begin{command}{\pgfgettransform\marg{macro}}
+ This command will (locally) define \meta{macro} to a representation of the
+ current coordinate transformation matrix. This matrix can later on be
+ reinstalled using |\pgfsettransform|.
+\end{command}
+
+\begin{command}{\pgfsettransform\marg{macro}}
+ Reinstalls a coordinate transformation matrix that was previously saved
+ using |\pgfgettransform|.
+\end{command}
+
+\begin{command}{\pgfgettransformentries\marg{macro for a}\marg{macro
+ for b}\marg{macro for c}\marg{macro for d}\marg{macro for shift
+ x}\marg{macro for shift y}%
+}
+ This command is similar to |\pgfgettransform| except that it stores the
+ current coordinate transformation matrix in a set of six macros.
+
+ The matrix can later on be reinstalled using |\pgfsettransformentries|.
+ Furthermore, all these macros (or just a few of them) can be used as
+ arguments for |\pgftransformcm|.
+\end{command}
+
+\begin{command}{\pgfsettransformentries\marg{a}\marg{b}\marg{c}\marg{d}\marg{shiftx}\marg{shifty}}
+ Reinstalls a coordinate transformation matrix that was previously saved
+ using the storage command |\pgfgettransformentries|. This command can also
+ be used to replace any previously existing coordinate transformation matrix
+ (it is thus equivalent to |\pgftransformreset| followed by
+ |\pgftransformcm|).
+\end{command}
+
+
+\subsubsection{Applying Coordinate Transformation to Points}
+
+\begin{command}{\pgfpointtransformed\marg{point}}
+ Applies current transformation matrix to \marg{point} $(x,y)$ and returns a
+ transformed point $(ax+cy+s,bx+dy+t)$. Normally, this is done automatically
+ by commands like |\pgfpathlineto| or |\pgfpathmoveto|, but sometimes you
+ may wish to access a transformed point yourself.
+\end{command}
+
+
+\subsubsection{Computing Adjustments for Coordinate Transformations}
+\label{section-adjustment-transformations}
+
+\begin{command}{\pgftransformationadjustments}
+ This command computes ``adjustments'' for the current transformation matrix
+ so that even when you install a transformation matrix that scales
+ everything by a certain factor, you can still draw something of ``an
+ absolute size''. Suppose for instance that you install a transformation
+ matrix that scales everything by a factor of 4 and you now wish to draw a
+ horizontal line of length 1cm. Then, if you do not reset the transformation
+ matrix, you can draw a line of logical length 2.5mm, which will then get
+ scaled to a line of 1cm. Things get more difficult in case you scale things
+ only, say, vertically. In this case, the adjustment necessary for
+ horizontal lines is different from the one needed for vertical lines.
+
+ This function computes two scaling factors, one for horizontal lines
+ and one for vertical lines, and stores them in the following macros:
+ %
+ \begin{command}{\pgfhorizontaltransformationadjustment}
+ When you scale the length of a horizontal line by this factor in the
+ current transformation, you compensate for the scaling. Formally, it is
+ $1/\|\mathit{transform}(1,0)\|_2$, where $\mathit{transform}$ applies
+ the current transformations matrix to the given number.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw [help lines] (0,0) grid (2,2);
+ \begin{scope}[xscale=2,thick]
+ \draw [red] (1,1) -- ++(1,0);
+
+ \pgftransformationadjustments
+ \draw [blue] (1,0) -- ++(\pgfhorizontaltransformationadjustment,0);
+ \end{scope}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw [help lines] (0,0) grid (2,2);
+ \begin{scope}[xscale=2,thick,rotate=90]
+ \draw [red] (1,1) -- ++(1,0);
+
+ \pgftransformationadjustments
+ \draw [blue] (1,0) -- ++(\pgfhorizontaltransformationadjustment,0);
+ \end{scope}
+\end{tikzpicture}
+\end{codeexample}
+ \end{command}
+ %
+ \begin{command}{\pgfverticaltransformationadjustment}
+ $1/\|\mathit{transform}(0,1)\|_2$.
+ \end{command}
+
+ Note that the ``right'' way to draw a line of absolute length 1cm in a
+ transformed coordinate system is to first compute the start point and to
+ then reset the transformation matrix. The transformation adjustments
+ computed here are important only in situations where you cannot do this,
+ for instance when an |outer xsep| must be set.
+\end{command}
+
+
+\subsection{Canvas Transformations}
+
+The canvas transformation matrix is not managed by \pgfname, but by the output
+format like \pdf\ or PostScript. All that \pgfname\ does is to call appropriate
+low-level |\pgfsys@| commands to change the canvas transformation matrix.
+
+Unlike coordinate transformations, canvas transformations apply to
+``everything'', including images, text, shadings, line thickness, and so on.
+The idea is that a canvas transformation really stretches and deforms the
+canvas after the graphic is finished.
+
+Unlike coordinate transformations, canvas transformations are local to the
+current |{pgfscope}|, not to the current \TeX\ group. This is due to the fact
+that they are managed by the backend driver, not by \TeX\ or \pgfname.
+
+Unlike the coordinate transformation matrix, it is not possible to ``reset''
+the canvas transformation matrix. The only way to change it is to concatenate
+it with another canvas transformation matrix or to end the current
+|{pgfscope}|.
+
+Unlike coordinate transformations, \pgfname\ does not ``keep track'' of canvas
+transformations. In particular, it will not be able to correctly save the
+coordinates of shapes or nodes when a canvas transformation is used.
+
+
+\subsubsection{Applying General Canvas Transformations}
+
+\pgfname\ does not offer many commands for modifying the canvas transformation
+matrix. Instead, different commands allow you to concatenate the canvas
+transformation matrix with a coordinate transformation matrix (and there are
+numerous commands for specifying a coordinate transformation, see the previous
+section).
+
+\begin{command}{\pgflowlevelsynccm}
+ This command concatenates the canvas transformation matrix with the current
+ coordinate transformation matrix. Afterward, the coordinate transformation
+ matrix is reset.
+
+ The effect of this command is to ``synchronize'' the coordinate
+ transformation matrix and the canvas transformation matrix. All
+ transformations that were previously applied by the coordinate
+ transformations matrix are now applied by the canvas transformation matrix.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgfsetlinewidth{1pt}
+ \pgftransformscale{5}
+ \draw (0,0) -- (0.4,.2);
+ \pgftransformxshift{0.2cm}
+ \pgflowlevelsynccm
+ \draw[red] (0,0) -- (0.4,.2);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgflowlevel\marg{transformation code}}
+ This command concatenates the canvas transformation matrix with the
+ coordinate transformation specified by \meta{transformation code}.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgfsetlinewidth{1pt}
+ \pgflowlevel{\pgftransformscale{5}}
+ \draw (0,0) -- (0.4,.2);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgflowlevelobj\marg{transformation code}\marg{code}}
+ This command creates a local |{pgfscope}|. Inside this scope,
+ |\pgflowlevel| is first called with the argument \meta{transformation
+ code}, then the \meta{code} is inserted.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgfsetlinewidth{1pt}
+ \pgflowlevelobj{\pgftransformscale{5}} {\draw (0,0) -- (0.4,.2);}
+ \pgflowlevelobj{\pgftransformxshift{-1cm}}{\draw (0,0) -- (0.4,.2);}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{environment}{{pgflowlevelscope}\marg{transformation code}}
+ This environment first surrounds the \meta{environment contents} by a
+ |{pgfscope}|. Then it calls |\pgflowlevel| with the argument
+ \meta{transformation code}.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \draw[help lines] (0,0) grid (3,2);
+ \pgfsetlinewidth{1pt}
+ \begin{pgflowlevelscope}{\pgftransformscale{5}}
+ \draw (0,0) -- (0.4,.2);
+ \end{pgflowlevelscope}
+ \begin{pgflowlevelscope}{\pgftransformxshift{-1cm}}
+ \draw (0,0) -- (0.4,.2);
+ \end{pgflowlevelscope}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{environment}
+
+\begin{plainenvironment}{{pgflowlevelscope}\marg{transformation code}}
+ Plain \TeX\ version of the environment.
+\end{plainenvironment}
+
+\begin{contextenvironment}{{pgflowlevelscope}\marg{transformation code}}
+ Con\TeX t version of the environment.
+\end{contextenvironment}
+
+
+\subsubsection{Establishing View Boxes}
+\label{section-base-view}
+
+A \emph{view box} is like a ``window'' through which you see a graphic. To
+establish a view box, you specify a rectangle -- which is the window -- and
+another rectangle surrounding the to-be-viewed graphic. The graphic will then
+be rescaled and shifted in such a way that the to-be-viewed rectangle matches
+the view box's rectangle as well as possible. Note that establishing a view box
+does, indeed, cause a canvas transformation to be installed.
+
+View boxes are only seldom needed in normal graphics. Their main application is
+with animations since you can \emph{animate} the to-be-viewed rectangle. This
+makes it easy to create animations in which you zoom in, zoom out, and pan a
+graphic.
+
+\begin{environment}{{pgfviewboxscope}\marg{$ll_1$}\marg{$ur_1$}\marg{$ll_2$}\marg{$ur_2$}\marg{meet or slice}}
+ Inside the viewbox scope, the source rectangle (with the two \pgfname\
+ points $ll_1$ and $ur_1$ as corners) will be translated and scaled so that
+ it becomes centered on the target rectangle (with the corners $ll_2$ and
+ $ur_2$) and will, for |meet| as last parameter, be as large as possible so
+ that it fits inside the target and, for |slice|, be as small as possible so
+ that it encompasses the target.
+ %
+\begin{codeexample}[]
+\tikz {
+ \draw [red, very thick] (0,0) rectangle (20mm,20mm);
+ \begin{pgfviewboxscope}
+ {\pgfpoint{5mm}{5mm}}{\pgfpoint{25mm}{15mm}} % Source
+ {\pgfpoint{0mm}{0mm}}{\pgfpoint{20mm}{20mm}} % Target
+ {meet}
+ \draw [blue, very thick] (5mm,5mm) rectangle (25mm,15mm);
+ \draw [thick] (1,1) circle [radius=8mm] node {Hi};
+ \end{pgfviewboxscope} }
+\end{codeexample}
+ %
+\begin{codeexample}[]
+\tikz {
+ \draw [red, very thick] (0,0) rectangle (20mm,20mm);
+ \begin{pgfviewboxscope}
+ {\pgfpoint{5mm}{5mm}}{\pgfpoint{25mm}{15mm}} % Source
+ {\pgfpoint{0mm}{0mm}}{\pgfpoint{20mm}{20mm}} % Target
+ {slice}
+ \draw [blue, very thick] (5mm,5mm) rectangle (25mm,15mm);
+ \draw [thick] (1,1) circle [radius=8mm] node {Hi};
+ \end{pgfviewboxscope} }
+\end{codeexample}
+ %
+\end{environment}
+
+\begin{plainenvironment}{{pgfviewboxscope}\marg{$ll_1$}\marg{$ur_1$}\marg{$ll_2$}\marg{$ur_2$}\marg{meet or slice}}
+ Plain \TeX\ version of the environment.
+\end{plainenvironment}
+
+\begin{contextenvironment}{{pgfviewboxscope}\marg{$ll_1$}\marg{$ur_1$}\marg{$ll_2$}\marg{$ur_2$}\marg{meet or slice}}
+ Con\TeX t version of the environment.
+\end{contextenvironment}
+
+
+\subsection{Nonlinear Transformations}
+\label{section-nonlinear-transformations}
+
+In order to use nonlinear transformations, you first have to load the following
+\pgfname\ module:
+
+\begin{pgfmodule}{nonlineartransformations}
+ Loads the necessary functionality for nonlinear transformations.
+\end{pgfmodule}
+
+
+\subsubsection{Introduction}
+
+The difference between the coordinate transformations introduced in
+Section~\ref{section-linear-coordinate-transformations} above to nonlinear
+transformations is, of course, that the transformations can be nonlinear. An
+example of a nonlinear transformation is the transformation underlying polar
+coordinates: A polar coordinate $(r,d)$ gets transformed to the canvas position
+$(d\cos r,d\sin r)$, which is clearly not a linear transformation.
+
+Nonlinear transformations work somewhat like the normal linear coordinate
+transformations in the sense that they apply to coordinate and thereby to the
+construction of paths, but not to things like text or line width or shadings.
+(Indeed, it is not possible to apply nonlinear transformations to, say, text.)
+
+This means that there is a fundamental difference between, on the one hand,
+calling a function like |\pgfpointpolar| or specifying a coordinate as |(45:2)|
+in \tikzname\ and, on the other hand, installing the nonlinear transformation
+``polar coordinates'' using the command |\pgftransformnonlinear|: In a
+coordinate like |(45:2)| the user explicitly says ``please evaluate this one
+coordinate in polar coordinate and then continue in the normal coordinate
+system with the result''. Otherwise nothing changes and a line between two
+points specified in this way is still a straight line.
+
+Things are quite different when we install a polar \emph{transformation} using
+|\pgftransformnonlinear|. Now, even a seemingly low-level Cartesian coordinate
+|\pgfqpoint{1pt}{1pt}| will get transformed. Even more drastically, what is
+specified as a straight line like
+%
+\begin{codeexample}[code only]
+\draw (0,1) -- (1,1);
+\end{codeexample}
+%
+can become curved since \emph{everything} gets transformed.
+
+
+\subsubsection{Installing Nonlinear Transformation}
+
+\begin{codeexample}[setup code,hidden]
+\makeatletter
+\def\polartransformation{
+ % \pgf at x will contain the radius
+ % \pgf at y will contain the distance
+ \pgfmathsincos@{\pgf at sys@tonumber\pgf at x}%
+ % pgfmathresultx is now the cosine of radius and
+ % pgfmathresulty is the sine of radius
+ \pgf at x=\pgfmathresultx\pgf at y%
+ \pgf at y=\pgfmathresulty\pgf at y%
+}
+\makeatother
+\end{codeexample}
+
+\begin{command}{\pgftransformnonlinear\marg{transformation code}}
+ This command adds the \meta{transformation code} to the list of non-linear
+ transformations currently in force. Thus, similar to linear coordinate
+ transformations, each additional call to this function adds another
+ transformation to the current \TeX\ scope and the effect ends at the end of
+ the current scope. In practice, however, you typically will not have more
+ than one active nonlinear transformation.
+
+ The job of the \meta{transformation code} is to map a point~$p$ given in
+ the registers |\pgf at x| and |\pgf at y| to a new coordinate~$f(p)$, which
+ should be returned in |\pgf at x| and |\pgf at y| as well. As an example, suppose
+ we wish to install polar coordinates as the nonlinear transformation. For
+ this, we need a bit of code:
+ %
+\begin{codeexample}[code only]
+\def\polartransformation{%
+ % \pgf at x will contain the radius
+ % \pgf at y will contain the distance
+ \pgfmathsincos@{\pgf at sys@tonumber\pgf at x}%
+ % pgfmathresultx is now the cosine of radius and
+ % pgfmathresulty is the sine of radius
+ \pgf at x=\pgfmathresultx\pgf at y%
+ \pgf at y=\pgfmathresulty\pgf at y%
+}
+\end{codeexample}
+ %
+ (In case you wonder why you cannot just call |\pgfpointpolar| at this
+ point: You can, but this function internally uses |\pgf at x| and |\pgf at y| in
+ complicated ways, so you would first have to safe them so some other
+ registers. Also, the above is faster.)
+
+ If we were to call this function again, we would get something funny like
+ ``polar-polar coordinates'', so let's not do this. Let us instead have a
+ look at the effect this call has: Once a nonlinear transformation is
+ installed, all subsequent path constructions are affected by this
+ transformation. In particular, a normal grid now becomes the typical
+ ``polar grid''.
+ %
+\begin{codeexample}[preamble={\usepgfmodule{nonlineartransformations}}]
+\begin{tikzpicture}
+ \draw [help lines] (0,0) grid (3,2);
+ % Start nonlinear transformation
+ \pgftransformnonlinear{\polartransformation}% see above
+
+ % Draw something with this transformation in force
+ \draw (0pt,0mm) grid [xstep=10pt, ystep=5mm] (90pt, 20mm);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+
+\subsubsection{Applying Nonlinear Transformations to Points}
+
+\begin{command}{\pgfpointtransformednonlinear\marg{point}}
+ Works like |\pgfpointtransformed|, but also applies the current nonlinear
+ transformation; that is, it first applies the current linear transformation
+ and then the current nonlinear transformations. Note that, just like
+ |\pgfpointtransformed|, you normally do not call this function directly
+ since it is called internally by the path drawing commands.
+\end{command}
+
+
+\subsubsection{Applying Nonlinear Transformations to Paths}
+
+When a nonlinear transformation is installed, the normal path construction
+commands like |\pgfpathmoveto| get adjusted so that the ``honour'' the
+nonlinear transformations currently in force. For |\pgfpathmoveto| this is
+pretty simple: Instead of just applying the linear transformation matrix to the
+point to which the path should ``jump'' next, we also apply the nonlinear
+transformation. However, for a command like |\pgfpathlineto|, things are much
+more difficult: A straight line will no longer be a straight line!
+
+In order to make straight lines ``bend'', the following changes are in force
+while a nonlinear transformation is installed:
+%
+\begin{enumerate}
+ \item Whenever a straight line between two points $p$ and $q$ should be
+ added to the path, either through |\pgfpathlineto| or through
+ |\pgfpathclose|, we replace this straight line by a ``degenerated
+ curve'' from $p$ to $q$ whose control points are at one third and two
+ third of the distance between $p$ and $q$ on the line between $p$ and
+ $q$. In this way, while nonlinear transformations are in force, we only
+ need to transform curves.
+ \item Next, suppose we wish to transform a curve from $p$ to $q$ with
+ supports $s$ and $t$. For this, we simply apply the nonlinear
+ transformation $f$ to all four points and draw a line with the results.
+ Note that this mapping is actually not quite satisfactory for long
+ lines that are strongly curved:
+ %
+\begin{codeexample}[preamble={\usepgfmodule{nonlineartransformations}}]
+\begin{tikzpicture}
+ \draw [help lines] (0,0) grid (3,2);
+ {
+ \pgftransformnonlinear{\polartransformation}
+ % The curve with the controls computed by pgf: a nice quarter arc
+ \draw [red] (0,20mm) -- (90pt,20mm);
+ }
+ % Here is the curve with controls just transformed:
+ \draw (0:20mm) .. controls (30pt:20mm) and (60pt:20mm) .. (90pt:20mm);
+\end{tikzpicture}
+\end{codeexample}
+ %
+ As the example shows, the control points now lie on the arc; but in
+ reality they should point along the tangents at the start and the end.
+ This is exactly when \pgfname\ does through the computation described
+ above.
+ \item To overcome the effect of the control points being ``off'', it is
+ necessary to split up longer curves into smaller parts, which are drawn
+ individually to increase the accuracy. When such splitting occurs, can
+ be configured using the following command:
+ %
+ \begin{command}{\pgfsettransformnonlinearflatness\marg{dimension} (initially 5pt)}
+ Whenever in a to-be-drawn curve the $L^\infty$-distance (maximum of
+ the distances in $x$- and $y$-directions) between the start of a
+ curve and its first control point or between the first and second
+ control points or between the second control point and the end is
+ more than \meta{distance}, the curve gets split in the middle (more
+ precisely, at time $t= 0.5$) and we draw the two parts individually
+ (for them, splitting may occur again, if the curve is still too
+ long).
+ %
+\begin{codeexample}[preamble={\usepgfmodule{nonlineartransformations}}]
+\begin{tikzpicture}
+ \draw [help lines] (0,0) grid (3,2);
+ \draw[red] (0:20mm) arc [start angle=0, end angle=90, radius=2cm];
+ {
+ \pgftransformnonlinear{\polartransformation}
+ \pgfsettransformnonlinearflatness{2pt} % very precise
+ \draw (0,20mm) -- (90pt,20mm);
+ }
+\end{tikzpicture}
+\end{codeexample}
+ \end{command}
+\end{enumerate}
+
+
+\subsubsection{Applying Nonlinear Transformations to Text}
+
+Earlier, it was pointed that nonlinear transformations do not apply to text.
+Nevertheless, when you use |\pgftext| or |\pgfnode|, \pgfname\ will do a sort
+of ``best effort'' to render the text in the nonlinear coordinate system: The
+point where the text should be shown can obviously be computed easily. When
+then temporarily reset the nonlinear transformation and, instead, setup a
+linear transformation that matches the nonlinear transformation at the point
+where the text should be. Then, the text is shown. This means that if the text
+is longer, it will not ``follow'' the nonlinear transformation, but near the
+origin of the text it will look ``correct''. As an example, let us add some
+text at the grid point of the above example:
+%
+\begin{codeexample}[preamble={\usepgfmodule{nonlineartransformations}}]
+\begin{tikzpicture}
+ \draw [help lines] (0,0) grid (3,2);
+ \pgftransformnonlinear{\polartransformation}% see above
+
+ % Draw something with this transformation in force
+ \draw (0pt,0mm) grid [xstep=10pt, ystep=5mm] (90pt, 20mm);
+
+ \foreach \angle in {0,30,60,90}
+ \foreach \dist in {1,2}
+ {
+ \pgftransformshift{\pgfpoint{\angle pt}{\dist cm}}
+ \pgftext{\angle$^\circ$}
+ }
+\end{tikzpicture}
+\end{codeexample}
+
+
+\subsubsection{Approximating Nonlinear Transformations Using Linear Transformations}
+
+At any given point, the current nonlinear transformation can be approximated
+using a linear transformation. The following two functions allow you to install
+such a local approximation:
+
+\begin{command}{\pgfapproximatenonlineartransformation}
+ This command will do two things:
+ %
+ \begin{enumerate}
+ \item It clears the nonlinear transformations for the rest of the
+ current \TeX\ scope, so only linear transformations apply.
+ \item However, before removing the nonlinear transformations, the
+ linear transformation matrix is modified so that it mimics the
+ effect the nonlinear transformation had at the origin. That is,
+ after you call this command, drawing something near the origin will
+ look almost the same as if you had not called it.
+ \end{enumerate}
+ %
+\begin{codeexample}[preamble={\usepgfmodule{nonlineartransformations}}]
+\begin{tikzpicture}
+ \draw [help lines] (0,0) grid (3,2);
+ \pgftransformnonlinear{\polartransformation}% see above
+ \draw (0pt,0mm) grid [xstep=10pt, ystep=5mm] (90pt, 20mm);
+
+ \begin{scope}[shift={(45pt,20mm)}]
+ % Draw something near "origin":
+ \draw [red] (-10pt,-10pt) -- (10pt,10pt);
+ \draw [red] (10pt,-10pt) -- (-10pt,10pt);
+
+ % Now draw the same, but in the "approximate" coordinate system:
+ \pgfapproximatenonlineartransformation
+ \draw [] (-10pt,-10pt) -- (10pt,10pt);
+ \draw [] (10pt,-10pt) -- (-10pt,10pt);
+ \pgftext{foo}
+ \end{scope}
+\end{tikzpicture}
+\end{codeexample}
+ %
+ This command is used by |\pgftext| and |\pgfnode| to transform text when a
+ nonlinear transformation is in force.
+\end{command}
+
+\begin{command}{\pgfapproximatenonlineartranslation}
+ This command works like the normal approximation command, but it will only
+ approximate how the origin gets translated, it will not approximate the
+ rotation, skewing, or scaling that is involved. This is useful for drawing
+ text at the right position, but without ``mutilating'' the text.
+ %
+\begin{codeexample}[preamble={\usepgfmodule{nonlineartransformations}}]
+\begin{tikzpicture}
+ \draw [help lines] (0,0) grid (3,2);
+ \pgftransformnonlinear{\polartransformation}% see above
+ \draw (0pt,0mm) grid [xstep=10pt, ystep=5mm] (90pt, 20mm);
+
+ \begin{scope}[shift={(45pt,20mm)}]
+ % Draw something near "origin":
+ \draw [red] (-10pt,-10pt) -- (10pt,10pt);
+ \draw [red] (10pt,-10pt) -- (-10pt,10pt);
+
+ % Now draw the same, but in the "approximate" coordinate system:
+ \pgfapproximatenonlineartranslation
+ \draw [] (-10pt,-10pt) -- (10pt,10pt);
+ \draw [] (10pt,-10pt) -- (-10pt,10pt);
+ \pgftext{foo}
+ \end{scope}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+
+\subsubsection{Nonlinear Transformation Libraries}
+\label{section-library-curvilinear}
+
+\begin{pgflibrary}{curvilinear}
+ This library defines commands for computing nonlinear transformations
+ ``along Bézier curves''.
+\end{pgflibrary}
+
+Up to now, our running example for a nonlinear transformation was polar
+transformation. However, is \pgfname\ nonlinear transformations are
+\emph{actually} mainly used for transforming arrow tips; and these need to be
+transformed ``along curves''. The |curvilinear| library defines a number of
+commands that offer the necessary computations for such transformations.
+
+\begin{command}{\pgfsetcurvilinearbeziercurve\marg{start}\marg{first support}\marg{second support}\marg{end}}
+ Prior to using any other command from this library, you first call this
+ function to ``install'' a Bézier curve to which the commands will refer.
+ This curve will be local to the current \TeX\ scope and you can install
+ only one curve at a time.
+
+ The main job of this command is to store the passed points internally and
+ to build a lookup table for distance-to-time conversions, see the next
+ command.
+ %
+\begin{codeexample}[code only]
+\pgfsetcurvilinearbeziercurve
+ {\pgfpointorigin}
+ {\pgfpoint{1cm}{1cm}}
+ {\pgfpoint{2cm}{1cm}}
+ {\pgfpoint{3cm}{0cm}}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfcurvilineardistancetotime\marg{distance}}
+ This command does a ``distance-to-time-conversion'': It tries to compute a
+ time $t$, returned in |\pgf at x|, that corresponds to travelling
+ \meta{distance} along the curve that has last been installed using the
+ command |\pgfsetcurvilinearbeziercurve|. The distance-to-time-conversion
+ uses the precomputations done by that command. Note that several
+ compromises had to be made between speed and accuracy:
+ %
+ \begin{itemize}
+ \item The conversion will be best near the start of the curve.
+ \item The more ``degenerate'' the curve, the worse the results.
+ \end{itemize}
+\end{command}
+
+\begin{command}{\pgfpointcurvilinearbezierorthogonal\marg{distance}\marg{offset}}
+ This command computes the following point: Consider the curve last
+ installed using the command |\pgfsetcurvilinearbeziercurve|. We travel
+ along this curve by \meta{distance}, arriving at a point $p$. Then, we turn
+ by $90^\circ$ and travel by \meta{offset} units ``always from the curve'',
+ arriving at a point $q$. This point $q$ will now be returned in |\pgf at x|
+ and |\pgf at y|; furthermore, the transformed local coordinate system at point
+ $q$ will also be returned |\pgf at xa| and the other registers, see
+ |\pgftransformnonlinear| for details.
+ %
+\makeatletter
+\begin{codeexample}[
+ preamble={\usepgfmodule{nonlineartransformations}
+\usetikzlibrary{curvilinear}},
+ pre=\makeatletter]
+\begin{tikzpicture}
+ \draw [help lines] (0,0) grid (3,2);
+ {
+ \pgfsetcurvilinearbeziercurve
+ {\pgfpoint{0mm}{20mm}}
+ {\pgfpoint{11mm}{20mm}}
+ {\pgfpoint{20mm}{11mm}}
+ {\pgfpoint{20mm}{0mm}}
+ \pgftransformnonlinear{\pgfpointcurvilinearbezierorthogonal\pgf at x\pgf at y}%
+ \draw (0,-30pt) grid [step=10pt] (80pt,30pt);
+ }
+ \draw[red, very thick]
+ (0mm,20mm) .. controls (11mm,20mm) and (20mm,11mm) .. (20mm,0mm);
+\end{tikzpicture}
+\end{codeexample}
+
+\begin{codeexample}[
+ preamble={\usepgfmodule{nonlineartransformations}
+\usetikzlibrary{curvilinear}},
+ pre=\makeatletter]
+\begin{tikzpicture}
+ \draw [help lines] (0,0) grid (3,2);
+ {
+ \pgfsetcurvilinearbeziercurve
+ {\pgfpoint{0mm}{20mm}}
+ {\pgfpoint{10mm}{20mm}}
+ {\pgfpoint{10mm}{10mm}}
+ {\pgfpoint{20mm}{10mm}}
+ \pgftransformnonlinear{\pgfpointcurvilinearbezierorthogonal\pgf at x\pgf at y}%
+ \draw (0,-30pt) grid [step=10pt] (80pt,30pt);
+ }
+ \draw[red, very thick]
+ (0mm,20mm) .. controls (10mm,20mm) and (10mm,10mm) .. (20mm,10mm);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfpointcurvilinearbezierpolar\marg{x}\marg{y}}
+ This command is similar to the previous version, but the transformation is
+ different: The idea is that a line form $(0,0)$ to $(x,0)$ gets transformed
+ to the curve from the start of the curve to a point at distance $x$ along
+ the curve. This is identical to what the ``orthogonal'' transformation
+ above also does. The difference is that a line from $(0,0)$ to $(0,y)$ gets
+ still transformed to an initial segment of the curve of a length of $y$,
+ but now rotated by $90^\circ$. In general, the point $p = (x,y)$ gets
+ transferred to a point that at distance $|p| = \sqrt{x^2+y^2}$ along the
+ curve, but rotated by the angle of $p$ relative to the $x$-axis.
+
+ All of these computations mainly have the following effect: Two straight
+ lines from the start of the curve as in a |Straight Barb| arrow tip get
+ transformed to an initial segment of the curve whose length is the length
+ of the two lines, but this segment gets rotated by the angle of the two
+ lines.
+ %
+\makeatletter
+\begin{codeexample}[
+ preamble={\usepgfmodule{nonlineartransformations}
+\usetikzlibrary{curvilinear}},
+ pre=\makeatletter]
+\begin{tikzpicture}
+ \draw [help lines] (0,0) grid (3,2);
+ {
+ \pgfsetcurvilinearbeziercurve
+ {\pgfpoint{0mm}{20mm}}
+ {\pgfpoint{11mm}{20mm}}
+ {\pgfpoint{20mm}{11mm}}
+ {\pgfpoint{20mm}{0mm}}
+ \pgftransformnonlinear{\pgfpointcurvilinearbezierpolar\pgf at x\pgf at y}%
+ \draw (0,-30pt) grid [step=10pt] (80pt,30pt);
+ % Add a "barb":
+ \draw [blue, very thick] (20pt,10pt) -- (0,0) -- (20pt,-10pt);
+ }
+ \draw[red, very thick]
+ (0mm,20mm) .. controls (11mm,20mm) and (20mm,11mm) .. (20mm,0mm);
+\end{tikzpicture}
+\end{codeexample}
+
+\begin{codeexample}[
+ preamble={\usepgfmodule{nonlineartransformations}
+\usetikzlibrary{curvilinear}},
+ pre=\makeatletter]
+\begin{tikzpicture}
+ \draw [help lines] (0,0) grid (3,2);
+ {
+ \pgfsetcurvilinearbeziercurve
+ {\pgfpoint{0mm}{20mm}}
+ {\pgfpoint{10mm}{20mm}}
+ {\pgfpoint{10mm}{10mm}}
+ {\pgfpoint{20mm}{10mm}}
+ \pgftransformnonlinear{\pgfpointcurvilinearbezierpolar\pgf at x\pgf at y}%
+ \draw (0,-30pt) grid [step=10pt] (80pt,30pt);
+ % Add a "barb":
+ \draw [blue, very thick] (20pt,10pt) -- (0,0) -- (20pt,-10pt);
+ }
+ \draw[red, very thick]
+ (0mm,20mm) .. controls (10mm,20mm) and (10mm,10mm) .. (20mm,10mm);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "pgfmanual"
+%%% End:
+
+% LocalWords: nonlineartransformations PGF cx dy pdf PostScript pgfscope xstep
+% LocalWords: Reinstalls shiftx backend pgflowlevelscope ystep ezier lookup xa
+% LocalWords: precomputations
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-transformations.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-transparency.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-transparency.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-transparency.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,391 @@
+% Copyright 2019 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section{Transparency}
+\label{section-transparency}
+
+For an introduction to the notion of transparency, fadings, and transparency
+groups, please consult Section~\ref{section-tikz-transparency}.
+
+
+\subsection{Specifying a Uniform Opacity}
+
+Specifying a stroke and/or fill opacity is quite easy.
+
+\begin{command}{\pgfsetstrokeopacity\marg{value}}
+ Sets the opacity of stroking operations. The \meta{value} should be a
+ number between |0| and |1|, where |1| means ``fully opaque'' and |0| means
+ ``fully transparent''. A value like |0.5| will cause paths to be stroked in
+ a semitransparent way.
+ %
+\begin{codeexample}[]
+\begin{pgfpicture}
+ \pgfsetlinewidth{5mm}
+ \color{red}
+ \pgfpathcircle{\pgfpoint{0cm}{0cm}}{10mm} \pgfusepath{stroke}
+ \color{black}
+ \pgfsetstrokeopacity{0.5}
+ \pgfpathcircle{\pgfpoint{1cm}{0cm}}{10mm} \pgfusepath{stroke}
+\end{pgfpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfsetfillopacity\marg{value}}
+ Sets the opacity of filling operations. As for stroking, the \meta{value}
+ should be a number between |0| and~|1|.
+
+ The ``filling transparency'' will also be used for text and images.
+ %
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \pgfsetfillopacity{0.5}
+ \fill[red] (90:1cm) circle (11mm);
+ \fill[green] (210:1cm) circle (11mm);
+ \fill[blue] (-30:1cm) circle (11mm);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+Note the following effect: If you set up a certain opacity for stroking or
+filling and you stroke or fill the same area twice, the effect accumulates:
+%
+\begin{codeexample}[]
+\begin{tikzpicture}
+ \pgfsetfillopacity{0.5}
+ \fill[red] (0,0) circle (1);
+ \fill[red] (1,0) circle (1);
+\end{tikzpicture}
+\end{codeexample}
+
+Often, this is exactly what you intend, but not always. You can use
+transparency groups, see the end of this section, to change this.
+
+
+\subsection{Specifying a Blend Mode}
+
+To set the blend mode, use the following command:
+
+\begin{command}{\pgfsetblendmode\marg{mode}}
+ Sets the blend mode to one of the values described in
+ Section~\ref{section-blend-modes}. As described there, blend modes are an
+ advanced feature of \textsc{pdf} and not always rendered correctly.
+ %
+\begin{codeexample}[]
+\tikz [transparency group] {
+ \pgfsetblendmode{screen}
+
+ \fill[red!90!black] ( 90:.6) circle (1);
+ \fill[green!80!black] (210:.6) circle (1);
+ \fill[blue!90!black] (330:.6) circle (1);
+}
+\end{codeexample}
+ %
+\end{command}
+
+
+\subsection{Specifying a Fading}
+
+The method used by \pgfname\ for specifying fadings is quite general: You
+``paint'' the fading using any of the standard graphics commands. In more
+detail: You create a normal picture, which may even contain text, image, and
+shadings. Then, you create a fading based on this picture. For this, the
+\emph{luminosity} of each pixel of the picture is analyzed (the brighter the
+pixel, the higher the luminosity -- a black pixel has luminosity $0$, a white
+pixel has luminosity $1$, a gray pixel has some intermediate value as does a
+red pixel). Then, when the fading is used, the luminosity of the pixel
+determines the opacity of the fading at that position. Positions in the fading
+where the picture was black will be completely transparent, positions where the
+picture was white will be completely opaque. Positions that have not been
+painted at all in the picture are always completely transparent.
+
+\begin{command}{\pgfdeclarefading\marg{name}\marg{contents}}
+ This command declares a fading named \meta{name} for later use. The
+ ``picture'' on which the fading is based is given by the \meta{contents}.
+ The \meta{contents} are normally typeset in a \TeX\ box. The resulting box
+ is then used as the ``picture''. In particular, inside the \meta{contents}
+ you must explicitly open a |{pgfpicture}| environment if you wish to use
+ \pgfname\ commands.
+
+ Let's start with an easy example. Our first fading picture is just some
+ text:
+ %
+\begin{codeexample}[]
+\pgfdeclarefading{fading1}{\textcolor{white}{Ti\emph{k}Z}}
+\begin{tikzpicture}
+ \fill [black!20] (0,0) rectangle (2,2);
+ \fill [black!30] (0,0) arc (180:0:1);
+ \pgfsetfading{fading1}{\pgftransformshift{\pgfpoint{1cm}{1cm}}}
+ \fill [red] (0,0) rectangle (2,2);
+\end{tikzpicture}
+\end{codeexample}
+ %
+ What's happening here? The ``fading picture'' is mostly transparent, except
+ for the pixels that are part of the word Ti\emph{k}Z. Now, these pixels are
+ \emph{white} and, thus, have a high luminosity. This in turn means that
+ these pixels of the fading will be highly opaque. For this reason, only
+ those pixels of the big red rectangle ``shine through'' that are at the
+ positions of these opaque pixels.
+
+ It is somewhat counter-intuitive that the white pixels in a fading picture
+ are opaque in a fading. For this reason, the color |pgftransparent| is
+ defined to be the same as |black|. This allows one to write
+ |pgftransparent| for completely transparent parts of a fading picture and
+ |pgftransparent!0| for the opaque parts and things like |pgftransparent!20|
+ for parts that are 20\% transparent.
+
+ Furthermore, the color |pgftransparent!0| (which is the same as white and
+ which corresponds to completely opaque) is installed at the beginning of a
+ fading picture. Thus, in the above example the |\color{white}| was not
+ really necessary.
+
+ Next, let us create a fading that gets more and more transparent as we go
+ from left to right. For this, we put a shading inside the fading picture
+ that has the color |pgftransparent!0| at the left-hand side and the color
+ |pgftransparent!100| at the right-hand side.
+ %
+\begin{codeexample}[]
+\pgfdeclarefading{fading2}
+{\tikz \shade[left color=pgftransparent!0,
+ right color=pgftransparent!100] (0,0) rectangle (2,2);}
+\begin{tikzpicture}
+ \fill [black!20] (0,0) rectangle (2,2);
+ \fill [black!30] (0,0) arc (180:0:1);
+ \pgfsetfading{fading2}{\pgftransformshift{\pgfpoint{1cm}{1cm}}}
+ \fill [red] (0,0) rectangle (2,2);
+\end{tikzpicture}
+\end{codeexample}
+
+ In our final example, we create a fading that is based on a radial shading.
+ %
+\begin{codeexample}[]
+\pgfdeclareradialshading{myshading}{\pgfpointorigin}
+{
+ color(0mm)=(pgftransparent!0);
+ color(5mm)=(pgftransparent!0);
+ color(8mm)=(pgftransparent!100);
+ color(15mm)=(pgftransparent!100)
+}
+\pgfdeclarefading{fading3}{\pgfuseshading{myshading}}
+\begin{tikzpicture}
+ \fill [black!20] (0,0) rectangle (2,2);
+ \fill [black!30] (0,0) arc (180:0:1);
+ \pgfsetfading{fading3}{\pgftransformshift{\pgfpoint{1cm}{1cm}}}
+ \fill [red] (0,0) rectangle (2,2);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+After having declared a fading, we can use it. As for shadings, there are
+different commands for using fadings:
+
+\begin{command}{\pgfsetfading\marg{name}\marg{transformations}}
+ This command sets the graphic state parameter ``fading'' to a previously
+ defined fading \meta{name}. This graphic state works like other graphic
+ states, that is, is persists till the end of the current scope or until a
+ different transparency setting is chosen.
+
+ When the fading is installed, it will be centered on the origin with its
+ natural size. Anything outside the fading picture's original bounding box
+ will be transparent and, thus, the fading effectively clips against this
+ bounding box.
+
+ The \meta{transformations} are applied to the fading before it is used.
+ They contain normal \pgfname\ transformation commands like
+ |\pgftransformshift|. You can also scale the fading using this command.
+ Note, however, that the transformation needs to be inverted internally,
+ which may result in inaccuracies and the following graphics may be slightly
+ distorted if you use a strong \meta{transformation}.
+ %
+\begin{codeexample}[]
+\pgfdeclarefading{fading2}
+{\tikz \shade[left color=pgftransparent!0,
+ right color=pgftransparent!100] (0,0) rectangle (2,2);}
+\begin{tikzpicture}
+ \fill [black!20] (0,0) rectangle (2,2);
+ \fill [black!30] (0,0) arc (180:0:1);
+ \pgfsetfading{fading2}{}
+ \fill [red] (0,0) rectangle (2,2);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\begin{codeexample}[preamble={\pgfdeclarefading{fading2}
+{\tikz \shade[left color=pgftransparent!0,
+ right color=pgftransparent!100] (0,0) rectangle (2,2);}}]
+\begin{tikzpicture}
+ \fill [black!20] (0,0) rectangle (2,2);
+ \fill [black!30] (0,0) arc (180:0:1);
+ \pgfsetfading{fading2}{\pgftransformshift{\pgfpoint{1cm}{1cm}}
+ \pgftransformrotate{20}}
+ \fill [red] (0,0) rectangle (2,2);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfsetfadingforcurrentpath\marg{name}\marg{transformations}}
+ This command works like |\pgfsetfading|, but the fading is scaled and
+ transformed according to the following rules:
+ %
+ \begin{enumerate}
+ \item If the current path is empty, the command has the same effect as
+ |\pgfsetfading|.
+ \item Otherwise it is assumed that the fading has a size of 100bp times
+ 100bp.
+ \item The fading is resized and shifted (using appropriate
+ transformations) such that the position
+ $(25\mathrm{bp},25\mathrm{bp})$ lies at the lower-left corner of
+ the current path and the position $(75\mathrm{bp},75\mathrm{bp})$
+ lies at the upper-right corner of the current path.
+ \end{enumerate}
+ %
+ Note that these rules are the same as the ones used in |\pgfshadepath| for
+ shadings. After these transformations, the \meta{transformations} are
+ executed (typically a rotation).
+ %
+\begin{codeexample}[]
+\pgfdeclarehorizontalshading{shading}{100bp}
+{ color(0pt)=(transparent!0); color(25bp)=(transparent!0);
+ color(75bp)=(transparent!100); color(100bp)=(transparent!100)}
+
+\pgfdeclarefading{fading}{\pgfuseshading{shading}}
+
+\begin{tikzpicture}
+ \fill [black!20] (0,0) rectangle (2,2);
+ \fill [black!30] (0,0) arc (180:0:1);
+
+ \pgfpathrectangle{\pgfpointorigin}{\pgfpoint{2cm}{1cm}}
+ \pgfsetfadingforcurrentpath{fading}{}
+ \pgfusepath{discard}
+
+ \fill [red] (0,0) rectangle (2,1);
+
+ \pgfpathrectangle{\pgfpoint{0cm}{1cm}}{\pgfpoint{2cm}{1cm}}
+ \pgfsetfadingforcurrentpath{fading}{\pgftransformrotate{90}}
+ \pgfusepath{discard}
+
+ \fill [red] (0,1) rectangle (2,2);
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+\begin{command}{\pgfsetfadingforcurrentpathstroked\marg{name}\marg{transformations}}
+ This command works like |\pgfsetfadingforcurrentpath|, only the current
+ path is enlarged by the line width in both $x$- and $y$-direction. This is
+ exactly the enlargement necessary to compensate for the fact that if the
+ current path will be stroked, this much needs to be added around the path's
+ bounding box to actually contain the path.
+ %
+\begin{codeexample}[preamble={\pgfdeclarehorizontalshading{shading}{100bp}
+{ color(0pt)=(transparent!0); color(25bp)=(transparent!0);
+ color(75bp)=(transparent!100); color(100bp)=(transparent!100)}
+%
+\pgfdeclarefading{fading}{\pgfuseshading{shading}}}]
+\begin{tikzpicture}
+ \pgfsetlinewidth{2mm}
+ \pgfpathmoveto{\pgfpointorigin}
+ \pgfpathlineto{\pgfpoint{2cm}{0cm}}
+ \pgfsetfadingforcurrentpathstroked{fading}{}
+ \pgfusepath{stroke}
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
+
+
+\subsection{Transparency Groups}
+
+Transparency groups are declared using the following commands.
+
+\begin{environment}{{pgftransparencygroup}\opt{\oarg{options}}}
+ This environment should only be used inside a |{pgfpicture}|. It has the
+ following effect:
+ %
+ \begin{enumerate}
+ \item The \meta{environment contents} are stroked/filled ``ignoring any
+ outside transparency''. This means, all previous transparency
+ settings are ignored (you can still set transparency inside the
+ group, but never mind). This means that if in the \meta{environment
+ contents} you stroke a pixel three times in black, it is just
+ black. Stroking it white afterwards yields a white pixel, and so
+ on.
+ \item When the group is finished, it is painted as a whole. The
+ \emph{fill} transparency settings are now applied to the resulting
+ picture. For instance, the pixel that has been painted three times
+ in black and once in white is just white at the end, so this white
+ color will be blended with whatever is ``behind'' the group on the
+ page.
+ \end{enumerate}
+
+ The optional \meta{options} are keys that configure the transparency group
+ further. Two keys are currently defined:
+ %
+ \begin{itemize}
+ \item \declare{|knockout|\opt{|=|\meta{true or false}}} Configures
+ whether the group is a knockout group (if no argument is given,
+ |true| is assumed; initially the key is always false, even when the
+ command is used in a nested manner.) See
+ Section~\ref{section-transparency-groups} for details on knockout
+ groups.
+ \item \declare{|isolated|\opt{|=|\meta{true or false}}} Similar, but
+ configures whether the group is an isolated group. Also see
+ Section~\ref{section-transparency-groups} for details on isolated
+ groups.
+ \end{itemize}
+
+ Note that, depending on the driver, \pgfname\ may have to guess the size of
+ the contents of the transparency group (because such a group is put in an
+ XForm in \textsc{pdf} and a bounding box must be supplied). \pgfname\ will
+ use normally use the size of the picture's bounding box at the end of the
+ transparency group plus a safety margin of 1cm. Under normal circumstances,
+ this will work nicely since the picture's bounding box contains everything
+ anyway. However, if you have switched off the picture size tracking or if
+ you are using canvas transformations, you may have to make sure that the
+ bounding box is big enough. The trick is to locally create a picture that
+ is ``large enough'' and then insert this picture into the main picture
+ while ignoring the size. The following example shows how this is done:
+
+% TODO: Nesting tikzpictures is NOT supported
+{\ifpgfmanualexternalize\tikzexternaldisable\fi
+\begin{codeexample}[preamble={\usetikzlibrary{shapes.symbols}}]
+\begin{tikzpicture}
+ \draw [help lines] (0,0) grid (2,2);
+
+ % Stuff outside the picture, but still in a transparency group.
+ \node [left,overlay] at (0,1) {
+ \begin{tikzpicture}
+ \pgfsetfillopacity{0.5}
+ \pgftransparencygroup
+ \node at (2,0) [forbidden sign,line width=2ex,draw=red,fill=white]
+ {Smoking};
+ \endpgftransparencygroup
+ \end{tikzpicture}
+ };
+\end{tikzpicture}
+\end{codeexample}
+}%
+
+ \begin{plainenvironment}{{pgftransparencygroup}}
+ Plain \TeX\ version of the |{pgftransparencygroup}| environment.
+ \end{plainenvironment}
+
+ \begin{contextenvironment}{{pgftransparencygroup}}
+ This is the Con\TeX t version of the environment.
+ \end{contextenvironment}
+\end{environment}
+
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "pgfmanual"
+%%% End:
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-base-transparency.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-drivers.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-drivers.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-drivers.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,468 @@
+% Copyright 2019 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section{Supported Formats}
+\label{section-formats}
+
+\TeX\ was designed to be a flexible system. This is true both for the
+\emph{input} for \TeX\ as well as for the \emph{output}. The present section
+explains which input formats there are and how they are supported by \pgfname.
+It also explains which different output formats can be produced.
+
+
+\subsection{Supported Input Formats: \LaTeX, Plain \TeX, Con\TeX t}
+
+\TeX\ does not prescribe exactly how your input should be formatted. While it
+is \emph{customary} that, say, an opening brace starts a scope in \TeX, this is
+by no means necessary. Likewise, it is \emph{customary} that environments start
+with |\begin|, but \TeX\ could not really care less about the exact command
+name.
+
+Even though \TeX\ can be reconfigured, users can not. For this reason, certain
+\emph{input formats} specify a set of commands and conventions how input for
+\TeX\ should be formatted. There are currently three ``major'' formats: Donald
+Knuth's original |plain| \TeX\ format, Leslie Lamport's popular \LaTeX\ format,
+and Hans Hangen's Con\TeX t format.
+
+
+\subsubsection{Using the \LaTeX\ Format}
+
+Using \pgfname\ and \tikzname\ with the \LaTeX\ format is easy: You say
+|\usepackage{pgf}| or |\usepackage{tikz}|. Usually, that is all you need to do,
+all configuration will be done automatically and (hopefully) correctly.
+
+The style files used for the \LaTeX\ format reside in the subdirectory
+|latex/pgf/| of the \pgfname-system. Mainly, what these files do is to include
+files in the directory |generic/pgf|. For example, here is the content of the
+file |latex/pgf/frontends/tikz.sty|:
+%
+\begin{codeexample}[code only]
+% Copyright 2019 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Public License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\RequirePackage{pgf,pgffor}
+
+\input{tikz.code.tex}
+
+\endinput
+\end{codeexample}
+
+The files in the |generic/pgf| directory do the actual work.
+
+
+\subsubsection{Using the Plain \TeX\ Format}
+
+When using the plain \TeX\ format, you say |\input{pgf.tex}| or
+|\input{tikz.tex}|. Then, instead of |\begin{pgfpicture}| and
+|\end{pgfpicture}| you use |\pgfpicture| and |\endpgfpicture|.
+
+Unlike for the \LaTeX\ format, \pgfname\ is not as good at discerning the
+appropriate configuration for the plain \TeX\ format. In particular, it can
+only automatically determine the correct output format if you use |pdftex| or
+|tex| plus |dvips|. For all other output formats you need to set the macro
+|\pgfsysdriver| to the correct value. See the description of using output
+formats later on.
+
+Like the \LaTeX\ style files, the plain \TeX\ files like |tikz.tex| also just
+include the correct |tikz.code.tex| file.
+
+
+\subsubsection{Using the Con\TeX t Format}
+
+When using the Con\TeX t format, you say |\usemodule[pgf]| or
+|\usemodule[tikz]|. As for the plain \TeX\ format you also have to replace the
+start- and end-of-environment tags as follows: Instead of |\begin{pgfpicture}|
+and |\end{pgfpicture}| you use |\startpgfpicture| and |\stoppgfpicture|;
+similarly, instead of |\begin{tikzpicture}| and |\end{tikzpicture}| you use
+must now use |\starttikzpicture| and |\stoptikzpicture|; and so on for other
+environments.
+
+The Con\TeX t support is very similar to the plain \TeX\ support, so the same
+restrictions apply: You may have to set the output format directly and graphics
+inclusion may be a problem.
+
+In addition to |pgf| and |tikz| there also exist modules like |pgfcore| or
+|pgfmodulematrix|. To use them, you may need to include the module |pgfmod|
+first (the modules |pgf| and |tikz| both include |pgfmod| for you, so typically
+you can skip this). This special module is necessary since old versions of
+Con\TeX t~MkII before 2005 satanically restricted the length of module names to
+8 characters and \pgfname's long names are mapped to cryptic 6-letter-names for
+you by the module |pgfmod|. This restriction was never in place in
+Con\TeX t~MkIV and the |pgfmod| module can be safely ignored nowadays.
+
+
+\subsection{Supported Output Formats}
+\label{section-drivers}
+
+An output format is a format in which \TeX\ outputs the text it has typeset.
+Producing the output is (conceptually) a two-stage process:
+%
+\begin{enumerate}
+ \item \TeX\ typesets your text and graphics. The result of this
+ typesetting is mainly a long list of letter--coordinate pairs, plus
+ (possibly) some ``special'' commands. This long list of pairs is
+ written to something called a |.dvi|-file (informally known as
+ ``device-independent file'').
+ \item Some other program reads this |.dvi|-file and translates the
+ letter--coordinate pairs into, say, PostScript commands for placing
+ the given letter at the given coordinate.
+\end{enumerate}
+
+The classical example of this process is the combination of |latex| and
+|dvips|. The |latex| program (which is just the |tex| program called with the
+\LaTeX-macros preinstalled) produces a |.dvi|-file as its output. The |dvips|
+program takes this output and produces a |.ps|-file (a PostScript file).
+Possibly, this file is further converted using, say, |ps2pdf|, whose name is
+supposed to mean ``PostScript to PDF''. Another example of programs using this
+process is the combination of |tex| and |dvipdfm|. The |dvipdfm| program takes
+a |.dvi|-file as input and translates the letter--coordinate pairs therein into
+\pdf-commands, resulting in a |.pdf| file directly. Finally, the |tex4ht| is
+also a program that takes a |.dvi|-file and produces an output, this time it is
+a |.html| file. The programs |pdftex| and |pdflatex| are special: They directly
+produce a |.pdf|-file without the intermediate |.dvi|-stage. However, from the
+programmer's point of view they behave exactly as if there was an intermediate
+stage.
+
+Normally, \TeX\ only produces letter--coordinate pairs as its ``output''. This
+obviously makes it difficult to draw, say, a curve. For this, ``special''
+commands can be used. Unfortunately, these special commands are not the same
+for the different programs that process the |.dvi|-file. Indeed, every program
+that takes a |.dvi|-file as input has a totally different syntax for the
+special commands.
+
+One of the main jobs of \pgfname\ is to ``abstract away'' the difference in the
+syntax of the different programs. However, this means that support for each
+program has to be ``programmed'', which is a time-consuming and complicated
+process.
+
+
+\subsubsection{Selecting the Backend Driver}
+
+When \TeX\ typesets your document, it does not know which program you are going
+to use to transform the |.dvi|-file. If your |.dvi|-file does not contain any
+special commands, this would be fine; but these days almost all |.dvi|-files
+contain lots of special commands. It is thus necessary to tell \TeX\ which
+program you are going to use later on.
+
+Unfortunately, there is no ``standard'' way of telling this to \TeX. For the
+\LaTeX\ format a sophisticated mechanism exists inside the |graphics| package
+and \pgfname\ plugs into this mechanism. For other formats and when this
+plugging does not work as expected, it is necessary to tell \pgfname\ directly
+which program you are going to use. This is done by redefining the macro
+|\pgfsysdriver| to an appropriate value \emph{before} you load |pgf|. If you
+are going to use the |dvips| program, you set this macro to the value
+|pgfsys-dvips.def|; if you use |pdftex| or |pdflatex|, you set it to
+|pgfsys-pdftex.def|; and so on. In the following, details of the support of the
+different programs are discussed.
+
+
+\subsubsection{Producing PDF Output}
+
+\pgfname\ supports three programs that produce \pdf\ output (\pdf\ means
+``portable document format'' and was invented by the Adobe company): |dvipdfm|,
+|pdftex|, and |vtex|. The |pdflatex| program is the same as the |pdftex|
+program: it uses a different input format, but the output is exactly the same.
+
+\begin{filedescription}{pgfsys-pdftex.def}
+ This is the driver file for use with pdf\TeX, that is, with the |pdftex| or
+ |pdflatex| command. It includes |pgfsys-common-pdf.def|.
+
+ This driver has a lot of functionality. (Almost) everything \pgfname\ ``can
+ do at all'' is implemented in this driver.
+\end{filedescription}
+
+\begin{filedescription}{pgfsys-dvipdfm.def}
+ This is a driver file for use with (|la|)|tex| followed by |dvipdfm|. It
+ includes |pgfsys-common-pdf.def|.
+
+ This driver supports most of \pgfname's features, but there are some
+ restrictions:
+ %
+ \begin{enumerate}
+ \item In \LaTeX\ mode it uses |graphicx| for the graphics inclusion
+ and does not support masking.
+ \item In plain \TeX\ mode it does not support image inclusion.
+ \end{enumerate}
+\end{filedescription}
+
+\begin{filedescription}{pgfsys-xetex.def}
+ This is a driver file for use with |xe|(|la|)|tex| followed by |xdvipdfmx|.
+ This driver supports largely the same operations as the |dvipdfm| driver.
+\end{filedescription}
+
+\begin{filedescription}{pgfsys-vtex.def}
+ This is the driver file for use with the commercial \textsc{vtex} program.
+ Even though it produces \textsc{pdf} output, it includes
+ |pgfsys-common-postscript.def|. Note that the \textsc{vtex} program can
+ produce \emph{both} Postscript and \textsc{pdf} output, depending on the
+ command line parameters. However, whether you produce Postscript or
+ \textsc{pdf} output does not change anything with respect to the driver.
+
+ This driver supports most of \pgfname's features, except for the following
+ restrictions:
+ %
+ \begin{enumerate}
+ \item In \LaTeX\ mode it uses |graphicx| for the graphics inclusion
+ and does not support masking.
+ \item In plain \TeX\ mode it does not support image inclusion.
+ \item Shadings are approximated with discrete colors. This typically
+ leads to aliasing patterns in PostScript and \textsc{pdf} viewing
+ applications.
+ \item Opacity, Transparency Groups, Fadings and Blend Modes are not
+ supported.
+ \item Remembering of pictures (inter-picture connections) is not
+ supported.
+ \end{enumerate}
+\end{filedescription}
+
+It is also possible to produce a |.pdf|-file by first producing a PostScript
+file (see below) and then using a PostScript-to-\pdf\ conversion program like
+|ps2pdf| or Acrobat Distiller.
+
+
+\subsubsection{Producing PostScript Output}
+
+\begin{filedescription}{pgfsys-dvips.def}
+ This is a driver file for use with (|la|)|tex| followed by |dvips|. It
+ includes |pgfsys-common-postscript.def|.
+
+ This driver also supports most of \pgfname's features, except for the
+ following restrictions:
+ %
+ \begin{enumerate}
+ \item In \LaTeX\ mode it uses |graphicx| for the graphics inclusion.
+ Image masking is supported if the PostScript output is further
+ processed with |ps2pdf| to produce \textsc{pdf}.
+ \item In plain \TeX\ mode it does not support image inclusion.
+ \item Functional shadings are approximated with Type-0 functions
+ (sampled functions), because Type-4 functions are not available in
+ the latest (version 3) PostScript language definition. Due to
+ their fixed resolution, Type-0 functional shadings are of lesser
+ quality at higher zoom levels as compared to functional shadings
+ from \textsc{pdf} producing drivers. Axial and radial shadings are
+ fully supported. The same output quality (smooth shadings) is
+ achieved as with drivers that produce \textsc{pdf} output.
+ \item Although fully supported, opacity and fadings are \textsc{pdf}
+ features that become visible only after further processing the
+ PostScript output with |ps2pdf|. Note that newer Ghostscript
+ versions are necessary for producing opacity in the \textsc{pdf}
+ output. Also, beginning with version 9.52 of Ghostscript, command
+ line option |-dALLOWPSTRANSPARENCY| must be added:
+\begin{codeexample}[code only]
+ps2pdf -dALLOWPSTRANSPARENCY example.ps
+\end{codeexample}
+ \item For remembering of pictures (inter-picture connections) you
+ need to use a recent version of |pdftex| running in DVI-mode.
+ \end{enumerate}
+\end{filedescription}
+
+\begin{filedescription}{pgfsys-textures.def}
+ This is a driver file for use with the \textsc{textures} program. It
+ includes |pgfsys-common-postscript.def|.
+
+ This driver shares the restrictions of the |vtex| driver, but adds limited
+ opacity support (no transparency groups, fadings and blend modes, though).
+\end{filedescription}
+
+You can also use the |vtex| program together with |pgfsys-vtex.def| to produce
+Postscript output.
+
+
+\subsubsection{Producing SVG Output}
+
+\begin{filedescription}{pgfsys-dvisvgm.def}
+ This driver converts \textsc{dvi} files to \textsc{svg} file, including
+ text and fonts. When you select this driver, \pgfname\ will output the
+ required raw \textsc{svg} code for the pictures it produces.
+
+ Since the |graphics| package does not (yet?) support this driver directly,
+ there is special rule for this driver in \LaTeX: If the option |dvisvgm| is
+ given to the |tikz| package, this driver gets selected (normally, the
+ driver selected by |graphics| would be used). For packages like |beamer|
+ that load \pgfname\ themselves, this means that the option |dvisvgm| should
+ be given to the document class.
+ %
+\begin{codeexample}[code only]
+% example.tex
+\documentclass[dvisvgm]{minimal}
+
+\usepackage{tikz}
+
+\begin{document}
+Hello \tikz [baseline] \fill [fill=blue!80!black] (0,.75ex) circle[radius=.75ex];
+\end{document}
+\end{codeexample}
+
+ And then run
+ %
+\begin{codeexample}[code only]
+latex example
+dvisvgm example
+\end{codeexample}
+ %
+ or better
+ %
+\begin{codeexample}[code only]
+lualatex --output-format=dvi example
+dvisvgm example
+\end{codeexample}
+ %
+ (This is ``better'' since it gives you access to the full power of Lua\TeX\
+ inside your \TeX-file. In particular, \tikzname\ is able to run graph
+ drawing algorithms in this case.)
+
+ Unlike the |tex4ht| driver below, this driver has full support of text
+ nodes.
+\end{filedescription}
+
+\begin{filedescription}{pgfsys-tex4ht.def}
+ This is a driver file for use with the |tex4ht| program. It is selected
+ automatically when the |tex4ht| style or command is loaded. It includes
+ |pgfsys-common-svg.def|.
+
+ The |tex4ht| program converts |.dvi|-files to |.html|-files. While the
+ \textsc{html}-format cannot be used to draw graphics, the
+ \textsc{svg}-format can. This driver will ask \pgfname\ to produce an
+ \textsc{svg}-picture for each \pgfname\ graphic in your text.
+
+ When using this driver you should be aware of the following restrictions:
+ %
+ \begin{enumerate}
+ \item In \LaTeX\ mode it uses |graphicx| for the graphics inclusion.
+ \item In plain \TeX\ mode it does not support image inclusion.
+ \item Remembering of pictures (inter-picture connections) is not
+ supported.
+ \item Text inside |pgfpicture|s is not supported very well. The
+ reason is that the \textsc{svg} specification currently does not
+ support text very well and, although it is possible to ``escape
+ back'' to \textsc{html}, \tikzname\ has then to guess what size
+ the text rendered by the browser would have.
+ \item Unlike for other output formats, the bounding box of a picture
+ ``really crops'' the picture.
+ \item Matrices do not work.
+ \item Functional shadings are not supported.
+ \end{enumerate}
+
+ The driver basically works as follows: When a |{pgfpicture}| is started,
+ appropriate |\special| commands are used to directed the output of |tex4ht|
+ to a new file called |\jobname-xxx.svg|, where |xxx| is a number that is
+ increased for each graphic. Then, till the end of the picture, each (system
+ layer) graphic command creates a special that inserts appropriate
+ \textsc{svg} literal text into the output file. The exact details are a bit
+ complicated since the imaging model and the processing model of
+ PostScript/\pdf\ and \textsc{svg} are not quite the same; but they are
+ ``close enough'' for \pgfname's purposes.
+
+ Because text is not supported very well in the \textsc{svg} standard, you
+ may wish to use the following options to modify the way text is handled:
+
+ \begin{key}{/pgf/tex4ht node/escape=\meta{boolean} (default |false|)}
+ Selects the rendering method for a text node with the tex4ht driver.
+
+ When this key is set to |false|, text is translated into \textsc{svg}
+ text, which is somewhat limited: simple characters (letters, numerals,
+ punctuation, $\sum$, $\int$, \ldots), subscripts and superscripts (but
+ not subsubscripts) will display but everything else will be filtered
+ out, ignored or will produce invalid \textsc{html} code (in the worst
+ case). This means that two kind of texts render reasonably well:
+ %
+ \begin{enumerate}
+ \item First, plain text without math mode, special characters or
+ anything else special.
+ \item Second, \emph{very} simple mathematical text that contains
+ subscripts or superscripts. Even then, variables are not
+ correctly set in italics and, in general, text simple does
+ not look very nice.
+ \end{enumerate}
+ %
+ If you use text that contains anything special, even something as
+ simple as |$\alpha$|, this may corrupt the graphic.
+ %
+\begin{codeexample}[code only]
+\tikz \node[draw,/pgf/tex4ht node/escape=false] {Example : $(a+b)^2=a^2+2ab+b^2$};
+\end{codeexample}
+
+ When you write |node[/pgf/tex4ht node/escape=true] {|\meta{text}|}|,
+ \pgfname\ escapes back to \textsc{html} to render the \meta{text}. This
+ method produces valid \textsc{html} code in most cases and the support for
+ complicated text nodes is much better since code that renders well outside
+ a |{pgfpicture}|, should also render well inside a text node. Another
+ advantage is that inside text nodes with fixed width, \textsc{html} will
+ produce line breaks for long lines. On the other hand, you need a browser
+ with good \textsc{svg} support to display the picture. Also, the text will
+ display differently, depending on your browsers, the fonts you have on your
+ system and your settings. Finally, \pgfname\ has to guess the size of the
+ text rendered by the browser to scale it and prevent it from sticking from
+ the node. When it fails, the text will be either cropped or too small.
+ %
+\begin{codeexample}[code only]
+\tikz \node[draw,/pgf/tex4ht node/escape=true]
+ {Example : $\int_0^\infty\frac{1}{1+t^2}dt=\frac{\pi}{2}$};
+\end{codeexample}
+ %
+ \end{key}
+
+ \begin{key}{/pgf/tex4ht node/css=\meta{filename} (default |\string\jobname|)}
+ This option allows you to tell the browser what \textsc{css} file it
+ should use to style the display of the node (only with
+ |tex4ht node/escape=true|).
+ \end{key}
+
+ \begin{key}{/pgf/tex4ht node/class=\meta{class name} (default foreignobject)}
+ This option allows you to give a class name to the node, allowing it to
+ be styled by a \textsc{css} file (only with |tex4ht node/escape=true|).
+ \end{key}
+
+ \begin{key}{/pgf/tex4ht node/id=\meta{id name} (default |\string\jobname\ picture number-node number|)}
+ This option allows you to give a unique id to the node, allowing
+ it to be styled by a \textsc{css} file (only with
+ |tex4ht node/escape=true|).
+ \end{key}
+\end{filedescription}
+
+
+\subsubsection{Producing Perfectly Portable DVI Output}
+
+\begin{filedescription}{pgfsys-dvi.def}
+ This is a driver file that can be used with any output driver, except for
+ |tex4ht|.
+
+ The driver will produce perfectly portable |.dvi| files by composing all
+ pictures entirely of black rectangles, the basic and only graphic shape
+ supported by the \TeX\ core. Even straight, but slanted lines are tricky to
+ get right in this model (they need to be composed of lots of little
+ squares).
+
+ Naturally, \emph{very little} is possible with this driver. In fact, so
+ little is possible that it is easier to list what is possible:
+ %
+ \begin{itemize}
+ \item Text boxes can be placed in the normal way.
+ \item Lines and curves can be drawn (stroked). If they are not
+ horizontal or vertical, they are composed of hundreds of small
+ rectangles.
+ \item Lines of different width are supported.
+ \item Transformations are supported.
+ \end{itemize}
+ %
+ Note that, say, even filling is not supported! (Let alone color or anything
+ fancy.)
+
+ This driver has only one real application: It might be useful when you only
+ need horizontal or vertical lines in a picture. Then, the results are quite
+ satisfactory.
+\end{filedescription}
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-drivers.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-axes.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-axes.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-axes.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,3822 @@
+% Copyright 2019 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section{Axes}
+\label{section-dv-axes}
+
+\subsection{Overview}
+
+When a data point is visualized, the most obvious way of creating a visual
+representation of its many attributes is to vary \emph{where} the data point is
+shown. The data visualization system uses \emph{axes} to turn data point
+attributes into positions on a page. The simplest -- and most common -- use of
+axes is to vary the horizontal position of data points according to one
+attribute and to vary the vertical position according to another attribute. In
+contrast, in a polar plot one attribute dictates the distance of the data point
+from the origin and another attribute describes the angle. From the data
+visualization engine's point of view, in both cases two \emph{axes} are
+involved.
+
+In addition to specifying how the value of a certain attribute is converted
+into a displacement on the page, an axis is also typically (but not always)
+visualized (``drawn'') somewhere on the page. In this case, it is also
+customary to add a visual representation on this axis of which attribute values
+correspond to which positions on the page -- something commonly known as
+\emph{ticks}. Similar to ticks, \emph{grid lines} also indicate positions where
+a certain attribute has a certain value, but instead of just indicating a
+single position on an axis, a grid line goes through all points that share an
+attribute value.
+
+In the following, in Section~\ref{section-dv-axes-main} we first have a look at
+how axes can be defined and configured. As you will see, a lot of powerful
+configurations are available, but you will rarely define and configure an axis
+from scratch. Rather, it is more common to use a preconfigured axis instead.
+Section~\ref{section-dv-axis-systems} introduces \emph{axis systems}, which are
+predefined bundles of axes. You can define your own axis systems, but, again,
+in most cases it will suffice to just use one of the many preconfigured axis
+systems and use a few options to configure it so that it fits your need.
+Section~\ref{section-dv-ticks-and-grids} explains how ticks and grid lines can
+be configured. Again, several layers of options allow you to configure the way
+ticks look and where they are placed in great detail.
+
+This section documents the standard axis systems that are always available. For
+polar axis systems, a special library needs to be loaded, which is documented
+in Section~\ref{section-dv-polar}.
+
+
+\subsection{Basic Configuration of Axes}
+\label{section-dv-axes-main}
+
+Inside the data visualization system, an \emph{axis} is roughly a ``systematic,
+named way of mapping an attribute to a position on a page''. For instance, the
+classical ``$x$-axis'' is the ``systematic way of mapping the value of the |x|
+attribute of data points to a horizontal position on the page''. An axis is
+\emph{not} its visual representation (such as the horizontal line with the
+ticks drawn to represent the $x$-axis), but a visual representation can be
+created once an axis has been defined.
+
+The transformation of an attribute value (such as the value |1000000000| for
+the |x| attribute) to a specific displacement of the corresponding data point
+on the page involves two steps:
+%
+\begin{enumerate}
+ \item First, the range of possible values such as $[-5.6\cdot
+ 10^{12},7.8\cdot 10^{12}]$ must be mapped to a ``reasonable'' interval
+ such as $[0\mathrm{cm},5\mathrm{cm}]$ or $[0^\circ,180^\circ]$.
+ \tikzname's drawing routines will only be able to cope with values from
+ such a ``reasonable'' interval.
+ \item Second, the values from the reasonable interval must be mapped to a
+ transformation.
+\end{enumerate}
+%
+The first step is always the same for all axes, while the second requires
+different strategies. For this reason, the command |new axis base| is used to
+create a ``basic'' axis that has a ``scaling mapper'', whose job it is to map
+the range of values of a specific attribute to a reasonable interval, but such
+a basic axis does not define an actual transformation object. For this second
+step, additional objects such as a |linear transformer| need to be created
+separately.
+
+
+\subsubsection{Usage}
+
+To create an axis, the key |new axis base| is used first. Since this key does
+not create a transformation object, users typically do not use this key
+directly. Rather, it is used internally by other keys that create ``real''
+axes. These keys are listed in Section~\ref{section-dv-reference-axis-types}.
+
+\begin{key}{/tikz/data visualization/new axis base=\meta{axis name}}
+ This key defines a new axis for the current data visualization called
+ \meta{name}. This has two effects:
+ %
+ \begin{enumerate}
+ \item A so called \emph{scaling mapper} is created that will monitor a
+ certain attribute, rescale it, and map it to another attribute.
+ (This will be explained in detail in a moment.)
+ \item The \meta{axis name} is made available as a key that can be used
+ to configure the axis:
+ %
+ \begin{key}{/tikz/data visualization/\meta{axis name}=\meta{options}}
+ This key becomes available once |new axis base=|meta{axis name}
+ has been called. It will execute the \meta{options} with the
+ path prefix |/tikz/data visualization/axis options|.
+ %
+\begin{codeexample}[code only]
+[new axis base=my axis,
+ my axis={attribute=some attribute}]
+\end{codeexample}
+ \end{key}
+ \item The \meta{axis name} becomes part of the current set of axes.
+ This set can be accessed through the following key:
+ %
+ \begin{key}{/tikz/data visualization/all axes=\meta{options}}
+ This key passes the \meta{options} to all axes inside the
+ current scope, just as if you had written \meta{some axis
+ name}|=|\meta{options} for each \meta{some axis name} in the
+ current scope, including the just-created name \meta{axis
+ name}.
+ \end{key}
+ \end{enumerate}
+ %
+ There are many \meta{options} that can be passed to a newly created axis.
+ They are explained in the rest of this section.
+\end{key}
+
+Note the |new axis base| does \emph{not} cause attributes to be mapped to
+positions on a page. Rather, special keys like |new Cartesian axis| first use
+|new axis base| to create an axis and then create an internal object that
+performs a linear mapping of the attribute to positions along a vectors.
+
+
+\subsubsection{The Axis Attribute}
+\label{section-dv-axis-attribute}
+
+The first main job of an axis is to map the different values of some attribute
+to a reasonable interval. To achieve this, the following options are important
+(recall that these options are passed to the key whose name is the name of the
+axis):
+
+\begin{key}{/tikz/data visualization/axis options/attribute=\meta{attribute}}
+ Specifies that the axis is used to transform the data points according the
+ different values of the key |/data point/|\meta{attribute}. For instance,
+ when we create a classical two-dimensional Cartesian coordinate system,
+ then there are two axes called |x axis| and |y axis| that monitor the
+ values of the attributes |/data point/x| and |/data point/y|, respectively:
+ %
+\begin{codeexample}[code only]
+ [new axis base=x axis,
+ new axis base=y axis,
+ x axis={attribute=x},
+ y axis={attribute=y}]
+\end{codeexample}
+ %
+ In another example, we also create an |x axis| and a |y axis|. However,
+ this time, we want to plot the values of the |/data point/time| attribute
+ on the $x$-axis and, say, the value of the |height| attribute on the
+ $y$-axis:
+ %
+\begin{codeexample}[code only]
+ [new axis base=x axis,
+ new axis base=y axis,
+ x axis={attribute=time},
+ y axis={attribute=height}]
+\end{codeexample}
+ %
+ During the data visualization, the \meta{attribute} will be ``monitored''
+ during the survey phase. This means that for each data point, the current
+ value of |/data point/|\meta{attribute} is examined and the minimum value
+ of all of these values as well as the maximum value is recorded internally.
+ Note that this works even when very large numbers like |100000000000| are
+ involved.
+
+ Here is a real-life example. The |scientific axes| create two axes, called
+ |x axis| and |y axis|, respectively.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\tikz \datavisualization [scientific axes,
+ x axis={attribute=people, length=2.5cm, ticks=few},
+ y axis={attribute=year},
+ visualize as scatter]
+ data {
+ year, people
+ 1900, 100
+ 1910, 200
+ 1950, 200
+ 1960, 250
+ 2000, 150
+ };
+\end{codeexample}
+ %
+\end{key}
+
+
+\subsubsection{The Axis Attribute Range Interval}
+
+Once an attribute has been specified for an axis, the data visualization engine
+will start monitoring this value. This means that before anything actual
+visualization is done, a ``survey phase'' is used to determine the range of
+values encountered for the attribute for all data points. This range of values
+results in what is called the \emph{attribute range interval}. Its minimum is
+the smallest value encountered in the data and its maximum is the largest
+value.
+
+Even though the attribute range interval is computed automatically and even
+though you typically do not need to worry about it, there are some situations
+where you may wish to set or enlarge the attribute range interval:
+%
+\begin{itemize}
+ \item You may wish to start the interval with $0$, even though the range of
+ values contains only positive values.
+ \item You may wish to slightly enlarge the interval so that, say, the
+ maximum is some ``nice'' value like |100| or |60|.
+\end{itemize}
+
+The following keys can be used to influence the size of the attribute range
+interval:
+%
+\begin{key}{/tikz/data visualization/axis options/include value=\meta{list of value}}
+ This key ``fakes'' data points for which the attribute's values are in the
+ comma-separated \meta{list of values}. For instance, when you write
+ |include value=0|, then the attribute range interval is guaranteed to
+ contain |0| -- even if the actual data points are all positive or all
+ negative.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization [scientific axes, all axes={length=3cm},
+ visualize as line]
+ data [format=function] {
+ var x : interval [5:10];
+ func y = \value x * \value x;
+ };
+\end{codeexample}
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization [scientific axes, all axes={length=3cm},
+ visualize as line,
+ x axis={include value=20},
+ y axis={include value=0}]
+ data [format=function] {
+ var x : interval [5:10];
+ func y = \value x * \value x;
+ };
+\end{codeexample}
+ %
+\end{key}
+
+\begin{key}{/tikz/data visualization/axis options/min value=\meta{value}}
+ This key allows you to simply set the minimum value, regardless of which
+ values are present in the actual data. This key should be used with care:
+ If there are data points for which the attribute's value is less than
+ \meta{value}, they will still be depicted, but typically outside the normal
+ visualization area. Usually, saying |include value=|\meta{value} will
+ achieve the same as saying |min value=|\meta{value}, but with less danger
+ of creating ill-formed visualizations.
+\end{key}
+
+\begin{key}{/tikz/data visualization/axis options/max value=\meta{value}}
+ Works like |min value|.
+\end{key}
+
+
+\subsubsection{Scaling: The General Mechanism}
+
+The above key allows us specify which attribute should be ``monitored''. The
+next key is used to specify what should happen with the observed values.
+
+\begin{key}{/tikz/data visualization/axis options/scaling=\meta{scaling spec}}
+ The \meta{scaling spec} must have the following form:
+ %
+ \begin{quote}
+ \meta{$s_1$}| at |\meta{$t_1$}| and |\meta{$s_2$}| at |\meta{$t_2$}
+ \end{quote}
+ %
+ This means that monitored values in the interval $[s_1,s_2]$ should be
+ mapped to values the ``reasonable'' interval $[t_1,t_2]$, instead. For
+ instance, we might write
+ %
+\begin{codeexample}[code only]
+[y axis = {scaling = 1900 at 0cm and 2000 at 5cm}]
+\end{codeexample}
+ %
+ in order to map dates between 1900 and 2000 to the dimension interval
+ $[0\mathrm{cm},5\mathrm{cm}]$.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\tikz \datavisualization
+ [scientific axes,
+ x axis={attribute=people, length=2.5cm, ticks=few},
+ y axis={attribute=year, scaling=1900 at 0cm and 2000 at 5cm},
+ visualize as scatter]
+ data {
+ year, people
+ 1900, 100
+ 1910, 200
+ 1950, 200
+ 1960, 250
+ 2000, 150
+ };
+\end{codeexample}
+ %
+ So much for the basic idea. Let us now have a detailed look at what
+ happens.
+
+
+ \medskip
+ \textbf{Number format and the min and max keywords.}
+ The source values $s_1$ and $s_2$ are typically just numbers like |3.14| or
+ |10000000000|. However, as described in
+ Section~\ref{section-dv-expressions}, you can also specify expressions like
+ |(pi/2)|, provided that (currently) you put them in parentheses.
+
+ Instead of a number, you may alternatively also use the two key words |min|
+ and |max| for $s_1$ and/or $s_2$. In this case, |min| evaluates to the
+ smallest value observed for the attribute in the data, symmetrically |max|
+ evaluates to the largest values. For instance, in the above example with
+ the |year| attribute ranging from |1900| to |2000|, the keyword |min| would
+ stand for |1900| and |max| for |2000|. Similarly, for the |people|
+ attribute |min| stands for |100| and |max| for |250|. Note that |min| and
+ |max| can only be used for $s_1$ and $s_2$, not for $t_1$ and $t_2$.
+
+ A typical use of the |min| and |max| keywords is to say
+ %
+\begin{codeexample}[code only]
+scaling = min at 0cm and max at 5cm
+\end{codeexample}
+ %
+ to map the complete range of values into an interval of length of 5cm.
+
+ The interval $[s_1,s_2]$ need not contain all values that the
+ \meta{attribute} may attain. It is permissible that values are less than
+ $s_1$ or more than $s_2$.
+
+
+ \medskip
+ \textbf{Linear transformation of the attribute.}
+ As indicated earlier, the main job of an axis is to map values from a
+ ``large'' interval $[s_1,s_2]$ to a more reasonable interval $[t_1,t_2]$.
+ Suppose that for the current data point the value of the key
+ |/data point/|\meta{attribute} is the number $v$. In the simplest case, the
+ following happens: A new value $v'$ is computed so that $v' = t_1$ when
+ $v=s_1$ and $v'=t_2$ when $v=s_2$ and $v'$ is some value in between $t_1$
+ and $t_2$ then $v$ is some value in between $s_1$ and $s_2$. (Formally, in
+ this basic case $v' = t_1 + (v-s_1)\frac{t_2-t_1}{s_2-s_1}$.)
+
+ Once $v'$ has been computed, it is stored in the key
+ |/data point/|\meta{attribute}|/scaled|. Thus, the ``reasonable'' value
+ $v'$ does not replace the value of the attribute, but it is placed in a
+ different key. This means that both the original value and the more
+ ``scaled'' values are available when the data point is visualized.
+
+ As an example, suppose you have written
+ %
+\begin{codeexample}[code only]
+[x axis = {attribute = x, scaling=1000 at 20 and 2000 at 30}]
+\end{codeexample}
+ %
+ Now suppose that |/data point/x| equals |1200| for a data point. Then the
+ key |/data point/x/scaled| will be set to |22| when the data point is being
+ visualized.
+
+
+ \medskip
+ \textbf{Nonlinear transformations of the attribute.}
+ By default, the transformation of $[s_1,s_2]$ to $[t_1,t_2]$ is the linear
+ transformation described above. However, in some case you may be interested
+ in a different kind of transformation: For example, in a logarithmic plot,
+ values of an attribute may range between, say, |1| and |1000| and we want
+ an axis of length |3cm|. So, we would write
+ %
+\begin{codeexample}[code only]
+[x axis = {attribute = x, scaling=1 at 0cm and 1000 at 3cm}]
+\end{codeexample}
+ %
+ Indeed, |1| will now be mapped to position |0cm| and |1000| will be mapped
+ to position |3cm|. Now, the value |10| will be mapped to approximately
+ |0.03cm| because it is (almost) at one percent between |1| and |1000|.
+ However, in a logarithmic plot we actually want |10| to be mapped to the
+ position |1cm| rather than |0.03cm| and we want |100| to be mapped to the
+ position |2cm|. Such a mapping a \emph{nonlinear} mapping between the
+ intervals.
+
+ In order to achieve such a nonlinear mapping, the |function| key can be
+ used, whose syntax is described in a moment. The effect of this key is to
+ specify a function $f \colon \mathbb{R} \to \mathbb{R}$ like, say, the
+ logarithm function. When such a function is specified, the mapping of $v$
+ to $v'$ is computed as follows:
+ %
+ \begin{align*}
+ v' = t_1 + (f(s_2) - f(v))\frac{t_2 - t_1}{f(s_2)-f(s_1)}.
+ \end{align*}
+
+ The syntax of the |function| key is described next, but you typically will
+ not call this key directly. Rather, you will use a key like |logarithmic|
+ that installs appropriate code for the |function| key for you.
+ %
+ \begin{key}{/tikz/data visualization/axis options/function=\meta{code}}
+ The \meta{code} should specify a function $f$ that is applied during
+ the transformation of the interval $[s_1,s_2]$ to the interval
+ $[t_1,t_2]$ in the following way: When the \meta{code} is called, the
+ macro |\pgfvalue| will have been set to an internal representation of
+ the to-be-transformed value~$v$. You can then call the commands of the
+ math-micro-kernel of the data visualization system, see
+ Section~\ref{section-dv-math-kernel}, to compute a new value. This new
+ value must once more be stored in |\pgfvalue|.
+
+ The most common use of this key is to say
+ %
+\begin{codeexample}[code only]
+some axis={function=\pgfdvmathln{\pgfvalue}{\pgfvalue}}
+\end{codeexample}
+ %
+ This specifies that the function $f$ is the logarithm function.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\tikz \datavisualization
+ [scientific axes,
+ x axis={ticks={major={at={1,10,100,1000}}},
+ scaling=1 at 0cm and 1000 at 3cm,
+ function=\pgfdvmathln{\pgfvalue}{\pgfvalue}},
+ visualize as scatter]
+ data [format=named] {
+ x={1,100,...,1000}, y={1,2,3}
+ };
+\end{codeexample}
+ %
+ Another possibility might be to use the square-root function, instead:
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\tikz \datavisualization
+ [scientific axes,
+ x axis={ticks=few,
+ scaling=1 at 0cm and 1000 at 3cm,
+ function=\pgfdvmathunaryop{\pgfvalue}{sqrt}{\pgfvalue}},
+ visualize as scatter]
+ data [format=named] {
+ x={0,100,...,1000}, y={1,2,3}
+ };
+\end{codeexample}
+ \end{key}
+
+
+ \medskip
+ \textbf{Default scaling.}
+ When no scaling is specified, it may seem natural to use $[0,1]$ both as
+ the source and the target interval. However, this would not work when the
+ logarithm function is used as transformations: In this case the logarithm
+ of zero would be computed, leading to an error. Indeed, for a logarithmic
+ axis it is far more natural to use $[1,10]$ as the source interval and
+ $[0,1]$ as the target interval.
+
+ For these reasons, the default value for the |scaling| that is used when no
+ value is specified explicitly can be set using a special key:
+ %
+ \begin{key}{/tikz/data visualization/axis options/scaling/default=\meta{text}}
+ The \meta{text} is used as |scaling| whenever no other scaling is
+ specified. This key is mainly used when a transformation function is
+ set using |function|; normally, you will not use this key directly.
+ \end{key}
+\end{key}
+
+Most of the time, you will not use neither the |scaling| nor the |function| key
+directly, but rather you will use one of the following predefined styles
+documented in the following.
+
+
+\subsubsection{Scaling: Logarithmic Axes}
+
+\begin{key}{/tikz/data visualization/axis options/logarithmic}
+ When this key is used with an axis, three things happen:
+ %
+ \begin{enumerate}
+ \item The transformation |function| of the axis is setup to the
+ logarithm.
+ \item The strategy for automatically generating ticks and grid lines is
+ set to the |exponential strategy|, see
+ Section~\ref{section-dv-exponential-strategy} for details.
+ \item The default scaling is setup sensibly.
+ \end{enumerate}
+ %
+ All told, to turn an axis into a logarithmic axis, you just need to add
+ this option to the axis.
+ %
+\begin{codeexample}[
+ width=8cm,
+ preamble={\usetikzlibrary{datavisualization.formats.functions}},
+]
+\tikz \datavisualization [scientific axes,
+ x axis={logarithmic},
+ y axis={logarithmic},
+ visualize as line]
+ data [format=function] {
+ var x : interval [0.01:100];
+ func y = \value x * \value x;
+ };
+\end{codeexample}
+ %
+ Note that this will work with any axis, including, say, the degrees on a
+ polar axis:
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.polar}}]
+\tikz \datavisualization
+ [new polar axes,
+ angle axis={logarithmic, scaling=1 at 0 and 90 at 90},
+ radius axis={scaling=0 at 0cm and 100 at 3cm},
+ visualize as scatter]
+ data [format=named] {
+ angle={1,10,...,90}, radius={1,10,...,100}
+ };
+\end{codeexample}
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.polar}}]
+\tikz \datavisualization
+ [new polar axes,
+ angle axis={degrees},
+ radius axis={logarithmic, scaling=1 at 0cm and 100 at 3cm},
+ visualize as scatter]
+ data [format=named] {
+ angle={1,10,...,90}, radius={1,10,...,100}
+ };
+\end{codeexample}
+ %
+\end{key}
+
+
+\subsubsection{Scaling: Setting the Length or Unit Length}
+
+\begin{key}{/tikz/data visualization/axis options/length=\meta{dimension}}
+ Sets |scaling| to |min at 0cm and max at |\meta{dimension}. The effect is
+ that the range of all values of the axis's attribute will be mapped to an
+ interval of exact length \meta{dimension}.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\tikz \datavisualization [scientific axes,
+ x axis={length=3cm},
+ y axis={length=2cm},
+ all axes={ticks=few},
+ visualize as line]
+ data {
+ x, y
+ 10, 10
+ 20, 20
+ 15, 30
+ 13, 20
+ };
+\end{codeexample}
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\tikz \datavisualization [scientific axes,
+ x axis={length=3cm},
+ y axis={length=4cm},
+ all axes={ticks=few},
+ visualize as line]
+ data {
+ x, y
+ 10, 10
+ 20, 20
+ 15, 30
+ 13, 20
+ };
+\end{codeexample}
+ %
+\end{key}
+
+\begin{key}{/tikz/data visualization/axis options/unit length=\meta{dimension}\opt{| per |\meta{number}| units|}}
+ Sets |scaling| to |0 at 0cm and 1 at |\meta{dimension}. In other words,
+ this key allows you to specify how long a single unit should be. This key
+ is particularly useful when you wish to ensure that the same scaling is
+ used across multiple axes or pictures.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\tikz \datavisualization [scientific axes,
+ all axes={ticks=few, unit length=1mm},
+ visualize as line]
+ data {
+ x, y
+ 10, 10
+ 40, 20
+ 15, 30
+ 13, 20
+ };
+\end{codeexample}
+ %
+ The optional |per |\meta{number}| units| allows you to apply more drastic
+ scaling. Suppose that you want to plot a graph where one billion
+ corresponds to one centimeter. Then the unit length would be need to be set
+ to a hundredth of a nanometer -- much too small for \TeX\ to handle as a
+ dimension. In this case, you can write
+ |unit length=1cm per 1000000000 units|:
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\tikz \datavisualization
+ [scientific axes,
+ x axis={unit length=1mm per 1000000000 units, ticks=few},
+ visualize as line]
+ data {
+ x, y
+ 10000000000, 10
+ 40000000000, 20
+ 15000000000, 30
+ 13000000000, 20
+ };
+\end{codeexample}
+ %
+\end{key}
+%
+\begin{key}{/tikz/data visualization/axis options/power unit length=\meta{dimension}}
+ This key is used in conjunction with the |logarithmic| setting. It cases
+ the |scaling| to be set to |1 at 0cm and 10 at |\meta{dimension}. This
+ causes a ``power unit'', that is, one power of ten in a logarithmic plot,
+ to get a length of \meta{dimension}. Again, this key is useful for ensuring
+ that the same scaling is used across multiple axes or pictures.
+ %
+\begin{codeexample}[width=8cm,preamble={\usetikzlibrary{datavisualization}}]
+\tikz \datavisualization
+ [scientific axes,
+ y axis={logarithmic, power unit length=1mm, grid},
+ visualize as line]
+ data {
+ x, y
+ 0, 0.0000000001
+ 1, 1
+ 2, 100000
+ 3, 100000000000
+ 4, 10000000000000000000000000000000
+ 5, 500000000
+ 6, 5000000000000000000
+ };
+\end{codeexample}
+ %
+\end{key}
+
+
+\subsubsection{Axis Label}
+
+An axis can have a \emph{label}, which is a textual representation of the
+attribute according to which the axis varies the position of the page. You can
+set the attribute using the following key:
+
+\begin{key}{/tikz/data visualization/axis options/label=\opt{|\char`\{[|\meta{options}|]|}\meta{text}\opt{|\char`\}|}
+ (default \normalfont axis's label in math mode)%
+}
+ This key sets the label of an axis to \meta{text}. This text will typically
+ be placed inside a |node| and the \meta{options} can be used to further
+ configure the way this node is rendered. The \meta{options} will be
+ executed with the path prefix |/tikz/data visualization/|, so you need to
+ say |node style| to configure the styling of a node, see
+ Section~\ref{section-dv-style}.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization [
+ scientific axes,
+ x axis = {label, length=2.5cm},
+ y axis = {label={[node style={fill=blue!20}]{$x^2$}}},
+ visualize as smooth line]
+ data [format=function] {
+ var x : interval [-3:5];
+ func y = \value x * \value x;
+ };
+\end{codeexample}
+ %
+\end{key}
+
+Note that using the |label| key does not actually cause a node to be created,
+because it is somewhat unclear where the label should be placed. Instead, the
+|visualize label| key is used (typically internally by an axis system) to show
+the label at some sensible position. This key is documented in
+Section~\ref{section-dv-visualize-label}.
+
+
+\subsubsection{Reference: Axis Types}
+\label{section-dv-reference-axis-types}
+
+As explained earlier, when you use |new axis base| to create a new axis, a
+powerful scaling and attribute mapping mechanism is installed, but no mapping
+of values to positions on the page is performed. For this, a
+\emph{transformation object} must be installed. The following keys take care of
+this for you. Note, however, that even these keys do not cause a visual
+representation of the axis to be added to the visualization -- this is the job
+of an axis system, see Section~\ref{section-dv-axis-systems}.
+
+\begin{key}{/tikz/data visualization/new Cartesian axis=\meta{name}}
+ This key creates a new ``Cartesian'' axis, named \meta{name}. For such an
+ axis, the (scaled) values of the axis's attribute are transformed into a
+ displacement on the page along a straight line. The following key is used
+ to configure in which ``direction'' the axis points:
+ %
+ \begin{key}{/tikz/data visualization/axis options/unit vector=\meta{coordinate} (initially {(1pt,0pt)})}
+ Recall that an axis takes the values of an attribute and rescales them
+ so that they fit into a ``reasonable'' interval $[t_1,t_2]$. Suppose
+ that $v'$ is the rescaled dimension in (\TeX) points. Then when the
+ data point is visualized, the coordinate system will be shifted by $v'$
+ times the \meta{coordinate}.
+
+ As an example, suppose that you have said
+ |scaling=0 and 10pt and 50 and 20pt|. Then when the underlying
+ attribute has the value |25|, it will be mapped to a $v'$ of $15$
+ (because |25| lies in the middle of |0| and |50| and |15pt| lies in the
+ middle of |10pt| and |20pt|). This, in turn, causes the data point to
+ be displaced by $15$ times the \meta{coordinate}.
+
+ The bottom line is that the \meta{coordinate} should usually denote a
+ point that is at distance |1pt| from the origin and that points into
+ the direction of the axis.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\begin{tikzpicture}
+ \draw [help lines] (0,0) grid (3,2);
+
+ \datavisualization
+ [new Cartesian axis=x axis, x axis={attribute=x},
+ new Cartesian axis=y axis, y axis={attribute=y},
+ x axis={unit vector=(0:1pt)},
+ y axis={unit vector=(60:1pt)},
+ visualize as scatter]
+ data {
+ x, y
+ 0, 0
+ 1, 0
+ 2, 0
+ 1, 1
+ 2, 1
+ 1, 1.5
+ 2, 1.5
+ };
+\end{tikzpicture}
+\end{codeexample}
+ \end{key}
+\end{key}
+
+
+\subsection{Axis Systems}
+\label{section-dv-axis-systems}
+
+An \emph{axis system} is, as the name suggests, a whole family of axes that act
+in concert. For example, in the ``standard'' axis system there is a horizontal
+axis called the $x$-axis that monitors the |x| attribute (by default, you can
+change this easily) and a vertical axis called the $y$-axis. Furthermore, a
+certain number of ticks are added and labels are placed at sensible positions.
+
+
+\subsubsection{Usage}
+
+Using an axis system is usually pretty easy: You just specify a key like
+|scientific axes| and the necessary axes get initialized with sensible default
+values. You can then start to modify these default values, if necessary.
+
+First, you can (and should) set the attributes to which the difference axes
+refer. For instance, if the |time| attribute is plotted along the $x$-axis, you
+would write
+%
+\begin{codeexample}[code only]
+x axis = {attribute = time}
+\end{codeexample}
+
+Second, you may wish to modify the lengths of the axes. For this, you can use
+keys like |length| or further keys as described in the references later on.
+
+Third, you may often wish to modify how many ticks and grid lines are shown. By
+default, no grid lines are shown, but you can say the following in order to
+cause grid lines to be shown:
+%
+\begin{codeexample}[code only]
+all axes={grid}
+\end{codeexample}
+%
+Naturally, instead of |all axes| you can also specify a single axis, causing
+only grid lines to be shown for this axis. In order to change the number of
+ticks that are shown, you can say
+%
+\begin{codeexample}[code only]
+all axes={ticks=few}
+\end{codeexample}
+%
+or also |many| instead of |few| or even |none|. Far more fine-grained control
+over the tick placement and rendering is possible, see
+Section~\ref{section-dv-ticks-and-grids} for details.
+
+Fourth, consider adding units (like ``cm'' for centimeters or
+``$\mathrm{m}/\mathrm{s}^2$'' for acceleration) to your ticks:
+%
+\begin{codeexample}[code only]
+x axis={ticks={tick unit=cm}}, y axis={ticks={tick unit=m/s^2}}
+\end{codeexample}
+
+Finally, consider adding labels to your axes. For this, use the label option:
+%
+\begin{codeexample}[code only]
+x axes={time $t$ (ms)}, y axis={distance $d$ (mm)}
+\end{codeexample}
+
+Here is an example that employs most of the above features:
+%
+\begin{codeexample}[width=8.5cm,preamble={\usetikzlibrary{datavisualization}}]
+\tikz \datavisualization [
+ scientific axes=clean,
+ x axis={attribute=time, ticks={tick unit=ms},
+ label={elapsed time}},
+ y axis={attribute=v, ticks={tick unit=m/s},
+ label={speed of disc}},
+ all axes=grid,
+ visualize as line]
+data {
+ time, v
+ 0, 0
+ 1, 0.001
+ 2, 0.002
+ 3, 0.004
+ 4, 0.0035
+ 5, 0.0085
+ 6, 0.0135
+};
+\end{codeexample}
+
+
+\subsubsection{Reference: Scientific Axis Systems}
+
+\begin{key}{/tikz/data visualization/scientific axes=\opt{\meta{options}}}
+ This key installs a two-dimensional coordinate system based on the
+ attributes |/data point/x| and |/data point/y|.
+ %
+\begin{codeexample}[
+ width=7cm,
+ preamble={\usetikzlibrary{datavisualization.formats.functions}},
+]
+\begin{tikzpicture}
+ \datavisualization [scientific axes,
+ visualize as smooth line]
+ data [format=function] {
+ var x : interval [0:100];
+ func y = sqrt(\value x);
+ };
+\end{tikzpicture}
+\end{codeexample}
+
+ This axis system is usually a good choice to depict ``arbitrary two
+ dimensional data''. Because the axes are automatically scaled, you do not
+ need to worry about how large or small the values will be. The name
+ |scientific axes| is intended to indicate that this axis system is often
+ used in scientific publications.
+
+ You can use the \meta{options} to fine tune the axis system. The
+ \meta{options} will be executed with the following path prefix:
+ %
+\begin{codeexample}[code only]
+/tikz/data visualization/scientific axes
+\end{codeexample}
+ %
+ All keys with this prefix can thus be passed as \meta{options}.
+
+ This axis system will always distort the relative magnitudes of the units
+ on the two axis. If you wish the units on both axes to be equal, consider
+ directly specifying the unit length ``by hand'':
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\begin{tikzpicture}
+ \datavisualization [visualize as smooth line,
+ scientific axes,
+ all axes={unit length=1cm per 10 units, ticks={few}}]
+ data [format=function] {
+ var x : interval [0:100];
+ func y = sqrt(\value x);
+ };
+\end{tikzpicture}
+\end{codeexample}
+
+ The |scientific axes| have the following properties:
+ %
+ \begin{itemize}
+ \item The |x|-values are surveyed and the $x$-axis is then scaled and
+ shifted so that it has the length specified by the following key.
+ %
+ \begin{key}{/tikz/data visualization/scientific axes/width=\meta{dimension} (initially 5cm)}
+ \end{key}
+ %
+ The minimum value is at the left end of the axis and at the canvas
+ origin. The maximum value is at the right end of the axis. \item
+ The |y|-values are surveyed and the $y$-axis is then scaled so that
+ is has the length specified by the following key.
+ %
+ \begin{key}{/tikz/data visualization/scientific axes/height=\meta{dimension}}
+ By default, the |height| is the golden ratio times the |width|.
+ \end{key}
+ %
+ The minimum value is at the bottom of the axis and at the canvas
+ origin. The maximum value is at the top of the axis.
+ \item Lines (forming a frame) are depicted at the minimum and maximum
+ values of the axes in 50\% black.
+ \end{itemize}
+
+ The following keys are executed by default as options: |outer ticks| and
+ |standard labels|.
+
+ You can use the following style to overrule the defaults:
+
+ \begin{stylekey}{/tikz/data visualization/every scientific axes}
+ \end{stylekey}
+\end{key}
+
+The keys described in the following can be used to fine-tune the way the
+scientific axis system is rendered.
+
+\begin{key}{/tikz/data visualization/scientific axes/outer ticks}
+ This causes the ticks to be drawn `` on the outside'' of the frame so that
+ they interfere as little as possible with the data. It is the default.
+ %
+\begin{codeexample}[
+ width=7cm,
+ preamble={\usetikzlibrary{datavisualization.formats.functions}},
+]
+\begin{tikzpicture}
+ \datavisualization [scientific axes=outer ticks,
+ visualize as smooth line]
+ data [format=function] {
+ var x : interval [-12:12];
+ func y = \value x*\value x*\value x;
+ };
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{key}
+
+\begin{key}{/tikz/data visualization/scientific axes/inner ticks}
+ This axis system works like |scientific axes|, only the ticks are on the
+ ``inside'' of the frame.
+ %
+\begin{codeexample}[
+ width=7cm,
+ preamble={\usetikzlibrary{datavisualization.formats.functions}},
+]
+\begin{tikzpicture}
+ \datavisualization [scientific axes=inner ticks,
+ visualize as smooth line]
+ data [format=function] {
+ var x : interval [-12:12];
+ func y = \value x*\value x*\value x;
+ };
+\end{tikzpicture}
+\end{codeexample}
+
+ This axis system is also common in publications, but the ticks tend to
+ interfere with marks if they are near to the border as can be seen in the
+ following example:
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\begin{tikzpicture}
+ \datavisualization [scientific axes={inner ticks, width=3.2cm},
+ style sheet=cross marks,
+ visualize as scatter/.list={a,b}]
+ data [set=a] {
+ x, y
+ 0, 0
+ 1, 1
+ 0.5, 0.5
+ 2, 1
+ }
+ data [set=b] {
+ x, y
+ 0.05, 0
+ 1.5, 1
+ 0.5, 0.75
+ 2, 0.5
+ };
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{key}
+
+\begin{key}{/tikz/data visualization/scientific axes/clean}
+ The axes and the ticks are completely removed from the actual data, making
+ this axis system especially useful for scatter plots, but also for most
+ other scientific plots.
+ %
+\begin{codeexample}[
+ width=7.5cm,
+ preamble={\usetikzlibrary{datavisualization.formats.functions}},
+]
+\tikz \datavisualization [
+ scientific axes=clean,
+ visualize as smooth line]
+data [format=function] {
+ var x : interval [-12:12];
+ func y = \value x*\value x*\value x;
+};
+\end{codeexample}
+
+ The distance of the axes from the actual plot is given by the padding of
+ the axes.
+\end{key}
+
+For all scientific axis systems, different label placement strategies can be
+specified. They are discussed in the following.
+
+\begin{key}{/tikz/data visualization/scientific axes/standard labels}
+ As the name suggests, this is the standard placement strategy. The label of
+ the $x$-axis is placed below the center of the $x$-axis, the label of the
+ $y$-axis is rotated by $90^\circ$ and placed left of the center of the
+ $y$-axis.
+ %
+\begin{codeexample}[
+ width=8cm,
+ preamble={\usetikzlibrary{datavisualization.formats.functions}},
+]
+\tikz \datavisualization
+ [scientific axes={clean, standard labels},
+ visualize as smooth line,
+ x axis={label=degree $d$,
+ ticks={tick unit={}^\circ}},
+ y axis={label=$\sin d$}]
+data [format=function] {
+ var x : interval [-10:10] samples 10;
+ func y = sin(\value x);
+};
+\end{codeexample}
+ %
+\end{key}
+
+\begin{key}{/tikz/data visualization/scientific axes/upright labels}
+ Works like |scientific axes standard labels|, only the label of the
+ $y$-axis is not rotated.
+ %
+\begin{codeexample}[
+ width=8cm,
+ preamble={\usetikzlibrary{datavisualization.formats.functions}},
+]
+\tikz \datavisualization [
+ scientific axes={clean, upright labels},
+ visualize as smooth line,
+ x axis={label=degree $d$,
+ ticks={tick unit={}^\circ}},
+ y axis={label=$\cos d$, include value=1,
+ ticks={style={
+ /pgf/number format/precision=4,
+ /pgf/number format/fixed zerofill}}}]
+data [format=function] {
+ var x : interval [-10:10] samples 10;
+ func y = cos(\value x);
+};
+\end{codeexample}
+ %
+\end{key}
+
+\begin{key}{/tikz/data visualization/scientific axes/end labels}
+ Places the labels at the end of the $x$- and the $y$-axis, similar to the
+ axis labels of a school book axis system.
+ %
+\begin{codeexample}[
+ width=8cm,
+ preamble={\usetikzlibrary{datavisualization.formats.functions}},
+]
+\tikz \datavisualization [
+ scientific axes={clean, end labels},
+ visualize as smooth line,
+ x axis={label=degree $d$,
+ ticks={tick unit={}^\circ}},
+ y axis={label=$\tan d$}]
+data [format=function] {
+ var x : interval [-80:80];
+ func y = tan(\value x);
+};
+\end{codeexample}
+ %
+\end{key}
+
+
+\subsubsection{Reference: School Book Axis Systems}
+
+\begin{key}{/tikz/data visualization/school book axes=\meta{options}}
+ This axis system is intended to ``look like'' the coordinate systems often
+ used in school books: The axes are drawn in such a way that they intersect
+ to origin. Furthermore, no automatic scaling is done to ensure that the
+ lengths of units are the same in all directions.
+
+ This axis system must be used with care -- it is nearly always necessary to
+ specify the desired unit length by hand using the option |unit length|. If
+ the magnitudes of the units on the two axes differ, different unit lengths
+ typically need to be specified for the different axes.
+
+ Finally, if the data is ``far removed'' from the origin, this axis system
+ will also ``look bad''.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\begin{tikzpicture}
+ \datavisualization [school book axes, visualize as smooth line]
+ data [format=function] {
+ var x : interval [-1.3:1.3];
+ func y = \value x*\value x*\value x;
+ };
+\end{tikzpicture}
+\end{codeexample}
+
+ The stepping of the ticks is one unit by default. Using keys like
+ |ticks=some| may help to give better steppings.
+
+ The \meta{options} are executed with the key itself as path prefix. Thus,
+ the following subkeys are permissible options:
+ %
+ \begin{key}{/tikz/data visualization/school book axes/unit=\meta{value}}
+ Sets the scaling so that 1\,cm corresponds to \meta{value} units. At
+ the same time, the stepping of the ticks will also be set to
+ \meta{value}.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\begin{tikzpicture}
+ \datavisualization [school book axes={unit=10},
+ visualize as smooth line,
+ clean ticks,
+ x axis={label=$x$},
+ y axis={label=$f(x)$}]
+ data [format=function] {
+ var x : interval [-20:20];
+ func y = \value x*\value x/10;
+ };
+\end{tikzpicture}
+\end{codeexample}
+ \end{key}
+
+ \begin{key}{/tikz/data visualization/school book axes/standard labels}
+ This key makes the label of the $x$-axis appear at the right end of
+ this axis and it makes the label of the $y$-axis appear at the top of
+ the $y$-axis.
+
+ Currently, this is the only supported placement strategy for the school
+ book axis system.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\begin{tikzpicture}
+ \datavisualization [school book axes={standard labels},
+ visualize as smooth line,
+ clean ticks,
+ x axis={label=$x$},
+ y axis={label=$f(x)$}]
+ data [format=function] {
+ var x : interval [-1:1];
+ func y = \value x*\value x + 1;
+ };
+\end{tikzpicture}
+\end{codeexample}
+ \end{key}
+\end{key}
+
+
+\subsubsection{Advanced Reference: Underlying Cartesian Axis Systems}
+
+The axis systems described in the following are typically not used directly by
+the user. The systems setup \emph{directions} for several axes in some sensible
+way, but they do not actually draw anything on these axes. For instance, the
+|xy Cartesian| creates two axes called |x axis| and |y axis| and makes the
+$x$-axis point right and the $y$-axis point up. In contrast, an axis system
+like |scientific axes| uses the axis system |xy Cartesian| internally and then
+proceeds to setup a lot of keys so that the axis lines are drawn, ticks and
+grid lines are drawn, and labels are placed at the correct positions.
+
+\begin{key}{/tikz/data visualization/xy Cartesian}
+ This axis system creates two axes called |x axis| and |y axis| that point
+ right and up, respectively. By default, one unit is mapped to one cm.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\begin{tikzpicture}
+ \datavisualization [xy Cartesian, visualize as smooth line]
+ data [format=function] {
+ var x : interval [-1.25:1.25];
+ func y = \value x*\value x*\value x;
+ };
+\end{tikzpicture}
+\end{codeexample}
+
+ \begin{key}{/tikz/data visualization/xy axes=\meta{options}}
+ This key applies the \meta{options} both to the |x axis| and the
+ |y axis|.
+ \end{key}
+\end{key}
+
+\begin{key}{/tikz/data visualization/xyz Cartesian cabinet}
+ This axis system works like |xy Cartesian|, only it \emph{additionally}
+ creates an axis called |z axis| that points left and down. For this axis,
+ one unit corresponds to $\frac{1}{2}\sin 45^\circ\mathrm{cm}$. This is also
+ known as a cabinet projection.
+
+ \begin{key}{/tikz/data visualization/xyz axes=\meta{options}}
+ This key applies the \meta{options} both to the |x axis| and the
+ |y axis|.
+ \end{key}
+\end{key}
+
+\begin{key}{/tikz/data visualization/uv Cartesian}
+ This axis system works like |xy Cartesian|, but it introduces two axes
+ called |u axis| and |v axis| rather than the |x axis| and the |y axis|. The
+ idea is that in addition to a ``major'' $xy$-coordinate system this is also
+ a ``smaller'' or ``minor'' coordinate system in use for depicting, say,
+ small vectors with respect to this second coordinate system.
+
+ \begin{key}{/tikz/data visualization/uv axes=\meta{options}}
+ Applies the \meta{options} to both the |u axis| and the |y axis|.
+ \end{key}
+\end{key}
+
+\begin{key}{/tikz/data visualization/uvw Cartesian cabinet}
+ Like |xyz Cartesian cabinet|, but for the $uvw$-system.
+
+ \begin{key}{/tikz/data visualization/uvw axes=\meta{options}}
+ Like |xyz axes|.
+ \end{key}
+\end{key}
+
+
+\subsection{Ticks and Grids}
+\label{section-dv-ticks-and-grids}
+
+\subsubsection{Concepts}
+
+A \emph{tick} is a small visual indication on an axis of the value of the
+axis's attribute at the position where the tick is shown. A tick may be
+accompanied additionally by a textual representation, but it need not. A
+\emph{grid line} is similar to a tick, but it is not an indication on the axis,
+but rather a whole line that indicates all positions where the attribute has a
+certain value. Unlike ticks, grid lines (currently) are not accompanied by a
+textual representation.
+
+Just as for axes, the data visualization system decouples the specification of
+which ticks are present \emph{in principle} from where they are visualized. In
+the following, I describe how you specify which ticks and grid lines you would
+like to be drawn and how they should look like (their styling). The axis system
+of your choice will then visualize the ticks at a sensible position for the
+chosen system. For details on how to change where whole axis is shown along
+with its ticks, see Section~\ref{section-dv-visualize-ticks}.
+
+Specifying which ticks you are interested in is done as follows: First, you use
+|ticks| key (or, for specifying which grid lines should be present, the |grid|
+key). This key takes several possible options, described in detail in the
+following, which have different effects:
+%
+\begin{enumerate}
+ \item Keys like |step=10| or |minor steps between steps| cause a
+ ``semi-automatic'' computation of possible steps. Here, you explicitly
+ specify the stepping of steps, but the first stepping and their number
+ are computed automatically according to the range of possible values
+ for the attribute.
+ \item Keys like |few|, |some|, or |many| can be passed to |ticks| in order
+ to have \tikzname\ compute good tick positions automatically. This is
+ usually what you want to happen, which is why most axis system will
+ implicitly say |ticks={some}|.
+ \item Keys like |at| or |also at| provide ``absolute control'' over which
+ ticks or grid lines are shown. For these keys, you can not only specify
+ at what value a tick should be shown, but also its styling and also
+ whether it is a major, minor, or subminor tick or grid line.
+\end{enumerate}
+
+In the following, the main keys |ticks| and |grids| are documented first. Then
+the different kinds of ways of specifying where ticks or grid lines should be
+shown are explained.
+
+
+\subsubsection{The Main Options: Tick and Grid}
+
+\begin{key}{/tikz/data visualization/axis options/ticks=\meta{options} (default some)}
+ This key can be passed to an axis in order to configure which ticks are
+ present for the axis. The possible \meta{options} include, for instance,
+ keys like |step|, which is used to specify a stepping for the ticks, but
+ also keys like |major| or |minor| for specifying the positions of major and
+ minor ticks in detail. The list of possible options is described in the
+ rest of this section.
+
+ Note that the |ticks| option will only configure which ticks should be
+ shown in principle. The actual rendering is done only when the
+ |visualize ticks| key is used, documented in
+ Section~\ref{section-dv-visualize-ticks}, which is typically done only
+ internally by an axis system.
+
+ The \meta{options} will be executed with the path prefix
+ |/tikz/data visualization/|. When the |ticks| key is used multiple times
+ for an axis, the \meta{options} accumulate.
+ %
+\begin{codeexample}[width=6cm,preamble={\usetikzlibrary{datavisualization}}]
+\tikz \datavisualization [
+ scientific axes, visualize as line,
+ x axis={ticks={step=24, minor steps between steps=3},
+ label=hours}]
+ data {
+ x, y
+ 0, 0
+ 10, 0
+ 20, 0.5
+ 30, 0.75
+ 40, 0.7
+ 50, 0.6
+ 60, 0.5
+ 70, 0.45
+ 80, 0.47
+ };
+\end{codeexample}
+ %
+\end{key}
+
+\begin{key}{/tikz/data visualization/axis options/grid=\meta{options} (default at default ticks)}
+ This key is similar to |ticks|, only it is used to configure where grid
+ lines should be shown rather than ticks. In particular, the options that
+ can be passed to the |ticks| key can also be passed to the |grid| key. Just
+ like |ticks|, the \meta{options} only specify which grid lines should be
+ drawn in principle; it is the job of the |visualize grid| key to actually
+ cause any grid lines to be shown.
+
+ If you do not specify any \meta{options}, the default text
+ |at default ticks| is used. This option causes grid lines to be drawn at
+ all positions where ticks are shown by default. Since this usually exactly
+ what you would like to happen, most of the time you just need to
+ |all axes=grid| to cause a grid to be shown.
+\end{key}
+
+\begin{key}{/tikz/data visualization/axis options/ticks and grid=\meta{options}}
+ This key passes the \meta{options} to both the |ticks| key and also to the
+ |grid| key. This is useful when you want to specify some special points
+ explicitly where you wish a tick to be shown and also a grid line.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization
+ [scientific axes,
+ visualize as smooth line,
+ all axes= {grid, unit length=1.25cm},
+ y axis={ ticks=few },
+ x axis={ ticks=many, ticks and grid={ major also at={(pi/2) as $\frac{\pi}{2}$}}}]
+ data [format=function] {
+ var x : interval [-pi/2:3*pi] samples 50;
+ func y = sin(\value x r);
+ };
+\end{codeexample}
+ %
+\end{key}
+
+
+\subsubsection{Semi-Automatic Computation of Tick and Grid Line Positions}
+\label{section-dv-concept-tick-placement-strategies}
+
+Consider the following problem: The data visualization engine determines that
+in a plot the $x$-values vary between $17.4$ and $34.5$. In this case, we
+certainly do not want, say, ten ticks at exactly ten evenly spaced positions
+starting with $17.4$ and ending with $34.5$, because this would yield ticks at
+positions like $32.6$. Ticks should be placed at ``nice'' positions like $20$,
+$25$, and $30$.
+
+Determining which positions are ``nice'' is somewhat difficult. In the above
+example, the positions $20$, $25$, and $30$ are certainly nice, but only three
+ticks may be a bit few of them. Better might be the tick positions $17.5$,
+$20$, $22.5$, through to $32.5$. However, users might prefer even numbers over
+fractions like $2.5$ as the stepping.
+
+A \emph{tick placement strategy} is a method of automatically deciding which
+positions are \emph{good} for placing ticks. The data visualization engine
+comes with a number of predefined strategies, but you can also define new ones
+yourself. When the data visualization is requested to automatically determine
+``good'' positions for the placement of ticks on an axis, it uses one of
+several possible \emph{basic strategies}. These strategies differ dramatically
+in which tick positions they will choose: For a range of values between $5$ and
+$1000$, a |linear steps| strategy might place ticks at positions $100$, $200$,
+through to $1000$, while an |exponential steps| strategy would prefer the tick
+positions $10$, $100$ and $1000$. The exact number and values of the tick
+positions chosen by either strategy can be fine-tuned using additional options
+like |step| or |about|.
+
+Here is an example of the different stepping chosen when one varies the tick
+placement strategy:
+%
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\begin{tikzpicture}
+ \datavisualization [scientific axes, visualize as smooth line]
+ data [format=function] {
+ var x : interval [1:11];
+ func y = \value x*\value x;
+ };
+\end{tikzpicture}
+\qquad
+\begin{tikzpicture}
+ \datavisualization [scientific axes, visualize as smooth line,
+ y axis={exponential steps},
+ x axis={ticks={quarter about strategy}},
+ ]
+ data [format=function] {
+ var x : interval [1:11];
+ func y = \value x*\value x;
+ };
+\end{tikzpicture}
+\end{codeexample}
+
+Two strategies are always available: |linear steps|, which yields
+(semi)automatic ticks are evenly spaced positions, and |exponential steps|,
+which yields (semi)automatic steps at positions at exponentially increasing
+positions -- which is exactly what is needed for logarithmic plots. These
+strategies are details in Section~\ref{section-dv-strategies}.
+
+The following options are used to configure tick placement strategies like
+|linear steps|. Unlike the basic choice of a placement strategy, which is an
+axis option, the following should be passed to the option |ticks| or |grid|
+only. So, you would write things like |x axis={ticks={step=2}}|, but
+|x axis={linear steps}|.
+
+\begin{key}{/tikz/data visualization/step=\meta{value} (initially 1)}
+ The value of this key is used to determine the spacing of the major ticks.
+ The key is used by the |linear steps| and |exponential steps| strategies,
+ see the explanations in Section~\ref{section-dv-strategies} for details.
+ Basically, all ticks are placed at all multiples of \meta{value} that lie
+ in the attribute range interval.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization [
+ school book axes, visualize as smooth line,
+ y axis={ticks={step=1.25}},
+ ]
+ data [format=function] {
+ var x : interval [0:3];
+ func y = \value x*\value x/2;
+ };
+\end{codeexample}
+ %
+\end{key}
+
+\begin{key}{/tikz/data visualization/minor steps between steps=\meta{number} (default 9)}
+ Specifies that between any two major steps (whose positions are specified
+ by the |step| key), there should be \meta{number} many minor steps. Note
+ that the default of |9| is exactly the right number so that each interval
+ between two minor steps is exactly a tenth of the size of a major step. See
+ also Section~\ref{section-dv-strategies} for further details.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\begin{tikzpicture}
+ \datavisualization [school book axes, visualize as smooth line,
+ x axis={ticks={minor steps between steps=3}},
+ y axis={ticks={minor steps between steps}},
+ ]
+ data [format=function] {
+ var x : interval [-1.5:1.5];
+ func y = \value x*\value x;
+ };
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{key}
+
+\begin{key}{/tikz/data visualization/phase=\meta{value} (initially 0)}
+ See Section~\ref{section-dv-strategies} for details on how the phase of
+ steps influences the tick placement.
+\end{key}
+
+
+\subsubsection{Automatic Computation of Tick and Grid Line Positions}
+
+The |step| option gives you ``total control'' over the stepping of ticks on an
+axis, but you often do not know the correct stepping in advance. In this case,
+you may prefer to have a good value for |step| being computed for you
+automatically.
+
+Like the |step| key, these options are passed to the |ticks| option. So, for
+instance, you would write |x axis={ticks={about=4}}| to request about four
+ticks to be placed on the $x$-axis.
+
+\begin{key}{/tikz/data visualization/about=\meta{number}}
+ This key asks the data visualization to place \emph{about} \meta{number}
+ many ticks on an axis. It is not guaranteed that \emph{exactly}
+ \meta{number} many ticks will be used, rather the actual number will be the
+ closest number of ticks to \meta{number} so that their stepping is still
+ ``good''. For instance, when you say |about=10|, it may happen that exactly
+ |10|, but perhaps even |13| ticks are actually selected, provided that
+ these numbers of ticks lead to good stepping values like |5| or |2.5|
+ rather than numbers like |3.4| or |7|. The method that is used to determine
+ which steppings a deemed to be ``good'' depends on the current tick
+ placement strategy.
+
+
+ \medskip
+ \textbf{Linear steps.}
+ Let us start with |linear steps|: First, the difference between the maximum
+ value $v_{\max}$ and the minimum value $v_{\min}$ on the axis is computed;
+ let us call it $r$ for ``range''. Then, $r$ is divided by \meta{number},
+ yielding a target stepping~$s$. If $s$ is a number like $1$ or $5$ or $10$,
+ then this number could be used directly as the new value of |step|.
+ However, $s$ will typically something strange like $0.023\,45$ or
+ $345\,223.76$, so $s$ must be replaced by a better value like $0.02$ in the
+ first case and perhaps $250\,000$ in the second case.
+
+ In order to determine which number is to be used, $s$ is rewritten in the
+ form $m \cdot 10^k$ with $1 \le m < 10$ and $k \in \mathbb Z$. For
+ instance, $0.023\,45$ would be rewritten as $2.345 \cdot 10^{-2}$ and
+ $345\,223.76$ as $3.452\,2376 \cdot 10^5$. The next step is to replace the
+ still not-so-good number $m$ like $2.345$ or $3.452\,237$ by a ``good''
+ value $m'$. For this, the current value of the |about strategy| is used:
+ %
+ \begin{key}{/tikz/data visualization/about strategy=\meta{list}}
+ The \meta{list} is a comma-separated sequence of pairs
+ \meta{threshold}/\meta{value} like for instance |1.5/1.0| or |2.3/2.0|.
+ When a good value $m'$ is sought for a given $m$, we iterate over the
+ list and find the first pair \meta{threshold}/\meta{value} where
+ \meta{threshold} exceeds~$m$. Then $m'$ is set to \meta{value}. For
+ instance, if \meta{list} is |1.5/1.0,2.3/2.0,4/2.5,7/5,11/10|, which is
+ the default, then for $m=3.141$ we would get $m'=2.5$ since $4 >
+ 3.141$, but $2.3 \le 3.141$. For $m=6.3$ we would get $m'=5$.
+ \end{key}
+ %
+ Once $m'$ has been determined, the stepping is set to $s' = m' \cdot 10^k$.
+
+ % Define an axis type
+ \tikzdatavisualizationset{
+ one dimensional axis/.style={
+ new Cartesian axis=axis,
+ axis={
+ attribute=main,
+ unit vector={(0pt,1pt)},
+ visualize axis={style=->},
+ visualize ticks={major={tick text at low},direction axis=perpendicular},
+ length=3cm
+ },
+ new Cartesian axis=perpendicular,
+ perpendicular={
+ attribute=perp,
+ unit vector={(1pt,0pt)},
+ include value=0,
+ include value=1
+ }
+ }
+ }
+
+ \def\showstrategy#1{
+ % Show the effect for the different strategies
+ \medskip
+ \begin{tikzpicture}
+ \foreach \max/\about [count=\c] in {10/5,20/5,30/5,40/5,50/5,60/5,70/5,80/5,90/5,100/5,100/3,100/10}
+ {
+ \begin{scope}[xshift=\c pt*30]
+ \datavisualization [#1,
+ one dimensional axis,
+ axis={
+ ticks={about=\about},
+ include value=0,
+ include value=\max
+ }
+ ];
+
+ \node at (0,-5mm) [anchor=mid] {\texttt{\about}};
+ \end{scope}
+ }
+
+ \node at (30pt,-5mm) [anchor=mid east] {\texttt{about=\ \ }};
+ \end{tikzpicture}
+ }
+
+ The net effect of all this is that for the default strategy the only valid
+ stepping are the values $1$, $2$, $2.5$ and $5$ and every value obtainable
+ by multiplying one of these values by a power of ten. The following example
+ shows the effects of, first, setting |about=5| (corresponding to the |some|
+ option) and then having axes where the minimum value is always |0| and
+ where the maximum value ranges from |10| to |100| and, second, setting
+ |about| to the values from |3| (corresponding to the |few| option) and to
+ |10| (corresponding to the |many| option) while having the minimum at |0|
+ and the maximum at |100|:
+
+ \showstrategy{standard about strategy}
+
+ \medskip
+ \textbf{Exponential steps.}
+ For |exponential steps| the strategy for determining a good stepping value
+ is similar to |linear steps|, but with the following differences:
+ %
+ \begin{itemize}
+ \item Naturally, since the stepping value refers to the exponent, the
+ whole computation of a good stepping value needs to be done ``in
+ the exponent''. Mathematically spoken, instead of considering the
+ difference $r = v_{\max} - v_{\min}$, we consider the difference $r
+ = \log v_{\max} - \log v_{\min}$. With this difference, we still
+ compute $s = r / \meta{number}$ and let $s = m \cdot 10^k$ with $1
+ \le m < 10$.
+ \item It makes no longer sense to use values like $2.5$ for $m'$ since
+ this would yield a fractional exponent. Indeed, the only sensible
+ values for $m'$ seem to be $1$, $3$, $6$, and $10$. Because of
+ this, the |about strategy| is ignored and one of these values or a
+ multiple of one of them by a power of ten is used.
+ \end{itemize}
+
+ The following example shows the chosen steppings for a maximum varying from
+ $10^1$ to $10^5$ and from $10^{10}$ to $10^{50}$ as well as for $10^{100}$
+ for |about=3|:
+
+ \medskip
+ \begin{tikzpicture}
+ \foreach \max [count=\c] in {1,...,5,10,20,...,50,100}
+ {
+ \begin{scope}[xshift=\c pt*40]
+ \datavisualization [
+ one dimensional axis,
+ axis={
+ logarithmic,
+ ticks={about=3},
+ include value=1,
+ include value=1e\max
+ }
+ ];
+ \end{scope}
+ }
+ \end{tikzpicture}
+
+
+ \medskip
+ \textbf{Alternative strategies.}
+
+ In addition to the standard |about strategy|, there are some additional
+ strategies that you might wish to use instead:
+
+ \begin{key}{/tikz/data visualization/standard about strategy}
+ Permissible values for $m'$ are: $1$, $2$, $2.5$, and~$5$. This
+ strategy is the default strategy.
+ \end{key}
+
+ \begin{key}{/tikz/data visualization/euro about strategy}
+ Permissible values for $m'$ are: $1$, $2$, and~$5$. These are the same
+ values as for the Euro coins, hence the name.
+
+ \showstrategy{euro about strategy}
+ \end{key}
+
+ \begin{key}{/tikz/data visualization/half about strategy}
+ Permissible values for $m'$: $1$ and $5$. Use this strategy if only
+ powers of $10$ or halves thereof seem logical.
+
+ \showstrategy{half about strategy}
+ \end{key}
+
+ \begin{key}{/tikz/data visualization/decimal about strategy}
+ The only permissible value for $m'$ is $1$. This is an even more
+ radical version of the previous strategy.
+
+ \showstrategy{decimal about strategy}
+ \end{key}
+
+ \begin{key}{/tikz/data visualization/quarter about strategy}
+ Permissible values for $m'$ are: $1$, $2.5$, and $5$.
+
+ \showstrategy{quarter about strategy}
+ \end{key}
+
+ \begin{key}{/tikz/data visualization/int about strategy}
+ Permissible values for $m'$ are: $1$, $2$, $3$, $4$, and $5$.
+
+ \showstrategy{int about strategy}
+ \end{key}
+\end{key}
+
+\begin{key}{/tikz/data visualization/many}
+ This is an abbreviation for |about=10|.
+\end{key}
+
+\begin{key}{/tikz/data visualization/some}
+ This is an abbreviation for |about=5|.
+\end{key}
+
+\begin{key}{/tikz/data visualization/few}
+ This is an abbreviation for |about=3|.
+\end{key}
+
+\begin{key}{/tikz/data visualization/none}
+ Switches off the automatic step computation. Unless you use |step=|
+ explicitly to set a stepping, no ticks will be (automatically) added.
+\end{key}
+
+
+\subsubsection{Manual Specification of Tick and Grid Line Positions}
+
+The automatic computation of ticks and grid lines will usually do a good job,
+but not always. For instance, you might wish to have ticks exactly at, say,
+prime numbers or at Fibonacci numbers or you might wish to have an additional
+tick at $\pi$. In these cases you need more direct control over the
+specification of tick positions.
+
+First, it is important to understand that the data visualization system
+differentiates between three kinds of ticks and grid lines: major, minor, and
+subminor. The major ticks are the most prominent ticks where, typically, a
+textual representation of the tick is shown; and the major grid lines are the
+thickest. The minor ticks are smaller, more numerous, and lie between major
+ticks. They are used, for instance, to indicate positions in the middle between
+major ticks or at all integer positions between major ticks. Finally, subminor
+ticks are even smaller than minor ticks and they lie between minor ticks.
+
+Four keys are used to configure the different kinds:
+
+\begin{key}{/tikz/data visualization/major=\meta{options}}
+ The key can be passed as an option to the |ticks| key and also to the
+ |grid| key, which in turn is passed as an option to an axis. The
+ \meta{options} passed to |major| specify at which positions major
+ ticks/grid lines should be shown (using the |at| option and |also at|
+ option) and also any special styling. The different possible options are
+ described later in this section.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization
+ [ school book axes, visualize as smooth line,
+ x axis={ticks={major={at={1, 1.5, 2}}}}]
+ data [format=function] {
+ var x : interval [-1.25:2];
+ func y = \value x * \value x / 2;
+ };
+\end{codeexample}
+ %
+\end{key}
+
+\begin{key}{/tikz/data visualization/minor=\meta{options}}
+ Like |major|, only for minor ticks/grid lines.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization
+ [ school book axes, visualize as smooth line,
+ x axis={grid={minor={at={1, 1.5, 2}}}}]
+ data [format=function] {
+ var x : interval [-1.25:2];
+ func y = \value x * \value x / 2;
+ };
+\end{codeexample}
+ %
+\end{key}
+
+\begin{key}{/tikz/data visualization/subminor=\meta{options}}
+ Like |major|, only for subminor ticks/grid lines.
+\end{key}
+
+\begin{key}{/tikz/data visualization/common=\meta{options}}
+ This key allows you to specify \meta{options} that apply to |major|,
+ |minor| and |subminor| alike. It does not make sense to use |common| to
+ specify positions (since you typically do not want both a major and a minor
+ tick at the same position), but it can be useful to configure, say, the
+ size of all kinds of ticks:
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization
+ [ school book axes, visualize as smooth line,
+ x axis={ticks={minor steps between steps, common={low=0}}} ]
+ data [format=function] {
+ var x : interval [-1.25:2];
+ func y = \value x * \value x / 2;
+ };
+\end{codeexample}
+ %
+\end{key}
+
+The following keys can now be passed to the |major|, |minor|, and |subminor|
+keys to specify where ticks or grid lines should be shown:
+
+\begin{key}{/tikz/data visualization/at=\meta{list}}
+ Basically, the \meta{list} must be a list of values that is processed with
+ the |\foreach| macro (thus, it can contain ellipses to specify ranges of
+ value). Empty values are skipped.
+
+ The effect of passing |at| to a |major|, |minor|, or |subminor| key is that
+ ticks or grid lines on the axis will be placed exactly at the values in
+ \meta{list}. Here is an example:
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization
+ [ school book axes, visualize as smooth line,
+ x axis={ticks={major={at={-1,0.5,(pi/2)}}}}]
+ data [format=function] {
+ var x : interval [-1.25:2];
+ func y = \value x * \value x / 2;
+ };
+\end{codeexample}
+ When this option is used, any previously specified tick positions are
+ overwritten by the values in \meta{list}. Automatically computed ticks are
+ also overwritten. Thus, this option gives you complete control over where
+ ticks should be placed.
+
+ Normally, the individual values inside the \meta{list} are just numbers
+ that are specified in the same way as an attribute value. However, such a
+ value may also contain the keyword |as|, which allows you so specify the
+ styling of the tick in detail. Section~\ref{section-dv-ticks-styling}
+ details how this works.
+
+ It is often a bit cumbersome that one has to write things like
+ %
+\begin{codeexample}[code only]
+some axis = {ticks = {major = {at = {...}}}}
+\end{codeexample}
+ %
+ A slight simplification is given by the following keys, which can be passed
+ directly to |ticks| and |grid|:
+ %
+ \begin{key}{/tikz/data visualization/major at=\meta{list}}
+ A shorthand for |major={at={|\meta{list}|}}|.
+ \end{key}
+ %
+ \begin{key}{/tikz/data visualization/minor at=\meta{list}}
+ A shorthand for |major={at={|\meta{list}|}}|.
+ \end{key}
+ %
+ \begin{key}{/tikz/data visualization/subminor at=\meta{list}}
+ A shorthand for |major={at={|\meta{list}|}}|.
+ \end{key}
+\end{key}
+
+\begin{key}{/tikz/data visualization/also at=\meta{list}}
+ This key is similar to |at|, but it causes ticks or grid lines to be placed
+ at the positions in the \meta{list} \emph{in addition} to the ticks that
+ have already been specified either directly using |at| or indirectly using
+ keys like |step| or |some|. The effect of multiple calls of this key
+ accumulate. However, when |at| is used after an |also at| key, the |at| key
+ completely resets the positions where ticks or grid lines are shown.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization
+ [ school book axes, visualize as smooth line,
+ x axis={grid, ticks and grid={major={also at={0.5}}}}]
+ data [format=function] {
+ var x : interval [-1.25:2];
+ func y = \value x * \value x / 2;
+ };
+\end{codeexample}
+ %
+ As for |at|, there are some shorthands available:
+ %
+ \begin{key}{/tikz/data visualization/major also at=\meta{list}}
+ A shorthand for |major={also at={|\meta{list}|}}|.
+ \end{key}
+ %
+ \begin{key}{/tikz/data visualization/minor also at=\meta{list}}
+ A shorthand for |major={also at={|\meta{list}|}}|.
+ \end{key}
+ %
+ \begin{key}{/tikz/data visualization/subminor also at=\meta{list}}
+ A shorthand for |major={also at={|\meta{list}|}}|.
+ \end{key}
+\end{key}
+
+
+\subsubsection{Styling Ticks and Grid Lines: Introduction}
+\label{section-dv-ticks-styling}
+
+When a tick, a tick label, or a grid line is visualized on the page, a whole
+regiment of styles influences the appearance. The reason for this large number
+of interdependent styles is the fact that we often wish to influence only a
+very certain part of how a tick is rendered while leaving the other aspects
+untouched: Sometimes we need to modify just the font of the tick label;
+sometimes we wish to change the length of the tick label and the tick label
+position at the same time; sometimes we wish to change the color of grid line,
+tick, and tick label; and sometimes we wish to generally change the thickness
+of all ticks.
+
+Let us go over the different kinds of things that can be styled (grid lines,
+ticks, and tick labels) one by one and let us have a look at which styles are
+involved. We will start with the grid lines, since they turn out to be the most
+simple, but first let us have a look at the general |style| and |styling|
+mechanism that is used in many placed in the following:
+
+
+\subsubsection{Styling Ticks and Grid Lines: The Style and Node Style Keys}
+\label{section-dv-style}
+
+All keys of the data visualization system have the path prefix
+|/tikz/data visualization|. This is not only true for the main keys like
+|scientific axes| or |visualize as line|, but also for keys that govern how
+ticks are visualized. In particular, a style like |every major grid| has the
+path prefix |/tikz/data visualization| and all keys stored in this style are
+also executed with this path prefix.
+
+Normally, this does not cause any trouble since most of the keys and even
+styles used in a data visualization are intended to configure what is shown in
+the visualization. However, at some point, we may also with to specify options
+that no longer configure the visualization in general, but specify the
+appearance of a line or a node on the \tikzname\ layer.
+
+Two keys are used to ``communicate'' with the \tikzname\ layer:
+
+\begin{key}{/tikz/data visualization/style=\meta{\tikzname\ options}}
+ This key takes options whose path prefix is |/tikz|, not
+ |/tikz/data visualization|. These options will be \emph{appended} to a
+ current list of such options (thus, multiple calls of this key accumulate).
+ The resulting list of keys is not executed immediately, but it will be
+ executed whenever the data visualization engine calls the \tikzname\ layer
+ to draw something (this placed will be indicated in the following).
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization
+ [scientific axes,
+ all axes={ticks={style=blue}, length=3cm},
+ y axis={grid, grid={minor steps between steps, major={style=red}}},
+ visualize as line]
+ data [format=function] {
+ var x : interval [5:10];
+ func y = \value x * \value x;
+ };
+\end{codeexample}
+ %
+\end{key}
+
+\begin{key}{/tikz/data visualization/styling}
+ Executing this key will cause all ``accumulated'' \tikzname\ options from
+ previous calls to the key |/tikz/data visualization/style| to be executed.
+ Thus, you use |style| to set \tikzname\ options, but you use |styling| to
+ actually apply these options. Usually, you do not call this option directly
+ since this application is only done deep inside the data visualization
+ engine.
+\end{key}
+
+Similar to |style| (and |styling|) there also exist the |node style| (and
+|node styling|) key that takes \tikzname\ options that apply to nodes only --
+in addition to the usual |style|.
+
+\begin{key}{/tikz/data visualization/node style=\meta{\tikzname\ options}}
+ This key works like |style|, but it has an effect only on nodes that are
+ created during a data visualization. This includes tick labels and axis
+ labels:
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization
+ [scientific axes,
+ all axes={ticks={node style=red}, length=3cm},
+ visualize as line]
+ data [format=function] {
+ var x : interval [5:10];
+ func y = \value x * \value x;
+ };
+\end{codeexample}
+ %
+ Note that in the example the ticks themselves (the little thicker lines)
+ are not red.
+\end{key}
+
+\begin{key}{/tikz/data visualization/node styling}
+ Executing this key will cause all ``accumulated'' node stylings to be
+ executed.
+\end{key}
+
+
+\subsubsection{Styling Ticks and Grid Lines: Styling Grid Lines}
+\label{section-dv-styling-grid-lines}
+
+When a grid line is visualized, see
+Section~\ref{section-dv-visualize-gridlines} for details on when this happens,
+the following styles are executed in the specified order.
+%
+\begin{enumerate}
+ \item |grid layer|.
+ \item |every grid|.
+ \item |every major grid| or |every minor grid| or |every subminor grid|,
+ depending on the kind of grid line.
+ \item locally specified options for the individual grid line, see
+ Section~\ref{section-dv-local-styles}.
+ \item |styling|, see Section~\ref{section-dv-style}.
+\end{enumerate}
+
+All of these keys have the path prefix |/tikz/data visualization|. However, the
+options stored in the first style (|grid layer|) and also in the last
+(|styling|) are executed with the path prefix |/tikz| (see
+Section~\ref{section-dv-style}).
+
+Let us now have a look at these keys in detail:
+
+\begin{stylekey}{/tikz/data visualization/grid layer (initially on background layer)}
+\label{section-dv-grid-layer}%
+ This key is used to specified the \emph{layer} on which grid lines should
+ be drawn (layers are explained in Section~\ref{section-tikz-backgrounds}).
+ By default, all grid lines are placed on the |background| layer and thus
+ behind the data visualization. This is a sensible strategy since it avoids
+ obscuring the more important data with the far less important grid lines.
+ However, you can change this style to ``get the grid lines to the front'':
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization
+ [scientific axes,
+ all axes={
+ length=3cm,
+ grid,
+ grid={minor steps between steps}
+ },
+ grid layer/.style=, % none, so on top of data (bad idea)
+ visualize as line]
+ data [format=function] {
+ var x : interval [5:10];
+ func y = \value x * \value x;
+ };
+\end{codeexample}
+ %
+ When this style is executed, the keys stored in the style will be executed
+ with the prefix |/tikz|. Normally, you should only set this style to be
+ empty or to |on background layer|.
+\end{stylekey}
+
+\begin{stylekey}{/tikz/data visualization/every grid}
+ This style provides overall configuration options for grid lines. By
+ default, it is set to the following:
+ %
+\begin{codeexample}[code only]
+low=min, high=max
+\end{codeexample}
+ %
+ This causes grid lines to span all possible values when they are
+ visualized, which is usually the desired behavior (the |low| and |high|
+ keys are explained in Section~\ref{section-dv-visualize-ticks}. You can
+ append the |style| key to this style to configure the overall appearance of
+ grid lines. It should be noted that settings to |style| inside |every grid|
+ will take precedence over ones in |every major grid| and |every minor grid|.
+ In the following example we cause all grid lines to be dashed (which is not
+ a good idea in general since it creates a distracting background pattern).
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization
+ [scientific axes,
+ all axes={length=3cm, grid},
+ every grid/.append style={style=densely dashed},
+ visualize as line]
+ data [format=function] {
+ var x : interval [5:10];
+ func y = \value x * \value x;
+ };
+\end{codeexample}
+ %
+\end{stylekey}
+
+\begin{stylekey}{/tikz/data visualization/every major grid}
+ This style configures the appearance of major grid lines. It does so by
+ calling the |style| key to setup appropriate \tikzname\ options for
+ visualizing major grid lines. The default definition of this style is:
+ %
+\begin{codeexample}[code only]
+style = {help lines, thin, black!25}
+\end{codeexample}
+ %
+ In the following example, we use thin major blue grid lines:
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization
+ [scientific axes,
+ all axes={
+ length=3cm,
+ grid,
+ grid={minor steps between steps}
+ },
+ every major grid/.style = {style={blue, thin}},
+ visualize as line]
+ data [format=function] {
+ var x : interval [5:10];
+ func y = \value x * \value x;
+ };
+\end{codeexample}
+ %
+ As can be seen, this is not exactly visually pleasing. The default settings
+ for the grid lines should work in most situations; you may wish to increase
+ the blackness level, however, when you experience trouble during printing
+ or projecting graphics.
+\end{stylekey}
+
+\begin{stylekey}{/tikz/data visualization/every minor grid}
+ Works like |every major grid|. The default is
+ %
+\begin{codeexample}[code only]
+style = {help lines, black!25}
+\end{codeexample}
+ %
+\end{stylekey}
+
+\begin{stylekey}{/tikz/data visualization/every subminor grid}
+ Works like |every major grid|. The default is
+ %
+\begin{codeexample}[code only]
+style = {help lines, black!10}
+\end{codeexample}
+ %
+\end{stylekey}
+
+
+\subsubsection{Styling Ticks and Grid Lines: Styling Ticks and Tick Labels}
+\label{section-dv-styling-ticks}
+
+Styling ticks and tick labels is somewhat similar to styling grid lines. Let us
+start with the tick \emph{mark}, that is, the small line that represents the
+tick. When this mark is drawn, the following styles are applied:
+%
+\begin{enumerate}
+ \item |every ticks|.
+ \item |every major ticks| or |every minor ticks| or |every subminor ticks|,
+ depending on the kind of ticks to be visualized.
+ \item locally specified options for the individual tick, see
+ Section~\ref{section-dv-local-styles}.
+ \item |tick layer|
+ \item |every odd tick| or |every even tick|, see
+ Section~\ref{section-dv-stacking}.
+ \item |draw|
+ \item |styling|, see Section~\ref{section-dv-style}.
+\end{enumerate}
+
+For the tick label node (the node containing the textual representation of the
+attribute's value at the tick position), the following styles are applied:
+%
+\begin{enumerate}
+ \item |every ticks|.
+ \item |every major ticks| or |every minor ticks| or |every subminor ticks|,
+ depending on the kind of ticks to be visualized.
+ \item locally specified options for the individual tick, see
+ Section~\ref{section-dv-local-styles}.
+ \item |tick node layer|
+ \item |every odd tick| or |every even tick|, see
+ Section~\ref{section-dv-stacking}.
+ \item |styling|, see Section~\ref{section-dv-style}.
+ \item |node styling|, see Section~\ref{section-dv-style}.
+\end{enumerate}
+
+\begin{stylekey}{/tikz/data visualization/every ticks}
+ This style allows you to configure the appearance of ticks using the
+ |style| and |node style| key. Here is (roughly) the default definition of
+ this style:
+ %
+\begin{codeexample}[code only]
+node style={
+ font=\footnotesize,
+ inner sep=1pt,
+ outer sep=.1666em,
+ rounded corners=1.5pt
+}
+\end{codeexample}
+ %
+\end{stylekey}
+
+\begin{stylekey}{/tikz/data visualization/every major ticks}
+ The default is
+ %
+\begin{codeexample}[code only]
+ style={line cap=round}, tick length=2pt
+\end{codeexample}
+ %
+\end{stylekey}
+
+\begin{stylekey}{/tikz/data visualization/every minor ticks}
+ The default is
+ %
+\begin{codeexample}[code only]
+ style={help lines,thin, line cap=round}, tick length=1.4pt
+\end{codeexample}
+ %
+\end{stylekey}
+
+\begin{stylekey}{/tikz/data visualization/every subminor ticks}
+ The default is
+ %
+\begin{codeexample}[code only]
+ style={help lines, line cap=round}, tick length=0.8pt
+\end{codeexample}
+ %
+\end{stylekey}
+
+\begin{stylekey}{/tikz/data visualization/tick layer (initially on background layer)}
+ Like |grid layer|, this key specifies on which layer the ticks should be
+ placed.
+\end{stylekey}
+
+\begin{stylekey}{/tikz/data visualization/tick node layer (initially \normalfont empty)}
+ Like |tick layer|, but now for the nodes. By default, tick nodes are placed
+ on the main layer and thus on top of the data in case that the tick nodes
+ are inside the data.
+\end{stylekey}
+
+
+\subsubsection{Styling Ticks and Grid Lines: Exceptional Ticks}
+
+You may sometimes wish to style a few ticks differently from the other ticks.
+For instance, in the axis system |school book axes| there should be a tick
+label at the |0| position only on one axis and then this label should be offset
+a bit. In many cases this is easy to achieve: When you add a tick ``by hand''
+using the |at| or |also at| option, you can add any special options in square
+brackets.
+
+However, in some situations the special tick position has been computed
+automatically for you, for instance by the |step| key or by saying |tick=some|.
+In this case, adding a tick mark with the desired options using |also at| would
+cause the tick mark with the correct options to be shown in addition to the
+tick mark with the wrong options. In cases like this one, the following option
+may be helpful:
+
+\begin{key}{/tikz/data visualization/options at=\meta{value} |as [|\meta{options}|]|}
+ This key causes the \meta{options} to be executed for any tick mark(s) at
+ \meta{value} in addition to any options given already for this position:
+ %
+\begin{codeexample}[
+ width=7cm,
+ preamble={\usetikzlibrary{datavisualization.formats.functions}},
+]
+\tikz \datavisualization [
+ scientific axes,
+ visualize as smooth line,
+ x axis={ticks={major={
+ options at = 3 as [no tick text],
+ also at = (pi) as
+ [{tick text padding=1ex}] $\pi$}}}]
+data [format=function] {
+ var x : interval[0:2*pi];
+ func y = sin(\value x r);
+};
+\end{codeexample}
+ %
+\end{key}
+
+\begin{key}{/tikz/data visualization/no tick text at=\meta{value}}
+ Shorthand for |options at=|\meta{value}| as [no tick text]|.
+\end{key}
+
+
+\subsubsection{Styling Ticks and Grid Lines: Styling and Typesetting a Value}
+\label{section-dv-local-styles}
+\label{section-dv-tick-labels}
+
+The \todosp{why 2 labels?} |at| and |also at| key allow you to provide a
+comma-separated \meta{list} of \meta{value}s where ticks or grid lines should
+be placed. In the simplest case, the \meta{value} is simply a number. However,
+the general syntax allows three different kinds of \meta{value}s:
+%
+\begin{enumerate}
+ \item \meta{value}
+ \item \meta{value} |as| |[|\meta{local options}|]|
+ \item \meta{value} |as| \opt{|[|\meta{local options}|]|} \meta{text}
+\end{enumerate}
+
+In the first case, the \meta{value} is just a number that is interpreted like
+any other attribute value.
+
+In the second case, where the keyword |as| is present, followed by some option
+in square brackets, but nothing following the closing square bracket, when the
+tick or grid line at position \meta{value} is shown, the \meta{local options}
+are executed first. These can use the |style| key or the |node style| key to
+configure the appearance of this single tick or grid line. You can also use
+keys like |low| or |high| to influence how large the grid lines or the ticks
+are or keys like |tick text at low| to explicitly hide or show a tick label.
+
+In the third case, which is only important for |ticks| and not for |grid|, the
+same happens as in the second case, but the text that is shown as tick label is
+\meta{text} rather than the automatically generated tick label. This automatic
+generation of tick labels is explained in the following.
+%
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization
+ [scientific axes=clean,
+ x axis={length=2.5cm, ticks={major at={
+ 5,
+ 6 as [style=red],
+ 7 as [{style=blue, low=-1em}],
+ 8 as [style=green] $2^3$,
+ 10 as ten
+ }}},
+ visualize as line]
+ data [format=function] {
+ var x : interval [5:10];
+ func y = \value x * \value x;
+ };
+\end{codeexample}
+
+A value like ``2'' or ``17'' could just be used as \meta{text} to be displayed
+in the node of a tick label. However, things are more difficult when the
+to-be-shown value is $0.0000000015$, because we then would typically (but not
+always) prefer something like $1.5 \cdot 10^{-9}$ to be shown. Also, we might
+wish a unit to be added like $23\mathrm{m}/\mathrm{s}$. Finally, we might wish
+a number like $3.141$ to be replaced by $\pi$. For these reasons, the data
+visualization system does not simply put the to-be-shown value in a node as
+plain text. Instead, the number is passed to a \emph{typesetter} whose job it
+is to typeset this number nicely using \TeX's typesetting capabilities. The
+only exception is, as indicated above, the third syntax version of the |at| and
+|also at| keys, where \meta{text} is placed in the tick label's node,
+regardless of what the typesetting would usually do.
+
+The text produced by the automatic typesetting is computed as follows:
+%
+\begin{enumerate}
+ \item The current contents of the key |tick prefix| is put into the node.
+ \item This is followed by a call of the key |tick typesetter| which gets
+ the \meta{value} of the tick as its argument in scientific notation.
+ \item This is followed by the contents of the key |tick suffix|.
+\end{enumerate}
+
+Let us have a look at these keys in detail:
+
+\begin{key}{/tikz/data visualization/tick prefix=\meta{text} (initially \normalfont empty)}
+ The \meta{text} will be put in front of every typeset tick:
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization
+ [scientific axes, all axes={ticks=few, length=2.5cm},
+ x axis={ticks={tick prefix=$\langle$, tick suffix=$]$}},
+ visualize as line]
+ data [format=function] {
+ var x : interval [5:10];
+ func y = \value x * \value x;
+ };
+\end{codeexample}
+ %
+\end{key}
+
+\begin{key}{/tikz/data visualization/tick suffix=\meta{text} (initially \normalfont empty)}
+ Works like |tick prefix|. This key is especially useful for adding units
+ like ``cm'' or ``$\mathrm m/\mathrm s$'' to every tick label. For this
+ reason, there is a (near) alias that is easier to memorize:
+ %
+ \begin{key}{/tikz/data visualization/tick unit=\meta{roman math text}}
+ A shorthand for |tick suffix={$\,\rm|\meta{roman math text}|$}|:
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization
+ [scientific axes, all axes={length=3cm},
+ x axis={ticks={tick unit=s}},
+ y axis={ticks={tick unit=m/s^2}},
+ visualize as line]
+ data [format=function] {
+ var x : interval [5:10];
+ func y = \value x * \value x;
+ };
+\end{codeexample}
+ \end{key}
+\end{key}
+
+\begin{key}{/tikz/data visualization/tick typesetter=\meta{value}}
+ The key gets called for each number that should be typeset. The argument
+ \meta{value} will be in scientific notation (like |1.0e1| for $10$). By
+ default, this key applies |\pgfmathprintnumber| to its argument. This
+ command is a powerful number printer whose configuration is documented in
+ Section~\ref{pgfmath-numberprinting}.
+
+ You are invited to code underlying this key so that a different typesetting
+ mechanism is used. Here is a (not quite finished) example that shows how,
+ say, numbers could be printed in terms of multiples of $\pi$:
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\def\mytypesetter#1{%
+ \pgfmathparse{#1/pi}%
+ \pgfmathprintnumber{\pgfmathresult}$\pi$%
+}
+\tikz \datavisualization
+ [school book axes, all axes={unit length=1.25cm},
+ x axis={ticks={step=(0.5*pi), tick typesetter/.code=\mytypesetter{##1}}},
+ y axis={include value={-1,1}},
+ visualize as smooth line]
+ data [format=function] {
+ var x : interval [0.5:7];
+ func y = sin(\value x r);
+ };
+\end{codeexample}
+ %
+\end{key}
+
+
+\subsubsection{Stacked Ticks}
+\label{section-dv-stacking}
+
+Sometimes, the text of tick labels are so long or so numerous that the text of
+adjacent tick labels overlap (or have too little padding):
+%
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization [scientific axes,
+ all axes={length=2.5cm},
+ visualize as smooth line]
+ data [format=function] {
+ var y : interval[-100:100];
+ func x = \value y*\value y;
+ };
+\end{codeexample}
+%
+There are two ways to address this problem:
+%
+\begin{itemize}
+ \item One can rotate the labels on horizontal axes:
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization [scientific axes,
+ all axes={length=2.5cm},
+ x axis={ticks={node style={rotate=90, anchor=east}}},
+ visualize as smooth line]
+ data [format=function] {
+ var y : interval[-100:100];
+ func x = \value y*\value y;
+ };
+\end{codeexample}
+ %
+ This is often a good solution, but may be hard to read. Also consider
+ rotating labels only by $45^\circ$ or $30^\circ$.
+ \item One can specify different shifts of the nodes for the different
+ ticks, whereby the ticks text no longer overlap.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization [scientific axes,
+ all axes={length=2.5cm},
+ x axis={ticks={major at={0,4000,8000,
+ 2000 as [node style={yshift=-1em}],
+ 6000 as [node style={yshift=-1em}],
+ 10000 as [node style={yshift=-1em}]}}},
+ visualize as smooth line]
+ data [format=function] {
+ var y : interval[-100:100];
+ func x = \value y*\value y;
+ };
+\end{codeexample}
+ %
+ However, specifying shifts ``by hand'' in the above way is not always
+ an option, especially when the tick positions should be computed
+ automatically. Instead, the |stack| option can be used, which is much
+ easier to use and gives better results:
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization [scientific axes,
+ all axes={length=2.5cm}, x axis={ticks=stack},
+ visualize as smooth line]
+ data [format=function] {
+ var y : interval[-100:100];
+ func x = \value y*\value y;
+ };
+\end{codeexample}
+ %
+\end{itemize}
+
+The |stack| option is actually just a style that gives you access to the
+general even/odd mechanism for ticks with labels. Whenever a tick mark is
+created where a tick label is also to be drawn, two special things happen:
+%
+\begin{enumerate}
+ \item For every odd tick mark, the |every odd tick| style is executed, for
+ every even tick mark the |every even tick|. Here, ``odd'' and ``even''
+ are with respect to the order in which the ticks have been added to the
+ list of |at| positions for each major, minor, or subminor tick list,
+ not with respect to the order in which they will appear on the axis.
+ Thus, when you write
+ %
+\begin{codeexample}[code only]
+ticks={major at={1,2,3,4}, major at={0,-1,-2}, minor at={9,8,7}}
+\end{codeexample}
+ %
+ then for |1|, |3|, |0|, and |-2| as well as |9| and |7| the key
+ |every odd tick| will be executed, while |every even tick| will be
+ executed for positions |2|, |4|, |-1|, and also |8|.
+ \item When a tick node label is shown at the |low| position of the tick
+ mark, the dimension stored in the key |tick text low even padding| is
+ added to the |low| value. Provided that this padding is not zero (which
+ is the default), the length of the even tick marks will be increased
+ and the tick label node will be placed at a greater distance from the
+ axis.
+
+ Similar keys exist for padding ticks with labels at high positions and
+ also at even positions.
+\end{enumerate}
+
+\begin{key}{/tikz/data visualization/tick text low even padding=\meta{dimension} (initially 0pt)}
+ When a tick label is shown at the low position of an even tick, the
+ \meta{distance} is added to the |low| value, see also
+ Section~\ref{section-dv-visualize-ticks}.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization [scientific axes,
+ all axes={length=2.5cm},
+ x axis={ticks={tick text low even padding=-1em}},
+ visualize as smooth line]
+ data [format=function] {
+ var y : interval[-100:100];
+ func x = \value y*\value y;
+ };
+\end{codeexample}
+ %
+ Note that \meta{dimension} should usually be non-positive.
+\end{key}
+
+The following keys work similarly:
+%
+\begin{key}{/tikz/data visualization/tick text low odd padding=\meta{dimension} (initially 0pt)}
+\end{key}
+%
+\begin{key}{/tikz/data visualization/tick text high even padding=\meta{dimension} (initially 0pt)}
+\end{key}
+%
+\begin{key}{/tikz/data visualization/tick text high odd padding=\meta{dimension} (initially 0pt)}
+\end{key}
+
+\begin{key}{/tikz/data visualization/tick text odd padding=\meta{dimension}}
+ A shorthand for setting |tick text odd low padding| and
+ |tick text odd high padding| at the same time.
+\end{key}
+
+\begin{key}{/tikz/data visualization/tick text even padding=\meta{dimension}}
+ A shorthand for setting |tick text even low padding| and
+ |tick text even high padding| at the same time.
+\end{key}
+
+\begin{key}{/tikz/data visualization/tick text padding=\meta{dimension}}
+ Sets all text paddings to \meta{dimension}.
+\end{key}
+
+\begin{key}{/tikz/data visualization/stack=\meta{dimension} (default 1em)}
+ Shorthand for |tick text even padding=|\meta{dimension}.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization [scientific axes,
+ all axes={length=2.5cm},
+ x axis={ticks={stack=1.5em}},
+ visualize as smooth line]
+ data [format=function] {
+ var y : interval[-100:100];
+ func x = \value y*\value y;
+ };
+\end{codeexample}
+ %
+\end{key}
+
+\begin{key}{/tikz/data visualization/stack'=\meta{dimension}}
+ Shorthand for |tick text odd padding=|\meta{dimension}. The difference to
+ |stack| is that the set of value that are ``lowered'' is exactly exchanged
+ with the set of value ``lowered'' by |stack|.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization [scientific axes,
+ all axes={length=2.5cm},
+ x axis={ticks=stack'},
+ visualize as smooth line]
+ data [format=function] {
+ var y : interval[-100:100];
+ func x = \value y*\value y;
+ };
+\end{codeexample}
+ %
+\end{key}
+
+Note that the above keys have an effect on all tick labels of an axis, also on
+special ticks that you may have added using the |also at| key. When using the
+|stack| key, you should specify a |tick text padding| explicitly for such keys:
+%
+\begin{codeexample}[
+ width=7cm,
+ preamble={\usetikzlibrary{datavisualization.formats.functions}},
+]
+\tikz \datavisualization
+ [scientific axes,
+ x axis={ticks={stack, many, major also at=
+ {(pi) as [{tick text padding=2.5em}] $\pi$}}},
+ visualize as smooth line]
+ data [format=function] {
+ var x : interval[0:(2*pi)];
+ func y = sin(\value x r);
+ };
+\end{codeexample}
+
+
+\subsubsection{Reference: Basic Strategies}
+\label{section-dv-strategies}
+
+\begin{key}{/tikz/data visualization/axis options/linear steps}
+ This strategy places ticks at positions that are evenly spaced by the
+ current value of |step|.
+
+ In detail, the following happens: Let $a$ be the minimum value of the data
+ values along the axis and let $b$ be the maximum. Let the current
+ \emph{stepping} be $s$ (the stepping is set using the |step| option, see
+ below) and let the current \emph{phasing} be $p$ (set using the |phase|)
+ option. Then ticks are placed all positions $i\cdot s + p$ that lie in the
+ interval $[a,b]$, where $i$ ranges over all integers.
+
+ The tick positions computed in the way described above are \emph{major}
+ step positions. In addition to these, if the key
+ |minor steps between steps| is set to some number $n$, then $n$ many minor
+ ticks are introduced between each two major ticks (and also before and
+ after the last major tick, provided the values still lie in the interval
+ $[a,b]$). Note that is $n$ is $1$, then one minor tick will be added in the
+ middle between any two major ticks. Use a value of $9$ (not $10$) to
+ partition the interval between two major ticks into ten equally sized minor
+ intervals.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\begin{tikzpicture}
+ \datavisualization
+ [scientific axes={inner ticks, width=3cm},
+ x axis={ticks={step=3, minor steps between steps=2}},
+ y axis={ticks={step=.36}},
+ visualize as scatter]
+ data {
+ x, y
+ 17, 30
+ 34, 32
+ };
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{key}
+
+\label{section-dv-exponential-strategy}
+
+\begin{key}{/tikz/data visualization/axis options/exponential steps}
+ This strategy produces ticks at positions that are appropriate for
+ logarithmic plots. It is automatically selected when you use the
+ |logarithmic| option with an axis.
+
+ In detail, the following happens: As for |linear steps| let numbers $a$,
+ $b$, $s$, and $p$ be given. Then, major ticks are placed at all positions
+ $10^{i\cdot s+p}$ that lie in the interval $[a,b]$ for $i \in \mathbb{Z}$.
+
+ The minor steps are added in the same way as for |linear steps|. In
+ particular, they interpolate \emph{linearly} between major steps.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\begin{tikzpicture}
+ \datavisualization
+ [scientific axes,
+ x axis={logarithmic, length=2cm, ticks={step=1.5}},
+ y axis={logarithmic, ticks={step=1, minor steps between steps=9}},
+ visualize as scatter]
+ data {
+ x, y
+ 1, 10
+ 1000, 1000000
+ };
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{key}
+
+
+\subsubsection{Advanced: Defining New Placement Strategies}
+
+\begin{key}{/tikz/data visualization/axis options/tick placement strategy=\meta{macro}}
+ This key can be used to install a so-called \emph{tick placement strategy}.
+ Whenever |visualize ticks| is used to request some ticks to be visualized,
+ it is checked whether some automatic ticks should be created. This is the
+ case when the following key is set:
+ %
+ \begin{key}{/tikz/data visualization/compute step=\meta{code}}
+ The \meta{code} should compute a suitable value for the stepping to be
+ used by the \meta{macro} in the tick placement strategy.
+
+ For instance, the |step| key sets |compute step| to
+ |\def\tikz at lib@dv at step{#1}|. Thus, when you say |step=5|, then the
+ desired stepping of |5| is communicated to the \meta{macro} via the
+ macro |\tikz at lib@dv at step|.
+ \end{key}
+
+ Provided |compute step| is set to some nonempty value, upon visualization
+ of ticks the \meta{macro} is executed. Typically, \meta{macro} will first
+ call the \meta{code} stored in the key |compute step|. Then, it should
+ implement some strategy then uses the value of the computed or desired
+ stepping to create appropriate |at| commands. To be precise, it should set
+ the keys |major|, |minor|, and/or |subminor| with some appropriate |at|
+ values.
+
+ Inside the call of \meta{macro}, the macro |\tikzdvaxis| will have been set
+ to the name of the axis for which default ticks need to be computed. This
+ allows you to access the minimum and the maximum value stored in the
+ |scaling mapper| of that axis.
+ %
+\begin{codeexample}[width=7cm,preamble={\usetikzlibrary{datavisualization}}]
+\def\silly{
+ \tikzdatavisualizationset{major={at={
+ 2,3,5,7,11,13}}}
+}
+\begin{tikzpicture}
+ \datavisualization [
+ scientific axes, visualize as scatter,
+ x axis={tick placement strategy=\silly}
+ ]
+ data {
+ x, y
+ 0, 0
+ 15, 15
+ };
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{key}
+
+
+\subsection{Advanced: Creating New Axis Systems}
+
+The |datavisualization| library comes with a number of predefined axis systems,
+like |scientific axes=clean|, but it is also possible and to define new axis
+systems. Doing so involves the following steps:
+%
+\begin{enumerate}
+ \item Creating a number of axes.
+ \item Configuring attributes of these axes like their length or default
+ scaling.
+ \item Creating visual representations of the axes.
+ \item Creating visual representations of the ticks and grid lines.
+\end{enumerate}
+
+The first step uses |new ... axis| keys to create new axes, the last steps use
+|visualize ...| keys to create the visual representations of the axes.
+
+Note that the axis system has no control over the actual attribute value ranges
+and neither over which ticks need to be drawn. The axis system can only provide
+good defaults and then specify \emph{how} the ticks or labels should be drawn
+and \emph{where} on the page -- but not at which values.
+
+In the following, as a running example let us develop an axis system
+|our system| that does the following: For the $x$-axis is looks like a normal
+scientific axis system, but there are actually two $y$-axes: One at the left
+and one at the right, each using a different attribute, but both coexisting in
+the same picture.
+
+
+\subsubsection{Creating the Axes}
+
+A new axis system is created as a style key with the prefix
+|/tikz/data visualization|. Thus, we would write:
+%
+\begin{codeexample}[code only]
+\tikzset{
+ data visualization/our system/.style={
+ ...
+ }
+}
+\end{codeexample}
+
+In our system we need three axis: The $x$-axis, the left axis and the right
+axis. Since all of these axes are Cartesian axes, we write the following:
+%
+\begin{codeexample}[code only]
+\tikzset{
+ data visualization/our system/.style={
+ new Cartesian axis=x axis,
+ new Cartesian axis=left axis,
+ new Cartesian axis=right axis,
+ x axis={attribute=x},
+ left axis={unit vector={(0cm,1pt)}},
+ right axis={unit vector={(0cm,1pt)}},
+ }
+}
+\end{codeexample}
+%
+As can be seen, we also configure things so that the $x$-axis will use the |x|
+attribute by default (users can later change this by saying
+|x axis={attribute=|\meta{some other attribute}|}|), but we do not configure
+the attributes of the |left axis| nor the |right axis|. We also make the left
+and right axis point upward (the |x axis| needs no configuration here since a
+Cartesian axis points right by default). The reason is the |left| would not be
+a particularly good attribute name and this way we ensure that users have to
+pick names themselves (hopefully good ones).
+
+The next step is to define a standard scaling for the axes. Here, we can use
+the same as for |scientific axes|, so we would add the following keys to the
+definition of |our system|:
+%
+\begin{codeexample}[code only]
+x axis ={length=\pgfkeysvalueof{/tikz/data visualization/scientific axes/width}},
+left axis ={length=\pgfkeysvalueof{/tikz/data visualization/scientific axes/height}},
+right axis={length=\pgfkeysvalueof{/tikz/data visualization/scientific axes/height}}
+\end{codeexample}
+
+We now already have enough to try our system, although we will not yet see any
+axes or ticks, but we will see the correct scaling of the attributes. Let us
+first define a data group:
+%
+\begin{codeexample}[setup code]
+\tikz \datavisualization data group {people and money} = {
+ data [set=people 1] {
+ time, people
+ 1900, 1000000000
+ 1920, 1500000000
+ 1930, 2000000000
+ 1980, 3000000000
+ }
+ data [set=people 2] {
+ time, people
+ 1900, 2000000000
+ 1920, 2500000000
+ 1940, 4000000000
+ 2000, 5700000000
+ }
+ data [set=money 1] {
+ time, money
+ 1910, 1.1
+ 1920, 2
+ 1930, 5
+ 1980, 2
+ }
+ data [set=money 2] {
+ time, money
+ 1950, 3
+ 1960, 3
+ 1970, 4
+ 1990, 3.5
+ }
+ };
+\end{codeexample}
+
+\begin{codeexample}[setup code,hidden]
+\tikzdatavisualizationset{
+ our system/.style={
+ new Cartesian axis=x axis,
+ new Cartesian axis=left axis,
+ new Cartesian axis=right axis,
+ x axis={attribute=x},
+ left axis={unit vector={(0cm,1pt)}},
+ right axis={unit vector={(0cm,1pt)}},
+ x axis ={length=\pgfkeysvalueof{/tikz/data visualization/scientific axes/width}},
+ left axis ={length=\pgfkeysvalueof{/tikz/data visualization/scientific axes/height}},
+ right axis={length=\pgfkeysvalueof{/tikz/data visualization/scientific axes/height}}
+ }
+}
+\end{codeexample}
+%
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\tikz \datavisualization [
+ our system,
+ x axis={attribute=time, length=4cm},
+ left axis ={attribute=money},
+ right axis={attribute=people},
+ visualize as line/.list={people 1, people 2, money 1, money 2},
+ people 1={style={visualizer color=blue}},
+ people 2={style={visualizer color=blue!50}},
+ money 1={style={visualizer color=red}},
+ money 2={style={visualizer color=red!50}}]
+ data group {people and money};
+\end{codeexample}
+
+
+\subsubsection{Visualizing the Axes}
+\label{section-dv-visualize-axis}
+
+We must now show the axes themselves. For this we can use the |visualize axis|
+key:
+
+\begin{key}{/tikz/data visualization/axis options/visualize axis=\meta{options}}
+ This key is passed to an axis as an option. It causes a visual
+ representation of the axis to be created during the data visualization. The
+ \meta{options} are used to determine where the axis should be drawn and how
+ long it should be. We can specify, for instance, that an axis should be
+ drawn at the minimum value of another axis or where another axis has the
+ value |0|.
+
+
+ \medskip
+ \textbf{The goto, high, and low Keys.}
+ In our example, the |left axis| should be shown at the left hand side. This
+ is the position where the |x axis| has its minimum value. To specify this,
+ we would use the following code:
+ %
+\begin{codeexample}[code only]
+left axis={ visualize axis={ x axis={ goto=min } }
+\end{codeexample}
+ %
+ As can be seen, we can pass another axis as an \meta{option} to
+ |visualize axis|, where we pass the following key to the axis in turn:
+ %
+ \begin{key}{/tikz/data visualization/axis options/goto=\meta{value}}
+ The key can be passed to an axis. It will set the attribute monitored
+ by the axis to the given \meta{value}, which is usually some number.
+ However, \meta{value} may also be one of the following, which causes a
+ special behavior:
+ %
+ \begin{itemize}
+ \item |min|: The attribute is set to the minimal value that the
+ attribute has attained along this axis.
+ \item |max|: Like |min|.
+ \item |padded min|: This will also set the \meta{attribute}
+ monitored by the axis to the same value as |min|.
+ Additionally, however, the subkey
+ |/data point/|\meta{attribute}|/offset| is set to the current
+ padding for the minimum, see the description of |padding min|
+ later on. The effect of this is that the actual point ``meant''
+ by the attribute is offset by this padding along the
+ attribute's axis.
+ \item |padded max|: Like |padded min|.
+ \end{itemize}
+ \end{key}
+
+ The |right axis| would be visualized the same way, only at |goto=max|. The
+ $x$-axis actually needs to be visualized \emph{twice}: Once at the bottom
+ and once at the top. Thus, we need to call |visualize axis| twice for this
+ axis:
+ %
+\tikzdatavisualizationset{
+ our system/.style={
+ new Cartesian axis=x axis,
+ new Cartesian axis=left axis,
+ new Cartesian axis=right axis,
+ x axis={attribute=x},
+ left axis={unit vector={(0cm,1pt)}},
+ right axis={unit vector={(0cm,1pt)}},
+ x axis ={length=\pgfkeysvalueof{/tikz/data visualization/scientific axes/width}},
+ left axis ={length=\pgfkeysvalueof{/tikz/data visualization/scientific axes/height}},
+ right axis={length=\pgfkeysvalueof{/tikz/data visualization/scientific axes/height}}
+ }
+}
+\begin{codeexample}[
+ preamble={\usetikzlibrary{datavisualization}},
+ pre={\tikzdatavisualizationset{
+ our system/.style={
+ new Cartesian axis=x axis,
+ new Cartesian axis=left axis,
+ new Cartesian axis=right axis,
+ x axis={attribute=x},
+ left axis={unit vector={(0cm,1pt)}},
+ right axis={unit vector={(0cm,1pt)}},
+ x axis ={length=\pgfkeysvalueof{/tikz/data visualization/scientific axes/width}},
+ left axis ={length=\pgfkeysvalueof{/tikz/data visualization/scientific axes/height}},
+ right axis={length=\pgfkeysvalueof{/tikz/data visualization/scientific axes/height}}
+ }
+}}]
+\tikzset{
+ data visualization/our system/.append style={
+ left axis= {visualize axis={x axis= {goto=min}}},
+ right axis={visualize axis={x axis= {goto=max}}},
+ x axis= {visualize axis={left axis={goto=min}},
+ visualize axis={left axis={goto=max}}},
+ }
+}
+\tikz \datavisualization [
+ our system,
+ x axis={attribute=time, length=4cm},
+ left axis ={attribute=money},
+ right axis={attribute=people},
+ visualize as line/.list={people 1, people 2, money 1, money 2}]
+ data group {people and money};
+\end{codeexample}
+
+ There is another key that is similar to |goto|, but has a slightly
+ different semantics:
+ %
+ \begin{key}{/tikz/data visualization/axis options/goto pos=\meta{fraction}}
+ The key works like |goto|, only the \meta{fraction} is not interpreted
+ as a value but as a fraction of the way between the minimum and the
+ maximum value for this axis.
+
+ Suppose that for an axis the attribute range interval is $[500,1000]$
+ and the reasonable interval is $[1,3]$. Then for a \meta{fraction} of
+ |0|, the mapping process would choose value $1$ from the reasonable
+ interval, for a \meta{fraction} of |1| the position $3$ from the
+ reasonable interval, and for a \meta{fraction} or |0.25| the position
+ $1.5$ since it is one quarter at the distance from $1$ to $3$.
+
+ Note that neither the attribute range interval nor the transformation
+ function for the attribute are important for the |goto pos| option --
+ the \meta{fraction} is computed with respect to the reasonable
+ interval. Also note that the values of the actual attribute
+ corresponding to the fractional positions in the reasonable interval
+ are not computed.
+ %
+\begin{codeexample}[
+ preamble={\usetikzlibrary{datavisualization}},
+ pre={\tikzdatavisualizationset{
+ our system/.style={
+ new Cartesian axis=x axis,
+ new Cartesian axis=left axis,
+ new Cartesian axis=right axis,
+ x axis={attribute=x},
+ left axis={unit vector={(0cm,1pt)}},
+ right axis={unit vector={(0cm,1pt)}},
+ x axis ={length=\pgfkeysvalueof{/tikz/data visualization/scientific axes/width}},
+ left axis ={length=\pgfkeysvalueof{/tikz/data visualization/scientific axes/height}},
+ right axis={length=\pgfkeysvalueof{/tikz/data visualization/scientific axes/height}}
+ }
+}}]
+\tikzset{
+ data visualization/our system/.append style={
+ x axis= {visualize axis={left axis={goto pos=0.25}},
+ visualize axis={left axis={goto pos=0.5}}},
+ }
+}
+\tikz \datavisualization [
+ our system,
+ x axis={attribute=time, length=4cm},
+ left axis ={attribute=money},
+ right axis={attribute=people},
+ visualize as line/.list={people 1, people 2, money 1, money 2}]
+ data group {people and money};
+\end{codeexample}
+ \end{key}
+
+ By default, when an axis is visualized, it spans the set of all possible
+ values for the monitored attribute, that is, from |min| to |max|. However,
+ there are actually two keys that allow you to adjust this:
+ %
+ \begin{key}{/tikz/data visualization/low=\meta{value}}
+ This is the attribute value where the axis visualization starts. The
+ same special values as for |goto| are permissible (like |min| or
+ |padded min|, but also |0| or |1|).
+ \end{key}
+ %
+ \begin{key}{/tikz/data visualization/high=\meta{value}}
+ Like |low|, only for where the axis ends.
+ \end{key}
+
+ By default, |low=min| and |high=max| are set for an axis visualization.
+ Another sensible setting is |low=padded min| and |high=padded max|. The
+ following key provides a shorthand for this:
+ %
+ \begin{key}{/tikz/data visualization/padded}
+ Shorthand for |low=padded min, high=padded max|.
+ \end{key}
+ %
+ As an example, consider the |scientific axes=clean|. Here, each axis is
+ actually drawn three times: Once at the minimum, once at the maximum and
+ then once more at the padded minimum.
+
+
+ \medskip
+ \textbf{The axis line.}
+ When an axis is drawn, \tikzname\ does not simply draw a straight line from
+ the |low| position to the |high| position. In reality, the data
+ visualization system uses the two commands |\pgfpathdvmoveto| and
+ |\pgfpathdvlineto| internally. These will replace the straight line by a
+ curve in certain situations. For instance, in a polar coordinate system, if
+ an axis should be drawn along an angle axis for a fixed radius, an arc will
+ be used instead of a straight line.
+
+
+ \medskip
+ \textbf{Styling the axis.}
+ As can be seen, we now get the axis we want (but without the ticks,
+ visualizing them will be explained later). The axis is, however, simply a
+ black line. We can \emph{style} the axis in a manner similar to styling
+ ticks and grid lines, see Section~\ref{section-dv-style}. In detail, the
+ following styles get executed:
+ %
+ \begin{enumerate}
+ \item |axis layer|
+ \item |every axis|
+ \item |styling|
+ \end{enumerate}
+ %
+ Additionally, even before |every axis| is executed, |low=min| and
+ |high=max| are executed.
+
+ \begin{stylekey}{/tikz/data visualization/axis layer (initially on background layer)}
+ The layer on which the axis is drawn. See the description of
+ |grid layer| on page~\pageref{section-dv-grid-layer} for details.
+ \end{stylekey}
+
+ \begin{stylekey}{/tikz/data visualization/every axis}
+ Put styling of the axis here. It is usually a good idea to set this
+ style to |style={black!50}|.
+ \end{stylekey}
+
+ Recall that the |styling| key is set using the |style| key, see
+ Section~\ref{section-dv-style}.
+ %
+% TODOsp: codeexamples: What is this empty `\tikzset` good for?
+\tikzset{
+}
+\begin{codeexample}[
+ preamble={\usetikzlibrary{datavisualization}},
+ pre={\tikzdatavisualizationset{
+ our system/.style={
+ new Cartesian axis=x axis,
+ new Cartesian axis=left axis,
+ new Cartesian axis=right axis,
+ x axis={attribute=x},
+ left axis={unit vector={(0cm,1pt)}},
+ right axis={unit vector={(0cm,1pt)}},
+ x axis ={length=\pgfkeysvalueof{/tikz/data visualization/scientific axes/width}},
+ left axis ={length=\pgfkeysvalueof{/tikz/data visualization/scientific axes/height}},
+ right axis={length=\pgfkeysvalueof{/tikz/data visualization/scientific axes/height}}
+ }
+}}]
+\tikzset{
+ data visualization/our system/.append style={
+ every axis/.style={style=black!50}, % make this the default
+ left axis= {visualize axis={x axis= {goto=min}, style=red!75}},
+ right axis={visualize axis={x axis= {goto=max}, style=blue!75}},
+ x axis= {visualize axis={left axis={goto=min}},
+ visualize axis={left axis={goto=max}}},
+ }
+}
+\tikz \datavisualization [
+ our system,
+ x axis={attribute=time, length=4cm},
+ left axis ={attribute=money},
+ right axis={attribute=people},
+ visualize as line/.list={people 1, people 2, money 1, money 2}]
+ data group {people and money};
+\end{codeexample}
+\tikzset{
+ data visualization/our system/.append style={
+ every axis/.style={style=black!50}, % make this the default
+ left axis= {visualize axis={x axis= {goto=min}, style=red!75}},
+ right axis={visualize axis={x axis= {goto=max}, style=blue!75}},
+ x axis= {visualize axis={left axis={goto=min}},
+ visualize axis={left axis={goto=max}}},
+ }
+}
+
+
+ \medskip
+ \textbf{Padding the Axis.}
+ When an axis is visualized, it is often a good idea to make it ``a little
+ bit longer'' or to ``remove it a bit from the border'', because the
+ visualization of an axis should not interfere with the actual data. For
+ this reason, a \emph{padding} can be specified for axes:
+
+ \begin{key}{/tikz/data visualization/axis options/padding min=\meta{dimension}}
+ This is the dimension that is used whenever |goto=padded min| is used.
+ The \meta{dimension} is then put into the |offset| subkey of the
+ attribute monitored by the axis. When a data point is transformed by a
+ linear transformer and when this subkey is nonzero, this offset is
+ added. (For an angle axis of a polar transformer, the \meta{dimension}
+ is interpreted as an additional angle rather than as an additional
+ distance). Note that \meta{dimension} should typically be negative
+ since ``adding the \meta{dimension}'' will then make the axis longer
+ (because it starts at a smaller value). The standard axis systems set
+ the padding to some default and take its value into account:
+ %
+\begin{codeexample}[
+ width=8cm,
+ preamble={\usetikzlibrary{datavisualization.formats.functions}},
+]
+\begin{tikzpicture}
+ \datavisualization [scientific axes=clean,
+ x axis={padding min=-1cm},
+ visualize as smooth line]
+ data [format=function] {
+ var x : interval [-3:5];
+ func y = \value x * \value x;
+ };
+\end{tikzpicture}
+\end{codeexample}
+
+ Using padded and using the |padded| key, we can visualize our axis ``a
+ little removed from the actual data'':
+ %
+\begin{codeexample}[
+ preamble={\usetikzlibrary{datavisualization}},
+ pre={\tikzdatavisualizationset{
+ our system/.style={
+ new Cartesian axis=x axis,
+ new Cartesian axis=left axis,
+ new Cartesian axis=right axis,
+ x axis={attribute=x},
+ left axis={unit vector={(0cm,1pt)}},
+ right axis={unit vector={(0cm,1pt)}},
+ x axis ={length=\pgfkeysvalueof{/tikz/data visualization/scientific axes/width}},
+ left axis ={length=\pgfkeysvalueof{/tikz/data visualization/scientific axes/height}},
+ right axis={length=\pgfkeysvalueof{/tikz/data visualization/scientific axes/height}}
+ }
+}%
+\tikzset{
+ data visualization/our system/.append style={
+ every axis/.style={style=black!50}, % make this the default
+ left axis= {visualize axis={x axis= {goto=min}, style=red!75}},
+ right axis={visualize axis={x axis= {goto=max}, style=blue!75}},
+ x axis= {visualize axis={left axis={goto=min}},
+ visualize axis={left axis={goto=max}}},
+ }
+}}]
+\tikzset{
+ data visualization/our system/.append style={
+ all axes= {padding=.5em},
+ left axis= {visualize axis={x axis= {goto=padded min}, padded}},
+ right axis={visualize axis={x axis= {goto=padded max}, padded}},
+ x axis= {visualize axis={left axis={goto=padded min}, padded},
+ visualize axis={left axis={goto=padded max}, padded}},
+ }
+}
+\tikz \datavisualization [
+ our system,
+ x axis={attribute=time, length=3cm},
+ left axis ={attribute=money},
+ right axis={attribute=people},
+ visualize as line/.list={people 1, people 2, money 1, money 2}]
+ data group {people and money};
+\end{codeexample}
+ \end{key}
+
+ \begin{key}{/tikz/data visualization/axis options/padding max=\meta{dimension}}
+ Works like |padding min|, but \meta{dimension} should typically be
+ positive.
+ \end{key}
+
+ \begin{key}{/tikz/data visualization/axis options/padding=\meta{dimension}}
+ Sets both |padding min| to the negated value of \meta{dimension} and
+ |padding max| to \meta{dimension}.
+ \end{key}
+\end{key}
+
+
+\subsubsection{Visualizing Grid Lines}
+\label{section-dv-visualize-gridlines}
+
+As explained earlier, the |grid| key is used to specify at which positions grid
+lines should be drawn in principle. However, this key does not actually cause
+any grid lines to be drawn. Instead, the |visualize grid| key is used by the
+axis system to specify how grid lines are drawn.
+
+\begin{key}{/tikz/data visualization/axis options/visualize grid=\meta{options}}
+ This key is passed to an axis. It causes grid lines to be drawn at the
+ positions specified by the |grid| key for this axis. The \meta{options}
+ govern where and how the grid lines will be drawn.
+
+
+ \medskip
+ \textbf{The direction axis.}
+ At first sight, one might expect that the grid lines for an axis should
+ simply be drawn perpendicular to the axis between the minimum and maximum
+ value of the axis. However, things are somewhat more difficult in reality:
+ %
+ \begin{enumerate}
+ \item A grid line is supposed to indicate all positions where a certain
+ attribute attains a fixed value. But, then, a grid line does not
+ really need to be a grid \emph{line}. Consider for instance a three
+ dimensional axis system. A ``grid line'' for the $x$-coordinate |3|
+ would actually be a ``grid plane''.
+ \item For a polar coordinate system and a fixed radius, this set of
+ positions at a certain radius is not a straight line, but an arc.
+ For more complicated coordinate systems such as the one arising
+ from three-dimensional spherical projections, a grid line may well
+ be a fairly involved curve.
+ \end{enumerate}
+ %
+ The |visualize grid| command addresses these complications as follows:
+ %
+ \begin{enumerate}
+ \item A grid line is always a line, not a plane or a volume. This means
+ that in the example of a three dimensional axis system and the
+ $x$-attribute being |3|, one would have to choose whether the grid
+ line should go ``along'' the $y$-axis or ``along'' the $z$-axis for
+ this position. One can, however, call the |visualize grid| command
+ twice, once for each direction, to cause grid lines to be shown for
+ both directions.
+ \item A grid line is created by moving to a start position and then
+ doing a lineto to the target position. However, the ``moveto'' and
+ ``lineto'' are done by calling special commands of the data
+ visualization system. These special commands allow coordinate
+ system to ``notice'' that the line is along an axis and will allow
+ them to replace the straight line by an appropriate curve. The
+ polar axes systems employ this strategy, for instance.
+ \end{enumerate}
+
+ By the above discussion, in order to create a grid line for attribute $a$
+ having value $v$, we need to specify an axis ``along'' which the line
+ should be drawn. When there are only two axes, this is usually ``the other
+ axis''. This ``other axis'' is specified using the following key:
+ %
+ \begin{key}{/tikz/data visualization/direction axis=\meta{axis name}}
+ You must pass this key as an \meta{option} each time you use
+ |visualize axis|. When the grid line is drawn, the attribute $a$ is set
+ to $v$ and the axis \meta{axis name}'s attribute is set once to the
+ current value of |low| and once to |high|. Then a line is drawn between
+ these two positions using |\pgfpathdvlineto|.
+ \end{key}
+ %
+ The |low| and |high| keys are the same as the ones used in the
+ |visualize axis| key.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\tikz \datavisualization [
+ xyz Cartesian cabinet,
+ all axes={visualize axis={low=0, style=->}},
+ x axis={visualize grid={direction axis=y axis}, grid=many},
+ visualize as scatter]
+ data {
+ x, y, z
+ 0, 0, 1
+ 0, 1, 0
+ 2, 2, 2
+ };
+\end{codeexample}
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\tikz \datavisualization [
+ xyz Cartesian cabinet,
+ all axes={visualize axis={low=0, style=->}, grid=many},
+ x axis={visualize grid={direction axis=z axis}},
+ z axis={visualize grid={direction axis=x axis},
+ visualize grid={direction axis=y axis},},
+ visualize as scatter]
+ data {
+ x, y, z
+ 0, 0, 1
+ 0, 1, 0
+ 2, 2, 2
+ };
+\end{codeexample}
+
+
+ \medskip
+ \textbf{Styling the grid lines.}
+ When a grid line is draw, styles are applied as described in
+ Section~\ref{section-dv-styling-grid-lines}.
+
+
+ \medskip
+ \textbf{The major, minor, and subminor grid lines.}
+ The |grid| option allows you to specify for each kind of grid line (major,
+ minor, or subminor) a set of different values for which these grid lines
+ should be drawn. Correspondingly, it is also possible to configure for each
+ kind of grid line how it should be drawn. For this, the |major|, |minor|,
+ |subminor|, and also the |common| keys can be used inside the
+ \meta{options} of |visualize grid|. While as option to |grid| these keys
+ are used to specify |at| values, as options of |visualize grid| they are
+ used to configure the different kinds of grid lines.
+
+ Most of the time, no special configuration is necessary since all styling
+ is best done by configuring keys like |every major grid|. You need to use a
+ key like |major| only if you wish to configure for instance the |low| or
+ |high| values of a |major| grid line differently from those of |minor| grid
+ lines -- are rather unlikely setting -- or when the styling should deviate
+ from the usual settings.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\tikz \datavisualization [
+ xy Cartesian,
+ all axes={visualize axis={low=0, style=->},
+ grid={some, minor steps between steps}},
+ x axis= {visualize grid={
+ direction axis=y axis,
+ minor={low=0.25, high=1.75, style=red!50}}},
+ visualize as scatter]
+ data {
+ x, y
+ 0, 0
+ 3, 3
+ };
+\end{codeexample}
+ %
+\end{key}
+
+Returning to the example of |our system| with the two axis systems, it is
+straight-forward to configure the grid lines of the $x$-axis: The direction
+axis is either of the other two axis (they point in the same direction and they
+have the same range). For the other two axes, we visualize one grid
+independently of the other, using different colors.
+%
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\tikzset{
+ data visualization/our system/.append style={
+ x axis= {visualize grid={direction axis=left axis}},
+ left axis= {visualize grid={direction axis=x axis,
+ common={style=red!50}}},
+ right axis={visualize grid={direction axis=x axis,
+ common={style=blue!50}}},
+ }
+}
+\tikz \datavisualization [
+ our system,
+ x axis={attribute=time, length=3cm, grid=many},
+ left axis ={attribute=money, grid=some},
+ right axis={attribute=people, grid=few},
+ visualize as line/.list={people 1, people 2, money 1, money 2}]
+ data group {people and money};
+\end{codeexample}
+
+
+\subsubsection{Visualizing the Ticks and Tick Labels}
+\label{section-dv-visualize-ticks}
+
+\begin{key}{/tikz/data visualization/axis options/visualize ticks=\meta{options}}
+ Visualizing a tick involves (possibly) drawing a tick mark and adding
+ (possibly) the tick node. The process is similar to |visualize grid|: Users
+ use the |ticks| key to configure how many ticks they would like for an axis
+ and at which positions. The axis system uses the |visualize ticks| key to
+ specify where these ticks should actually be shown.
+
+ Unlike grid lines, which are typically only visualized once for each
+ combination of an axis and a direction axis, tick marks might be visualized
+ at different places for the same axis. Consider for instance the
+ |scientific axes|:
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization [scientific axes, all axes={length=3cm},
+ x axis={ticks={stack}},
+ visualize as smooth line]
+ data [format=function] {
+ var x : interval [0:2];
+ func y = \value x*\value x;
+ };
+\end{codeexample}
+ %
+ Have a look at the ticks on the $y$-axis: There are ticks at values |0|,
+ |1|, |2|, |3|, and~|4|. These are visualized both at the left side (where
+ the tick nodes are also shown) and additionally also at the right side, but
+ only as small marks. Similarly, the ticks on the $x$-axis appear at the
+ bottom, but also (in much simpler versions) at the top. Both for the
+ $x$-axis and for the $y$-axis the |visualize ticks| key was called twice.
+
+
+ \medskip
+ \textbf{The tick marks.}
+ Drawing a tick mark is quite similar to visualizing a grid line; indeed a
+ tick mark can be thought of as a ``mini grid line'': Just like a grid line
+ it ``points a long an axis''. However, a tick will always be a short
+ straight line -- even when the coordinate system is actually twisted
+ (experimentation has shown that ticks that follow the curvature of the
+ coordinate system like grid lines are hard to recognize). For this reason,
+ the |low| and |high| keys have a different meaning from the one used with
+ the |visualize grid| key. In detail to configure the size and position of a
+ tick mark for the value $v$ of attribute $a$, proceed as follows:
+ %
+ \begin{itemize}
+ \item The |visualize ticks| key will have setup attribute $a$ to be
+ equal to $v$.
+ \item You should now use the |goto| or |goto pos| key together with all
+ \emph{other} axes to configure at which position with respect to
+ these other options the tick mark should be shown. For instance,
+ suppose we want tick marks in |our system| for the $x$-axis at the
+ bottom and at the top. This corresponds to once setting the
+ |left axis| to its minimal value and once to its maximal value:
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\tikzset{
+ data visualization/our system/.append style={
+ x axis={visualize ticks={direction axis=left axis, left axis={goto=min}},
+ visualize ticks={direction axis=left axis, left axis={goto=max}},
+ }
+ }
+}
+\tikz \datavisualization [
+ our system,
+ x axis={attribute=time, length=3cm, ticks=many},
+ left axis ={attribute=money},
+ right axis={attribute=people},
+ visualize as line/.list={people 1, people 2, money 1, money 2}]
+ data group {people and money};
+\end{codeexample}
+ %
+ \item In the above example, we may wish to shorten the ticks a bit at
+ the bottom and at the top. For this, we use the |low| and |high|
+ key:
+ %
+ \begin{key}{/tikz/data visualization/low=\meta{dimension}}
+ When used with the |visualize ticks| option, the |low| key
+ contains a dimension that specifies the extend of the tick
+ going ``toward the minimum'' of the direction axis. More
+ precisely, when a tick mark is visualized, a unit tangent
+ vector at the current data point in the direction of the
+ |direction axis| is computed and this vector is multiplied by
+ \meta{dimension} to compute the start position of the tick
+ line. The end position is given by this vector times the |high|
+ value.
+
+ Note that the \meta{dimension} should usually be negative for
+ the |low| key and positive for the |high| key.
+
+ For tick marks where a tick label node is shown, the
+ \meta{dimension} is increased by the current values of keys
+ like |tick text even low padding|, see
+ Section~\ref{section-dv-stacking} for details.
+ \end{key}
+ %
+ \begin{key}{/tikz/data visualization/high=\meta{dimension}}
+ Like |low|.
+ \end{key}
+ %
+ \begin{key}{/tikz/data visualization/tick length=\meta{dimension}}
+ Shorthand for |low=-|\meta{dimension}|, high=|\meta{dimension}.
+ \end{key}
+
+ What we want to happen is that in the upper visualization of the
+ ticks the |low| value is |0pt|, while in the lower one the |high|
+ value is |0pt|:
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\tikzset{
+ data visualization/our system/.append style={
+ x axis={
+ visualize ticks={direction axis=left axis,high=0pt,left axis={goto=min}},
+ visualize ticks={direction axis=left axis,low=0pt,left axis={goto=max}},
+ }
+ }
+}
+\tikz \datavisualization [
+ our system,
+ x axis={attribute=time, length=3cm, ticks=many},
+ left axis ={attribute=money},
+ right axis={attribute=people},
+ visualize as line/.list={people 1, people 2, money 1, money 2}]
+ data group {people and money};
+\end{codeexample}
+ %
+ \end{itemize}
+ %
+ In order to style the tick mark, use the styling mechanism that is detailed
+ in Section~\ref{section-dv-styling-ticks}.
+
+
+ \medskip
+ \textbf{The tick label node.}
+ At certain tick positions, we may wish to add a node indicating the value
+ of the attribute at the given position. The |visualize ticks| command has
+ no influence over which text should be shown at a node -- the text is
+ specified and typeset as explained in Section~\ref{section-dv-tick-labels}.
+
+ Each time |visualize ticks|, for each tick position up to two tick label
+ nodes will be created: One at the |low| position and one at the |high|
+ position. The following keys are used to configure which of these cases
+ happen:
+ %
+ \begin{key}{/tikz/data visualization/tick text at low=\opt{\meta{true or false}} (default true)}
+ Pass this option to |visualize ticks| when you want tick label nodes to
+ be placed at the |low| position of each tick mark.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\tikzset{
+ data visualization/our system/.append style={
+ x axis={
+ visualize ticks={direction axis=left axis, left axis={goto=min},
+ high=0pt, tick text at low, stack},
+ visualize ticks={direction axis=left axis, left axis={goto=max},
+ low=0pt, tick text at high, stack}
+ }
+ }
+}
+\tikz \datavisualization [
+ our system,
+ x axis={attribute=time, length=3cm, ticks=some},
+ left axis ={attribute=money},
+ right axis={attribute=people},
+ visualize as line/.list={people 1, people 2, money 1, money 2}]
+ data group {people and money};
+\end{codeexample}
+ \end{key}
+ %
+ \begin{key}{/tikz/data visualization/tick text at high=\opt{\meta{true or false}} (default true)}
+ Like |tick text at low|.
+ \end{key}
+
+ \begin{key}{/tikz/data visualization/no tick text}
+ Shorthand for |tick text at low=false, tick text at high=false|.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization [scientific axes, all axes={length=3cm},
+ x axis={ticks={
+ major also at={6.5 as [no tick text]}}},
+ visualize as smooth line]
+ data [format=function] {
+ var x : interval [5:10];
+ func y = \value x * \value x;
+ };
+\end{codeexample}
+ \end{key}
+
+ When a tick label node is to be placed at the low or the high position, the
+ next step is to determine the exact position and the correct anchor of the
+ node. This is done as follows:
+ %
+ \begin{itemize}
+ \item In order to compute an appropriate |anchor|, the tick mark is
+ considered: This is a short line pointing in a certain direction.
+ For a tick label node at the |low| position, the |anchor| attribute
+ is setup in such a way that the node label will be below the |low|
+ position when the tick mark direction points up, it will be to the
+ right when the direction points left, above when it points down,
+ and so on also for diagonal directions. Similarly, for the |high|
+ position, when the direction points up, the node will be placed
+ above the tick mark and so on.
+
+ This computation is done automatically.
+ \item The tick label node is styled. The styles that are applied are
+ described in Section~\ref{section-dv-styling-ticks}.
+ \item A tick label node for the |low| position is usually anchored at
+ this |low| position, but an additional padding will be added as
+ described in Section~\ref{section-dv-stacking}.
+ \end{itemize}
+\end{key}
+
+
+\subsubsection{Visualizing the Axis Labels}
+\label{section-dv-visualize-label}
+
+The |label| option can be used with an axis to specify a text should be shown
+next to the axis to indicates which attribute this axis refers to. Like |ticks|
+or |grid|, the |label| option does not actually draw the label, this is the job
+of the |visualize label| key, which is configured by the axis system.
+
+\begin{key}{/tikz/data visualization/axis options/visualize label=\meta{options}}
+ The \meta{options} should be used to configure a ``good place'' for the
+ axis label. Usually, you will use the |goto| or the |goto pos| key.
+
+ For the example of |our system|, we would like the label of the |x axis| to
+ be placed below at the middle of the axis, so we use |goto pos=.5| to
+ determine this position. Concerning the other axes, we want it to be placed
+ at the minimum position of the |left axis| with a lot of padding.
+ %
+\begin{codeexample}[width=7cm,preamble={\usetikzlibrary{datavisualization}}]
+\tikzdatavisualizationset{
+ our system/.append style={
+ x axis={visualize label={
+ x axis={goto pos=.5},
+ left axis={padding=1.5em, goto=padded min}}}
+ }
+}
+\tikz \datavisualization [
+ our system,
+ x axis={attribute=time, ticks=some, label},
+ left axis ={attribute=money},
+ right axis={attribute=people},
+ visualize as line/.list={
+ people 1, people 2, money 1, money 2}]
+ data group {people and money};
+\end{codeexample}
+
+ In the above example, the |padding| of |1.5em| was rather arbitrary and
+ ``suboptimal''. It would be outright wrong if the labels on the |x axis|
+ were larger or if they were missing. It would be better if the vertical
+ position of the |x axis| label were always ``below'' all other options. For
+ such cases a slightly strange approach is useful: You position the node
+ using |node style={at=...}| where |at| is now the normal \tikzname\ option
+ that is used to specify the position of a node. Inside the |...|, you
+ specify that the horizontal position should be the bottom of
+ up-to-now-constructed data visualization and the vertical position should
+ be at the ``origin'', which is, however, the position computed by the
+ |goto| keys for the axes:
+ %
+\begin{codeexample}[width=7cm,preamble={\usetikzlibrary{datavisualization}}]
+\tikzdatavisualizationset{
+ our system/.append style={
+ x axis={visualize label={
+ x axis={goto pos=.5},
+ node style={
+ at={(0,0 |- data visualization bounding box.south)},
+ below
+} } } } }
+\tikz \datavisualization [
+ our system,
+ x axis={attribute=time, ticks=some, label=Year},
+ left axis ={attribute=money},
+ right axis={attribute=people},
+ visualize as line/.list={
+ people 1, people 2, money 1, money 2}]
+ data group {people and money};
+\end{codeexample}
+
+ Two additional keys are useful for positioning axis labels:
+ %
+ \begin{key}{/tikz/data visualization/axis option/anchor at min}
+ When passed to an axis, this key sets the |anchor| so that a node
+ positioned at either the |min| or the |padded min| value of the axis
+ will be placed ``nicely'' with respect to the axis. For instance, if
+ the axis points upwards from the |min| value to the |max| value, the
+ |anchor| would be set to |north| since this gives a label below the
+ axis's start. Similarly, if the axis points right, the anchor would be
+ set to |east|, and so on.
+ \end{key}
+ %
+ \begin{key}{/tikz/data visualization/axis option/anchor at max}
+ Like |anchor at min|.
+ \end{key}
+\end{key}
+
+
+\subsubsection{The Complete Axis System}
+
+Here is the code for the complete axis system developed above and an example of
+how it is used:
+%
+\begin{codeexample}[code only]
+\tikzdatavisualizationset{ our system/.style={
+ % The axes
+ new Cartesian axis=x axis, new Cartesian axis=left axis, new Cartesian axis=right axis,
+ % The directions of the axes
+ all axes={padding=.5em}, left axis={unit vector={(0cm,1pt)}}, right axis={unit vector={(0cm,1pt)}},
+ % The default attributes, other attributes must be configured
+ x axis={attribute=x},
+ % The lengths of the axes
+ x axis ={length=\pgfkeysvalueof{/tikz/data visualization/scientific axes/width}},
+ left axis ={length=\pgfkeysvalueof{/tikz/data visualization/scientific axes/height}},
+ right axis={length=\pgfkeysvalueof{/tikz/data visualization/scientific axes/height}},
+ % The styling of the axes
+ every axis/.style={style=black!50}, % make this the default
+ % Visualizing the axes themselves
+ left axis= {visualize axis={x axis= {goto=padded min}, style=red!75, padded}},
+ right axis={visualize axis={x axis= {goto=padded max}, style=blue!75,padded}},
+ x axis= {visualize axis={left axis={goto=padded min}, padded},
+ visualize axis={left axis={goto=padded max}, padded}},
+ % Visualizing the grid, when requested
+ x axis= {visualize grid={direction axis=left axis}},
+ left axis= {visualize grid={direction axis=x axis, common={style=red!50}}},
+ right axis={visualize grid={direction axis=x axis, common={style=blue!50}}},
+ % Visualizing the ticks, when requested
+ left axis={visualize ticks={style={red!50!black}, direction axis=x axis,
+ x axis={goto=padded min}, high=0pt, tick text at low}},
+ right axis={visualize ticks={style={blue!80!black}, direction axis=x axis,
+ x axis={goto=padded max}, low=0pt, tick text at high}},
+ x axis={visualize ticks={direction axis=left axis, left axis={goto=padded min}, high=0pt,
+ tick text at low},
+ visualize ticks={direction axis=left axis, left axis={goto=padded max}, low=0pt}},
+ % By default, there are ticks on all axes
+ all axes={ticks},
+ % Visualizing the axis labels, when requested
+ x axis={visualize label={x axis={goto pos=.5}, node style={
+ at={(0,0 |- data visualization bounding box.south)}, below}}},
+ left axis={visualize label={left axis={goto pos=.5}, node style={
+ at={(0,0 -| data visualization bounding box.west)}, rotate=90, anchor=south, red!50!black}}},
+ right axis={visualize label={right axis={goto pos=.5}, node style={
+ at={(0,0 -| data visualization bounding box.east)}, rotate=-90, anchor=south, blue!80!black}}},
+}}
+\end{codeexample}
+
+\begin{codeexample}[
+ preamble={\usetikzlibrary{datavisualization}},
+ pre={\tikzdatavisualizationset{
+ our system/.style={
+ % The axes
+ new Cartesian axis=x axis,
+ new Cartesian axis=left axis,
+ new Cartesian axis=right axis,
+ % The default attributes, other attributes must be configured
+ x axis={attribute=x},
+ % The directions of the axes
+ all axes={padding=.5em},
+ left axis={unit vector={(0cm,1pt)}},
+ right axis={unit vector={(0cm,1pt)}},
+ % The lengths of the axes
+ x axis ={length=\pgfkeysvalueof{/tikz/data visualization/scientific axes/width}},
+ left axis ={length=\pgfkeysvalueof{/tikz/data visualization/scientific axes/height}},
+ right axis={length=\pgfkeysvalueof{/tikz/data visualization/scientific axes/height}},
+ % The styling of the axes
+ every axis/.style={style=black!50}, % make this the default
+ % Visualizing the axes themselves
+ left axis= {visualize axis={x axis= {goto=padded min}, style=red!75, padded}},
+ right axis={visualize axis={x axis= {goto=padded max}, style=blue!75,padded}},
+ x axis= {visualize axis={left axis={goto=padded min}, padded},
+ visualize axis={left axis={goto=padded max}, padded}},
+ % Visualizing the grid, when requested
+ x axis= {visualize grid={direction axis=left axis, padded}},
+ left axis= {visualize grid={direction axis=x axis, padded, common={style=red!50}}},
+ right axis={visualize grid={direction axis=x axis, padded, common={style=blue!50}}},
+ % Visualizing the ticks, when requested
+ left axis={
+ visualize ticks={style={red!50!black}, direction axis=x axis, x axis={goto=padded min}, high=0pt, tick text at low}},
+ right axis={
+ visualize ticks={style={blue!80!black}, direction axis=x axis, x axis={goto=padded max}, low=0pt, tick text at high}},
+ x axis={
+ visualize ticks={direction axis=left axis, left axis={goto=padded min}, high=0pt, tick text at low},
+ visualize ticks={direction axis=left axis, left axis={goto=padded max}, low=0pt}
+ },
+ % By default, there are ticks on all axes
+ all axes={ticks},
+ % Visualizing the axis labels, when requested
+ x axis={visualize label={
+ x axis={goto pos=.5}, node style={at={(0,0 |- data visualization bounding box.south)}, below}}},
+ left axis={visualize label={
+ left axis={goto pos=.5}, node style={
+ at={(0,0 -| data visualization bounding box.west)}, rotate=90, anchor=south, red!50!black}}},
+ right axis={visualize label={
+ right axis={goto pos=.5}, node style={
+ at={(0,0 -| data visualization bounding box.east)}, rotate=-90, anchor=south, blue!80!black}}},
+ }
+}}]
+\tikz \datavisualization [
+ our system,
+ x axis={attribute=time, label=Year,
+ ticks={tick text padding=2pt, style={/pgf/number format/set thousands separator=}}},
+ left axis={attribute=money, label=Spending,
+ padding min=0, include value=0, grid,
+ ticks={tick prefix=\$, style={/pgf/number format/fixed,
+ /pgf/number format/fixed zerofill, /pgf/number format/precision=2}}},
+ right axis={attribute=people,
+ label=Population,
+ padding min=0, include value=0,
+ ticks={style=/pgf/number format/fixed}},
+ visualize as line/.list={
+ people 1, people 2, money 1, money 2},
+ people 1={style={visualizer color=blue}},
+ people 2={style={visualizer color=blue!50}},
+ money 1={style={visualizer color=red}},
+ money 2={style={visualizer color=red!50}} ]
+data group {people and money};
+\end{codeexample}
+
+
+\subsubsection{Using the New Axis System Key}
+
+The axis system |our system| that we developed in the course of the previous
+section is not yet ``configurable''. The only configuration that was possible
+was to ``misuse'' the |width| and |height| keys of the |scientific axes|.
+
+In order to make |our system| configurable so that we can say
+|our system=|\meta{options}, where \meta{options} are executed with the path
+prefix
+%
+\begin{codeexample}[code only]
+/tikz/data visualization/our system
+\end{codeexample}
+%
+we can use the following key:
+
+\begin{key}{/tikz/data visualization/new axis system=\marg{axis system
+ name}\marg{axis setup}\marg{default options}\\ \marg{application
+ options}%
+}
+ The |new axis system| key takes four parameters. The first one,
+ \meta{system name}, is the name of the to-be-created axis system,
+ |our system| in our case. The |new axis system| will create the following
+ new key:
+ %
+ \begin{key}{/tikz/data visualization/\meta{axis system name}=\opt{\meta{options}}}
+ When the key \meta{axis system name} is used, the following keys will be
+ executed in the following order:
+ %
+ \begin{enumerate}
+ \item The \meta{axis setup} with the path prefix
+ |/tikz/data visualization/|.
+ \item The \meta{default options} with the same path prefix.
+ \item The following style:
+ %
+ \begin{stylekey}{/tikz/data visualization/every \meta{axis system name}}
+ Even though this style has the path prefix
+ |/tikz/data visualization| itself, the keys stored in this
+ style will be executed with the path prefix
+ |/tikz/data visualization/|\meta{axis system name}.
+ \end{stylekey}
+ \item The \meta{options} with the path prefix
+ |/tikz/data visualization/|\meta{axis system name}.
+ \item The \meta{application options} with the path prefix
+ |/tikz/data visualization/|
+ \end{enumerate}
+ \end{key}
+
+ Let us now have a look at what all of this means. First, the \meta{axis
+ setup} will contain all options that setup the axis system in all ways that
+ need not be configured. For instance, the \meta{axis setup} for the
+ |scientific axes| will create an |x axis| and also a |y axis| (because
+ these are always present), but will not setup the label visualization
+ (because this can be configured in different ways). For |our system|, which
+ cannot be configured at all, we would place all of our configuration in the
+ \meta{axis setup}.
+
+ The \meta{default options} can be used to pick default values that would
+ usually be passed to the \meta{options} of the newly created axis system.
+ For instance, for |scientific axis|, the \meta{default options} are set to
+ |outer ticks,standard labels|, because these are the defaults.
+
+ Finally, the \meta{application options} can be used to actually apply the
+ configuration that has been chosen by the \meta{options}. The idea is that
+ \meta{default options}, \meta{options}, and also |every| \meta{axis system
+ name} all have a chance of changing, re-changing and re-setting all sorts
+ of styles and keys. Then, with the last change ``winning'', the resulting
+ setting of a style can be executed, which may then cause a label
+ visualization to be installed.
+\end{key}
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-axes.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-backend.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-backend.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-backend.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,34 @@
+% Copyright 2018 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section{The Data Visualization Backend}
+\label{section-dv-backend}
+
+\subsection{Overview}
+
+The present section explains the mechanisms behind the data visualization
+engine.
+
+Until it is documented properly, we will have to make do with the documentation
+in the source code.
+
+
+\subsection{The Rendering Pipeline}
+
+To be written...
+
+\subsection{Usage}
+
+To be written...
+
+\subsection{The Mathematical Micro-Kernel}
+\label{section-dv-math-kernel}
+
+To be written...
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-backend.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-examples.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-examples.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-examples.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,95 @@
+% Copyright 2019 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+A first example:
+
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\begin{tikzpicture}[baseline]
+ \datavisualization [
+ school book axes,
+ visualize as smooth line,
+ clean ticks,
+ all axes={grid={step=1,minor steps between steps=1}},
+ x axis={
+ ticks={
+ major={
+ also at={(0.5*pi) as $\pi/2$},
+ also at={(pi) as $\pi$},
+ options at=3 as [no tick text]
+ }
+ },
+ label=$x$
+ },
+ y axis={
+ label=$y$,
+ }
+ ]
+ data [format=function] {
+ var x : interval [-0.5*pi:4] samples 50;
+ func y = sin(\value x r);
+ };
+\end{tikzpicture}
+\end{codeexample}
+%
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\begin{tikzpicture}[baseline]
+ \datavisualization [
+ scientific axes=clean,
+ visualize as line,
+ all axes={padding=4pt},
+ x axis={logarithmic,
+ ticks={many, tick unit={ms},
+ node style={rotate=45,anchor=north east}},
+ label={time},
+ grid},
+ y axis={label={distance}},
+ ]
+ data {
+ x, y, z
+ 0.001, 0, 0
+ 2000, 2.23, 2
+ 20670, 1, 3
+ 501, -2, 0
+ };
+\end{tikzpicture}
+\end{codeexample}
+
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\begin{tikzpicture}[baseline,mark=*]
+ \datavisualization [
+ scientific axes=inner ticks,
+ all axes={padding=4pt},
+ euro about strategy,
+ visualize as scatter,
+ x axis={attribute=x2},
+ y axis={attribute=y2}
+ ]
+ data [separator=\space] {
+x y x1 y1 x2 y2 x3 y3
+10.0 8.04 10.0 9.14 10.0 7.46 8.0 6.58
+8.0 6.95 8.0 8.14 8.0 6.77 8.0 5.76
+13.0 7.58 13.0 8.74 13.0 12.74 8.0 7.71
+9.0 8.81 9.0 8.77 9.0 7.11 8.0 8.84
+11.0 8.33 11.0 9.26 11.0 7.81 8.0 8.47
+14.0 9.96 14.0 8.10 14.0 8.84 8.0 7.04
+6.0 7.24 6.0 6.13 6.0 6.08 8.0 5.25
+4.0 4.26 4.0 3.10 4.0 5.39 19.0 12.50
+12.0 10.84 12.0 9.13 12.0 8.15 8.0 5.56
+7.0 4.82 7.0 7.26 7.0 6.42 8.0 7.91
+5.0 5.68 5.0 4.74 5.0 5.73 8.0 6.89
+ };
+\end{tikzpicture}
+\end{codeexample}
+
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "pgfmanual"
+%%% End:
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-examples.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-formats.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-formats.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-formats.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,645 @@
+% Copyright 2019 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section{Providing Data for a Data Visualization}
+\label{section-dv-formats}
+
+\subsection{Overview}
+
+The data visualization system needs a stream of data points as input. These
+data points can be directly generated by repeatedly calling the |\pgfdatapoint|
+command, but usually data is available in some special (text) format and one
+would like to visualize this data. The present section explains how data in
+some specific format can be fed to the data visualization system.
+
+This section starts with an explanation of the main concepts. Then, the
+standard formats are listed in the reference section. It is also possible to
+define new formats, but this an advanced concept which requires an
+understanding of some of the internals of the parsing mechanism, explained in
+Section~\ref{section-dv-parsing}, and the usage of a rather low-level command,
+explained in Section~\ref{section-dv-declaring-formats}.
+
+
+\subsection{Concepts}
+
+For the purposes of this section, let call a \emph{data format} some
+standardized way of writing down a list of data points. A simple example of a
+data format is the \textsc{csv} format (the acronym stands for \emph{comma
+separated values}), where each line contains a data point, specified by values
+separated by commas. A different format is the \emph{key--value format}, where
+data points are specified by lists of key--value pairs. A far more complex
+format is the \textsc{pdb}-format used by the protein database to describe
+molecules.
+
+The data visualization system does not use any specific format. Instead,
+whenever data is read by the data visualization system, you must specify a
+format parser (or it is chosen automatically for you). It is the job of the
+parser to read (parse) the data lines and to turn them into data points, that
+is, to setup appropriate subkeys of |/data point/|.
+
+To give a concrete example, suppose a file contains the following
+lines:
+%
+\begin{codeexample}[code only]
+x, y, z
+0, 0, 0
+1, 1, 0
+1, 1, 0.5
+0, 1, 0.5
+\end{codeexample}
+%
+This file is in the \textsc{csv}-format. This format can be read by the |table|
+parser (which is called thus, rather than ``|csv|'', since it can also read
+files in which the columns are separated by, say, a semicolon or a space). The
+|table| format will then read the data and for each line of the data, except
+for the headline of course, it will produce one data point. For instance, for
+the last data point the key |/data point/x| will be set to |0|, the key
+|/data point/y| will be set to |1|, and the key |/data point/z| will be set to
+|0.5|.
+
+All parsers are basically line-oriented. This means that, normally, each line
+in the input data should contain one data point. This rule may not always
+apply, for instance empty lines are typically ignored and sometimes a data
+point may span several lines, but deviating from this ``one data point per
+line'' rule makes parsers harder to program.
+
+
+\subsection{Reference: Built-In Formats}
+
+The following format is the default format, when no |format=...| is specified.
+
+\begin{dataformat}{table}
+ This format is used to parse data that is formatted in the following
+ manner: Basically, each line consists of \emph{values} that are separated
+ by a \emph{separator} like a comma or a space. The values are stored in
+ different \emph{attributes}, that is, subkeys of |/data point| like
+ |/data point/x|. In order to decide which attribute is chosen for a give
+ value, the headline is important. This is the first non-empty line of a
+ table. It is formatted in the same way as normal data lines (value
+ separated by the separator), but the meaning of the values is different:
+ The first value in the headline is the name of the attribute where the
+ first values in the following lines should go each time. Similarly, the
+ second value in the headline is the name of the attribute for the second
+ values in the following lines, and so on.
+
+ A simple example is the following:
+ %
+\begin{codeexample}[code only]
+angle, radius
+0, 1
+45, 2
+90, 3
+135, 4
+\end{codeexample}
+ %
+ The headline states that the values in the first column should be stored in
+ the |angle| attribute (|/data point/angle| to be precise) and that the
+ values in the second column should be stored in the |radius| attribute.
+ There are four data points in this data set.
+
+ The format will tolerate too few or too many values in a line. If there are
+ less values in a line than in the headline, the last attributes will simply
+ be empty. If there are more values in a line than in the headline, the
+ values are stored in attributes called |/data point/attribute |\meta{column
+ number}, where the first value of a line gets \meta{column number} equal to
+ |1| and so on.
+
+ The |table| format can be configured using the following options:
+ %
+ \begin{key}{/pgf/data/separator=\meta{character} (initially ,)}
+ Use this key to change which character is used to separate values in
+ the headline and in the data lines. To set the separator to a space,
+ either set this key to an empty value or say |separator=\space|. Note
+ that you must surround a comma by curly braces if you which to (re)set
+ the separator character to a space.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\begin{tikzpicture}
+ \datavisualization [school book axes, visualize as line]
+ data [separator=\space] {
+ x y
+ 0 0
+ 1 1
+ 2 1
+ 3 0
+ }
+ data [separator=;] {
+ x; y; z
+ 3; 1; 0
+ 2; 2; 0
+ };
+\end{tikzpicture}
+\end{codeexample}
+ \end{key}
+ %
+ \begin{key}{/pgf/data/headline=\meta{headline}}
+ When this key is set to a non-empty value, the value of \meta{headline}
+ is used as the headline and the first line of the data is treated as a
+ normal line rather than as a headline.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\begin{tikzpicture}
+ \datavisualization [school book axes, visualize as line]
+ data [headline={x, y}] {
+ 0, 0
+ 1, 1
+ 2, 1
+ 3, 0
+ };
+\end{tikzpicture}
+\end{codeexample}
+ \end{key}
+\end{dataformat}
+
+\begin{dataformat}{named}
+ Basically, each line of the data must consist of a comma-separated sequence
+ of attribute--values pairs like |x=5, lo=500|. This will cause the
+ attribute |/data point/x| to be set to |5| and |/data point/lo| to be set
+ to |500|.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\begin{tikzpicture}
+ \datavisualization [school book axes, visualize as line]
+ data [format=named] {
+ x=0, y=0
+ x=1, y=1
+ x=2, y=1
+ x=3, y=0
+ };
+\end{tikzpicture}
+\end{codeexample}
+ %
+ However, instead of just specifying a single value for an attribute as in
+ |x=5|, you may also specify a whole set of values as in |x={1,2,3}|. In
+ this case, three data points will be created, one for each value in the
+ list. Indeed, the |\foreach| statement is used to iterate over the list of
+ values, so you can write things like |x={1,...,5}|.
+
+ It is also permissible to specify lists of values for more than one
+ attribute. In this case, a data point is created for each possible
+ combination of values in the different lists:
+ %
+\begin{codeexample}[
+ width=7cm,
+ preamble={\usetikzlibrary{datavisualization}},
+]
+\tikz \datavisualization
+ [scientific axes=clean,
+ visualize as scatter/.list={a,b,c},
+ style sheet=cross marks]
+data [format=named] {
+ x=0, y={1,2,3}, set=a
+ x={2,3,4}, y={3,4,5,7}, set=b
+ x=6, y={5,7,...,15}, set=c
+};
+\end{codeexample}
+ %
+\end{dataformat}
+
+\begin{dataformat}{TeX code}
+ This format will simply execute each line of the data, each of which should
+ contain some normal TeX code. Note that at the end of each line control
+ returns to the format handler, so for instance the arguments of a command
+ may not be spread over several lines. However, not each line needs to
+ produce a data point.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\begin{tikzpicture}
+ \datavisualization [school book axes, visualize as line]
+ data [format=TeX code] {
+ \pgfkeys{/data point/.cd,x=0, y=0} \pgfdatapoint
+ \pgfkeys{/data point/.cd,x=1, y=1} \pgfdatapoint
+ \pgfkeys{/data point/x=2} \pgfdatapoint
+ \pgfkeyssetvalue{/data point/x}{3}
+ \pgfkeyssetvalue{/data point/y}{0} \pgfdatapoint
+ };
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{dataformat}
+
+
+\subsection{Reference: Advanced Formats}
+
+\begin{tikzlibrary}{datavisualization.formats.functions}
+ This library defines the formats described in the following, which allow
+ you to specify the data points indirectly, namely via a to-be-evaluated
+ function.
+
+ \begin{dataformat}{function}
+ This format allows you to specify a function that is then evaluated in
+ order to create the desired data points. In other words, the data lines
+ do not contain the data itself, but rather a functional description of
+ the data.
+
+ The format used to specify the function works as follows: Each nonempty
+ line of the data should contain at least one of either a \emph{variable
+ declaration} or a \emph{function declaration}. A variable declaration
+ signals that a certain attribute will range over a given interval. The
+ function declarations will then, later, be evaluated for values inside
+ this interval. The syntax for a variable declaration is one of the
+ following:
+ %
+ \begin{enumerate}
+ \item |var |\declare{\meta{variable}}| : interval[|\meta{low}|:|\meta{high}|]|
+ \opt{|samples |\meta{number}}|;|
+ \item |var |\declare{\meta{variable}}| : interval[|\meta{low}|:|\meta{high}%
+ |] step |\meta{step}|;|
+ \item |var |\declare{\meta{variable}}| : {|\meta{values}|};|
+ \end{enumerate}
+ %
+ In the first case, if the optional |samples| part is missing, the
+ number of |samples| is taken from the value stored in the following
+ key:
+ %
+ \begin{key}{/pgf/data/samples=\meta{number} (initially 25)}
+ Sets the number of samples to be used when no sample number is
+ specified.
+ \end{key}
+ %
+ The meaning of declaring a variable declaration to range over an
+ |interval| is that the attribute named \meta{variable}, that is, the
+ key |/data point/|\meta{variable}, will range over the interval
+ $[\meta{low},\meta{high}]$. If the number of |samples| is given
+ (directly or indirectly), the interval is evenly divided into
+ \meta{number} many points and the attribute is set to each of these
+ values. Similarly, when a \meta{step} is specified, this stepping is
+ used to increase \meta{low} iteratively up to the largest value that is
+ still less or equal to \meta{high}.
+
+ The meaning of declaring a variable using a list of \meta{values} is
+ that the variable will simply iterate over the values using |\foreach|.
+
+ You can specify more than one variable. In this case, each variable is
+ varied independently of the other variables. For instance, if you
+ declare an $x$-variable to range over the interval $[0,1]$ in $25$
+ steps and you also declare a $y$-variable to range over the same
+ interval, you get a total of $625$ value pairs.
+
+ The variable declarations specify which (input) variables will take
+ which values. It is the job of the \emph{function declarations} to
+ specify how some additional attributes are to be computed. The syntax
+ of a function declaration is as follows:
+ %
+ \begin{quote}
+ |func |\declare{\meta{attribute}}| = |\meta{expression}|;|
+ \end{quote}
+ %
+ The meaning of such a declaration is the following: For each setting of
+ the input variables (the variables specified using the |var|
+ declaration), evaluate the \meta{expression} using the standard
+ mathematical parser of \tikzname. The resulting value is then stored in
+ |/data point/|\meta{attribute}.
+
+ Inside \meta{expression} you can reference data point attributes using
+ the following command, which is only defined inside such an expression:
+ %
+ \begin{command}{\value\marg{variable}}
+ This expands to the current value of the key
+ |/data point/|\meta{variable}.
+ \end{command}
+
+ There can be multiple function declarations in a single data
+ specification. In this case, all of these functions will be evaluated
+ for each setting of input variables.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz
+ \datavisualization [school book axes, visualize as smooth line]
+ data [format=function] {
+ var x : interval [-1.5:1.5];
+
+ func y = \value x * \value x;
+ };
+\end{codeexample}
+ %
+\begin{codeexample}[
+ width=6cm,
+ preamble={\usetikzlibrary{datavisualization.formats.functions}},
+]
+\tikz \datavisualization [
+ school book axes,
+ all axes={unit length=5mm, ticks={step=2}},
+ visualize as smooth line]
+data [format=function] {
+ var t : interval [0:2*pi];
+
+ func x = \value t * cos(\value t r);
+ func y = \value t * sin(\value t r);
+};
+\end{codeexample}
+ %
+\begin{codeexample}[
+ width=7cm,
+ preamble={\usetikzlibrary{datavisualization.formats.functions}},
+]
+\tikz \datavisualization [
+ scientific axes=clean,
+ y axis={ticks={style={
+ /pgf/number format/fixed,
+ /pgf/number format/fixed zerofill,
+ /pgf/number format/precision=2}}},
+ x axis={ticks={tick suffix=${}^\circ$}},
+ visualize as smooth line/.list={1,2,3,4,5,6},
+ style sheet=vary hue]
+data [format=function] {
+ var set : {1,...,6};
+ var x : interval [0:50];
+ func y = sin(\value x * (\value{set}+10))/(\value{set}+5);
+};
+\end{codeexample}
+ \end{dataformat}
+\end{tikzlibrary}
+
+
+\subsection{Advanced: The Data Parsing Process}
+\label{section-dv-parsing}
+
+Whenever data is fed to the data visualization system, it will be handled by
+the |\pgfdata| command, declared in the |datavisualization| module. The command
+is both used to parse data stored in external sources (that is, in external
+files or which is produced on the fly by calling an external command) as well
+as data given inline. A data format does not need to know whether data comes
+from a file or is given inline, the |\pgfdata| command will take care of this.
+
+Since \TeX\ will always read files in a line-wise fashion, data is always fed
+to data format parsers in such a fashion. Thus, even it would make more sense
+for a format to ignore line-breaks, the parser must still handle data given
+line-by-line.
+
+Let us now have a look at how |\pgfdata| works.
+
+\begin{command}{\pgfdata\opt{\oarg{options}\marg{inline data}}}
+ This command is used to feed data to the visualization pipeline. This
+ command can only be used when a data visualization object has been properly
+ setup, see Section~\ref{section-dv-main-setup}.
+
+
+ \medskip
+ \textbf{Basic options.}
+ The |\pgfdata| command may be followed by \meta{options}, which are
+ executed with the path |/pgf/data/|. Depending on these options, the
+ \meta{options} may either be followed by \meta{inline data} or,
+ alternatively, no \meta{inline data} is present and the data is read from
+ an external source.
+
+ The first important option is \meta{source}, which governs which of these
+ two alternatives applies:
+ %
+ \begin{key}{/pgf/data/read from file=\meta{filename} (initially \normalfont empty)}
+ If you set the |read from file| attribute to a non-empty
+ \meta{filename}, the data will be read from this file. In this case, no
+ \meta{inline data} may be present, not even empty curly braces should
+ be provided. If |read from file| is empty, the data must directly
+ follow as \meta{inline data}.
+ %
+\begin{codeexample}[code only]
+% Data is read from two external files:
+\pgfdata[format=table, read from file=file1.csv]
+\pgfdata[format=table, read from file=file2.csv]
+\end{codeexample}
+ %
+\begin{codeexample}[code only]
+% Data is given inline:
+\pgfdata[format=table]
+{
+ x, y
+ 1, 2
+ 2, 3
+}
+\end{codeexample}
+ \end{key}
+ %
+ \begin{key}{/pgf/data/inline}
+ This is a shorthand file |read from file={}|. You can add this to make
+ it clear(er) to the reader that data follows inline.
+ \end{key}
+ %
+ The second important key is |format|, which is used to specify the data
+ format:
+ %
+ \begin{key}{/pgf/data/format=\meta{format} (initially table)}
+ Use this key to locally set the format used for parsing the data. The
+ \meta{format} must be a format that has been previously declared using
+ the |\pgfdeclaredataformat| command. See the reference section for a
+ list of the predefined formats.
+ \end{key}
+ %
+ In case all your data is in a certain format, you may wish to generally set
+ the above key somewhere at the beginning of your file. Alternatively, you
+ can use the following style to setup the |format| key and possibly further
+ keys concerning the data format:
+ %
+ \begin{stylekey}{/pgf/every data}
+ This style is executed by |\pgfdata| before the \meta{options} are
+ parsed.
+
+ Note that the path of this key is just |/pgf/|, not |/pgf/data/|. Also
+ note that \tikzname\ internally sets the value of this key up in such a
+ way that the keys |/tikz/every data| and also
+ |/tikz/data visualization/every data| are executed. The bottom line of
+ this is that when using \tikzname, you should not set this key
+ directly, set |/tikz/every data| instead.
+ \end{stylekey}
+
+ \medskip
+ \textbf{Gathering of the data.}
+ Once the data format and the source have been decided upon, the data is
+ ``gathered''. During this phase the data is not actually parsed in detail,
+ but just gathered so that it can later be parsed during the visualization.
+ There are two different ways in which the data is gathered:
+ %
+ \begin{itemize}
+ \item In case you have specified an external source, the data
+ visualization object is told (by means of invoking the |add data|
+ method) that it should (later) read data from the file specified
+ by the |source| key using the format specified by the |format| key.
+ The file is not read at this point, but only later during the
+ actual visualization.
+ \item Otherwise, namely when data is given inline, depending on which
+ format is used, some catcodes get changed. This is necessary since
+ \TeX's special characters are often not-so-special in a certain
+ format.
+
+ Independently of the format, the end-of-line character (carriage
+ return) is made an active character.
+
+ Finally, the \meta{inline data} is then read as a normal argument
+ and the data visualization object is told that later on it should
+ parse this data using the given format parser. Note that in this
+ case the data visualization object must store the whole data
+ internally.
+ \end{itemize}
+ %
+ In both cases the ``data visualization object'' is the object stored
+ in the |/pgf/data visualization/obj| key.
+
+
+ \medskip
+ \textbf{Parsing of the data.}
+ During the actual data visualization, all code that has been added to the
+ data visualization object by means of the |add data| method is executed
+ several times. It is the job of this code to call the |\pgfdatapoint|
+ method for all data points present in the data.
+
+ When the |\pgfdata| method calls |add data|, the code that is passed to the
+ data visualization object is just a call to internal macros of |\pgfdata|,
+ which are able to parse the data stored in an external file or in the
+ inlined data. Independently of where the data is stored, these macros
+ always do the following:
+ %
+ \begin{enumerate}
+ \item The catcodes are setup according to what the data format
+ requires.
+ \item Format-specific startup code gets called, which can initialize
+ internal variables of the parsing process. (The catcode changes are
+ not part of the startup code since in order to read inline data
+ |\pgfdata| must be able to setup to temporarily setup the catcodes
+ needed later on by the parsers, but since no reading is to be done,
+ no startup code should be called at this point.)
+ \item For each line of the data a format-specific code handler, which
+ depends on the data format, is called. This handler gets the
+ current line as input and should call |\pgfdatapoint| once for each
+ data point that is encoded by this line (a line might define
+ multiple data points or none at all). Empty lines are handled by
+ special format-specific code.
+ \item At the end, format-specific end code is executed.
+ \end{enumerate}
+ %
+ For an example of how this works, see the description of the
+ |\pgfdeclaredataformat| command.
+
+
+ \medskip
+ \textbf{Data sets.}
+ There are three options that allow you to create \emph{data sets}. Such a
+ data set is essentially a macro that stores a pre-parsed set of data that
+ can be used multiple times in subsequent visualizations (or even in the
+ same visualization).
+ %
+ \begin{key}{/pgf/data/new set=\meta{name}}
+ Creates an empty data set called \meta{name}. If a data set of the same
+ name already exists, it is overwritten and made empty. Data sets are
+ global.
+ \end{key}
+ %
+ \begin{key}{/pgf/data/store in set=\meta{name}}
+ When this key is set to any non-empty \meta{name} and if this
+ \meta{name} has previously been used with the |new set| key, then the
+ following happens: For the current |\pgfdata| command, all parsed data
+ is not passed to the rendering pipeline. Instead, the parsed data is
+ appended to the data set \meta{name}. This includes all options parsed
+ to the |\pgfdata| command, which is why neither this key nor the
+ previous key should be passed as options to a |\pgfdata| command.
+ \end{key}
+ %
+ \begin{key}{/pgf/data/use set=\meta{name}}
+ This works similar to |read from file|. When this key is used with a
+ |\pgfdata| command, no inline data may follow. Instead, the data stored
+ in the data set \meta{name} is used.
+ \end{key}
+\end{command}
+
+
+\subsection{Advanced: Defining New Formats}
+\label{section-dv-declaring-formats}
+
+In order to define a new data format you can use the following command, which
+is basic layer command defined in the module |datavisualization|:
+
+\begin{command}{\pgfdeclaredataformat\marg{format name}\marg{catcode
+ code}\marg{startup code}\marg{line arguments}\\\marg{line
+ code}\marg{empty line code}\marg{end code}%
+}
+ This command defines a new data format called \meta{format name}, which can
+ subsequently be used in the |\pgfdata| command. (The \tikzname's |data|
+ maps directly to |\pgfdata|, so the following applies to \tikzname\ as
+ well.)
+
+ As explained in the description of the |\pgfdata| command, when data is
+ being parsed that is formatted according to \meta{format name}, the
+ following happens:
+ %
+ \begin{enumerate}
+ \item The \meta{catcode code} is executed. This code should just
+ contain catcode changes. The \meta{catcode code} will also be
+ executed when inline data is read.
+ \item Next, the \meta{startup code} is executed.
+ \item Next, for each non-empty line of the data, the line is passed to
+ a macro whose argument list is given by \meta{line arguments} and
+ whose body is given by \meta{line code}. The idea is that you can
+ use \TeX's powerful pattern matching capabilities to parse the
+ non-empty lines. See also the below example.
+ \item Empty lines are not processed by the \meta{line code}, but rather
+ by the \meta{empty line code}. Typically, empty lines can simply be
+ ignored and in this case you can let this parameter be empty.
+ \item At the end of the data, the \meta{end code} is executed.
+ \end{enumerate}
+
+ As an example, let us now define a simple data format for reading files
+ formatted in the following manner: Each line should contain a coordinate
+ pair as in |(1.2,3.2)|, so two numbers separated by a comma and surrounded
+ by parentheses. To make things more interesting, suppose that the hash mark
+ symbol can be used to indicate comments. Here is an example of some data
+ given in this format:
+ %
+\begin{codeexample}[code only]
+# This is some data formatted according to the "coordinates" format
+(0,0)
+(0.5,0.25)
+(1,1)
+(1.5,2.25)
+(2,4)
+\end{codeexample}
+
+ A format parser for this format could be defined as follows:
+ %
+\begin{codeexample}[code only]
+\pgfdeclaredataformat{coordinates}
+% First comes the catcode argument. We turn the hash mark into a comment character.
+{\catcode`\#=14\relax}
+% Second comes the startup code. Since we do not need to setup things, we can leave
+% it empty. Note that we could also set it to something like \begingroup, provided we
+% put an \endgroup in the end code
+{}
+% Now comes the arguments for non-empty lines. Well, these should be of the form
+% (#1,#2), so we specify that:
+{(#1,#2)}
+% Now we must do something with a line of this form. We store the #1 argument in
+% /data point/x and #2 in /data point/y. Then we call \pgfdatapoint to create a data point.
+{
+ \pgfkeyssetvalue{/data point/x}{#1}
+ \pgfkeyssetvalue{/data point/y}{#2}
+ \pgfdatapoint
+}
+% We ignore empty lines:
+{}
+% And we also have no end-of-line code.
+{}
+\end{codeexample}
+ %
+ This format could now be used as follows:
+ %
+\begin{codeexample}[code only]
+\begin{tikzpicture}
+ \datavisualization[school book axes, visualize as smooth line]
+ data [format=coordinates] {
+ # This is some data formatted according
+ # to the "coordinates" format
+ (0,0)
+ (0.5,0.25)
+ (1,1)
+ (1.5,2.25)
+ (2,4)
+ };
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{command}
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-formats.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-introduction.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-introduction.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-introduction.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,149 @@
+% Copyright 2019 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section{Introduction to Data Visualization}
+
+\emph{Data visualization} is the process of converting \emph{data points,}
+which typically consist of multiple numerical values, into a graphical
+representation. Examples include the well-known function plots, but pie charts,
+bar diagrams, box plots, or vector fields are also examples of data
+visualizations.
+
+The data visualization subsystem of \pgfname\ takes a general, open approach to
+data visualization. Like everything else in \pgfname, there is a powerful, but
+not-so-easy-to-use basic layer in the data visualization system and a less
+flexible, but much simpler-to-use frontend layer. The present section gives an
+overview of the basic ideas behind the data visualization system.
+
+
+\subsection{Concept: Data Points}
+\label{section-dv-intro-data-points}
+
+The most important input for a data visualization is always raw data. This data
+is typically present in different formats and the data visualization subsystem
+provides methods for reading such formats and also for defining new input
+formats. However, independently of the input format, we may ask what kind of
+data the data visualization subsystem should be able to process. For
+two-dimensional plots we need lists of pairs of real numbers. For a bar plot we
+usually need a list of numbers, possibly together with some colors and labels.
+For a surface plot we need a matrix of triples of real numbers. For a vector
+field we need even more complex data.
+
+The data visualization subsystem makes no assumption concerning which kind of
+data is being processed. Instead, the whole ``rendering pipeline'' is centered
+around a concept called the \emph{data point}. Conceptually, a data point is an
+arbitrarily complex record that represents one piece of data that should be
+visualized. Data points are \emph{not} just coordinates in the plane or the
+numerical values that need to be visualized. Rather, they represent the basic
+units of the data that needs to be visualized.
+
+Consider the following example: In an experiment we drive a car along a road
+and have different measurement instruments installed. We measure the position
+of the car, the time, the speed, the direction the car is heading, the
+acceleration, and perhaps some further values. A data point would consist of a
+record consisting of a timestamp together with the current position of the car
+(presumably two or three numbers), the speed vector (another two or three
+numbers), the acceleration (another two or three numbers), and perhaps the
+label text of the current experiment.
+
+Data points should be ``information rich''. They might even contain more
+information than what will actually be visualized. It is the job of the
+rendering pipeline to pick out the information relevant to one particular data
+visualization -- another visualization of the same data might pick different
+aspects of the data points, thereby hopefully allowing new insights into the
+data.
+
+Technically, there is no special data structure for data points. Rather, when a
+special macro called |\pgfdatapoint| is called, the ``totality'' of all
+currently set keys with the |/data point/| prefix in the current scope forms
+the data point. This is both a very general approach and quite fast since no
+extra data structures need to be created.
+
+
+\subsection{Concept: Visualization Pipeline}
+
+The \emph{visualization pipeline} is a series of actions that are performed on
+the to-be-visualized data. The data is presented to the visualization pipeline
+in the form of a long stream of complex data points. The visualization
+pipeline makes several passes over this stream of data points. During the first
+pass(es), called the \emph{survey phase(s)}, information is gathered about the
+data points such as minimal and maximal values, which can be useful for
+automatic fitting of the data into a given area. In the main pass over the
+data, called the \emph{visualization phase}, the data points are actually
+visualized, for instance in the form of lines or points.
+
+Like as for data points, the visualization pipeline makes no assumptions
+concerning what kind of visualization is desired. Indeed, one could even use it
+to produce a plain-text table. This flexibility is achieved by extensive use of
+objects and signals: When a data visualization starts, a number of signals (see
+Section~\ref{section-signals} for an introduction to signals) are initialized.
+Then, numerous ``visualization objects'' are created that listen to these
+signals. These objects are all involved in processing the data points. For
+instance, the job of an |interval mapper| object is to map one attribute of a
+data point, such as a car's velocity, to another, such as the $y$-axis of a
+plot. For each data point the different signals are raised in a certain order
+and the different visualization objects now have a chance of preparing the data
+point for the actual visualization. Continuing the above example, there might
+be a second |interval mapper| that takes the computed $y$-position and applies
+a logarithm to it, because a log-plot was requested. Then another mapper, this
+time a |polar mapper| might be used to map everything to polar coordinates.
+Following this, a |plot mark visualizer| might actually draw something at the
+computed position.
+
+The whole idea behind the rendering pipeline is that new kinds of data
+visualizations can be implemented, ideally, just by adding one or two new
+objects to the visualization pipeline. Furthermore, different kinds of plots
+can be combined in novel ways in this manner, which is usually very
+hard to do otherwise.
+For instance, the visualization pipeline makes it easy to create, say,
+polar-semilog-box-plots. At first sight, such new kinds of plots may seem
+frivolous, but data visualization is all about gaining insights into the data
+from as many different angles as possible.
+
+Naturally, creating new classes and objects for the rendering pipeline is not
+trivial, so most users will just use the existing classes, which should, thus,
+be as flexible as possible. But even when one only intends to use existing
+classes, it is still tricky to setup the pipeline correctly since the ordering
+is obviously important and since things like axes and ticks need to be
+configured and taken care of. For this reason, the frontend libraries provide
+preconfigured rendering pipelines so that one can simply say that a data
+visualization should look like a |line plot| with |school book axes| or with
+|scientific axes|, which selects a certain visualization pipeline that is
+appropriate for this kind of plot:
+%
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\begin{tikzpicture}[scale=.7]
+ \datavisualization [school book axes, visualize as smooth line]
+ data [format=function] {
+ var x : interval [-2:2];
+ func y = \value x*\value x + 1;
+ };
+\end{tikzpicture}
+\end{codeexample}
+%
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\begin{tikzpicture}[scale=.7]
+ \datavisualization [scientific axes, visualize as smooth line]
+ data [format=function] {
+ var x : interval [-2:2];
+ func y = \value x*\value x + 1;
+ };
+\end{tikzpicture}
+\end{codeexample}
+%
+One must still configure such a plot (choose styles and themes and also specify
+which attributes of a data point should be used), but on the whole the plot is
+quite simple to specify.
+
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "pgfmanual"
+%%% End:
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-introduction.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-main.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-main.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-main.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,828 @@
+% Copyright 2019 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section{Creating Data Visualizations}
+\label{section-dv-main}
+\label{section-dv-main-setup}
+
+\subsection{Overview}
+
+The \todosp{why two labels? The first doesn't seem to be used.} present section
+explains how a data visualization is created in \tikzname. For this, you need
+to include the |datavisualization| library and then use the command
+|\datavisualization| whose syntax is explained in the rest of the present
+section. This command is part of the following library:
+
+\begin{tikzlibrary}{datavisualization}
+ This library must be loaded if you wish to use the |\datavisualization|
+ command. It defines all styles needed to create basic data visualizations;
+ additional, more specialized libraries need to be loaded for more advanced
+ features.
+\end{tikzlibrary}
+
+In order to visualize, you basically need to do three things:
+%
+\begin{enumerate}
+ \item You need to select what kind of plot you would like to have (a
+ ``school book plot'' or a ``scientific 2d plot'' or a ``scientific
+ spherical plot'' etc.). This is done by passing an option to the
+ |\datavisualization| command that selects this kind of plot.
+ \item You need to provide data points, which is done using the |data|
+ command.
+ \item Additionally, you can add options that give you more fine-grained
+ control over the way the visualization will look. You can configure the
+ number of ticks and grid lines, where the labels are placed, the
+ colors, or the fonts. Indeed, since the data visualization engine
+ internally uses \tikzname-styles, you can have extremely fine-grained
+ control over how a plot will look like.
+\end{enumerate}
+
+The syntax of the |\datavisualization| command is designed in such a way that
+you only need to provide very few options to create plots that ``look good by
+default''.
+
+This section is structured as follows: First, the philosophy behind concepts
+like ``data points'', ``axes'', or ``visualizers'' is explained. Each of these
+concepts is further detailed in later section. Then, the syntax of the
+|\datavisualization| command is covered. The reference sections explain which
+predefined plot kinds are available.
+
+
+\subsection{Concept: Data Points and Data Formats}
+
+As explained in Section~\ref{section-dv-intro-data-points}, data points are the
+basic entities that are processed by the data visualization engine. In order to
+specify data points, you use the |data| command, whose syntax is explained in
+more detail in Section~\ref{section-dv-data-syntax}. The |data| command allows
+you to either specify points ``inline'', directly inside your \TeX-file; or you
+can specify the name of file that contains the data points.
+
+\medskip
+\textbf{Specifying data points.}
+Data points can be formatted in different ways. For instance, in the so called
+\emph{comma separated values} format, there is one line for each data point and
+the different attributes of a data point are separated by commas. Another
+common format is to specify data points using the so called \emph{key--value}
+format, where on each line the different attributes of a data point are set
+using a comma-separated list of strings of the form |attribute=value|.
+
+Here are two examples, where similar data is given in different formats:
+%
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\begin{tikzpicture}
+ \datavisualization [school book axes, visualize as smooth line]
+ data {
+ x, y
+ -1.5, 2.25
+ -1, 1
+ -.5, .25
+ 0, 0
+ .5, .25
+ 1, 1
+ 1.5, 2.25
+ };
+\end{tikzpicture}
+\end{codeexample}
+
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\begin{tikzpicture}
+ \datavisualization [school book axes, visualize as smooth line]
+ data [format=function] {
+ var x : interval [-1.5:1.5] samples 7;
+ func y = \value x*\value x;
+ };
+\end{tikzpicture}
+\end{codeexample}
+
+In the first example, no format needed to be specified explicitly since the
+default format is the one used for the data following the |data| keyword: A
+list of comma-separated values, where each line represents a data point.
+
+\medskip
+\textbf{Number accuracy.}\label{section-dv-expressions}
+Data visualizations typically demand a much higher accuracy and range of values
+than \TeX\ provides: \TeX\ numbers are limited to 13 bits for the integer part
+and 16 bits for the fractional part. Because of this, the data visualization
+engine does not use \pgfname's standard representation of numbers and \TeX\
+dimensions and does not use the standard parser when reading numbers in a
+data point. Instead, the |fpu| library, described in
+Section~\ref{section-library-fpu}, is used to handle numbers.
+
+This use of the |fpu| library has several effects that users of the data
+visualization system should be aware of:
+%
+\begin{enumerate}
+ \item You can use numbers like |100000000000000| or |0.00000000001| in
+ data points.
+ \item Since the |fpu| library does not support advanced parsing, you
+ currently \emph{cannot} write things like |3+2| in a data point number.
+ This will result in an error.
+ \item However, there is a loop-hole: If a ``number'' in a data point starts
+ with a parenthesis, the value between the parentheses \emph{is} parsed
+ using the normal parser:
+ %
+ \begin{itemize}
+ \item |100000| is allowed.
+ \item |2+3| yields an error.
+ \item |(2+3)| is allowed and evaluates to |5|.
+ \item |(100000)| yields an error since $100\,000$ is beyond the
+ normal parser's precision.
+ \end{itemize}
+ %
+ The bottom line is that any normal calculations should be set inside
+ round parentheses, while large numbers should not be surrounded by
+ parentheses. Hopefully, in the future, these restrictions will be
+ lifted.
+\end{enumerate}
+
+Section~\ref{section-dv-formats} gives an in-depth coverage of the available
+data formats and explains how new data formats can be defined.
+
+
+\subsection{Concept: Axes, Ticks, and Grids}
+
+Most plots have two or three axes: A horizontal axis usually called the
+$x$-axis, a vertical axis called the $y$-axis, and possibly some axis pointing
+in a sloped direction called the $z$-axis. Axes are usually drawn as lines with
+\emph{ticks} indicating interesting positions on the axes. The data
+visualization engine gives you detailed control over where these ticks are
+rendered and how many of them are used. Great care is taken to ensure that the
+position of ticks are chosen well by default.
+
+From the point of view of the data visualization engine, axes are a somewhat
+more general concept than ``just'' lines that point ``along'' some dimension:
+The data visualization engine uses axes to visualize any change of an attribute
+by varying the position of data points in the plane. For instance, in a polar
+plot, there is an ``axis'' for the angle and another ``axis'' for the distance
+if the point from the center. Clearly these axes vary the position of data
+points in the plane according to some attribute of the data points; but just as
+clearly they do not point in any ``direction''.
+
+A great benefit of this approach is that the powerful methods for specifying
+and automatic inference of ``good'' positions for ticks or grid lines apply to
+all sorts of situations. For instance, you can use it to automatically put
+ticks and grid lines at well-chosen angles of a polar plot.
+
+Typically, you will not need to specify axes explicitly. Rather, predefined
+styles take care of this for you:
+%
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\begin{tikzpicture}
+ \datavisualization [
+ scientific axes,
+ x axis={length=3cm, ticks=few},
+ visualize as smooth line
+ ]
+ data [format=function] {
+ var x : interval [-1.5:1.5] samples 7;
+ func y = \value x*\value x;
+ };
+\end{tikzpicture}
+\end{codeexample}
+
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\begin{tikzpicture}
+ \datavisualization [
+ scientific axes=clean,
+ x axis={length=3cm, ticks=few},
+ all axes={grid},
+ visualize as smooth line
+ ]
+ data [format=function] {
+ var x : interval [-1.5:1.5] samples 7;
+ func y = \value x*\value x;
+ };
+\end{tikzpicture}
+\end{codeexample}
+
+Section~\ref{section-dv-axes} explains in more detail how axes, ticks, and grid
+lines can be chosen and configured.
+
+
+\subsection{Concept: Visualizers}
+
+Data points and axes specify \emph{what} is visualized and \emph{where}. A
+\emph{visualizer} specifies \emph{how} they are visualized. One of the most
+common visualizers is a \emph{line visualizer} which connects the positions of
+the data points in the plane using a line. Another common visualizer is the
+\emph{scatter plot visualizer} where small marks are drawn at the positions of
+the data points. More advanced visualizers include, say, box plot visualizers
+or pie chart visualizers.
+%
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\begin{tikzpicture}
+ \datavisualization [
+ scientific axes=clean,
+ x axis={length=3cm, ticks=few},
+ visualize as smooth line
+ ]
+ data [format=function] {
+ var x : interval [-1.5:1.5] samples 7;
+ func y = \value x*\value x;
+ };
+\end{tikzpicture}
+\end{codeexample}
+%
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\begin{tikzpicture}
+ \datavisualization [
+ scientific axes=clean,
+ x axis={length=3cm, ticks=few},
+ visualize as scatter
+ ]
+ data [format=function] {
+ var x : interval [-1.5:1.5] samples 7;
+ func y = \value x*\value x;
+ };
+\end{tikzpicture}
+\end{codeexample}
+
+Section~\ref{section-dv-visualizers} provides more information on visualizers
+as well as reference lists.
+
+
+\subsection{Concept: Style Sheets and Legends}
+
+A single data visualizations may use more than one visualizer. For instance, if
+you wish to create a plot containing several lines, a separate visualizer is
+used for each line. In this case, two problems arise:
+%
+\begin{enumerate}
+ \item You may wish to make it easy for the reader to differentiate between
+ the different visualizers. For instance, one line should be black,
+ another should be red, and another blue. Alternatively, you might wish
+ one line to be solid, another to be dashed, and a third to be dotted.
+
+ Specifying such styles is trickier than one might expect; experience
+ shows that many plots use ill-chosen and inconsistent styling. For this
+ reason, the data visualization introduces the notion of \emph{style
+ sheets} for visualizers and comes with some well-designed predefined
+ style sheets.
+ \item You may wish to add information concerning what the different
+ visualizers represent. This is typically done using a legend, but it is
+ even better to add labels directly inside the visualization. Both
+ approaches are supported.
+\end{enumerate}
+
+An example where three functions are plotted and a legend is added is shown
+below. Two style sheets are used so that \emph{both} the coloring and the
+dashing is varied.
+%
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\begin{tikzpicture}[baseline]
+ \datavisualization [ scientific axes=clean,
+ y axis=grid,
+ visualize as smooth line/.list={sin,cos,tan},
+ style sheet=strong colors,
+ style sheet=vary dashing,
+ sin={label in legend={text=$\sin x$}},
+ cos={label in legend={text=$\cos x$}},
+ tan={label in legend={text=$\tan x$}},
+ data/format=function ]
+ data [set=sin] {
+ var x : interval [-0.5*pi:4];
+ func y = sin(\value x r);
+ }
+ data [set=cos] {
+ var x : interval [-0.5*pi:4];
+ func y = cos(\value x r);
+ }
+ data [set=tan] {
+ var x : interval [-0.3*pi:.3*pi];
+ func y = tan(\value x r);
+ };
+\end{tikzpicture}
+\end{codeexample}
+
+Section~\ref{section-dv-style-sheets} details style sheets and legends.
+
+
+\subsection{Usage}
+\label{section-dv-data-syntax}
+
+Inside a \tikzname\ picture you can use the |\datavisualization| command to
+create a data visualization. You can use this command several times in a
+picture to create pictures containing multiple data visualizations.
+
+\begin{command}{\datavisualization\opt{\oarg{data visualization options}}\meta{data specification}|;|}
+ This command is available only inside a |{tikzpicture}| environment.
+
+ The \meta{data visualization options} are used to configure the data
+ visualization, that is, how the data is to be depicted. The options are
+ executed with the path prefix |/tikz/data visualization|. This means that
+ normal \tikzname\ options like |thin| or |red| cannot be used here. Rather,
+ a large number of options specific to data visualizations are available.
+
+ As a minimum, you should specify at least two options: First, you should
+ use an option that selects an axis system that is appropriate for your
+ plot. Typical possible keys are |school book axes| or |scientific axes|,
+ detailed information on them can be found in Section~\ref{section-dv-axes}.
+
+ Second, you use an option to select \emph{how} the data should be
+ visualized. This is done using a key like |visualize as line| which will,
+ as the name suggests, visualize the data by connecting data points in the
+ plane using a line. Similarly, |visualize as smooth cycle| will try to fit
+ a smooth cycle through the data points. Detailed information on possible
+ visualizers can be found in Section~\ref{section-dv-visualizers}.
+
+ Following these options, the \meta{data specification} is used to provide
+ the actual to-be-visualized data. The syntax is somewhat similar to
+ commands like |\path|: The \meta{data specification} is a sequence of
+ keywords followed by local options and parameters, terminated with a
+ semicolon. (Indeed, like for the |\path| command, the \meta{data
+ visualizers options} need not be specified at the beginning, but additional
+ option surrounded by square brackets may be given anywhere inside the
+ \meta{data specification}.)
+
+ The different possible keywords inside the \meta{data specification} are
+ explained in the following.
+\end{command}
+
+\begin{datavisualizationoperation}{data}{\opt{\oarg{options}}\opt{\marg{inline data}}}
+ This command is used to specify data for the data visualization. It can be
+ used several times inside a single visualization and each time the
+ to-be-read data may have a different format, but the data will be
+ visualized as if it have been specified inside a single |data| command.
+
+ The behavior of the |data| command depends on whether the \meta{inline
+ data} is present. If it is not present, the \meta{options} must be used to
+ specify a source file from which the data is read; if the \meta{inline
+ data} is present no file will be used, instead the data should directly
+ reside inside the \TeX-file and be given between the curly braces
+ surrounding the \meta{inline data}.
+
+ The \meta{options} are executed with the prefix |/pgf/data|. The following
+ options are always available:
+ %
+ \begin{key}{/pgf/data/read from file=\meta{filename} (initially \normalfont empty)}
+ If you set the |source| attribute to a non-empty \meta{filename}, the
+ data will be read from this file. In this case, no \meta{inline data}
+ may be present, not even empty curly braces should be provided.
+ %
+\begin{codeexample}[code only]
+\datavisualization ...
+ data [read from file=file1.csv]
+ data [read from file=file2.csv];
+\end{codeexample}
+ %
+ The other way round, if |read from file| is empty, the data must
+ directly follow as \meta{inline data}.
+ %
+\begin{codeexample}[code only]
+\datavisualization ...
+ data {
+ x, y
+ 1, 2
+ 2, 3
+ };
+\end{codeexample}
+ \end{key}
+ %
+ The second important key is |format|, which is used to specify the data
+ format:
+ %
+ \begin{key}{/pgf/data/format=\meta{format} (initially table)}
+ Use this key to locally set the format used for parsing the data, see
+ Section~\ref{section-dv-formats} for a list of predefined formats.
+
+ The default format is the |table|-format, also known as
+ ``comma-separated values''. The first line contains names of attributes
+ separated by commas, all following lines constitute a data point where
+ the attributes are given by the comma-separated values in that line.
+ \end{key}
+
+
+ \medskip
+ \textbf{Presetting attributes.}
+ Normally, the inline data or the external data contains for each data point
+ the values of the different attributes. However, sometimes you may also
+ wish to set an attribute to a fixed value for all data points of a data
+ set. Suppose, for instance, that you have to source files
+ |experiment007.csv| and |experiment023.csv| and you would like that for all
+ data points of the first file the attribute |/data point/experiment id| is
+ set to 7 while for the data points of the second file they are set to 23.
+ In this case, you can specify the desired settings using an absolute path
+ inside the \meta{options}. The effect will be local to the current |data|
+ command:
+ %
+\begin{codeexample}[code only]
+\datavisualization...
+ data [/data point/experiment=7, read from file=experiment007.csv]
+ data [/data point/experiment=23, read from file=experiment023.csv];
+\end{codeexample}
+
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\tikz
+ \datavisualization [school book axes, visualize as line]
+ data [/data point/x=1] {
+ y
+ 1
+ 2
+ }
+ data [/data point/x=2] {
+ y
+ 2
+ 0.5
+ };
+\end{codeexample}
+
+
+ \medskip
+ \textbf{Setting options for multiple |data| commands.}
+ You may wish to generally set the format once and for all. This can be done
+ by using the following key:
+ %
+ \begin{stylekey}{/tikz/every data}
+ This key is executed for every |data| command.
+ \end{stylekey}
+
+ Another way of passing options to multiple |data| commands is to use the
+ following facility: Whenever an option with the path
+ |/tikz/data visualization/data| is used, the path will be remapped to
+ |/pgf/data|. This means, in particular, that you can pass an option like
+ |data/format=table| to the |\datavisualization| command to set the data
+ format for all |data| commands of the data visualization.
+
+
+ \medskip
+ \textbf{Parsing inline data.}
+ When you specify data inline, \TeX\ needs to read the data
+ ``line-by-line'', while \TeX\ normally largely ignores end-of-line
+ characters. For this reason, the data visualization system temporarily
+ changes the meaning of the end-of-line character. This is only possible if
+ \TeX\ has not already processed the data in some other way (namely as the
+ parameter to some macro).
+
+ The bottom line is that you cannot use inline data when the whole
+ |\datavisualization| command is passed as a parameter to some macro that is
+ not setup to handle ``fragile'' code. For instance, in a \textsc{beamer}
+ |frame| you need to add the |fragile| option when a data visualization
+ contains inline data.
+
+ The problem does not arise when an external data |source| is specified.
+\end{datavisualizationoperation}
+
+\begin{datavisualizationoperation}{data point}{\opt{\oarg{options}}}
+ This command is used to specify data a single data point. The
+ \meta{options} are simply executed with the path |/data point| and then a
+ data point is created. This means that inside the \meta{options} you just
+ specify the values of all attributes in key--value syntax.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\tikz \datavisualization [school book axes, visualize as line]
+ data point [x=1, y=1] data point [x=1, y=2]
+ data point [x=2, y=2] data point [x=2, y=0.5];
+\end{codeexample}
+ %
+\end{datavisualizationoperation}
+
+\begin{key}{/tikz/data visualization/data point=\meta{options}}
+ This key is the ``key version'' of the previous command. The difference is
+ that this key can be used internally inside styles.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\tikzdatavisualizationset{
+ horizontal/.style={
+ data point={x=#1, y=1}, data point={x=#1, y=2}},
+}
+\tikz \datavisualization
+[ school book axes, visualize as line,
+ horizontal=1,
+ horizontal=2 ];
+\end{codeexample}
+ %
+\end{key}
+
+\begin{datavisualizationoperation}{data group}{\opt{\oarg{options}}\marg{name}\opt{|+=|\marg{data specifications}}}
+ You can store a whole \meta{data specification} in a \emph{data group}.
+ This allows you to reuse data in multiple places without having to write
+ the data to an external file.
+
+ The syntax of this command comes in the following three variants:
+ %
+ \begin{itemize}
+ \item |data group| \opt{\oarg{options}} \marg{name} |=| \marg{data
+ specifications}
+ \item |data group| \opt{\oarg{options}} \marg{name} |+=| \marg{data
+ specifications}
+ \item |data group| \opt{\oarg{options}} \marg{name}
+ \end{itemize}
+ %
+ In the first case, a new data group called \meta{name} is created (an
+ existing data group of the same name will be erased) and the following
+ \meta{data specifications} is stored in this data group. The data group
+ will not be fed to the rendering pipeline, but it is parsed at this point
+ as if it were. The defined data group is defined globally, so you can used
+ it in subsequent visualizations. The \meta{options} are saved with the
+ parsed \meta{data specifications}.
+
+ In the second case, an already existing data group is extended by adding
+ the \meta{data specifications} to it.
+
+ In the third case (detected by noting that the \meta{name} is neither
+ followed by an equal sign nor a plus sign), the contents of the previously
+ defined data group \meta{name} is inserted. The \meta{options} are also
+ executed.
+
+ Let is now first create a data group. Note that nothing is drawn since the
+ ``dummy'' data visualization is empty and used only for the definition of
+ the data group.
+ %
+\begin{codeexample}[setup code]
+\tikz \datavisualization data group {points} = {
+ data {
+ x, y
+ 0, 1
+ 1, 2
+ 2, 2
+ 5, 1
+ 2, 0
+ 1, 1
+ }
+};
+\end{codeexample}
+
+ We can now use this data in different plots:
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization}}]
+\tikz \datavisualization [school book axes, visualize as line] data group {points};
+\qquad
+\tikz \datavisualization [scientific axes=clean, visualize as line] data group {points};
+\end{codeexample}
+ %
+\end{datavisualizationoperation}
+
+\begin{datavisualizationoperation}{scope}{\opt{\oarg{options}}\marg{data specification}}
+ Scopes can be used to nest hierarchical data sets. The \meta{options} will
+ be executed with the path |/pgf/data| and will only apply to the data sets
+ specified inside the \meta{data specification}, which may contain |data| or
+ |scope| commands once more:
+ %
+\begin{codeexample}[code only]
+\datavisualization...
+ scope [/data point/experiment=7]
+ {
+ data [read from file=experiment007-part1.csv]
+ data [read from file=experiment007-part2.csv]
+ data [read from file=experiment007-part3.csv]
+ }
+ scope [/data point/experiment=23, format=foo]
+ {
+ data [read from file=experiment023-part1.foo]
+ data [read from file=experiment023-part2.foo]
+ };
+\end{codeexample}
+ %
+\end{datavisualizationoperation}
+
+\begin{datavisualizationoperation}{info}{\opt{\oarg{options}}\marg{code}}
+ This command will execute normal \tikzname\ \meta{code} at the end of a
+ data visualization. The \meta{options} are executed with the normal path
+ |/tikz/|.
+
+ The only difference between this command and just giving the \meta{code}
+ directly following the data visualization is that inside the \meta{code}
+ following an |info| command you still have access to the coordinate system
+ of the data visualization. In sharp contrast, \tikzname\ code given after a
+ data visualization can no longer access this coordinate system.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\begin{tikzpicture}[baseline]
+ \datavisualization [ school book axes, visualize as line ]
+ data [format=function] {
+ var x : interval [-0.1*pi:2];
+ func y = sin(\value x r);
+ }
+ info {
+ \draw [red] (visualization cs: x={(.5*pi)}, y=1) circle [radius=1pt]
+ node [above,font=\footnotesize] {extremal point};
+ };
+\end{tikzpicture}
+\end{codeexample}
+
+ As can be seen, inside a data visualization a special coordinate system is
+ available:
+
+ \begin{coordinatesystem}{visualization}
+ As for other coordinate systems, the syntax is
+ \declare{|(visualization cs:|\meta{list of attribute-value pairs}|)|}.
+ The effect is the following: For each pair
+ \meta{attribute}|=|\meta{value} in the \meta{list} the key
+ |/data point/|\meta{attribute} is set to \meta{value}. Then, it is
+ computed where the resulting data point ``would lie'' on the canvas
+ (however, no data point is passed to the visualizers).
+ \end{coordinatesystem}
+\end{datavisualizationoperation}
+
+\begin{datavisualizationoperation}{info'}{\opt{\oarg{options}}\marg{code}}
+ This command works like |info|, only the \meta{code} will be executed just
+ before the visualization is done. This allows you to draw things
+ \emph{behind} the visualization.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\begin{tikzpicture}[baseline]
+ \datavisualization [ school book axes, visualize as line ]
+ data [format=function] {
+ var x : interval [-0.1*pi:2];
+ func y = sin(\value x r);
+ }
+ info' {
+ \fill [red] (visualization cs: x={(.5*pi)}, y=1) circle [radius=2mm];
+ };
+\end{tikzpicture}
+\end{codeexample}
+ %
+\end{datavisualizationoperation}
+
+\label{section-dv-bounding-box}%
+\begin{predefinednode}{data visualization bounding box}
+ This rectangle node stores a bounding box of the data visualization that is
+ currently being constructed. This node can be useful inside |info| commands
+ or when labels need to be added.
+\end{predefinednode}
+
+\begin{predefinednode}{data bounding box}
+ This rectangle node is similar to |data visualization bounding box|, but it
+ keeps track only of the actual data. The spaces needed for grid lines,
+ ticks, axis labels, tick labels, and all other information that is not part
+ of the actual data is not part of this box.
+\end{predefinednode}
+
+
+\subsection{Advanced: Executing User Code During a Data Visualization}
+\label{section-dv-user-code}
+
+The following keys can be passed to the |\datavisualization| command and allow
+you to execute some code at some special time during the data visualization
+process. For details of the process and on which signals are emitted when, see
+Section~\ref{section-dv-backend}.
+
+\begin{key}{/tikz/data visualization/before survey=\meta{code}}
+ The \meta{code} is passed to the |before survey| method of the data
+ visualization object and then executed at the appropriate time (see
+ Section~\ref{section-dv-backend} for details).
+
+ The following commands work likewise:
+\end{key}
+%
+\begin{key}{/tikz/data visualization/at start survey=\meta{code}}
+\end{key}
+%
+\begin{key}{/tikz/data visualization/at end survey=\meta{code}}
+\end{key}
+%
+\begin{key}{/tikz/data visualization/after survey=\meta{code}}
+\end{key}
+%
+\begin{key}{/tikz/data visualization/before visualization=\meta{code}}
+\end{key}
+%
+\begin{key}{/tikz/data visualization/at start visualization=\meta{code}}
+\end{key}
+%
+\begin{key}{/tikz/data visualization/at end visualization=\meta{code}}
+\end{key}
+%
+\begin{key}{/tikz/data visualization/after visualization=\meta{code}}
+\end{key}
+
+
+\subsection{Advanced: Creating New Objects}
+
+You will need the following key only when you wish to create new rendering
+pipelines from scratch -- instead of modifying an existing pipeline as you
+would normally do. In the following it is assumed that you are familiar with
+the concepts of Section~\ref{section-dv-backend}.
+
+\begin{key}{/tikz/data visualization/new object=\meta{options}}
+ This key serves two purposes:
+ %
+ \begin{enumerate}
+ \item This method makes it easy to create a new object as part of the
+ rendering pipeline, using \meta{options} to specify arguments
+ rather that directly calling |\pgfoonew|. Since you have the full
+ power of the keys mechanism at your disposal, it is easy, for
+ instance, to control whether or not parameters to the constructor
+ are expanded or not.
+ \item The object is not created immediately, but only just before the
+ visualization starts. This allows you to specify that an object
+ must be created, but the parameter values of for its constructor
+ may depend on keys that are not yet set. A typical application is
+ the creating of an axis object: When you say |scientific axes|, the
+ |new object| command is used internally to create two objects
+ representing these axes. However, keys like |x={length=5cm}| can
+ only \emph{later} be used to specify the parameters that need to be
+ passed to the constructor of the objects.
+ \end{enumerate}
+
+ The following keys may be used inside the \meta{options}:
+ %
+ \begin{key}{/tikz/data visualization/class=\meta{class name}}
+ The class of the to-be-created object.
+ \end{key}
+ %
+ \begin{key}{/tikz/data visualization/when=\meta{phase name} (initially before survey)}
+ This key is used to specify when the object is to be created. As
+ described above, the object is not created immediately, but at some
+ time during the rendering process. You can specify any of the phases
+ defined by the data visualization object, see
+ Section~\ref{section-dv-backend} for details.
+ \end{key}
+ %
+ \begin{key}{/tikz/data visualization/store=\meta{key name}}
+ If the \meta{key name} is not empty, once the object has been created,
+ a handle to the object will be stored in \meta{key name}. If a handle
+ is already stored in \meta{key name}, the object is not created twice.
+ \end{key}
+ %
+ \begin{key}{/tikz/data visualization/before creation=\meta{code}}
+ This code is executed right before the object is finally created. It
+ can be used to compute values that are then passed to the constructor.
+ \end{key}
+ %
+ \begin{key}{/tikz/data visualization/after creation=\meta{code}}
+ This code is executed right after the object has just been created. A
+ handle to the just-created object is available in |\tikzdvobj|.
+ \end{key}
+ %
+ \begin{key}{/tikz/data visualization/arg1=\meta{value}}
+ The value to be passed as the first parameter to the constructor.
+ Similarly, the keys |arg2| to |arg8| specify further parameters passed.
+ Naturally, only as many arguments are passed as parameters are set.
+ Here is an example:
+ %
+\begin{codeexample}[code only]
+\tikzdatavisualizationset{
+ new object={
+ class = example class,
+ arg1 = foo,
+ arg2 = \bar
+ }
+}
+\end{codeexample}
+ %
+ causes the following object creation code to be executed later on:
+ %
+\begin{codeexample}[code only]
+\pgfoonew \tikzdvobj=new example class(foo,\bar)
+\end{codeexample}
+ %
+ Note that you key mechanisms like |.expand once| to pass the value of a
+ macro instead of the macro itself:
+ %
+\begin{codeexample}[code only]
+\tikzdatavisualizationset{
+ new object={
+ class = example class,
+ arg1 = foo,
+ arg2/.expand once = \bar
+ }
+}
+\end{codeexample}
+ %
+ Now, if |\bar| is set to |This \emph{is} it.|\@ at the moment to object
+ is created later on, the following object creation code is executed:
+ %
+\begin{codeexample}[code only]
+\pgfoonew \tikzdvobj=new example class(foo,This \emph{is} it)
+\end{codeexample}
+ \end{key}
+
+ \begin{key}{/tikz/data visualization/arg1 from key=\meta{key}}
+ Works like the |arg1|, only the value that is passed to the constructor
+ is the current value of the specified \meta{key} at the moment when the
+ object is created.
+ %
+\begin{codeexample}[code only]
+\tikzdatavisualizationset{
+ new object={
+ class = example class,
+ arg1 from key = /tikz/some key
+ }
+}
+\tikzset{some key/.initial=foobar}
+\end{codeexample}
+ %
+ causes the following to be executed:
+ %
+\begin{codeexample}[code only]
+\pgfoonew \tikzdvobj=new example class(foobar)
+\end{codeexample}
+ %
+ Naturally, the keys |arg2 from key| to |arg8 from key| are also
+ provided.
+ \end{key}
+
+ \begin{key}{/tikz/data visualization/arg1 handle from key=\meta{key}}
+ Works like the |arg1 from key|, only the key must store an object and
+ instead of the object a handle to the object is passed to the
+ constructor.
+ \end{key}
+\end{key}
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-main.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-polar.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-polar.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-polar.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,458 @@
+% Copyright 2019 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section{Polar Axes}
+\label{section-dv-polar}
+
+\subsection{Overview}
+
+\begin{tikzlibrary}{datavisualization.polar}
+ This library contains keys that allow you to create plots in a polar axis
+ system is used.
+\end{tikzlibrary}
+
+In a \emph{polar axis system} two attributes are visualized by displacing a
+data point as follows: One attribute is used to compute a an angle (a
+direction) while a second attribute is used as a radius (a distance). The angle
+can be measured in degrees, radians, or can be scaled arbitrarily.
+%
+\begin{codeexample}[
+ width=8.5cm,
+ preamble={\usetikzlibrary{
+ datavisualization.formats.functions,
+ datavisualization.polar,
+}},
+]
+\tikz \datavisualization [
+ scientific polar axes={0 to pi, clean},
+ all axes=grid,
+ style sheet=vary hue,
+ legend=below
+ ]
+ [visualize as smooth line=sin,
+ sin={label in legend={text=$1+\sin \alpha$}}]
+ data [format=function] {
+ var angle : interval [0:pi];
+ func radius = sin(\value{angle}r) + 1;
+ }
+ [visualize as smooth line=cos,
+ cos={label in legend={text=$1+\cos\alpha$}}]
+ data [format=function] {
+ var angle : interval [0:pi];
+ func radius = cos(\value{angle}r) + 1;
+ };
+\end{codeexample}
+
+Most of the time, in order to create a polar axis system, you will just use the
+|scientific polar axes| key, which takes a number of options that allow you to
+configure the axis system in greater detail. This key is documented in
+Section~\ref{section-dv-sci-polar-axes}. Internally, this key uses more low
+level keys which are documented in the en suite sections.
+
+It is worthwhile to note that the axes of a polar axis system are, still,
+normal axes of the data visualization system. In particular, all the
+configurations possible for, say, Cartesian axes also apply to the ``angle
+axis'' and the ``radius axis'' of a polar axis system. For instance, you can
+could make both axes logarithmic or style their ticks:
+%
+\begin{codeexample}[preamble={\usetikzlibrary{
+ datavisualization.formats.functions,
+ datavisualization.polar,
+}}]
+\tikz[baseline] \datavisualization [
+ scientific axes={clean},
+ x axis={attribute=angle, ticks={minor steps between steps=4}},
+ y axis={attribute=radius, ticks={some, style=red!80!black}},
+ all axes=grid,
+ visualize as smooth line=sin]
+ data [format=function] {
+ var t : interval [-3:3];
+ func angle = exp(\value t);
+ func radius = \value{t}*\value{t};
+ };
+\qquad
+\tikz[baseline] \datavisualization [
+ scientific polar axes={right half clockwise, clean},
+ angle axis={logarithmic,
+ ticks={
+ minor steps between steps=8,
+ major also at/.list={2,3,4,5,15,20}}},
+ radius axis={ticks={some, style=red!80!black}},
+ all axes=grid,
+ visualize as smooth line=sin]
+ data [format=function] {
+ var t : interval [-3:3];
+ func angle = exp(\value t);
+ func radius = \value{t}*\value{t};
+ };
+\end{codeexample}
+
+
+\subsection{Scientific Polar Axis System}
+\label{section-dv-sci-polar-axes}
+
+\begin{key}{/tikz/data visualization/scientific polar axes=\meta{options}}
+ This key installs a polar axis system that can be used in a ``scientific''
+ publication. Two axes are created called the |angle axis| and the
+ |radius axis|. Unlike ``normal'' Cartesian axes, these axes do not point in
+ a specific direction. Rather, the |radius axis| is used to map the values
+ of one attribute to a distance from the origin while the |angle axis| is
+ used to map the values of another attribute to a rotation angle.
+
+ The \meta{options} will be executed with the path prefix
+ %
+\begin{codeexample}[code only]
+/tikz/data visualization/scientific polar axes
+\end{codeexample}
+ %
+ The permissible keys are documented in the later subsections of this
+ section.
+
+ Let us start with the configuration of the radius axis since it is easier.
+ Firstly, you should specify which attribute is linked to the radius. The
+ default is |radius|, but you will typically wish to change this. As with
+ any other axis, the |attribute| key is used to configure the axis, see
+ Section~\ref{section-dv-axis-attribute} for details. You can also apply all
+ other configurations to the radius axis like, say, |unit length| or
+ |length| or |style|. Note, however, that the |logarithmic| key will not
+ work with the radius axis for a |scientific polar axes| system since the
+ attribute value zero is always placed at the center -- and for a
+ logarithmic plot the value |0| cannot be mapped.
+ %
+\begin{codeexample}[
+ width=8.8cm,
+ preamble={\usetikzlibrary{
+ datavisualization.formats.functions,
+ datavisualization.polar,
+}},
+]
+\tikz \datavisualization [
+ scientific polar axes,
+ radius axis={
+ attribute=distance,
+ ticks={step=5000},
+ padding=1.5em,
+ length=3cm,
+ grid
+ },
+ visualize as smooth line]
+data [format=function] {
+ var angle : interval [0:100];
+ func distance = \value{angle}*\value{angle};
+};
+\end{codeexample}
+
+ For the |angle axis|, you can also specify an attribute using the
+ |attribute| key. However, for this axis the mapping of a value to an actual
+ angle is a complicated process involving many considerations of how the
+ polar axis system should be visualized. For this reason, there are a large
+ number of predefined such mappings documented in
+ Section~\ref{section-dv-angle-ranges}. Finally, as for a |scientific plot|,
+ you can configure where the ticks should be shown using the keys
+ |inner ticks|, |outer ticks|, and |clean|, documented below.
+\end{key}
+
+
+\subsubsection{Tick Placements}
+
+\begin{key}{/tikz/data visualization/scientific polar axes/outer ticks}
+ This key, which is the default, causes ticks to be drawn ``outside'' the
+ outer ``ring'' of the polar axes:
+ %
+\begin{codeexample}[
+ width=8.8cm,
+ preamble={\usetikzlibrary{
+ datavisualization.formats.functions,
+ datavisualization.polar,
+}},
+]
+\tikz \datavisualization [
+ scientific polar axes={outer ticks, 0 to 180},
+ visualize as smooth line]
+data [format=function] {
+ var angle : interval [0:100];
+ func radius = \value{angle};
+};
+\end{codeexample}
+ %
+\end{key}
+
+\begin{key}{/tikz/data visualization/scientific polar axes/inner ticks}
+ This key causes the ticks to be ``turned to the inside''. I do not
+ recommend using this key.
+ %
+\begin{codeexample}[
+ width=8.8cm,
+ preamble={\usetikzlibrary{
+ datavisualization.formats.functions,
+ datavisualization.polar,
+}},
+]
+\tikz \datavisualization [
+ scientific polar axes={inner ticks, 0 to 180},
+ visualize as smooth line]
+data [format=function] {
+ var angle : interval [0:100];
+ func radius = \value{angle};
+};
+\end{codeexample}
+ %
+\end{key}
+
+\begin{key}{/tikz/data visualization/scientific polar axes/clean}
+ This key separates the area where the data is shown from the area where the
+ ticks are shown. Usually, this is the best choice for the tick placement
+ since it avoids a collision of data and explanations.
+ %
+\begin{codeexample}[
+ width=8.8cm,
+ preamble={\usetikzlibrary{
+ datavisualization.formats.functions,
+ datavisualization.polar,
+}},
+]
+\tikz \datavisualization [
+ scientific polar axes={clean, 0 to 180},
+ visualize as smooth line]
+data [format=function] {
+ var angle : interval [0:100];
+ func radius = \value{angle};
+};
+\end{codeexample}
+ %
+\end{key}
+
+
+\subsubsection{Angle Ranges}
+\label{section-dv-angle-ranges}
+
+Suppose you create a polar plot in which the radius values vary between, say,
+$567$ and $1234$. Then the normal axis scaling mechanisms can be used to
+compute a good scaling for the ``radius axis'': Place the value $1234$ at a
+distance of , say, $5\,\mathrm{cm}$ from the origin and place the value $0$ at
+the origin. Now, by comparison, suppose that the values of the angle axis's
+attribute ranged between, say, $10$ and $75.7$. In this case, we may wish the
+angles to be scaled so that the minimum value is horizontal and the maximum
+value is vertical. But we may also wish the a value of $0$ is horizontal and a
+value of $90$ is vertical.
+
+Since it is unclear which interpretation is the right one, you have to use an
+option to select which should happen. The applicable options fall into three
+categories:
+%
+\begin{itemize}
+ \item Options that request the scaling to be done in such a way that the
+ attribute is interpreted as a value in degrees and such that the
+ minimum and maximum of the depicted range is a multiple of $90^\circ$.
+ For instance, the option |0 to 180| causes the angle axis to range from
+ $0^\circ$ to $180^\circ$, independently of the actual range of the
+ values.
+ \item Options that work as above, but use radians rather than degrees. An
+ example is the option |0 to pi|.
+ \item Options that map the minimum value in the data to a horizontal or
+ vertical line and the maximum value to another such line. This is
+ useful when the values neither directly correspond to degrees or
+ radians. In this case, the angle axis may also be a logarithmic axis.
+\end{itemize}
+
+In addition to the above categories, all of the option documented in the
+following implicitly also select quadrants that are used to depict the data.
+For instance, the |0 to 90| key and also the |0 to pi half| key setup the polar
+axis system in such a way that only first (upper right) quadrant is used. No
+check is done whether the data fill actually lie in this quadrant -- if it does
+not, the data will ``bleed outside'' the range. Naturally, with a key like
+|0 to 360| or |0 to 2pi| this cannot happen.
+
+In order to save some space in this manual, in the following the different
+possible keys are only given in a table together with a small example for each
+key. The examples were created using the following code:
+%
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.polar}}]
+\tikz \datavisualization [
+ scientific polar axes={
+ clean,
+ 0 to 90 % the option
+ },
+ angle axis={ticks={step=30}},
+ radius axis={length=1cm, ticks={step=1}},
+ visualize as scatter]
+data point [angle=20, radius=0.5]
+data point [angle=30, radius=1]
+data point [angle=40, radius=1.5];
+\end{codeexample}
+
+For the options on radians, the angle values have been replaced by |0.2|,
+|0.3|, and |0.4| and the stepping has been changed by setting |step=(pi/6)|.
+For the quadrant options, no stepping is set at all (it is computed
+automatically).
+
+\def\polarexample#1#2#3#4#5{%
+ \texttt{#1}%
+ \indexkey{/tikz/data visualization/scientific polar axes/#1}&
+ \tikz [baseline]{\path(-2.25cm,0)(2.25cm,0); \datavisualization [
+ scientific polar axes={clean, #1},
+ angle axis={ticks={#2}},
+ radius axis={length=1cm, ticks={step=1}},
+ visualize as scatter
+ ]
+ data point [angle=#3, radius=0.5]
+ data point [angle=#4, radius=1]
+ data point [angle=#5, radius=1.5];
+ \path ([yshift=-1em]current bounding box.south);
+ }&
+ \tikz [baseline]{\path(-2.25cm,0)(2.25cm,0); \datavisualization [
+ scientific polar axes={outer ticks, #1},
+ angle axis={ticks={#2}},
+ radius axis={length=1cm, ticks={step=1}},
+ visualize as scatter
+ ]
+ data point [angle=#3, radius=0.5]
+ data point [angle=#4, radius=1]
+ data point [angle=#5, radius=1.5];
+ \path ([yshift=-1em]current bounding box.south);
+ }
+ \\
+}
+
+\begin{tabular}{lcc}
+ \emph{Option} & \emph{With clean ticks} & \emph{With outer ticks} \\
+ \polarexample{0 to 90}{step=30}{20}{30}{40}
+ \polarexample{-90 to 0}{step=30}{20}{30}{40}
+ \polarexample{0 to 180}{step=30}{20}{30}{40}
+ \polarexample{-90 to 90}{step=30}{20}{30}{40}
+ \polarexample{0 to 360}{step=30}{20}{30}{40}
+ \polarexample{-180 to 180}{step=30}{20}{30}{40}
+\end{tabular}
+
+\begin{tabular}{lcc}
+ \emph{Option} & \emph{With clean ticks} & \emph{With outer ticks} \\
+ \polarexample{0 to pi half}{step=(pi/6)}{0.2}{0.3}{0.4}
+ \polarexample{-pi half to 0}{step=(pi/6)}{0.2}{0.3}{0.4}
+ \polarexample{0 to pi}{step=(pi/6)}{0.2}{0.3}{0.4}
+ \polarexample{-pi half to pi half}{step=(pi/6)}{0.2}{0.3}{0.4}
+ \polarexample{0 to 2pi}{step=(pi/6)}{0.2}{0.3}{0.4}
+ \polarexample{-pi to pi}{step=(pi/6)}{0.2}{0.3}{0.4}
+\end{tabular}
+
+\begin{tabular}{lcc}
+ \emph{Option} & \emph{With clean ticks} & \emph{With outer ticks} \\
+ \polarexample{quadrant}{}{20}{30}{40}
+ \polarexample{quadrant clockwise}{}{20}{30}{40}
+ \polarexample{fourth quadrant}{}{20}{30}{40}
+ \polarexample{fourth quadrant clockwise}{}{20}{30}{40}
+ \polarexample{upper half}{}{20}{30}{40}
+ \polarexample{upper half clockwise}{}{20}{30}{40}
+ \polarexample{lower half}{}{20}{30}{40}
+ \polarexample{lower half clockwise}{}{20}{30}{40}
+\end{tabular}
+
+\begin{tabular}{lcc}
+ \emph{Option} & \emph{With clean ticks} & \emph{With outer ticks} \\
+ \polarexample{left half}{}{20}{30}{40}
+ \polarexample{left half clockwise}{}{20}{30}{40}
+ \polarexample{right half}{}{20}{30}{40}
+ \polarexample{right half clockwise}{}{20}{30}{40}
+\end{tabular}
+
+
+\subsection{Advanced: Creating a New Polar Axis System}
+
+\begin{key}{/tikz/data visualization/new polar axes=|\char`\{|\meta{angle axis name}|\char`\}||\char`\{|\meta{radius axis name}|\char`\}|}
+ This key actually creates two axes, whose names are give as parameters: An
+ \emph{angle axis} and a \emph{radius axis}. These two axes work in concert
+ in the following way: Suppose a data point has two attributes called
+ |angle| and |radius| (these attribute names can be changed by changing the
+ |attribute| of the \meta{angle axis name} or the \meta{radius axis name},
+ respectively). These two attributes are then scaled as usual, resulting in
+ two ``reasonable'' values $a$ (for the angle) and $r$ (for the radius).
+ Then, the data point gets visualized (in principle, details will follow) at
+ a position on the page that is at a distance of $r$ from the origin and at
+ an angle of~$a$.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.polar}}]
+\tikz \datavisualization
+ [new polar axes={angle axis}{radius axis},
+ radius axis={length=2cm},
+ visualize as scatter]
+ data [format=named] {
+ angle={0,20,...,160}, radius={0,...,5}
+ };
+\end{codeexample}
+ %
+ In detail, the \meta{angle axis} keeps track of two vectors $v_0$ and
+ $v_{90}$, each of which will usually have unit length (length |1pt|) and
+ which point in two different directions. Given a radius $r$ (measured in
+ \TeX\ |pt|s, so if the radius attribute |10pt|, then $r$ would be $10$) and
+ an angle $a$, let $s$ be the sine of $a$ and let $c$ be the cosine of $a$,
+ where $a$ is a number is degrees (so $s$ would be $1$ for $a = 90$). Then,
+ the current page position is shifted by $c \cdot r$ times $v_0$ and,
+ additionally, by $s \cdot r$ times $v_{90}$. This means that in the ``polar
+ coordinate system'' $v_0$ is the unit vector along the ``$0^\circ$-axis''
+ and $v_{90}$ is the unit vector along ``$90^\circ$-axis''. The values of
+ $v_0$ and $v_{90}$ can be changed using the following key on the
+ \meta{angle axis}:
+ %
+ \begin{key}{/tikz/data visualization/axis options/unit vectors=%
+ |\char`\{|\meta{unit vector 0 degrees}|\char`\}\char`\{|\meta{unit vector 90 degrees}|\char`\}|
+ (initially {\char`\{(1pt,0pt)\char`\}\char`\{(0pt,1pt)\char`\}})%
+ }
+ Both the \meta{unit vector 0 degrees} and the \meta{unit vector 90 degrees}
+ are \tikzname\ coordinates:
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.polar}}]
+\tikz \datavisualization
+ [new polar axes={angle axis}{radius axis},
+ radius axis={unit length=1cm},
+ angle axis={unit vectors={(10:1pt)}{(60:1pt)}},
+ visualize as scatter]
+ data [format=named] {
+ angle={0,90}, radius={0.25,0.5,...,2}
+ };
+\end{codeexample}
+ \end{key}
+\end{key}
+
+Once created, the |angle axis| can be scaled conveniently using the following
+keys:
+
+\begin{key}{/tikz/data visualization/axis options/degrees}
+ When this key is passed to the angle axis of a polar axis system, it sets
+ up the scaling so that a value of |360| on this axis corresponds to a
+ complete circle.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.polar}}]
+\tikz \datavisualization
+ [new polar axes={angle axis}{radius axis},
+ radius axis={unit length=1cm},
+ angle axis={degrees},
+ visualize as scatter]
+ data [format=named] {
+ angle={10,90}, radius={0.25,0.5,...,2}
+ };
+\end{codeexample}
+ %
+\end{key}
+
+\begin{key}{/tikz/data visualization/axis options/radians}
+ In contrast to |degrees|, this option sets up things so that a value of
+ |2*pi| on this axis corresponds to a complete circle.
+ %
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.polar}}]
+\tikz \datavisualization
+ [new polar axes={angle axis}{radius axis},
+ radius axis={unit length=1cm},
+ angle axis={radians},
+ visualize as scatter]
+ data [format=named] {
+ angle={0,1.5}, radius={0.25,0.5,...,2}
+ };
+\end{codeexample}
+ %
+\end{key}
Property changes on: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-polar.tex
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-stylesheets.tex
===================================================================
--- trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-stylesheets.tex (rev 0)
+++ trunk/Master/texmf-dist/doc/generic/pgf/pgfmanual-en-dv-stylesheets.tex 2023-01-15 20:58:27 UTC (rev 65553)
@@ -0,0 +1,4033 @@
+% Copyright 2019 by Till Tantau
+%
+% This file may be distributed and/or modified
+%
+% 1. under the LaTeX Project Public License and/or
+% 2. under the GNU Free Documentation License.
+%
+% See the file doc/generic/pgf/licenses/LICENSE for more details.
+
+
+\section{Style Sheets and Legends}
+\label{section-dv-style-sheets}
+
+\subsection{Overview}
+
+In many data visualizations, different sets of data need to be visualized in a
+single visualization. For instance, in a plot there might be a line for the
+sine of~$x$ and another line for the cosine of~$x$; in another visualization
+there might be a set of points representing data from a first experiment and
+another set of points representing data from a second experiment; and so on. In
+order to indicate to which data set a data point belongs, one might plot the
+curve of the sine in, say, black, and the curve of the cosine in red; we might
+plot the data from the first experiment using stars and the data from the second
+experiment using circles; and so on. Finally, at some place in the
+visualization -- either inside the data or in a legend next to it -- the
+meaning of the colors or symbols need to be explained.
+
+Just as you would like \tikzname\ to map the data points automatically onto the
+axes, you will also typically wish \tikzname\ to choose for instance the
+coloring of the lines automatically for you. This is done using \emph{style
+sheets}. There are at least two good reasons why you should prefer style sheets
+over configuring the styling of each visualizer ``by hand'' using the |style|
+key:
+%
+\begin{enumerate}
+ \item It is far more convenient to just say |style sheet=strong colors|
+ than having to individually picking the different colors.
+ \item The style sheets were chosen and constructed rather carefully.
+
+ For instance, the |strong colors| style sheet does not pick colors like
+ pure green or pure yellow, which have very low contrast with respect to
+ a white background and which often lead to unintelligible graphics.
+ Instead, opposing primary colors with maximum contrast on a white
+ background were picked that are visually quite pleasing.
+
+ Similarly, the different dashing style sheets are constructed in such a
+ way that there are only few and small gaps in the dashing so that no
+ data points get lost because the dashes are spaced too far apart. Also
+ dashing patterns were chosen that have a maximum optical difference.
+
+ As a final example, style sheets for plot marks are constructed in such
+ a way that even when two plot marks lie directly on top of each other,
+ they are still easily distinguishable.
+\end{enumerate}
+%
+The bottom line is that whenever possible, you should use one of the predefined
+style sheets rather than picking colors or dashings at random.
+
+
+\subsection{Concepts: Style Sheets}
+
+A \emph{style sheet} is a predefined list of styles such as a list of colors, a
+list of dashing pattern, a list of plot marks, or a combinations thereof. A
+style sheet can be \emph{attached} to a data point attribute. Then, the value
+of this attribute is used with data points to choose which style in the list
+should be chosen to visualize the data point.
+
+In most cases, there is just one attribute to which style sheets get attached:
+the |/data point/visualizer| attribute. The effect of attaching a style sheet
+to this attribute is that each visualizer is styled differently.
+
+For the following examples, let us first define a simple data set:
+%
+\begin{codeexample}[preamble={\usetikzlibrary{datavisualization.formats.functions}}]
+\tikz \datavisualization data group {function classes} = {
+ data [set=log, format=function] {
+ var x : interval [0.2:2.5];
+ func y = ln(\value x);
+ }
+ data [set=lin, format=function] {
+ var x : interval [-2:2.5];
+ func y = 0.5*\value x;
+ }
+ data [set=squared, format=function] {
+ var x : interval [-1.5:1.5];
+ func y = \value x*\value x;
+ }
+ data [set=exp, format=function] {
+ var x : interval [-2.5:1];
+ func y = exp(\value x);
+ }
+};
+\end{codeexample}
+
+\begin{codeexample}[
+ width=6cm,
+ preamble={\usetikzlibrary{datavisualization.formats.functions}},
+ pre={\tikz \datavisualization data group {function classes} = {
+ data [set=log, format=function] {
+ var x : interval [0.2:2.5];
+ func y = ln(\value x);
+ }
+ data [set=lin, format=function] {
+ var x : interval [-2:2.5];
+ func y = 0.5*\value x;
+ }
+ data [set=squared, format=function] {
+ var x : interval [-1.5:1.5];
+ func y = \value x*\value x;
+ }
+ data [set=exp, format=function] {
+ var x : interval [-2.5:1];
+ func y = exp(\value x);
+ }
+};}]
+\tikz \datavisualization [
+ school book axes, all axes={unit length=7.5mm},
+ visualize as smooth line/.list={log, lin, squared, exp},
+ style sheet=strong colors]
+data group {function classes};
+\end{codeexample}
+
+\begin{codeexample}[
+ width=6cm,
+ preamble={\usetikzlibrary{datavisualization.formats.functions}},
+ pre={\tikz \datavisualization data group {function classes} = {
+ data [set=log, format=function] {
+ var x : interval [0.2:2.5];
+ func y = ln(\value x);
+ }
+ data [set=lin, format=function] {
+ var x : interval [-2:2.5];
+ func y = 0.5*\value x;
+ }
+ data [set=squared, format=function] {
+ var x : interval [-1.5:1.5];
+ func y = \value x*\value x;
+ }
+ data [set=exp, format=function] {
+ var x : interval [-2.5:1];
+ func y = exp(\value x);
+ }
+};}]
+\tikz \datavisualization [
+ school book axes, all axes={unit length=7.5mm},
+ visualize as smooth line/.list={log, lin, squared, exp},
+ style sheet=vary dashing]
+data group {function classes};
+\end{codeexample}
+
+
+\subsection{Concepts: Legends}
+\label{section-dv-labels-in}
+
+A \emph{legend} is a box that is next to a data visualization (or inside it at
+some otherwise empty position) that contains a textual explanation of the
+different colors or styles used in a data visualization.
+
+Just as it is difficult to get colors and dashing patterns right ``by hand'',
+it is also difficult to get a legend right. For instance, when a small line is
+shown in the legend that represents the actual line in the data visualization,
+if the line is too short and the dashing is too large, it may be impossible to
+discern which dashing is actually meant. Similarly, when plot marks are shown
+on such a short line, using a simple straight line may make it hard to read the
+plot marks correctly.
+
+The data visualization engine makes some effort to make it easy to create
+high-quality legends. Additionally, it also offers ways of easily adding labels
+for visualizers directly inside the data visualization, which is even better
+than adding a legend, in general.
+%
+\begin{codeexample}[
+ width=7cm,
+ preamble={\usetikzlibrary{datavisualization.formats.functions}},
+ pre={\tikz \datavisualization data group {function classes} = {
+ data [set=log, format=function] {
+ var x : interval [0.2:2.5];
+ func y = ln(\value x);
+ }
+ data [set=lin, format=function] {
+ var x : interval [-2:2.5];
+ func y = 0.5*\value x;
+ }
+ data [set=squared, format=function] {
+ var x : interval [-1.5:1.5];
+ func y = \value x*\value x;
+ }
+ data [set=exp, format=function] {
+ var x : interval [-2.5:1];
+ func y = exp(\value x);
+ }
+};}]
+\tikz \datavisualization [
+ school book axes, all axes={unit length=7.5mm},
+ x axis={label=$x$},
+ visualize as smooth line/.list={log, lin, squared, exp},
+ log= {label in legend={text=$\log x$}},
+ lin= {label in legend={text=$x/2$}},
+ squared={label in legend={text=$x^2$}},
+ exp= {label in legend={text=$e^x$}},
+ style sheet=vary dashing]
+data group {function classes};
+\end{codeexample}
+
+\begin{codeexample}[
+ width=6.3cm,
+ preamble={\usetikzlibrary{datavisualization.formats.functions}},
+ pre={\tikz \datavisualization data group {function classes} = {
+ data [set=log, format=function] {
+ var x : interval [0.2:2.5];
+ func y = ln(\value x);
+ }
+ data [set=lin, format=function] {
+ var x : interval [-2:2.5];
+ func y = 0.5*\value x;
+ }
+ data [set=squared, format=function] {
+ var x : interval [-1.5:1.5];
+ func y = \value x*\value x;
+ }
+ data [set=exp, format=function] {
+ var x : interval [-2.5:1];
+ func y = exp(\value x);
+ }
+};}]
+\tikz \datavisualization [
+ school book axes,
+ x axis={label=$x$},
+ visualize as smooth line/.list={log, lin, squared, exp},
+ every data set label/.append style={text colored},
+ log= {pin in data={text'=$\log x$, when=y is -1}},
+ lin= {pin in data={text=$x/2$, when=x is 2,
+ pin length=1ex}},
+ squared={pin in data={text=$x^2$, when=x is 1.1,
+ pin angle=230}},
+ exp= {label in data={text=$e^x$, when=x is -2}},
+ style sheet=vary hue]
+data group {function classes};
+\end{codeexample}
+
+
+\subsection{Usage: Style Sheets}
+
+\subsubsection{Picking a Style Sheet}
+
+To use a style sheet, you need to \emph{attach} it to an attribute. You can
+attach multiple style sheets to an attribute and in this case all of these
+style sheets can influence the appearance of the data points.
+
+Most of the time, you will attach a style sheet to the |set| attribute. This
+has the effect that each different data set inside the same visualization is
+rendered in a different way. Since this use of style sheets is the most common,
+there is a special, easy-to-remember option for this:
+
+\begin{key}{/tikz/data visualization/style sheet=\meta{style sheet}}
+ Adds the \meta{style sheet} to the list of style sheets attached to the
+ |set| attribute.
+ %
+\begin{codeexample}[
+ width=6cm,
+ preamble={\usetikzlibrary{datavisualization.formats.functions}},
+ pre={\tikz \datavisualization data group {function classes} = {
+ data [set=log, format=function] {
@@ Diff output truncated at 1234567 characters. @@
More information about the tex-live-commits
mailing list.