Trevor G Quayle <Tin### [at] hotmailcom> wrote:
> Unfortuneately image_map can't be declared explicitly like:
> #declare A=image_map{jpg "MyImage.jpg"} so using it this way would require it to
> be applied to something (mind you it could be just a dummy pigment, but this
> seems un-neat to me).

  It's perfectly possible and in fact quite easy to do something like this:

#declare Im = pigment { image_map { jpg "MyImage" } };
#declare R = max_extent(Im);

and then R.x would be the width of the image and R.y the height.

  (I actually went ahead and implemented this just to see if it would work,
and it worked like a charm.)

  The only question is whether max_extent() is the suitable function for
this.

  It has been suggested that image_width, when used as a function (and given
the image map pigment identifier as parameter) would return the width of the
image, and likewise image_height the height, but I'm not completely sure how
trivial this is to implement in the parser because these keywords are already
used as float identifiers. It would mean that when parsing these keywords the
parser would have to look for an optional opening parenthesis after it, and
if it appears, behave differently. I haven't yet looked, but my past
experience in trying this "check for an optional syntax element" with the
current parser has been daunting. (More precisely, I tried to implement
concatenation of strings using the + operator. I hit a wall.)

  (max_extent() doesn't have this problem because it's already a vector
function, and thus it's simply a question of checking the type of the
parameter. This is very trivial to implement in the parser.)

-- 
                                                          - Warp

Post a reply to this message