AngleWyrm <no_### [at] hotmailcom> wrote:
> I think that this is rather an extra bunch of pre-processing data, that
> could be avoided if the end-of-line character were recognized as a valid
> data separator.

  But the thing is that POV-Ray does not read data files. It reads
POV-Ray SDL files which contain items separated by commas. It's not
much different from what you have between parentheses in a macro
call (ie. for example FancyMacro(1, 5*8-1, <1,5,2*3>)).

  If the newline character was an alternative character for item separator,
then each item must be written completely in one line. If the item is
a very long statement that can be unreasonable. It's the same as if
when calling a macro you could not split a parameter into several lines
if the parameter is a very long expression.

  POV-Ray reads and interprets the input file in a very versatile way.
It can contain much more than just numbers, vectors and strings. It
can contain variables, expressions and even #declares etc.
  Making the input file to be a plain data file which is not interpreted
in any way would be a downgrade.

  And besides, if the newline character was an item separator, how
several empty lines should be handled?

> How often is the end-of-line character used as part of a
> variable?

  But it can be used as a part of an expression.

> I would like to find the source file, and see if I can maybe customize it to
> recognize eol markers

  You would be downgrading the versatility of the #read command. You would
have to turn off almost all interpretation of the input data, which would
break many things badly.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message