Sparkles

Appearance

TikZ / PGF (TeX) ​

The TeX-native vector-graphics language: TikZ is the human-facing frontend syntax over the PGF (Portable Graphics Format) basic-layer engine, and it runs inside the TeX document compiler — the same engine that typesets the prose emits the figure — producing static PDF / PostScript / SVG vector graphics rather than a video stream.

FieldValue
LanguageTeX macro language (expanded by pdfTeX / LuaTeX / XeTeX); the frontend is authored in TeX, not a general-purpose language
LicenseDual, per component: code under GNU GPL v2 or LPPL 1.3c; documentation under GNU FDL 1.2 or LPPL 1.3c — "you can decide which license you wish to use" (LICENSE)
Repositorypgf-tikz/pgf
DocumentationThe pgfmanual (~1300 pp.; HTML edition at tikz.dev, PDF on CTAN / texdoc pgfmanual)
CategoryTeX-native declarative vector-graphics language — a document-embedded, compile-time figure engine, not a morph-animation or video engine
First releaseGrew from Till Tantau's PhD-thesis graphics; under development since 2005 (Tantau to 2018, then Henri Menke); current 3.1.11a (2025-08-29, CTAN); reviewed Jul 11 2026
LayersTikZ frontend (\draw/\node/\path) → PGF basic layer (\pgf… commands) → system/driver layer (\pgfsys@…) (base-design, pgfsys)
Rendered byThe TeX engine at document-compile time; the chosen driver (pdftex, dvips, dvisvgm, …) writes vector operators into the output (drivers)
Output formatVector graphics embedded in a document: PDF, PostScript, or SVG — never raster frames; rasterization is deferred to the viewer/RIP
Animation supportLimited & SVG-only. The animations library emits SMIL-annotated SVG (tikz-animations); beamer overlays give slide-step reveals; otherwise fundamentally static

NOTE

TikZ is a static, document-oriented vector language, not a video engine. It has no frame loop, no rate-function/easing library, no shape-to-shape morph, no pixel readback, and no codec/muxing — several of the survey's axis-2 and axis-5 concerns are therefore N/A and marked so below. It earns its place in the catalog for the opposite reason: it is the mature, production-hard declarative vector language whose TeX-native typesetting a Manim-class engine can only envy — labels are set by the very compiler that builds the document, with no external LaTeX→SVG shell-out.

WARNING

Verification note. Quotes below are drawn from the official pgfmanual via its HTML edition at tikz.dev (a verbatim rendering of the manual shipped in pgf-tikz/pgf), plus the CTAN package page and the in-repo LICENSE. Version and license facts are pinned to 3.1.11a (2025-08-29). No runnable CI probe ships with this page — see the note under Sources.

Overview ​

What it solves ​

PGF/TikZ solves portable, programmatic, publication-quality figures embedded directly in a TeX document. The CTAN description states the scope:

"PGF is a macro package for creating graphics. It is platform- and format-independent and works together with the most important TeX backend drivers, including pdfTeX and dvips." — CTAN pgf

The problem it uniquely solves for this survey is figures whose text is first-class TeX. In a Manim-class engine, math and labels are an external subsystem — Manim shells out to a LaTeX distribution and dvisvgm to turn an equation into a VMobject (the LaTeX→SVG pipeline). In TikZ there is no shell-out: the picture is expanded by the same TeX run that is typesetting the surrounding document, so a node's contents — $\int_0^1 x^2\,dx$, a full align environment, a \ref — are typeset by the document compiler itself, kerned and hinted identically to the body text. The cost of that power is the mirror image: TikZ is bound to the document-compile model, so it produces a page, not a movie.

Design philosophy ​

TikZ's name is a self-deprecating recursive acronym, in the GNU tradition:

"TikZ ist kein Zeichenprogramm" (TikZ is not a drawing program) — Design Principles

The point of the joke is the design bet. TikZ deliberately refuses a WYSIWYG canvas; a figure is described in a terse, key-value path language, not mouse-drawn. The manual states the goal plainly:

