search

yuzutech / kroki

Creates diagrams from textual descriptions!
https://kroki.io
MIT License
2.79k stars 206 forks source link

[Feature Request] Setting background color with a diagram option #1281

Open onnyyonn opened 2 years ago

onnyyonn commented 2 years ago

Some libraries allow changing the background color or theme of the diagram, such as Mermaid or PlantUML. But many of them don't. A few of the libraries (Actdiag, Blockdiag etc.) returns a transparent SVG which is often unreadable on a dark background.

Is it possible to set the background color of the SVG using fill? If it's possible, and a global diagram option is created for it, we'll be able to set the background without having to rely on upstream.

ggrossetie commented 2 years ago

I definitely want to "support" dark mode but I think it should be supported upstream. What Kroki can do is provide a generic option to activate dark mode (i.e., automatically infer which options need to be configured). For instance, on svgbob it should configure background to black and, most likely, fill-color to white, on PlantUML, it should use a dark mode theme and so on...

onnyyonn commented 2 years ago

Thanks for your response. Your proposal of the dark mode support is a great idea. But what I was suggesting is a bit different. Please let me clarify.

My proposal mostly concerns readability. Right now, there is no readability issue with PalantUML or Svgbob. They provide dark elements on a white background. This white background may not match with a dark-themed website or app. But that's an aesthetics issue, not a readability issue.

On the other hand, BlockDiag or ActDiag returns dark elements on a transparent background, which is not readable on a dark website or app. What I am suggesting is, passing fill=white (or fill=<bg-color> where <bg-color> is defined by user) with the SVG. I feel this would solve all readability issues, unless it can't be implemented due to some technical reason that I am not aware of. And it seems we don't have to rely on upstream for that. Please correct me if I am wrong.

What your proposal solves is the aesthetics issue. But that is not what I am asking for here. Because there are some usecases I can think of, where that issue is not solvable. For example many apps and some websites support dynamic / manual theme switching. So no matter which color you choose for the SVG, chances are it won't look good on some theme.

ggrossetie commented 2 years ago

I've created the following issues upstream:

And it seems we don't have to rely on upstream for that. Please correct me if I am wrong.

Technically, we could postprocess the SVG produced by BlockDiag but it would be somewhat brittle since we won't parse the SVG but replace/insert/update text using a regular expression.

Because there are some usecases I can think of, where that issue is not solvable. For example many apps and some websites support dynamic / manual theme switching. So no matter which color you choose for the SVG, chances are it won't look good on some theme.

If the SVG is embed in the HTML page then you can update SVG attributes (using JavaScript) when switching from light to dark theme. If the SVG is not embed then you could ask Kroki to generate a "dark" or "light" version depending on the chosen theme.

It's somewhat related but it might be a good idea to normalize the default style between diagram libraries. For instance, even if BlockDiag does have a transparent background by default, Kroki could automatically configure a white background to match other diagram libraries.

onnyyonn commented 2 years ago

It's somewhat related but it might be a good idea to normalize the default style between diagram libraries. For instance, even if BlockDiag does have a transparent background by default, Kroki could automatically configure a white background to match other diagram libraries.

Yes, I agree. A common default style would make styling them easier for the users.