I've thought about your suggestion, however, I think, at least from a
usability standpoint, there may be a better way to do it than to map
a text object to a 1x1x1 cube.  If the text was mapped to such a cube,
how would you know how much to scale it to make it look right?  You're
just back to trial and error, much like manipulating text right now.

Rather, I'm working on two new "built-in" functions, getlength and
getheight.  Both take a text string, a font name, and an offset (same
as a text object) and return (respectively) the length and height of
a text object of the given specs.  Doing this would allow users to
more easily manipulate a text object by doing simple math to center it,
resize it, etc.  With this information, one could even scale the text
to fit into a 1x1x1 cube, if one wanted.

So, that's what's happening right now.  I've almost got it...give me
another
week or so. :)  If anyone is interested in this, let me know and I'll
post
the altered source files to this group.

Ciao!

- Jamis Buck
buc### [at] csbyuedu
http://students.cs.byu.edu/~buck

Ken Cecka wrote:
> 
> 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