Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve texture coloring on bar/area #1202

Open
markov00 opened this issue Jun 14, 2021 · 3 comments
Open

Improve texture coloring on bar/area #1202

markov00 opened this issue Jun 14, 2021 · 3 comments
Labels
:accessibility Accessibility related issue enhancement New feature or request released Issue released publicly :styling Styling related issue

Comments

@markov00
Copy link
Member

Is your feature request related to a problem? Please describe.
A texture or a pattern should always start from the same point on the geometry.
When resizing, the texture/pattern should not move around.

Jun-14-2021 10-34-29

Describe the solution you'd like
The texture should probably always start from the baseline, or anyway always start at the same point in the geometry.
In this case, for example, the dot pattern on every bar starts at a different x position. This can reduce the readability because the pattern effect introduces artifacts on how the bars are rendered.
Screenshot 2021-06-14 at 10 41 14

We can also discuss if the texture should use:

  • screen pixels: this means that the texture doesn't rescale with the chart size, the texture is always the same but the image can be clipped
  • projection size: the pattern is applied based on one dimension of the geometry (height or width) and is rescaled based on that with the chart size.

Describe alternatives you've considered
n/a

Additional context
Needs as follow up of #1138

Kibana Cross Issues
Not yet used in Kibana

@markov00 markov00 added enhancement New feature or request :styling Styling related issue :accessibility Accessibility related issue labels Jun 14, 2021
@markov00 markov00 added this to Backlog in Accessibility via automation Jun 14, 2021
Accessibility automation moved this from Backlog to Done Aug 16, 2021
nickofthyme pushed a commit that referenced this issue Aug 16, 2021
# [34.0.0](v33.2.4...v34.0.0) (2021-08-16)

### Code Refactoring

* **cartesian:** cartesian rendering iteration ([#1286](#1286)) ([b2ae4f7](b2ae4f7)), closes [#1202](#1202)

### BREAKING CHANGES

* **cartesian:** - `TextStyle.fontStyle` is no longer a `string`, it's the more specific `FontStyle`
- For symmetry, `fontStyle` in word cloud is also switching from `string` to `FontStyle`
- Certain text configurations included both `fill` and `textColor` for the text color; `fill` got removed, because `textColor` is part of the public `Font` type, and because `textColor` has clearer meaning than `fill`. Yet, some of the code used the `fill` property and/or made the `fill` property also mandatory. So, userland code needs to remove some `fill` property, and might need to ensure that the correct value is going into `textColor`
- `getRadians` got unpublished
- No attempt to draw a rect border if there's not enough width/height for at least the specified border width (ie. width/height being at least twice the border width)
@nickofthyme
Copy link
Collaborator

🎉 This issue has been resolved in version 34.0.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@nickofthyme nickofthyme added the released Issue released publicly label Aug 16, 2021
@monfera
Copy link
Contributor

monfera commented Aug 17, 2021

While this issue auto-closed due to mention of the partial solution brought by #1286 there is still much opportunity to refine the size responsiveness of pattern fill, referenced in the further improvements meta issue #1303. Once work continues, this issue can be reopened or a new one can be created. I've some preference for the latter, as, during the review process, we discussed specific approaches toward future improvements, such as options for integral (full, unclipped) tile counts for consistent aesthetic of the bar thickness coverage, and roughly constant ratios (eg. approx. tile pixel size) to go with it; and the attention we need to give to negative bars

@nickofthyme nickofthyme reopened this Aug 17, 2021
Accessibility automation moved this from Done to Backlog Aug 17, 2021
@nickofthyme
Copy link
Collaborator

I think the idea of this issue was to make the patterns independent such that changing the size doesn't shift the values, as if it is masking a picture in the background, but that each follows their respective bar.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:accessibility Accessibility related issue enhancement New feature or request released Issue released publicly :styling Styling related issue
Projects
No open projects
Accessibility
  
Backlog
Development

No branches or pull requests

3 participants