Here's the problem: I want to modify truetype.c in the POV-Ray source to
allow text objects to be bent around a circle (without distorting the
characters). I would like to be able to specify either an inner radius
for the text or a desired total arc angle. The characters would be
separated by chords equal in length to the distance normally separating
each character, plus two more chords equal to half of the character
widths on each end.
Now when radius is specified, the total angle is easy to compute because
it's the sum of all the chord angles. Given the radius, those angles are
easy to find. But when the problem is reversed, only a total angle and
the individual chords are known, but so far I haven't figured out any
way to calculate the radius that fits. (It's pretty easy to determine
that there is such a radius, and the minimum possible value of that
radius is easy to find. But the exact value I can only think to find by
guessing.)
Without a radius given, finding the radius is awfully hard. Yet the
value of this solution is obvious, since being able to fill in a
specific arc angle will often be far more useful than fitting text
around a specific radius.
This seems like it should be a simple problem, so I've asked elsewhere,
but so far with no results. Since it came up in the course of my working
with POV-Ray, I figured I'd take a whack at asking here.

Lummox JR

Post a reply to this message

In article <38B### [at] aolcom> , Lummox JR <Lum### [at] aolcom>  wrote:

> Here's the problem: I want to modify truetype.c in the POV-Ray source to
> allow text objects to be bent around a circle (without distorting the
> characters). I would like to be able to specify either an inner radius
> for the text or a desired total arc angle. The characters would be
> separated by chords equal in length to the distance normally separating
> each character, plus two more chords equal to half of the character
> widths on each end.
> Now when radius is specified, the total angle is easy to compute because
> it's the sum of all the chord angles. Given the radius, those angles are
> easy to find. But when the problem is reversed, only a total angle and
> the individual chords are known, but so far I haven't figured out any
> way to calculate the radius that fits. (It's pretty easy to determine
> that there is such a radius, and the minimum possible value of that
> radius is easy to find. But the exact value I can only think to find by
> guessing.)
> Without a radius given, finding the radius is awfully hard. Yet the
> value of this solution is obvious, since being able to fill in a
> specific arc angle will often be far more useful than fitting text
> around a specific radius.
> This seems like it should be a simple problem, so I've asked elsewhere,
> but so far with no results. Since it came up in the course of my working
> with POV-Ray, I figured I'd take a whack at asking here.

Hmm, did you ever pay attention in your math classes? ;-)

Given that you know the total length you can use 2*pi*r (perimeter of a
circle) and the fact that  2*pi*r*360/angle = length


     Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

>Given that you know the total length you can use 2*pi*r (perimeter of a
>circle) and the fact that  2*pi*r*360/angle = length

This is only true in the limit as the number of characters approaches 
infinity.  He's only got the lengths of the chords, not of the arcs.
The length of a chord is 2*r*sin(angle/2).  So the equation is:

   _ n
  \       -1
   > 2*sin  (chord  / (2*r)) = 360 (or 2*pi, if you use radians)
  /_              i
    i=1

And he's hoping to find r.  That doesn't look very easy to me.  I think
the only solution might be an iterative one.  Your answer gives a good
lower bound for r; I'm not sure what a good upper bound would be.

I'm also not sure this is the right group for this question; he might 
find better answers in .advanced-users.

Also, as an aside to the original poster, how about writing this routine 
as a macro using min_extent and max_extent instead of modifying truetype.c?  
The result will be the same without having to make a new patch, and you
might even be able to offer more options (such as an optional angle
that can be used to rotate each character around the x axis before moving
it to its final position, making a cone shape or a cylinder instead of a 
flat circle)

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

Thorsten Froehlich wrote:
> Hmm, did you ever pay attention in your math classes? ;-)
> 
> Given that you know the total length you can use 2*pi*r (perimeter of
> a circle) and the fact that  2*pi*r*360/angle = length

