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