clipka <ano### [at] anonymousorg> wrote:
> Warp schrieb:
> >   The quotes allow putting there more than just a hex value prepended
> > with a #. You can put color names and everything else HTML supports,
> > plus more.

> Rather not. I'd pretty much consider that overkill. Unless you want to 
> extend POV-Ray's capabilities to rendering HTML documents of course...

  Then why have any such crippled "HTML colors" at all?

> >> A hash sign (#) followed by six uppercase(!) hex digits could denote a 
> >> HTML color.
> > 
> >   "HTML color" can be more than just hex values. By making it a non-string
> > you are removing the possibility of other color definitions being used
> > (such as named colors).

> ... which is what I'd prefer to do, actually: Straightforward 24-bit 
> colors should suffice.

  Except when they don't. If you are rendering to a 48-bit image, you
might want to use 48-bit colors for the input as well.

  As I said, your suggestion is rigid and inflexible. It cannot be easily
expanded.

  And as I said, what's the point in having "HTML-style colors" if you are
going to use a very limited and crippled subset of them? What's the point?

  I don't understand what is it that you oppose in the idea of defining a
color with a string. What's so bad about that?

> So rather than specifying a generic way how to 
> specify HTML colors, I'd rather specify that "a hash sign followed by 
> six uppercase hex digits is interpreted as a HTML color".

  To me that sounds more like a kludge than a solution to anything.
(What is the *problem* you are trying to solve with this "solution"?)

> If you want color names, go ahead and define them as genuine POV-Ray 
> variables in some .ini file.

  I don't want color names. I want a *flexible* and *expandable* system for
defining colors. You missed my point entirely. The color names were just an
*example*, not the core of the suggestion.

> the rigidity and limitations is something I see as a benefit

  Then we'll just have to disagree.

  It makes no sense to make the parser more complicated for the sake of
adding a crippled, rigid feature which cannot be expanded and is mostly
useless. Better leave it out completely.

> Supporting only a very limited, rigid subset of HTML color syntax would 
> perfectly avoid this can of worms.

  And not adding any such kludge at all would avoid even more problems.

> But given what fuss people seem capable of making about this, maybe the 
> best idea would be to not support any HTML-style color syntax in the 
> first place, and stick to POV-Ray's traditional way of specifying colors.

  I think it's only you who is making a fuss about it. You are the one who
is actually opposing HTML-style color syntax, not me.

-- 
                                                          - Warp

Post a reply to this message