Unfortunately it's not nearly that simple. If simple arc length formulas
would help me I wouldn't have needed to post.
The total length of all the adjacent chords is known, because the
individual chords are known--but the chord connecting the two endpoints
is not known, and that's the one that's needed to solve for r. (Either
that, or one of the individual angles corresponding to one of the chords
must be known.) Basically a bunch of points are spread out along a
circle of unknown radius, and the angle separating the two points on the
ends is known. (The arc length isn't known, however, because radius is
unknown.)
If this was just a matter of arc length the problem would be childishly
easy. However *chord* length involves cosines and square roots:
c=r*sqrt(2-2*cos(a)). Given two adjacent chords there is no way to find
their connecting chord without a radius; even calculating with the total
angle, which should be possible, delivers no end of mathematical
headaches. I'm still working on that one.
Reducing the problem to something simpler: Find a function C=f(c1,c2,A)
such that C is the chord connecting the endpoints of adjacent chords c1
and c2, knowing that their total central angle is A. Sounds simple, but
it gets tricky *really* fast. My problem is basically a superset of this
one, where instead of two chords the number is arbitrary; it could be
very high or something simple like 5 or 10.

To solve my problem, I need to find any one of the following:

- Any one of the angles corresponding to a given chord in the set.
- The length of the chord connecting to two endpoints.
- The arc length between the two endpoints.

With any of those I can solve for radius.

Lummox JR

Post a reply to this message

On Mon, 21 Feb 2000 14:17:47 -0500, Lummox JR wrote:
>- Any one of the angles corresponding to a given chord in the set.
>- The length of the chord connecting to two endpoints.
>- The arc length between the two endpoints.
>
>With any of those I can solve for radius.

Really?  How does it help to know the length of the chord connecting the
two endpoints?  What do you get if you assume it to be zero?

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

Ron Parker wrote:
> Really?  How does it help to know the length of the chord connecting the
> two endpoints?  What do you get if you assume it to be zero?

If the two endpoints match, then the text pretty much covers 360 degrees
as a total angle.
By knowing the length of the "total" chord connecting the two endpoints,
since I also know the angle that goes with that chord then the radius
would be easy to find from there.

Lummox JR

Post a reply to this message

Ron Parker wrote:
[snip]
> I'm also not sure this is the right group for this question; he might
> find better answers in .advanced-users.

So noted. I posted here because I couldn't think of a better group for
the discussion. Although to be honest, I think the mathematics make this
more of a programming question than anything else.

> Also, as an aside to the original poster, how about writing this routine
> as a macro using min_extent and max_extent instead of modifying truetype.c?
> The result will be the same without having to make a new patch, and you
> might even be able to offer more options (such as an optional angle
> that can be used to rotate each character around the x axis before moving
> it to its final position, making a cone shape or a cylinder instead of a
> flat circle)

Using macros would be nice, but I really can't think of a good way to go
about that. min_extent and max_extent cover the bounding area just fine,
but they don't go into issues like character spacing and kerning. It
might be possible to adjust for that somehow, but only with great
difficulty. The reason I decided to try to modify the primitive was
because I wanted to preserve proper spacing as much as
possible--although I realize some amount of distance would be added as a
result of the curvature of the circle.
Creating the glyphs individually would work, but it wouldn't correct for
kerning or other issues I consider somewhat important.
Perhaps what we really need here is a nice compile-time function added
to the library. Something like this:

character_center("Arial.ttf","Test message",depth,spacing,n)
dimensions("Arial.ttf","Test message",depth,spacing)

If character_center() were to return the proper coordinates for the
center of the (n+1)th character, and dimensions() could return the size
of the string's bounding box without actually creating a text object,
then we'd be in business.
A macro is in many ways a better way to go because of the greater
flexibility. However, without some way to account for the character
spacing, it would be difficult to pull this off satisfactorily.

Lummox JR

Post a reply to this message

In article <38b18d1f@news.povray.org> , ron### [at] povrayorg (Ron Parker)
wrote:

>>Given that you know the total length you can use 2*pi*r (perimeter of a
>>circle) and the fact that  2*pi*r*360/angle = length
>
> This is only true in the limit as the number of characters approaches
> infinity.  He's only got the lengths of the chords, not of the arcs.
> The length of a chord is 2*r*sin(angle/2).

