fix: preserve normalized colors in PDF output

[besmpl]

Summary

• preserve gg's normalized RGB values when translating PDF fills, strokes, text colors, and gradient stops
• apply solid-fill alpha directly instead of scaling it a second time
• centralize the shared gg-to-gxpdf color conversion
• replace invalid 255-based test fixtures and add focused color/opacity regressions

Root cause

Both gg.RGBA and creator.Color define color components in the range [0,1]. The backend divided gg components by 255 again, turning ordinary colors almost black and alpha almost transparent.

Verification

• solid fills preserve normalized RGB and alpha
• linear, radial, and sweep gradient strokes preserve their normalized first-stop fallback color
• go test -count=1 ./...
• go test -race -count=1 ./...
• go test -count=1 -coverprofile=coverage.out ./...
• local added executable-line patch coverage: 100% (12/12)
• go vet ./...
• go build ./...
• go mod tidy -diff
• gofmt and git diff --check

The PDF library's gradient, stroke, and text color APIs are RGB-only, so their pre-existing alpha limitation is unchanged. Solid fill opacity is covered by the regression tests.

Upstream GitHub Actions and codecov/patch are configured but await maintainer approval of the fork workflow run.

[kolkov]

Good catch — gg.RGBA components are normalized [0, 1], same as creator.Color. The /255.0 division was producing nearly-black colors for everything.

The colorFromGG helper centralizes the conversion nicely, and the opacity fix (br.Color.A instead of br.Color.A / 255.0) is correct.

Tests updated to use gg.RGB() / gg.RGBA2() constructors — much cleaner than the old {R: 255, ...} literals that implied byte-range values.

LGTM, merging.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!