Wonderful!  I have one suggestion.  It seems like pov doesn't generally
return information about an object, rather it gives you an object you know
information about.  For example, when you use height fields, pov maps the
height field to a 1x1x1 unit cube, from which it can be rotated, scaled, or
whatever.  It doesn't create a height field which is 640 units across and
480 units deep, and who knows how high, and then supply vectors giving the
dimensions.  The text object is the only one (to my knowledge) which does
not come prefit to a 1x1x1 cube, or require vectors to specify a size.  I
haven't looked at the code, so I don't know how difficult it would be, but
it seems to me that the text object would best be kept in the tradition of
other pov objects and automatically created in a 1x1x1 cube.  Unfortunately,
this kind of a change would violate backwards compatiblity.  My
recommendation is to add optional bounding vectors to the syntax of the text
object.  Similar to the syntax of a box, but optional.  That would allow for
backwards compatibility.  I'd be curious to hear any feedback about this
idea, both from a usability standpoint and programmability.

Ken

Jamis Buck wrote in message <348E0873.C5A421B1@cs.byu.edu>...
>Attached is a simple hack of the truetype.c file that makes text objects
>be centered about the x-origin.  Could be useful for those tricky text
>manipulations? :)  Perhaps if someone has time they could add a pov
>"built-in" function to find the length of a string, so the users can
>play with these things more...who knows...if i can find the time i may
>do it myself! :)
>
>Comments, criticisms, etc. are always welcome.  Just be nice... :)
>
>- Jamis Buck
>buc### [at] csbyuedu
>http://students.cs.byu.edu/~buck

Post a reply to this message