Skip to content

RGBColor.Sequence truncation loses one RGB channel step for hex colours #217

Description

@sachiniyer

RGBColor.Sequence truncates each channel with uint8(f.R*255) (and G/B) after colorful.Hex converts token integers to floats. Floating-point representation can put the product just below the original integer, losing one channel step in both foreground and background SGR.

Reproduction with termenv v0.16.0 and go-colorful v1.4.0:

fmt.Println(termenv.RGBColor("#657084").Sequence(false))
// actual: 38;2;101;112;131
// expected: 38;2;101;112;132
fmt.Println(termenv.RGBColor("#eceff4").Sequence(true))
// actual: 48;2;236;239;243
// expected: 48;2;236;239;244

Other examples: #4c566a emits #4c5669; #2d6271 emits #2c6171. We found this while checking the actual Lip Gloss output against shared web/TUI design tokens in sachiniyer/agent-factory#3937.

Could RGBColor.Sequence use f.RGB255() (which rounds) or parse the integer channels directly? A local scratch change to r, g, b := f.RGB255() preserves all 12 of our roles in both themes for foreground and background. A regression test covering all 256 channel values would guard the full range.

We are retaining the released dependency and documenting a temporary one-step-per-channel tolerance downstream; we can tighten that test to exact bytes when a fixed release is available.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions