POV-Ray : Newsgroups : povray.general : parsing colors : Re: parsing colors Server Time
19 Apr 2024 09:19:20 EDT (-0400)
  Re: parsing colors  
From: Le Forgeron
Date: 23 Jan 2017 04:32:55
Message: <5885cdc7$1@news.povray.org>
Le 23/01/2017 à 09:05, dick balaska a écrit :
> My povclipse2 parser is mature enough to throw someone else's code at
> it, and I chose BorderChars. [1]
>
> He uses a construct
> color <1,1,1>
> which, while it works, doesn't seem particularly legal according to the
> spec:
> http://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_1_7_3
>
> It should be
> color rgb <1,1,1>
>
> Should I flag this as an error? as a warning? or silently digest it as
> pov does?
>

actually, if I read the doc correctly, *color <1,1,1>* is to be 
interpreted as *color rgbft <1,1,1,0,0>* (due to the implicit rgbft when 
none are specified and to vector promotion from a vector).

It's a few paragraph above your reference.

The trap would be *color 1*, which would be promoted to *color 
rgbft<1,1,1,1,1>* (due this time to vector promotion from a real number)

Due to the trap, I would vote for at least a warning. If you can 
separate the real from the vector expression, the warning might be 
suppressed for the vector.

Back to the BorderChars, it is legal, and the documentation might need 
some proof-reading about the syntax after color.

because it is fine with
#declare Foo = rgb<1,1,1>;
... color Foo ...

So it should be fine with
... color rgb<1,1,1> ...


> [1] He also gave me
> #declare foo /*;*/ = 1;
> which made me realize I had to abandon the eclipse builtin scanners
> (give me the text from '#declare' to ';')
> because there is no chance to treat comments as whitespace.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.