It seems I don't understand the question completely then.  I learned math in
German and the English terms might have confused me ... but I still think
there should be a simple solution to the problem.

I have posted a diagram in povray.binaries.images which should help me
understand the problem.  To make it simple, could you state in terms of that
diagram which variables are known?


     Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

On Mon, 21 Feb 2000 14:43:43 -0600, Thorsten Froehlich wrote:
>I have posted a diagram in povray.binaries.images which should help me
>understand the problem.  To make it simple, could you state in terms of that
>diagram which variables are known?

The blue line comes closest to being what is known.  The letters are,
as I understand it, inside the circle (though I really don't know why.)

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

On Mon, 21 Feb 2000 15:05:54 -0500, Lummox JR wrote:
>Ron Parker wrote:
>[snip]
>> I'm also not sure this is the right group for this question; he might
>> find better answers in .advanced-users.
>
>So noted. I posted here because I couldn't think of a better group for
>the discussion. Although to be honest, I think the mathematics make this
>more of a programming question than anything else.

Probably, but I'm guessing some of our smarter math guys (For example, Adam 
Coffman, who teaches math at a university a few miles from me) don't hang out 
here.

>Using macros would be nice, but I really can't think of a good way to go
>about that. min_extent and max_extent cover the bounding area just fine,
>but they don't go into issues like character spacing and kerning.

You shouldn't worry about kerning anyway, since it is usually used to make
characters overlap and is really only valid if they're going to be in a 
straight line.  Perhaps character spacing is something best left to the user
to decide.  If not, it is possible to determine the character spacing for
a given character.  Just subtract the width of "|X|" from the width of "||"
where X is the character you want the advance widths for.  A modified version 
of this can give you kerning, too.  Find the advance widths for the two 
characters individually, and for the two characters in one string.  The 
difference is the kern.  Obviously this doesn't work when kerning extends
over multiple characters, but that's rare.  If TrueType fonts handled
ligatures like fi and ffi correctly, you'd also have problems, but fortunately
(or unfortunately) it doesn't.  You'll also have problems if there are kern
pairs using "|" but that doesn't seem likely either.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

In article <38b1b035@news.povray.org> , ron### [at] povrayorg (Ron Parker)
wrote:

