GeezerVison

display: inline;

.sdd.sd-dropdown {

box-shadow: none!important;

.sdd.sd-dropdown .sd-card-header +.sd-card-body{

--pst-sd-dropdown-color: none;

.section-toc.toctree-wrapper .toctree-l1>a{

display: none;

.section-toc.toctree-wrapper li>ul{

padding-inline-start:0;

In the Python files, to exclude an example from having a plot generated, insert

"sgskip" somewhere in the filename.

Format examples

The format of these files is relatively straightforward. Properly

formatted comment blocks are treated as ReST_ text, the code is

The first comment block is treated as ReST_ text. The other comment blocks

render as comments in :doc:`/gallery/lines_bars_and_markers/simple_plot`.

Tutorials are made with the exact same mechanism, except they are longer, and

Tutorials are made with the exact same mechanism, except they are longer and

typically have more than one comment block (i.e. :ref:`quick_start`). The

first comment block can be the same as the example above. Subsequent blocks of

ReST text are delimited by the line ``# %%`` :

any ``*.rst`` files to a ``:toctree:``, either in the ``README.txt`` or in a

manual ``index.rst``.

Examples guidelines

The gallery of examples contains visual demonstrations of matplotlib features. Gallery

examples exist so that users can scan through visual examples. Unlike tutorials or user

guides, gallery examples teach by demonstration, rather than by explanation or

instruction.

Gallery examples should contain a very brief description of *what* they demonstrate and,

when relevant, *how* it is achieved. Avoid instructions or excessive explanation;

instead, tag with related concepts and cross-link to relevant tutorials or user guides.

Format

All :ref:`examples-index` should aim to follow the following format:

:Title: Describe content in a short sentence (approx. 1-6 words). Do not use *demo* as

this is implied by being an example. Avoid implied verbs such as "creating,

making, etc", e.g. "annotated heatmaps" is preferred to "creating annotated

heatmaps". Use the simple present tense when a verb is necessary, e.g. *Fill the

area between two curves*

:Subtitle: In a short paragraph (approx 1-3 sentences) describe what visualization

technique is being demonstrated and how library features are used to execute

the technique, e.g. *Set bar color and bar label entries using the color and

label parameters of ~Axes.bar*

:Plot: Clearly demonstrate the subject and, when possible, show edge cases and different

applications. While the plot should be visually appealing, prioritize keeping the

plot uncluttered.

:Code: Write the minimum necessary to showcase the feature that is the focus of the

example. Avoid styling and annotation-such as setting titles, legends, colors,

etc.- when it will not improve the clarity of the example.

:Text: Use short comments sparingly to describe what hard to follow parts of code are

doing. When more context or explanation is required, add a text paragraph before

the code example.

Example:

The ``bbox_intersect`` gallery example demonstrates the point of visual examples:

* this example is "messy" in that it's hard to categorize, but the gallery is the right

spot for it because it makes sense to find it by visual search

* https://matplotlib.org/devdocs/gallery/misc/bbox_intersect.html#sphx-glr-gallery-misc-bbox-intersect-py

Miscellaneous

Tag Glossary

API tags: what content from the API reference is in the example?

Domain tags: what discipline(s) might seek this example consistently?

It's futile to draw fences around "who owns what", and that's not the point of domain tags. Domain tags help groups of people to privately organize relevant information, and so are not displayed publicly. See below for a list of existing domain tags. If you don't see the one you're looking for and you think it should exist, consider proposing it.

It's futile to draw fences around "who owns what", and that's not the point of domain

tags. See below for a list of existing domain tags. If you don't see the one you're

looking for and you think it should exist, consider proposing it.

|``tag`` | use case |

Internal tags: what information is helpful for maintainers or contributors?

These tags should be used only for development purposes; therefore please add them

separately behind a version guard:

.. code:: rst

|``tag`` | use case |

Why do we need tags?

Tags serve multiple purposes.

Tags have a one-to-many organization (i.e. one example can have several tags), while the gallery structure requires that examples are placed in only one location. This means tags provide a secondary layer of organization and make the gallery of examples more flexible and more user-friendly.

Tags have a one-to-many organization (i.e. one example can have several tags), while

the gallery structure requires that examples are placed in only one location. This means

tags provide a secondary layer of organization and make the gallery of examples more

flexible and more user-friendly.

They allow for better discoverability, search, and browse functionality. They are helpful for users struggling to write a search query for what they're looking for.

They allow for better discoverability, search, and browse functionality. They are

helpful for users struggling to write a search query for what they're looking for.

Hidden tags provide additional functionality for maintainers and contributors.

How to tag?

Place the tag directive at the bottom of each page and add the tags underneath::

What gets a tag?

* 1+ content tags

* structural, domain, or internal tag(s) if helpful

Tags can repeat existing forms of organization (e.g. an example is in the Animation folder and also gets an ``animation`` tag).

Tags can repeat existing forms of organization (e.g. an example is in the Animation

folder and also gets an ``animation`` tag).

Tags are helpful to denote particularly good "byproduct" examples. E.g. the explicit

purpose of a gallery example might be to demonstrate a colormap, but it's also a good

demonstration of a legend. Tag ``legend`` to indicate that, rather than changing the

title or the scope of the example.

**Tag Categories** - See :doc:`Tag Glossary <tag_glossary>` for a complete list of tags.

**Tag Categories**

^^^

.. rst-class:: section-toc

I. API tags: what content from the API reference is in the example?

II. Structural tags: what format is the example? What context can we provide?

III. Domain tags: what discipline(s) might seek this example consistently?

IV. Internal tags: what information is helpful for maintainers or contributors?

.. toctree::

:maxdepth: 2

tag_glossary

+++

See :doc:`Tag Glossary <tag_glossary>` for a complete list

Proposing new tags

1. Review existing tag list, looking out for similar entries (i.e. ``axes`` and ``axis``).

2. If a relevant tag or subcategory does not yet exist, propose it. Each tag is two parts: ``subcategory: tag``. Tags should be one or two words.

3. New tags should be be added when they are relevant to existing gallery entries too. Avoid tags that will link to only a single gallery entry.

2. If a relevant tag or subcategory does not yet exist, propose it. Each tag is two

parts: ``subcategory: tag``. Tags should be one or two words.

3. New tags should be be added when they are relevant to existing gallery entries too.

Avoid tags that will link to only a single gallery entry.

4. Tags can recreate other forms of organization.

Note: Tagging organization aims to work for 80-90% of cases. Some examples fall outside of the tagging structure. Niche or specific examples shouldn't be given standalone tags that won't apply to other examples.

How to tag?

Put each tag as a directive at the bottom of the page.

Related content

What is a gallery example?

The gallery of examples contains visual demonstrations of matplotlib features. Gallery examples exist so that users can scan through visual examples.

Unlike tutorials or user guides, gallery examples teach by demonstration, rather than by explanation or instruction.

Gallery examples should avoid instruction or excessive explanation except for brief clarifying code comments. Instead, they can tag related concepts and/or link to relevant tutorials or user guides.

Format

All :ref:`examples-index` should aim to follow the following format:

* Title: 1-6 words, descriptive of content

* Subtitle: 10-50 words, action-oriented description of the example subject

* Image: a clear demonstration of the subject, showing edge cases and different applications if possible

* Code + Text (optional): code, commented as appropriate + written text to add context if necessary

Example:

The ``bbox_intersect`` gallery example demonstrates the point of visual examples:

* this example is "messy" in that it's hard to categorize, but the gallery is the right spot for it because it makes sense to find it by visual search

* https://matplotlib.org/devdocs/gallery/misc/bbox_intersect.html#sphx-glr-gallery-misc-bbox-intersect-py

Tagging organization aims to work for 80-90% of cases. Some examples fall outside of the tagging structure. Niche or specific examples shouldn't be given standalone tags that won't apply to other examples.

- sphinx-copybutton

- sphinx-gallery>=0.12.0

- sphinx-design

- sphinx-tags>=0.3.0

- sphinx-tags>=0.4.0

- pip

- pip:

- mpl-sphinx-theme~=3.8.0

# sphinxext.redirect_from

"redirect-from",

# sphinx-design

"card",

"dropdown",

"grid",

"tab-set",

sphinx-copybutton

sphinx-design

sphinx-gallery>=0.12.0

sphinx-tags>=0.3.0

sphinx-tags>=0.4.0