files checked and corrected

[max123kl]

customized color scheme that better matches the former look

[ben]

Nice! I was trying to figure out why the images changed size, but it looks like you removed the hard dimensions, which is probably better.

Also, we haven't discussed your use of fill-opacity:.8. I'm not sure I like it. If you don't like the starkness of pure white, maybe we should use a slightly-muted gray like #f8f8f8 instead?

[lazarljubenovic]

If you don't like the starkness of pure white, maybe we should use a slightly-muted gray like #f8f8f8 instead?

Gray on orange would cause colors to bleed. The "let's use gray instead of black" actually comes from lowering the opacity of black text on white background, the most common color combination. So the strategy used in the image is good (reducing the contrast slightly to make everything blend in more naturally, as in real life light would reflect off the orange surface and make white text slightly orange). You can see examples here: https://material.io/design/color/text-legibility.html#text-backgrounds

That said, I also think that 0.8 is too low for white text. I'd boost it to 0.90-0.95.

[max123kl]

@ben

Nice! I was trying to figure out why the images changed size, but it looks like you removed the hard dimensions, which is probably better.

I haven't paid any attention to that yet. With SVG files it doesn't matter, because the quality of the images doesn't depend on the size.
The desired image width should always be specified for embedding in the following documents (e.g. CSS: <img src="…" width="400" ...>).
Possibly, I have chosen an option with Inkscape, when saving as "optimized SVG", which makes a "hard dimension" unnecessary. As it makes no difference for further use, it would only be "nice to know". On occasion, I will check which option is used for that.

Also, we haven't discussed your use of fill-opacity:.8. I'm not sure I like it. If you don't like the starkness of pure white, maybe we should use a slightly-muted gray like #f8f8f8 instead?

How did you find out the color #feddd6? Maybe it was a tool, like the browser addon Colorzilla, on a browser output?
Then this is the solution: The browser renders the data in the SVG file (fill="white" fill-opacity=".8") to the mixed color #feddd6. The rendered color can (is often) slightly different on different computers/monitors. Here I get the value of #fcd4cb. To avoid this completely you would have to do color management, which is extremely complex, requires, that such a system is installed on the server as well as on the users' computers, and finally it is completely utopian on the web that it would work.

The reason I chose this combination: I wanted the color of the surrounding area to have a small effect on the text. I prefer this to the very hard contrast with white. The attribute fill-opacity=".8" means that the color white (defined with fill="white" or fill=#ffffff) is included to 80% in the mixed color. The remaining 20% come from the underlying color. Therefore, the font in "HEAD" is also slightly yellowish.
If you prefer gray, then (#f8f8f8) is too bright to be recognized as gray. This color is mixed with white and only 3% black. A color that is seen as very light gray should contain at least 8% black (#ebebeb).
Another suggestion would be to use the background color (#efefe7) of the light gray fields (e.g. c2b9e) as the fill color of the text in fields like "HEAD" or "master".

@lazarljubenovic

That said, I also think that 0.8 is too low for white text. I'd boost it to 0.90-0.95.

My intention was to recognize the influence of the underlying color without reducing the contrast too much. The value of 0.95 would produce a barely noticeable color effect.

[ben]

Gray on orange would cause colors to bleed.

These images are used for a website and ebooks, and if printed at all will most likely be converted to grayscale.

I wanted the color of the surrounding area to have a small effect on the text. I prefer this to the very hard contrast with white.

This is an aesthetic judgement, which I disagree with. I don't like how the orange rectangle gives the text on it a pink hue.

How did you find out the color #feddd6? [...] Here I get the value of #fcd4cb. [...] The rendered color can (is often) slightly different on different computers/monitors. [...] The remaining 20% come from the underlying color.

I understand why you did it. I understand how transparency works. I understand that different browsers render transparency differently. I get all that, and I'm saying I won't merge this unless the R, G, and B values are all equal. If #ffffff and #f8f8f8 are too bright, consider #f0f0f0.

[max123kl]

No problem, I'll change that the way you want.
What about the texts, which look pretty black in some diagrams (e.g. local.png). Should they remain as dark (possibly a darker grey instead of black) or as grey as in the new SVG files?

[ben]

Yeah, a bit more contrast on the gray ones might be nice. The current is #979797, maybe we want something more like #808080?

[max123kl]

I think the #808080 is better and will continue with it.

[jnavila]

@max123kl do you want me to mass convert?

[max123kl]

That would be nice. If you can select that so well.
I will create a table as soon as possible to specify the colors exactly.

[max123kl]

The files replace*.svg, reset-*.svg have predefined transparencies in underlying fields, do not touch these definitions.
Text color in these fields should be #808080.

[jnavila]

I made the mass rewrite on the original filtered_svg branch. Please tell me if it's ok for you. I may still spend some more time to refine the detection pattern. As of now, the detection is made on groups containing a rectangle and some texts. Please do not upset this hierarchy, because otherwise automatic processing becomes almost impossible.

Incidentally, I spotted that some texts were centered erroneously, for instance in commit-and-trees.svg. This files should probably brought back to the state when ben generated them.

[max123kl]

I quickly looked at some files in your branch filtered_svg.

The files replace*.svg, reset-*.svg have predefined transparencies in underlying fields, do not touch these definitions.
Text color in these fields should be #808080.

e.g. Look at the faded color fields like in the file. IMHO, I think that there the color #808080 would be better than #f0f0f0. This gives a better contrast. It's your decision.

Sorry, but I don't have time enough, until late afternoon (time zone here UTC+1), to work on it again.
Then, I will delete my local branch max123kl:filtered_svg and re-insert a current clone of your branch. I will start a new PR if I do some fixes.
Is this the best way to go, or do you have any better advice?

[max123kl]

@ben
Please compare file1 with file2

There are some other files with similar problems.
Should I use the PNG data when correcting text position and color?
Here's my proposed fix.

[ben]

Sorry for the delay. Here's a side-by-side, PNG on the left:

I see a few issues, but I think what you're asking is whether the PNG should be considered the "right" version. In general I think the answer is yes, although there are probably some things about the PNG that could be improved, and if you see an obvious bug, I'd say go ahead and fix it.