> The blue line comes closest to being what is known.  The letters are,
> as I understand it, inside the circle (though I really don't know why.)

OK, now I understand the problem.  I makes much more sense now.


     Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Lummox JR <Lum### [at] aolcom> wrote:
: Here's the problem: I want to modify truetype.c in the POV-Ray source to
: allow text objects to be bent around a circle (without distorting the
: characters).

  I think this can be easyly done with a #macro. Why should the source code
be modified?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <38b28881@news.povray.org>, Nieminen Juha 
<war### [at] sarakerttunencstutfi> wrote:

>   I think this can be easyly done with a #macro. Why should the source 
>   code be modified?

If the characters are just being rearranged, than a macro would be easy 
to develop. If the characters also taper toward the center of the 
circle(which would be a more useful feature, in my opinion), than a 
patch would almost be required.(You might be able to get something by 
trace()'ing text objects and using that data to make prisms, but the 
results probably wouldn't be very good, it would be difficult to make, 
and could take a while to parse)

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff wrote:

> In article <38b28881@news.povray.org>, Nieminen Juha
> <war### [at] sarakerttunencstutfi> wrote:
>
> >   I think this can be easyly done with a #macro. Why should the source
> >   code be modified?
>
> If the characters are just being rearranged, than a macro would be easy
> to develop. If the characters also taper toward the center of the
> circle(which would be a more useful feature, in my opinion), than a
> patch would almost be required.(You might be able to get something by
> trace()'ing text objects and using that data to make prisms, but the
> results probably wouldn't be very good, it would be difficult to make,
> and could take a while to parse)
>

And another issue (which I think was mentioned) is that without some patch,
the macro would not have enough information on the characters in a string
to place them correctly.

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

Jon A. Cruz <jon### [at] geocitiescom> wrote:
: And another issue (which I think was mentioned) is that without some patch,
: the macro would not have enough information on the characters in a string
: to place them correctly.

  Wouldn't the min_extent and max_extent functions in megapov help?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 23 Feb 2000 04:16:07 -0500, Nieminen Juha wrote:
>Jon A. Cruz <jon### [at] geocitiescom> wrote:
>: And another issue (which I think was mentioned) is that without some patch,
>: the macro would not have enough information on the characters in a string
>: to place them correctly.
>
>  Wouldn't the min_extent and max_extent functions in megapov help?

Not entirely.  Jon is going back to the kerning and character spacing issues
that JR raised.  There might also be some issues with descenders; that's 
something I haven't investigated fully.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

Ron Parker wrote:

> On 23 Feb 2000 04:16:07 -0500, Nieminen Juha wrote:
> >Jon A. Cruz <jon### [at] geocitiescom> wrote:
> >: And another issue (which I think was mentioned) is that without some patch,
> >: the macro would not have enough information on the characters in a string
> >: to place them correctly.
> >
> >  Wouldn't the min_extent and max_extent functions in megapov help?
>
> Not entirely.  Jon is going back to the kerning and character spacing issues
> that JR raised.  There might also be some issues with descenders; that's
> something I haven't investigated fully.

Yes, kerning is one issue. And the baseline is a more obvious one.

This documentation on the Java font metrics class can be used to quickly see some
of the issues.

http://java.sun.com/products/jdk/1.1/docs/api/java.awt.FontMetrics.html#_top_

Just imagine trying to line up "jal_^T" vertically using the extent functions.

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

On Wed, 23 Feb 2000 16:48:12 -0800, Jon A. Cruz wrote:
>Ron Parker wrote:
>
>> On 23 Feb 2000 04:16:07 -0500, Nieminen Juha wrote:
>> >Jon A. Cruz <jon### [at] geocitiescom> wrote:
>> >: And another issue (which I think was mentioned) is that without some patch,
>> >: the macro would not have enough information on the characters in a string
>> >: to place them correctly.
>> >
>> >  Wouldn't the min_extent and max_extent functions in megapov help?
>>
>> Not entirely.  Jon is going back to the kerning and character spacing issues
>> that JR raised.  There might also be some issues with descenders; that's
>> something I haven't investigated fully.
>
>Yes, kerning is one issue. And the baseline is a more obvious one.
>
>This documentation on the Java font metrics class can be used to quickly see some
>of the issues.
>
>http://java.sun.com/products/jdk/1.1/docs/api/java.awt.FontMetrics.html#_top_
>
>Just imagine trying to line up "jal_^T" vertically using the extent functions.

The baseline is not actually a problem, believe it or not.  They're taken into
account by the ttf object.  Here are the extents for

  #local CF = text {
    ttf "arial.ttf" C 1 0
  }  

where C is each of the characters you specified.  So the only problem remaining
is the possibility that the correct advance width for the character could be 
less than the total width of the character, and that's taken care of by the 
method I already outlined for discovering it (i.e. width of "|X|" minus width 
of "||".)

C     min_extent             max_extent
------------------------------------------
j  <-0.00 -0.21 -0.00>   <0.20  0.72 1.00>
a  <-0.00 -0.01 -0.00>   <0.48  0.53 1.00>
l  <-0.00 -0.00 -0.00>   <0.09  0.72 1.00>
_  < 0.00 -0.20 -0.00>   <0.58 -0.14 1.00>
^  <-0.00  0.34 -0.00>   <0.42  0.73 1.00>
T  <-0.00 -0.00 -0.00>   <0.57  0.72 1.00>
    
-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

Nieminen Juha wrote:
>   I think this can be easyly done with a #macro. Why should the source code
> be modified?

Well, one problem I've had so far trying to work out a macro is that
POV-Ray contains no function for finding string length (somebody explain
*that*), meaning that it's going to be necessary to include a separate
array just for string lengths.
Also are some small issues like the fact that it's necessary to define
all of the text objects before placing them, because their width needs
to be a known quantity. Having done almost nothing with macros before,
this area is a little new to me. However, I'm working on that aspect of
it in the hopes that something will work.

Lummox JR

Post a reply to this message

