Sign inRegisterCheck connection

GD Weather Banner Reference: Dimensions, Fonts, and Unit Strings

Reference card for PHP-GD weather banners: canvas dimensions, font requirements, and unit strings copied from the station packet rather than assumed.

Back to Cumulus weather software guides

A weather banner is a wide identity image: a PNG meant for a site header, a webring slot, or a hot-linked strip on someone else’s page. It is not a square avatar, and it is not a live dashboard. This page is the reference card for the banner family: canvas dimensions, fonts, and unit strings. Rendering failures and “live” claims that outrun the file cadence belong on /projects/phpggbanner.

Spelling. Historical TNET URLs use both phpGDbanner (this reference: PHP’s GD graphics library) and phpGGbanner (project and gallery paths). Treat them as one banner family with two URL spellings. This card documents the family. It does not clone the project-history page.

Historical context

Cumulus operators wanted a single strip that still looked like a station when dropped into HTML that they did not control. PHP GD drew the strip from realtime.txt or from web tags. Sample galleries (including historical banner-sample addresses on the main host) collected other people’s strips. The scientific problem was never the gradient. It was whether the strip remained a labeled observation when it was 468 pixels across and 60 pixels tall.

The reference hub asks every card for inputs, outputs, versions, license, and breaking changes. The avatar card already specified cache headers and the minimum observation set for a square. This page specifies what changes when the canvas is wide: geometry, typography, and unit tokens as first-class strings.

TNET does not rehost banner PHP or font files.

Dimensions: the banner is a geometry contract

Unlike avatars, banners inherited advertising IAB widths as de facto slots: 468×60 was a common “full banner” class; 728×90 a “leaderboard” class; many station strips were custom (for example 500×80 or 550×100). Do not treat any of those numbers as a recovered TNET factory default unless a dated capture says so. Do treat declared width × height as mandatory documentation.

The card should state:

  • Pixel width and height of the GD canvas, and whether a transparent margin is part of that canvas.
  • Hot-link slot the strip was designed for (header, signature, remote <img>). A 728-pixel strip in a 468-pixel table cell will squash unit glyphs into unreadable marks.
  • Aspect ratio lock. GD that stretches a 468×60 template to 728×90 changes font metrics. Document “fixed size” versus “scaled.”
  • DPI is not a substitute. Banners are pixel products. Printing them does not make the numbers climate-official.

A complete output line looks like: image/png, 468×60, 1:1 display, no client scaling. If the generator emits GIF for older forums, say so; palette limits will flatten temperature colour scales.

Compare with the avatar card: avatars fail by clipping digits; banners fail by packing too many variables into a strip that still looks “official.” Dimension docs exist to stop operators from adding a sixth quantity without adding pixels.

Fonts: the unit string is a rendering dependency

GD can draw with built-in bitmap fonts (imagestring) or with TrueType (imagettftext) if the host has FreeType and a .ttf file on disk. Those are different instruments.

Bitmap GD fonts. Always available if GD is available. They do not respect a degree glyph the way a TTF does. They clip poorly at small sizes. Document the GD font index and a maximum character count for the temperature field (“−14.5°C” versus “72”).

TrueType. Document:

  • the font file name and license (many TTFs are not GPL just because the PHP is);
  • the point size used for the primary temperature versus secondary wind/rain;
  • fallback when imagettftext is missing: bitmap font, or an error PNG, not a blank strip;
  • whether the degree sign, superscript, or a plain C/F token is used.

A banner that looks correct on the author’s Windows box and draws boxes on a Linux host is a font-path failure, not a weather failure. Record the path as a configuration item, not as a hardcoded drive letter in the public card.

Do not attach fonts to this site. Name them and point at their upstream license.

Unit strings: copy the packet, do not assume the locale

The most common silent error in a GD banner is drawing numbers in one unit system and captions in another. Cumulus realtime.txt carries the unit tokens in the classic map as:

| Classic field | Token | Typical values | |---|---|---| | 14 | wind | m/s, mph, km/h, kts | | 15 | temperature | C or F (no degree character in the token) | | 16 | pressure | mb, hPa, in | | 17 | rain | mm, in | | 54 | cloud base (if used) | ft or the packet’s cloud-base unit |

The Cumulus Wiki is the authority for field meaning; last checked 13 August 2026. MX may add fields; a banner parser is version-sensitive.

Rules for the card

  1. Print the token next to the number. 21.4 C is complete; 21.4 is not. 30.12 without in or hPa is not pressure.
  2. Do not convert on the canvas unless the conversion is documented as derived. If the packet is Fahrenheit, a banner that shows Celsius has become a derived product and must say so.
  3. Pressure tokens are not interchangeable captions. mb and hPa are numerically equal at this precision; in is not. Drawing hPa beside an inch value is a unit error, not a style choice.
  4. Rain needs a period. “0.00 in” without “today” (and a reset timezone) is an incomplete claim. If there is no room, omit rain rather than omit the period.
  5. Wind needs a quantity name. Average versus gust versus latest are different fields in the packet. A banner that labels all of them “wind” is not a reference-grade output.

Secondary derived indices (wind chill, heat index, humidex, apparent temperature, MX feels-like) follow the avatar rule: label them derived or leave them off. Zambretti-style forecast numbers are scenario output from the station program, not NWS products.

Cache and freshness (banner-specific note)

The avatar card specifies HTTP caching in full. Banners are more often hot-linked from foreign sites, which makes long max-age more damaging: a webring can show last week’s high as if it were current. Specify Cache-Control max-age on the order of the realtime interval, with ETag or Last-Modified derived from packet time (RFC 9111). Do not copy a year-long cache policy from a static logo.

If a gallery shows sample banners, those samples are historical artwork. They must not be served from the same URL as the live generator without a header that says they are examples.

Practical checklist

  1. Declare width × height, MIME type, and no-stretch intent.
  2. Declare font engine (bitmap vs TTF), file, size, and fallback.
  3. Map every printed number to a packet field and a unit token.
  4. Cite the Cumulus flavour and wiki map date.
  5. Label derived and scenario text.
  6. Set cache lifetime to the upload cadence.
  7. Record license for PHP and for fonts separately; no ZIP from this site.
  8. Send readers who need rendering and live-claim issues to /projects/phpggbanner.

Modern relevance

CSS and SVG can replace GD for new work. The card remains: geometry, typeface availability, and unit strings copied from the source record. A responsive banner that scales without a minimum font size recreates the 468-into-200 squash. JSON from MX does not include a font.

TNET research bridge

Which atmospheric quantities are worth summarizing in a short display is the same grouping problem TNET discusses in how the service works: observed, modelled, and derived information stay labeled. That page does not publish assembly weights. The Cumulus hub lists related historical pages. Source-file freshness and units are treated for research records in data sources, quality controls, and methodology.

Sources