`scale_fill_gridpattern()`

[trevorld]

• There are a bunch of {ggplot2} fill color scales e.g. scale_fill_brewer(), scale_fill_distiller(), scale_fill_gradient(), scale_fill_grey(), scale_fill_hue(), scale_fill_viridis(), ...
• Now that {ggplot2} and {ggpattern} support pattern fills should we provide scale(s) of {gridpattern} patternFill() pattern fills?
• We may want a variety of these...?
• And perhaps scale_pattern_fill_gridpattern() ggpattern#119 since {ggpattern} supports patterned pattern_fill values...

[trevorld]

Some design notes from a brainstorming session:

Scope: geometry patterns only

Array-based patterns (plasma, ambient, image, magick) are raster/resolution-dependent and wrong for accessible/B&W chart use. The scale should be geometry-only. Users who want array fills can still use scale_fill_manual(values = list(...)) directly.

Primary design axis: pattern type; secondary: colour

The main axis of variation should be pattern type (stripe, crosshatch, circle, wave, regular_polygon subtypes, etc.), since that gives the most visually distinct fills. An optional colours argument would allow colour to vary alongside pattern type:

• colours = "black" → monochrome default (pattern type alone distinguishes groups; B&W/print safe)
• colours = c("red", "blue", ...) → manual colour per level
• colours = scales::hue_pal() → palette function, ggplot2-style

Palette functions

A named-palette approach (gridpattern_pal("monochrome"), gridpattern_pal("heraldic")) seems like the right abstraction. Each palette is a list of full patternFill() argument sets — inspectable and extensible:

gridpattern_pal <- function(palette = "monochrome") {
  specs <- gridpattern_palettes[[palette]]
  function(n) lapply(specs[seq_len(n)], function(p) do.call(patternFill, p))
}

This mirrors how scales::hue_pal() etc. work, and lets scale_fill_gridpattern() be a thin wrapper around ggplot2::discrete_scale().

Named palettes

Two natural starting palettes:

"monochrome" — varies pattern type, all black; 7–8 entries covering the most visually distinct geometry patterns:

n	pattern	notes
1	stripe, 0°	horizontal lines
2	crosshatch
3	circle (filled dots)
4	stripe, 45°	diagonal lines
5	regular_polygon, triangle
6	regular_polygon, hexagon
7	wave

"heraldic" — follows the Petra Sancta (1638) system still used in Unicode charts, flags, coin engraving; naturally maps patterns ↔ tincture colours:

n	pattern	tincture	colour
1	none (blank)	Argent	white/silver
2	dots	Or	gold
3	stripe 0°	Azure	blue
4	stripe 90°	Gules	red
5	stripe 45°	Vert	green
6	stripe 135°	Purpure	purple
7	crosshatch	Sable	black

The heraldic palette is interesting because it works both as a B&W pattern scale and as a colour-plus-pattern scale with semantically grounded color assignments — though the Petra Sancta system does have some historical variants (Zangrius 1600, de la Colombière 1639 differ slightly on a few tinctures).

How many groups?

He et al. (2023, IEEE TVCG) specifically studied B&W textures for categorical data and tested up to 7 categories successfully. Their key discrimination axes: element type > orientation > density/size. This matches the 7-entry palettes above. For n > 7 we should probably warn and recycle rather than silently generate confusable patterns.

Accessibility/journal context

• Nature explicitly recommends Okabe-Ito + patterns for colorblind safety; prohibits rainbow schemes; requires non-colour redundancy.
• IEEE recommends using both colour and shape/pattern together.
• Neither mandates specific pattern sets, just non-colour redundancy.

This suggests a natural "okabe_ito" palette variant as well — Okabe-Ito colours applied as fill to a consistent pattern (e.g. stripe), or paired with the monochrome pattern sequence.

USGS geological patterns

The FGDC-STD-013-2006 standard has hundreds of patterns for rock/sediment types — too domain-specific for a general palette, but could be a named palette option for geo users in future.

Open questions

1. Should colours be the argument name, or palette (to match ggplot2 convention where palette accepts a function)?
2. Should gridpattern_palettes be an exported named list so users can inspect and extend?
3. Should patternFill(group = TRUE/FALSE) be exposed in the scale? (group = TRUE tiles the whole panel; group = FALSE gives each bar its own tile.)
4. Tiling patterns (polygon_tiling with "hexagonal", "tetrakis_square", etc.) are visually very distinct — include in the default sequence or as a separate "tiling" style palette?