In article <38B### [at] aolcom> , Lummox JR <Lum### [at] aolcom>  wrote:

> Well, one problem I've had so far trying to work out a macro is that
> POV-Ray contains no function for finding string length (somebody explain
> *that*), meaning that it's going to be necessary to include a separate
> array just for string lengths.

If it is not in the docs then that is the bug. "strlen" should give the
string length, at least it is a valid token.


     Thorsten

Post a reply to this message

In article <38b7301f@news.povray.org>, "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> If it is not in the docs then that is the bug. "strlen" should give the
> string length, at least it is a valid token.

It is implemented, (in Parse_Num_Factor() or something like that in 
express.c). But I couldn't find it in the section of the documentation 
with the string functions, although it was mentioned in other 
places(4.1.1  Identifiers and Keywords, 4.1.3  Float Expressions, etc).


I found it's definition in 4.1.3.6  Float Functions:

strlen(S) Length of S . Returns an integer value that is the number of 
characters in the string S .


This might need to be reorganized in the future, since although it 
returns a float value, it is definitely a string function.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

An update on the macro progress: As it turns out, min_extent() and
max_extent() are indeed incapable of producing the desired result,
because there is no spacing whatsover included between the characters;
it's stripped out from the bounding boxes. Moreover, spaces don't appear
at all.
I think now that what's really needed here is not so much a redefinition
of the text primitive, but rather a function that will give the metrics
for a particular font. Specifically, it should be able to return the
following for any given font:

min_extent() of character (including spacing)
max_extent() of character (including spacing)
horizontal kerning of two characters
maximum height above baseline (all glyphs)
maximum descender size
maximum width

That ought to do it, I think.
An advantage of this approach is that the text object for each character
needn't be #declared until it's ready to be rotated. This saves all
kinds of trouble, and all kinds of memory as well.
Now that I've got this idea in my head, I think I'll see if I can modify
truetype.c (and, necessarily, the parser) to support this function
instead. My concept for a syntax so far:

fontmetrics(<font name>,<function number>,<argument>)

And the function numbers:

  1 - min_extent of string <argument>, spacing included
  2 - max_extent of string <argument>, (horizontal) spacing included
  3 - horizontal kerning between the two characters in string
      <argument>, or 0 if the string is invalid
  4 - maximum ascent of the font
  5 - maximum descent of the font
  6 - maximum character width (spacing included)

Functions 4-6 will of course ignore the argument, so "" can be used.
Naturally this idea is in its infancy, so any suggestions that could
improve it would be most welcome.

Lummox JR

Post a reply to this message

Lummox JR wrote in message <38B### [at] aolcom>...
>And the function numbers:
>
>  1 - min_extent of string <argument>, spacing included
>  2 - max_extent of string <argument>, (horizontal) spacing included
>  3 - horizontal kerning between the two characters in string
>      <argument>, or 0 if the string is invalid
>  4 - maximum ascent of the font
>  5 - maximum descent of the font
>  6 - maximum character width (spacing included)
>
>Functions 4-6 will of course ignore the argument, so "" can be used.
>Naturally this idea is in its infancy, so any suggestions that could
>improve it would be most welcome.


Improvement #1: Replace function numbers with keywords.  This is easy enough
to code, and will simplify using the function.  For example:

         Fontmetrics("arial.ttf", min_extent, "Hello, world!")

is easier to remember and understand than

         Fontmetrics("arial.ttf", 1, "Hello, world!")


Mark

Post a reply to this message

On Sat, 26 Feb 2000 14:50:31 -0500, Lummox JR wrote:
>An update on the macro progress: As it turns out, min_extent() and
>max_extent() are indeed incapable of producing the desired result,
>because there is no spacing whatsover included between the characters;
>it's stripped out from the bounding boxes. Moreover, spaces don't appear
>at all.

This only happens if you do it a character at a time.  Kindly reread
my messages on the subject and try what I suggested.

>min_extent() of character (including spacing)
>max_extent() of character (including spacing)
>horizontal kerning of two characters

