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