"TikZ's job is to make your life easier by providing an easy-to-learn and easy-to-use syntax for describing graphics." — Design Principles

Its syntax is a magpie synthesis of prior art, which the manual credits explicitly:

"The basic command names and the notion of path operations is taken from metafont, the option mechanism comes from pstricks, the notion of styles is reminiscent of svg, the graph syntax is taken from graphviz." — Design Principles

The MetaPost/metafont lineage is load-bearing for this survey: it is the origin of equation-solved, Hobby-spline drawing that TikZ inherits (see Object & scene model). The second philosophical commitment is the layered architecture — a portable basic layer with a thin, driver-specific bottom — covered next.

How it works ​

A TikZ picture is a tikzpicture environment whose body is a sequence of path commands. The atom is a path built from coordinates and path operations, then acted upon (drawn, filled, clipped):

latex
\begin{tikzpicture}
  \draw (0,0) -- (2,0) -- (2,1) -- cycle;      % a filled-outline triangle path
  \node[draw,circle] (a) at (0,0) {$x$};        % a node: TeX-typeset text in a shape
  \fill[blue!20] (a.east) circle (2pt);         % reference the node's `east` anchor
\end{tikzpicture}

Three verbs cover almost everything:

  • \path is the primitive — it constructs a path but takes no action by itself. \draw, \fill, \filldraw, \clip, and \shade are all \path[draw], \path[fill], … in disguise.
  • \node places TeX-typeset content (a shape with a border and a label) at a coordinate; nodes are the addressable, anchored objects.
  • \draw/\fill are the common actions.

Coordinates and path operations. Coordinates are Cartesian (x,y), polar (30:1cm), named ((a.north)), or relative (+(1,0) / ++(1,0)). Path operations join them: -- (line-to), |-/-| (right-angle), rectangle, circle, arc, grid, parabola, plot, and the curve-to operator .. controls … .. (a cubic Bézier, detailed below).

The three-layer architecture is the core mechanism. A TikZ command does not speak to the output driver; it descends through three layers (base-design, pgfsys):

LayerCommand prefixRole
TikZ frontend\draw, \node, \pathHuman syntax; parses coordinates/options and calls the basic layer
PGF basic layer\pgfpath…, \pgfusepathPortable, driver-independent path/scope/node primitives
System/driver layer\pgfsys@…The thin, driver-specific bottom that writes actual PDF/PS/SVG operators

"The basic layer does not provide a convenient syntax for describing graphics, which is left to frontends like TikZ." — Design Principles of the basic layer

The frontend is swappable: TikZ and pgfpict2e are both frontends over the same basic layer, and packages such as beamer skip the frontend entirely — "the beamer package uses the basic layer extensively, but does not need a convenient input syntax" (base-design). The system layer, in turn, hides every backend difference behind \pgfsys@… calls: "This interface provides a complete abstraction of the internals of the underlying drivers" (pgfsys). This layering is what makes one .tex source render to PDF under pdftex and to SVG under dvisvgm unchanged.

Runs inside TeX. There is no separate "engine" process. The tikzpicture is macro-expanded during the TeX run; coordinate arithmetic is TeX register math; the "renderer" is whichever driver \pgfsysdriver selects. The document compiler is the engine — a defining structural fact for every axis below.

\foreach. Repetition is the pgffor loop, usable inside or outside a picture — "execute the ⟨commands⟩ repeatedly, once for every element of the ⟨list⟩" (pgffor), with ... range expansion:

latex
\foreach \x in {1,2,...,6} {\x, }   % expands to: 1, 2, 3, 4, 5, 6,

Decorations transform a constructed path into a richer one — "Decorations are a general concept to make (sub)paths 'more interesting'" (tikz-decorations) — in three flavours: path morphing (a straight line becomes a zigzag/snake/coil), path replacing, and path removing. The rest of this page walks the survey's eight axes against this machinery.

Object & scene model ​

