Ok, since some avians request amphibians to post something, here 
something goes.

For a long time I'm bored by the fact that, when I need some named 
colors in 0..1 range (like required by POV-Ray), I find them in 0.255 
range at best (at worst they are hexed).

Today I felt like I need having some color gradient to height color my 
img2mesh output to make it look like printed map coloring, and the first 
thing I found was:

https://www.cartotype.com/developers/documentation/style-sheets/terrain-shading-and-coloring

but surely they are referring to SVG named colors!

At this point my patience got exhausted, depleted etc., so I copy/pasted 
text from:

https://www.w3.org/TR/SVG11/types.html#ColorKeywords

with a little search/replace turned into a form of Python dictionary, 
which turned into a file which, being run, exports all these colors in 
the form of POV-Ray .inc file.

Resulting .inc file attached in case someone need these named colors.

Python file attached as well in case someone wish to change something in 
output format, like rounding (currently set to 3 decimals) etc.

Note that Python program writes its output in default working directory, 
which normally is the directory the program is placed to.

Note that color names are processed with .title() to make them start 
with Cap to avoid conflicts with POV-Ray keywords like "blue"; maybe 
someone prefer other naming scheme (like adding "_" or something), feel 
free to edit the program.

Anyway, now I do post something, and it's your turn.

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

Attachments:
Download 'svg_colors.inc.txt' (8 KB) Download 'svg_recognized_color_keyword_names.py.txt' (6 KB)

Ilya Razmanov <ily### [at] gmailcom> wrote:
> [snip]
>
> but surely they are referring to SVG named colors!
>
> At this point my patience got exhausted, depleted etc., so I copy/pasted
> text from:
>
> https://www.w3.org/TR/SVG11/types.html#ColorKeywords
>
> with a little search/replace turned into a form of Python dictionary,
> which turned into a file which, being run, exports all these colors in
> the form of POV-Ray .inc file.

Thanks for this.  I toyed around with this idea a few years ago, but I got the
sense that the list of colors varied from distro to distro, so I put it on
indefinite hold.  Looking at your source, I wonder if the inconsistencies may
have been because I was looking at X11 rather than SVG.

> Resulting .inc file attached in case someone need these named colors.
>
> Python file attached as well in case someone wish to change something in
> output format, like rounding (currently set to 3 decimals) etc.

I'm pretty sure that, as the W3C has adopted sRGB as its standard, your colors
should be #declared with `srgb` rather than `rgb`.  Your list is consistent with
mine, and when I render these colors, it seems clear that they are gamma-2.2 or
sRGB encoded.  Note that the `srgb` keyword will yield consistent colors
regardless of your assumed_gamma setting.

Post a reply to this message

hi,

Ilya Razmanov <ily### [at] gmailcom> wrote:
> Ok, since some avians request amphibians to post something, here
> something goes.
> ...
> Anyway, now I do post something, and it's your turn.

after reading CR's reply, I'd like to add that POV-Ray include files, ideally,
should be "idempotent", too.  have attached a copy of a generated
'svg_colors.inc' post-processed (and renamed to fit :-)).

thank you for posting your script.


regards, jr.

Post a reply to this message

Attachments:
Download 'colours_svg.inc.txt' (8 KB)

On 26.03.2026 11:15, jr wrote:
> 
> after reading CR's reply, I'd like to add that POV-Ray include files, ideally,
> should be "idempotent", too.  have attached a copy of a generated
> 'svg_colors.inc' post-processed (and renamed to fit :-)).
> 

Unfortunately, I understand neither what "idempotent" mean nor what all 
these

#ifdef(View_POV_Include_Stack)
#debug "including colours_svg.inc\n"
#end

are good for ;-). Therefore I'm afraid I can't make my script any 
better, except for changing "rgb" to "srgb" (that's the only part I 
understand).

Well, on the other hand, there seem to be one more thing I understand: 
many colors in standard "colors.inc" seem to be named just like that 
would be in exported inc, and I'm too lazy to check them all for 
conflicts in case of importing both files. Perharps it would be better 
to change naming convention from color_name.title() (i.e., "blue" to 
"Blue") to, say, color_name.capitalize() (i.e., "blue" to "BLUE")? Or 
may be use prefixes, like "blue" to "svg_blue" or something?

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

hi,

Ilya Razmanov <ily### [at] gmailcom> wrote:
> On 26.03.2026 11:15, jr wrote:
> >
> > after reading CR's reply, I'd like to add that POV-Ray include files, ideally,
> > should be "idempotent", too.  have attached a copy of a generated
> > 'svg_colors.inc' post-processed (and renamed to fit :-)).
> >
>
> Unfortunately, I understand neither what "idempotent" mean nor what all
> these

idempotent -- in this context, if I were to have a '#include "colours_svg.inc'"
line in every one of my scene and include files, only the first one seen by the
parser gets processed in full, all subsequent ones will not (as the guard
('colours_svg_include_temp') is already defined).
<en.wiktionary.org/wiki/idempotent>


> #ifdef(View_POV_Include_Stack)
> #debug "including colours_svg.inc\n"
> #end

