Turn the lamp down on a figure, rather than take its paper away - #155
Merged
Merged
Conversation
A figure carries its own white inside the SVG, where no stylesheet reaches it. On a dark page that is a lit rectangle, and after 0.1.7 it was the one thing left bright. Taking the white away is not the fix it looks like: the axes and labels are dark ink and would be left dark on dark. So the page dims it instead. `brightness(.85)` makes the paper #d9d9d9 — measured there, ink/paper 14.9, axis/paper 7.2, a plotted line 4.4 (a graphical object wants 3), and the figure still stands 12.3 off the card. Chosen by looking at 1.00 / 0.92 / 0.85 / 0.78 against a real figure: 0.92 barely helps, 0.78 muddies the data. The token check caught its own blind spot on the way in. It read `#d9d9d9` out of the comment explaining the choice and called it a hard-coded colour, because it scanned the sheet without stripping comments first. A colour named in a `/* … */` is not a colour the sheet draws with — Archeion's equivalent check already knew that, and this one now does too. A mitigation, not a fix. The fix is figures not drawn on white, which belongs to whoever writes the report. Archeion carries the same rule in the layer it derives for reports frozen before this existed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
|
📚 Docs preview: https://QAtlasHub.github.io/Pinax.jl/previews/PR155/ (updates on each push to this PR) |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A figure carries its own white inside the SVG, where no stylesheet reaches it. On a dark page that is a lit rectangle — and after #154 it was the one thing left bright.
Taking the white away is not the fix it looks like: the axes, ticks and labels are dark ink, and without the paper they would be dark on dark. So the page dims it instead.
Why 0.85
Looked at 1.00 / 0.92 / 0.85 / 0.78 side by side against a real figure — 0.92 barely helps, 0.78 muddies the data — then checked the numbers:
brightness(.85)#ffffff→#d9d9d9The token check caught its own blind spot
On the way in, the check added in #154 failed — it read
#d9d9d9out of the comment explaining the choice and called it a hard-coded colour, because it scanned the sheet without stripping comments. A colour named in a/* … */is not a colour the sheet draws with. Archeion's equivalent check already knew that; this one now does too.A mitigation, not a fix. The fix is figures not drawn on white, which belongs to whoever writes the report. Archeion carries the same rule in the layer it derives for reports frozen before this existed (QAtlasHub/Archeion.jl#71).
Version 0.1.7 → 0.1.8.
🤖 Generated with Claude Code