TikZ has objects but no retained, mutable, animatable scene graph in the Mobject sense. There are two kinds of thing:

  • Paths — constructed then immediately consumed by an action. A \draw …; emits its stroke operators and is gone; there is no persistent path object you can later grab and morph. This is closest to immediate-mode emission (each command paints as it expands), not a retained tree the engine re-renders.
  • Nodes — the addressable objects. A node is placed at a coordinate, carries TeX-typeset content, and has a shape: "A node is typically a rectangle or circle or another simple shape with some text on it" (tikz-shapes). Nodes are named ((a)) and referenced later, which gives a picture a lightweight object graph — but a static one, fixed once the picture is compiled.

Anchors are the placement primitive: every shape exposes named points — "pgf defines numerous anchor positions in the shape. For example the upper right corner is called … the north east anchor … The center of the shape has an anchor called center" (tikz-shapes). Edges connect anchors (\draw (a.east) -- (b.west);), and the positioning library places nodes relative to each other (below=1cm of a, right=of b).

Coordinate space and transforms. Every scope carries an affine transform — \begin{scope}[shift={(1,1)},rotate=30,scale=2] composes translate∘rotate∘scale exactly as the affine-transform.d probe verifies for the general case, and the calc library does coordinate arithmetic (($(a)!0.5!(b)$) is the midpoint). TikZ distinguishes the canvas transform (applied by the driver, cheap, distorts line widths) from the coordinate transform (applied by PGF to points, preserves stroke width) — a subtlety without a Manim analog because Manim transforms model points, never the device.

NOTE

Layout is placement, not constraint-solving. Node positions come from explicit anchors, the relative positioning library, or the algorithmic graph-drawing (gd) subsystem — not from a numerical optimizer. Constraint/optimization-based layout (Penrose-style energy minimization) is N/A; the nearest TikZ has is graph-drawing algorithms and the MetaPost-inherited equation-solvedcalc/intersections machinery.

Animation & timing model ​

This is the axis where TikZ is fundamentally limited, and honestly so. There is no timeline, no play-loop, no interpolation engine, no rate functions, no lag/stagger — none of the execution models in the concepts glossary (imperative play-loop, generator, pure-frame, reactive, keyframe) applies, because there is no time axis in a compiled figure. What exists are two narrow, deliberately-scoped mechanisms plus one companion package.

The animations library (SVG/SMIL only). Loaded with \usetikzlibrary{animations}, it attaches an :attribute timeline to a node or scope. Crucially, it does not rasterize frames — it writes a declarative annotation into the SVG output and lets the viewer play it:

"TikZ animations currently work only with svg output (and use the smil 'flavor' of describing animations)." — Animations

"a TikZ animation is just 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." — Animations

The syntax is a :-namespaced key that maps timestamps to attribute values (e.g. myself:fill = {0s = "red", 2s = "blue"}), and the engine is the SMIL runtime in the browser/SVG viewer — so animations "neither increase output file sizes noticeably nor slow down TeX". The honesty is in the PDF caveat:

"It is very unlikely that pdf will ever support animations in a useful way." — Animations

For PDF (or a printed handout), the only recourse is snapshots — "it is … possible to create 'snapshots' of an animation and insert these into pdf files … also useful for creating 'printed versions'" (tikz-animations) — i.e. render selected instants as static figures, which is exactly the opposite of a frame-sampled video.

beamer overlays (slide-step "animation"). For presentations, the step-through illusion comes from beamer, not TikZ: overlay specifications in pointed brackets gate content per slide. \pause, \only<2->{…}, \onslide<3>{…}, and \visible<2->{…} reveal or hide material across "overlays" of one frame (beamer overlays). TikZ integrates via per-slide styles (\draw[visible on=<2->] …), so a diagram builds up step-by-step. But this is discrete slide stepping, not continuous interpolation — there is no tween between states, only presence/absence.

Manim axis-2 conceptTikZ
Interpolation / lerpDeferred to the viewer. SMIL interpolates attribute keyframes in the SVG player; TeX computes nothing over time.
Rate function / easingMinimal. SMIL calcMode/keySplines easing is available in the SVG output; no smooth/rush_into morph library.
Transform + point-count alignmentN/A. No shape-to-shape morph; paths are not retained, so there is nothing to align point-for-point.
lag_ratio / staggerN/A as a timeline primitive; per-object begin offsets exist only inside the SMIL annotation.
Execution modelNone of the five. A figure is macro-expanded once at compile time; beamer adds discrete slide stepping on top.