if you'll have a look at the distribution '.inc' files, you will notice those
same lines.  if you declare the 'View_POV_Include_Stack' variable in a scene
_before_ the scene file's "#include" lines, POV-Ray will print the name of each
as it gets parsed.


> are good for ;-). Therefore I'm afraid I can't make my script any
> better, except for changing "rgb" to "srgb" (that's the only part I
> understand).

well, I don't "speak" Python, so cannot do so either.


> Well, on the other hand, there seem to be one more thing I understand:
> many colors in standard "colors.inc" seem to be named just like that
> would be in exported inc, and I'm too lazy to check them all for
> conflicts in case of importing both files. Perharps it would be better
> to change naming convention from color_name.title() (i.e., "blue" to
> "Blue") to, say, color_name.capitalize() (i.e., "blue" to "BLUE")? Or
> may be use prefixes, like "blue" to "svg_blue" or something?

fwiw, personal opinion, the colour names are fine as is.


regards, jr.

Post a reply to this message

On 26.03.2026 14:38, jr wrote:

> well, I don't "speak" Python, so cannot do so either.

Well, initially my pythonic part consisted of three things:

1) One "with open..." for file handling.
2) One "for" loop for dictionary iterating.
3) One file .write with f-string, combining dictionary keys and values 
with POV-Ray syntax elements.

All the rest of the file consisted of 147 dictionary entries, whose keys 
and values were directly copied from W3C site.

Main reasons for doing all this with Python were:

1) I'm too lazy to think of search and replace sequence for transforming 
W3C source into POV-Ray, "let the iron mechanism work";
2) Now it's extremely easy to change things en masse by, say, editing 
that single f-string.

But now I tried to address all the issues mentioned in both replies, so 
my pythonic code like quadrupled in size ;-)

Here go the updated version (and exported .inc example for those who 
loathe to touch Python). Note that file name to be inserted here and 
there in all these "include_temp" is defined within program, so it's 
easy to edit it with notepad - all the "doing" code goes after 
dictionary definition, which, considering code and dictionary relative 
sizes, means "at the very end of Python file".

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

Attachments:
Download 'svg_recognized_color_keyword_names.py.txt' (7 KB) Download 'svg_colors.inc.txt' (8 KB)

That's the second time TODAY that I've seen the word "idempotent".
Spooky.  But an excellent goal to set for all code.

Also applicable to the keyword project I was discussing, with regard to
self-documenting.

As Richard stated:
"Note that the `srgb` keyword will yield consistent colors
regardless of your assumed_gamma setting."

So, if we are using assumed_gamma 1.0 for all scenes, then why are we even using
rgb?   If everything is implemented from here forward using srgb, then
everything should be good, right?   N^1 = N.

Now, I often have to do experimentation where I modify colors from rgb to rgbf
to rgbt to maybe rgbft, and that gets to be a pain to go back and rewrite all
the keywords and color vectors.

Having worked out a fairly robust system for handling vector arity, I'm
considering just making some kind of all-purpose color macro, that detects the
size of the color vector and emits the appropriate keyword.

- BE

Post a reply to this message

hi,

Ilya Razmanov <ily### [at] gmailcom> wrote:
> On 26.03.2026 14:38, jr wrote:
> > well, I don't "speak" Python, so cannot do so either.
> Well, initially my pythonic part consisted of three things:
> ...
> But now I tried to address all the issues mentioned in both replies, so
> my pythonic code like quadrupled in size ;-)
>
> Here go the updated version (and exported .inc example ...

super.  one small oversight (sorry :-)), all '#debug' statements need an
explicit '\n' to "show".


regards, jr.

Post a reply to this message

On 2026-03-25 18:02 (-4), Cousin Ricky wrote:
> Ilya Razmanov <ily### [at] gmailcom> wrote:
>> [snip]
>>
>> Resulting .inc file attached in case someone need these named colors.
>>
>> Python file attached as well in case someone wish to change something in
>> output format, like rounding (currently set to 3 decimals) etc.
> 
> I'm pretty sure that, as the W3C has adopted sRGB as its standard, your colors
> should be #declared with `srgb` rather than `rgb`.  Your list is consistent with
> mine, and when I render these colors, it seems clear that they are gamma-2.2 or
> sRGB encoded.  Note that the `srgb` keyword will yield consistent colors
> regardless of your assumed_gamma setting.

Verified: https://www.w3.org/TR/SVG11/types.html#DataTypeColor

You should use the `srgb` keyword, not the `rgb` keyword.

Post a reply to this message

On 26.03.2026 16:32, jr wrote:

> super.  one small oversight (sorry :-)), all '#debug' statements need an
> explicit '\n' to "show".

LOL, I was so concentrated on adding "\n" to the ends of my strings that 
completely missed adding "\\n" in the middle.

Anyway, here go finally corrected script, so anyone may change things to 
one's own taste.

-- 
Ilyich the Toad
https://dnyarri.github.io/

Post a reply to this message

Attachments:
Download 'svg_recognized_color_keyword_names.py.txt' (7 KB)