These three are all derivable using the methods I've already outlined.
Having a way to get them directly might be nice for speed purposes, but
the fact remains that you can use macros to get the information you 
need now.  However, I think you'll find that the POV Truetype code 
doesn't have any support for kern pairs anyway.

>maximum height above baseline (all glyphs)
>maximum descender size
>maximum width

What use are these, exactly?  Why do we care if the maximum height is
two X-heights if we don't plan to use the character that attains that
height?  If we do plan to use that character, we can derive all this
information with min_extent and max_extent.

>An advantage of this approach is that the text object for each character
>needn't be #declared until it's ready to be rotated. This saves all
>kinds of trouble, and all kinds of memory as well.

Doesn't save any memory at all.  You can #local the objects you need
to use and the memory will be freed when the macro returns.  Believe
it or not, I did think about all this stuff when I came up with 
min_extent and max_extent. 

Here are the macros I made to find the letter spacing and kerning. 
None of them allocate any memory that isn't freed before they return.
Try them.  They DO work.

// Find the advance width of character C in font F
#macro WidthWithSpacing( C, F )
  #local T=text {ttf F concat("|",C,"|") 1 0}
  #local W1=max_extent(T).x-min_extent(T).x;
  #local T=text {ttf F "||" 1 0}
  (W1-max_extent(T).x+min_extent(T).x)
#end

// Find the width of the glyph for character C in font F
#macro WidthNoSpacing( C, F )
  #local T=text {ttf F C 1 0}
  (max_extent(T).x-min_extent(T).x)
#end

// Find the kern for characters A and B from font F
#macro Kern( A, B, F )
  (WidthWithSpacing( concat(A, B), F)-WidthWithSpacing(A,F)
   -WidthWithSpacing(B,F))
#end

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

Ron Parker wrote:
> >maximum height above baseline (all glyphs)
> >maximum descender size
> >maximum width
> 
> What use are these, exactly?  Why do we care if the maximum height is
> two X-heights if we don't plan to use the character that attains that
> height?  If we do plan to use that character, we can derive all this
> information with min_extent and max_extent.

Well, knowing the font's maximum height helps for a max height of all
characters. My reasoning behind this is that in some of what I'd be
doing with this, I'd be using more than one arc of circular text, and
it's possible that the height of one string might not match the height
of the other, yet it would be necessary to match their proportions.
I suppose I could just use a macro to figure out the maximum height of
the font, though.

> >An advantage of this approach is that the text object for each character
> >needn't be #declared until it's ready to be rotated. This saves all
> >kinds of trouble, and all kinds of memory as well.
> 
> Doesn't save any memory at all.  You can #local the objects you need
> to use and the memory will be freed when the macro returns.  Believe
> it or not, I did think about all this stuff when I came up with
> min_extent and max_extent.

Doh! Serves me right for not having done more with macros.

> Here are the macros I made to find the letter spacing and kerning.
> None of them allocate any memory that isn't freed before they return.
> Try them.  They DO work.

Many thanks; I'll use those. They should save me no end of grief.

Lummox JR

Post a reply to this message

This is the scene file for a test image of a coin that I've posted on
povray.binaries.images. I've tested out all the macros I added, although
I didn't end up using RadiusOf() or TotalChords() in here.
This should come in handy the next time I want to do circular text. Many
thanks for all the help, Ron.

Lummox JR

Post a reply to this message

Attachments:
Download 'us-ascii' (5 KB)

On Sun, 27 Feb 2000 20:39:24 -0500, Lummox JR <Lum### [at] aolcom> wrote:

>This is the scene file for a test image of a coin that I've posted on
>povray.binaries.images. I've tested out all the macros I added, although
>I didn't end up using RadiusOf() or TotalChords() in here.
>This should come in handy the next time I want to do circular text. Many
>thanks for all the help, Ron.
>
>Lummox JR

This has been a great thread. It is good to see a resolution of a problem without the
need
to resort to modifying the code.  It illustrates everything that is right about this
newsgroup. Congratulations to everyone who has contributed and thank you for an
interesting tutorial.
----------------------------
dav### [at] cwcomnet
http://www.hamiltonite.mcmail.com
----------------------------

Post a reply to this message