The rate-functions.d probe describes the easing and stagger machinery a Manim-class engine bakes in — precisely the layer TikZ delegates (to the SMIL viewer) or omits.

Rendering backend & rasterization ​

TikZ has no rasterizer. This is the sharpest structural difference from every other engine in the survey. TikZ/PGF emits vector operators — path fill/stroke/clip commands in the output language — and the actual rasterization (turning vectors into pixels) happens downstream, in the PDF viewer, the print RIP, or the browser's SVG renderer. There is no CPU-vector vs GPU-vector choice inside TikZ, no anti-aliasing knob, no MSAA, no coverage buffer — those are the viewer's job.

What TikZ does choose is the output vector language, via the system/driver layer. The supported drivers are (drivers): luatex, pdftex, dvips, dvipdfm, dvipdfmx, dvisvgm, and tex4ht. Each is a pgfsys-⟨driver⟩.def file implementing the \pgfsys@… primitives:

Driver filePipelineOutput operators
pgfsys-pdftex.defpdftex (direct PDF)PDF content stream
pgfsys-luatex.defluatex (direct PDF)PDF content stream
pgfsys-dvips.def(la)tex → dvipsPostScript
pgfsys-dvipdfmx.defxetex/(la)tex → dvipdfmxPDF
pgfsys-dvisvgm.def(la)tex → dvisvgmraw SVG (with fonts)

"This driver converts dvi files to svg file, including text and fonts, and when you select this driver, pgf will output the required raw svg code for the pictures it produces." — Supported Formats

Because the pixels are produced by the viewer, TikZ output is resolution-independent by construction — a PDF figure is razor-sharp at any zoom and at print resolution, with no render-time DPI decision. The trade-off is that TikZ cannot observe its own pixels: there is no framebuffer to read back (see Output & encoding).

Typesetting & text ​

This is TikZ's signature strength and the reason it belongs in a mathematical-animation survey at all. Text is native TeX. A node's contents are typeset by the same TeX engine compiling the document — not a bolt-on math subsystem — so any TeX/LaTeX construct works verbatim:

latex
\node at (0,0) {$\displaystyle \int_{-\infty}^{\infty} e^{-x^2}\,dx = \sqrt{\pi}$};
\node at (0,-1) {\begin{tabular}{c}multi-line\\ \LaTeX\ content\end{tabular}};

Contrast the concepts glossary's LaTeX→SVG pipeline, which both Manim forks run to bring math in: compile LaTeX to dvi, run dvisvgm, parse the SVG, and rebuild a VMobject. TikZ collapses that entire round-trip — the equation is already in the TeX stream, laid out by the compiler's math engine, kerned and hinted like the body text. There is no external shell-out for a label, no version-skew between the figure's fonts and the document's, and no per-label caching problem.

The corollary is that the glyph-outline-extraction and text-shaping axes look different than for a morph engine:

  • Shaping is TeX's own line/math-mode layout (\hbox/\vbox, math atoms), not HarfBuzz/Pango. (Under LuaTeX + luaotfload, HarfBuzz is reachable, but that is TeX's font machinery, not TikZ's.)
  • Glyph outlines are usually NOT extracted. TikZ places a typeset glyph — a reference into an embedded font in the PDF/SVG — rather than decomposing the letter into contour Béziers as a VMobject would. Text stays text (selectable, searchable) instead of becoming path. The exception is opt-in: the dvisvgm driver can flatten fonts to SVG paths, and helper packages (tikz + \path[…] … node … decorations, or external outline tools) can turn a glyph into a decoratable path — but that is not the default, and morphing letters is not a native operation.

Output & encoding ​

