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