TikZ's output is a figure inside a document, not a media file — so the survey's axis-5 machinery is largely N/A and its absence is the finding.

  • Frame capture / readback — N/A. There is no RGBA framebuffer to read. PGF emits vector operators; there is no rendered pixel buffer anywhere in the pipeline (it lives, transiently, in the viewer). The frame-capture.d probe's render→buffer step has no TikZ counterpart.
  • Codec / muxing / pixel format — N/A. No yuv420p conversion, no libx264, no .mp4 muxing. The "encode" step is the driver writing PDF/PS/SVG vector operators, and the "container" is the surrounding .pdf/.svg document.
  • What it does produce: a page (or a standalone figure via the standalone document class or \usepackage{tikz} + crop), or — via dvisvgm — a self-contained SVG. For a "video", the workflow is external: compile one figure per instant (e.g. \foreach a parameter across N files), then feed the resulting PDFs/PNGs to an outside tool (ffmpeg, convert). That pipeline is bolted on, not part of TikZ.

The one genuinely animated output is the SVG/SMIL path of the animations library: the "encoding" of motion is a set of <animate> elements in the SVG, played by the viewer — declarative motion, zero rendered frames.

Interactivity, preview & authoring ​

Authoring is the edit-compile-view loop of TeX. You write TikZ source in an editor and compile the document; the figure appears when the page renders. There is no live canvas, no interactive scrubber, no REPL — authoring is inherently offline and batch, the antithesis of a reactive or GUI-timeline tool.

  • Preview. Iteration speed comes from the surrounding TeX ecosystem, not TikZ: standalone + preview to compile a single figure fast, editor live-preview (LaTeX Workshop, latexmk -pvc), or externalization (below) to avoid recompiling unchanged figures. The feedback loop is a document rebuild, typically sub-second for one figure but not interactive in the drag-a-handle sense.
  • Interactivity in the output. The only interactivity TikZ can bake in is what the viewer supports: PDF hyperlinks/hyperref targets, and — in SVG output — the SMIL animations and JavaScript-driven behaviour a browser can run. A native window that recomputes on drag (Makie's GLMakie, nannou) has no TikZ analog.
  • beamer as the authoring target for "playback". For talks, the overlay system is the authoring surface: you write one frame and annotate which parts appear on which slide, and the PDF viewer's next-slide key is the "play" button.

Extensibility & API surface ​

TikZ is extended the way TeX is extended — with macros, key-value styles, and loadable libraries — and the surface is enormous.

  • Styles and the pgfkeys system. Graphic parameters are keys (draw, fill=blue!20, line width=2pt, rounded corners), grouped into reusable styles (\tikzset{my style/.style={...}}) — the svg-inspired styling the design principles credit. pgfkeys is a general-purpose key-value/handler engine used well beyond graphics.

  • Libraries (\usetikzlibrary{…}) add vocabulary without touching the core. The survey-relevant ones:

    LibraryAdds
    calcCoordinate arithmetic — midpoints, projections, ($(a)!t!(b)$)
    positioningRelative node placement (below=of, right=1cm of)
    arrows.metaParameterized, composable arrow-tip system
    decorations.*Path morphing / replacing / removing — zigzag, snake, coil, braces (decorations)
    intersectionsNamed path intersections solved at compile time
    animationsThe SVG/SMIL animation annotations
    graphdrawingAlgorithmic layout (LuaTeX-only; layered/force/tree layouts)

  • The frontend seam. Because the basic layer is a stable, documented API, whole packages build on PGF without TikZ: pgfplots (function/data plots), tikz-cd (commutative diagrams), circuitikz, and beamer all target the basic layer or extend the TikZ frontend. Adding a new frontend (à la pgfpict2e) is a supported extension point (base-design).

  • Smooth curves and the MetaPost inheritance. plot[smooth] draws a tension-spline through points; for true MetaPost curves, the contributed hobby library (\usetikzlibrary{hobby}) implements Hobby's algorithm — "The algorithm was devised as part of the MetaPost program" (hobby package) — the curvature-minimizing spline through a point sequence, the same equation-solved drawing the concepts page attributes to the MetaPost lineage.

Determinism, caching & performance ​

  • Deterministic output — yes, by construction. A TikZ figure is a pure function of its source: recompiling the same .tex with the same TeX/driver build yields byte-identical vector operators. There is no RNG, no floating-point GPU variance, no driver-dependent rasterization (the vectors are exact; only the viewer's pixels vary). This is strictly stronger determinism than the CPU-oracle compromise a raster engine settles for — TikZ never commits to pixels at all.
  • Content caching — via externalization. PGF's external library is the direct analog of Manim's partial-movie-file cache: each tikzpicture is compiled once to a standalone PDF/PNG and reused on subsequent document builds unless its source changed, so an unchanged figure is not re-rendered. The granularity is the whole picture (Manim's is a play() call), and correctness rests on the same property — the render is deterministic, so a cached artifact is valid until the input changes.
  • Performance. The cost is TeX macro expansion, which is slow for heavy figures: coordinate math runs in TeX's fixed-point registers, thousands of path segments or a dense \foreach can take seconds, and there is no GPU acceleration. Externalization exists precisely because complex pictures dominate compile time. The counterweight is that this cost is paid once, at build time, for a resolution-independent artifact — not per-frame, per-second of video.

Strengths ​

  • TeX-native typesetting. Labels and math are set by the document compiler itself — no LaTeX→SVG shell-out, no font skew, perfect consistency with body text. The single capability a Manim-class engine most envies.
  • Resolution independence. Vector output (PDF/PS/SVG) is sharp at any zoom and at print DPI; TikZ makes no rasterization decision — the viewer does.
  • Deterministic and reproducible. Same source → identical vector output; no RNG, no GPU variance. Externalization gives content-hash-style figure caching.
  • Mature, vast, and stable. ~1300-page manual, two decades of development, huge library/package ecosystem (pgfplots, tikz-cd, circuitikz, beamer), and a clean three-layer frontend/basic/system architecture.
  • Portable. One source renders under pdftex, xetex+dvipdfmx, or dvisvgm unchanged — the system layer abstracts every driver.
  • Declarative, composable syntax. Key-value styles, \foreach, decorations, and calc/intersections make complex diagrams concise and parameterizable.

Weaknesses ​

  • Not a video/animation engine. No timeline, no interpolation/easing library, no shape morph. Animation is SVG/SMIL-only ("very unlikely that pdf will ever support animations" tikz-animations) or discrete beamer slide steps.
  • No rasterizer / no pixel access. Cannot read back frames; producing a raster or video is an external, bolted-on pipeline (ffmpeg/convert over per-instant PDFs).
  • No retained, mutable scene graph. Paths are emit-and-forget; nodes are static once compiled — no Mobject to grab and animate.
  • Slow for heavy figures. TeX-register coordinate math, no GPU; complex pictures dominate compile time (mitigated only by externalization).
  • Offline authoring. Edit-compile-view loop; no live canvas, scrubber, or interactive preview in the tool itself.
  • No linear-light compositing. Colours come from xcolor and are passed as device colours to the driver; there is no gamma-correct linear-space blend model because there is no per-pixel compositing stage.

Key design decisions and trade-offs ​

DecisionRationaleTrade-off
Run inside TeX; text is native TeX ("TikZ ist kein Zeichenprogramm")Labels/math typeset by the document compiler — perfect consistency, no external LaTeX→SVG shell-outBound to the document-compile model; produces a page, never a movie; slow macro-expansion math
Three layers: TikZ frontend → PGF basic layer → \pgfsys@ driverPortable core; one source → PDF/PS/SVG; frontends (TikZ, pgfpict2e) and packages (beamer) swapEvery backend needs a pgfsys-⟨driver⟩.def; feature parity across drivers is uneven
Emit vector operators; no built-in rasterizerResolution independence; deterministic, viewer-agnostic outputCannot read back pixels or produce raster/video without an external pipeline
Cubic-Bézier .. controls .. path model (MetaPost lineage)Standard, expressive curves; hobby library adds equation-solved MetaPost splinesCurve morphing is not a primitive; no point-count alignment for shape-to-shape tweens
Animation = SVG/SMIL annotation, computed by the viewerNo file-size/compile-time cost; declarative motion "for free" in a browserSVG-only; PDF unsupported; no continuous morph timeline — snapshots or beamer steps for print/PDF
Static figure, no timeline/execution modelMatches the document-figure purpose; deterministic and cacheableNone of the survey's five execution models applies; "animation" is out of scope by design
Externalization for figure cachingSkip re-rendering unchanged pictures — the play()-cache analog at picture granularityCoarse (whole-picture) granularity; adds build plumbing (\tikzexternalize)
Extensibility via pgfkeys styles + loadable librariesVast, composable vocabulary without core changes; whole packages build on the basic layerTeX-macro API surface; debugging expansion/keys is arcane; no type safety

Sources ​

  • pgf-tikz/pgf — the PGF/TikZ source repository (Till Tantau, Henri Menke, Christian Feuersänger, the PGF/TikZ Team); README positioning ("a TeX macro package for generating graphics … a user-friendly syntax layer called TikZ").
  • doc/generic/pgf/licenses/LICENSE — dual licensing: code under GNU GPL v2 or LPPL 1.3c; documentation under GNU FDL 1.2 orLPPL 1.3c; "you can decide which license you wish to use when using the pgf package."
  • CTAN: pgf — package metadata: Version 3.1.11a, 2025-08-29; licenses (GPL v2 / LPPL 1.3c / GNU FDL); "PGF is a macro package for creating graphics … works together with the most important TeX backend drivers, including pdfTeX and dvips."
  • Design Principles (pgfmanual) — "TikZ ist kein Zeichenprogramm"; TikZ's job ("easy-to-learn and easy-to-use syntax for describing graphics"); the metafont/pstricks/svg/graphviz influences.
  • Design Principles of the basic layer — the three-layer architecture; "The basic layer does not provide a convenient syntax … left to frontends like TikZ"; beamer uses the basic layer directly; TikZ vs pgfpict2e as frontends.
  • The System Layer — "This interface provides a complete abstraction of the internals of the underlying drivers"; the \pgfsys@… command family.
  • Supported Formats — backend drivers luatex/pdftex/dvips/ dvipdfm/dvipdfmx/dvisvgm/tex4ht; the dvisvgm driver emits "raw svg code … including text and fonts."
  • The Curve-To Operation (pgfmanual §14.3) — "The curve is a cubic Bézier curve"; two control points c, d; the tangent construction.
  • Nodes and Edges — "A node is typically a rectangle or circle or another simple shape with some text on it"; the north east/center anchor model.
  • Repeating Things: \foreach — "execute the ⟨commands⟩ repeatedly, once for every element of the ⟨list⟩"; {1,2,...,6} range expansion.
  • Decorated Paths — "Decorations are a general concept to make (sub)paths 'more interesting'"; path morphing / replacing / removing.
  • Animations — SVG/SMIL-only; the "annotation … the viewer computes and displays"; "very unlikely that pdf will ever support animations"; snapshots for PDF.
  • Introduction / manual home — history: "What began as a small LaTeX style for creating the graphics in Till Tantau's PhD thesis … has now grown to become a full-blown graphics language with a manual of over a thousand pages."
  • Creating Overlays (beamer manual) — \pause, \only, \onslide, \visible overlay specifications for slide-step reveals.
  • hobby package (Andrew Stacey) — "The algorithm was devised as part of the MetaPost program"; \usetikzlibrary{hobby} for equation-solved MetaPost splines.

NOTE

No runnable CI probe ships with this page. The catalog's convention is a CI-compiled D probe per deep-dive, but TikZ is a TeX macro package with no D API to exercise; its behaviour is a document-compile artifact, not a callable library. The shared geometry probes still apply by contrast — the cubic-Bézier curve-to operator is the bezier-eval.d cubic case, and TikZ scope transforms are the general affine-transform.d composition — but no new TeX-driving probe was added, as none would compile-and-run under the ci --example-files D toolchain.