Thorsten Froehlich wrote:

> In article <2oY### [at] econymdemoncouk> , Mike Williams 
> <mik### [at] nospamplease>  wrote:
> 
> 
>>Text objects appear to be slightly tilted
>>http://news.povray.org/3C306096.7040705@videotron.ca
>>
> 
> Was explained in the thread.


No.  What was explained was that I had to scale the text object by 10000 
to make the problem visible to the naked eye.

It appears that as the truetype font is parsed, a little error is added 
to the z component of every control point.  Since this is not reported 
with other splines or polygons*, I must assume that it is a problem with 
the code that converts the 2D set of control points of a truetype font 
to POV 3D points.

*I'm downloading RC2 as we speak, I'll test my theory tonight.
-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   videotron.ca  */}camera{location<6,1.25,-6>look_at a orthographic}

Post a reply to this message

In article <3CC### [at] videotronca> , Francois Labreque 
<fla### [at] videotronca>  wrote:

> It appears that as the truetype font is parsed, a little error is added
> to the z component of every control point.  Since this is not reported
> with other splines or polygons*, I must assume that it is a problem with
> the code that converts the 2D set of control points of a truetype font
> to POV 3D points.

But in order to assume this you already assume that (a) text characters are
internally presented by the same primitive as other objects and (b) that
characters are converted to 3d shapes before being rendered.  Both assumptions
are incorrect.

There is no "little error is added to the z component of every control point"
as the source code (of 3.1 for you right now, but nothing changed in 3.5)
clearly shows.

As I have pointed out numerous times before, this is simply a precision error
no matter how much you or others test your "theory", looking at the "fact" -
the source code - easily proves your "theory" wrong.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:

> In article <3CC### [at] videotronca> , Francois Labreque 
> <fla### [at] videotronca>  wrote:
> 
> 
>>It appears that as the truetype font is parsed, a little error is added
>>to the z component of every control point.  Since this is not reported
>>with other splines or polygons*, I must assume that it is a problem with
>>the code that converts the 2D set of control points of a truetype font
>>to POV 3D points.
>>
> 
> But in order to assume this you already assume that (a) text characters are
> internally presented by the same primitive as other objects and (b) that
> characters are converted to 3d shapes before being rendered.  Both assumptions
> are incorrect.


I didn't mean to say that truetype fonts were converted to meshes or 
prism objects, if that's what you think.  I made these "assumptions" 
assumption because, as you recommend below, I looked at the source code 
before making that reply and misinterpreted what GetZeroOneHits() does.

> 
> There is no "little error is added to the z component of every control point"
> as the source code (of 3.1 for you right now, but nothing changed in 3.5)
> clearly shows.


Again, sorry for using the wrong words. but...


> 
> As I have pointed out numerous times before, this is simply a precision error
> no matter how much you or others test your "theory", looking at the "fact" -
> the source code - easily proves your "theory" wrong.


You said "precision error", I said "little error addred to the z 
component".  Don't you think that amounts to the same thing?

The fact remains that:
- the longer the string, the larger the imprecision.
- this only affects text objects.
- it always increases in a left-to-right, top to bottom fashion.
- By the same amount.

It seemed to me like something that could be fixed.  But if you say it 
can't, then I'll drop the issue.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   videotron.ca  */}camera{location<6,1.25,-6>look_at a orthographic}

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote in news:3cc34e42@news.povray.org:

From the fixed bugs section:

> * Function namespace problem
>   (Declared function names can't be used as macro parameter names. Might
>   not be possible to be fixed with the current parser. This is being
>   investigated.)
>   Reported in:
> function declaration and namespace
> http://news.povray.org/l2ji3uc2k9su99o2gct3n2thgqoq7f4pd5@4ax.com

This one is still present / back in part in Windows RC3 with regard to 
#macro names rather than functions.

Example scene:

#macro Center(obj)
object {obj}
#end

#include "shapes.inc"

Parsing fails on line 248 of shapes.inc when the Spheroid macro attempts to 
use 'Center' as a parameter name.

If this can't be fixed in the parser, could the standard includes be 
modified so their parameter names are all lower case (like all other Pov 
keywords) or otherwise mangled to reduce the chances of collisions with 
user macros?  Coming up with macro names that don't collide is a real 
headache as long as this bug is in place because so name good names are 
already wasted on macro parameters.

Post a reply to this message

In article <Xns### [at] 204213191226> , che### [at] sympaticoca
(Coridon Henshaw) wrote:

> Parsing fails on line 248 of shapes.inc when the Spheroid macro attempts to
> use 'Center' as a parameter name.
>
> If this can't be fixed in the parser, could the standard includes be
> modified so their parameter names are all lower case (like all other Pov
> keywords) or otherwise mangled to reduce the chances of collisions with
> user macros?  Coming up with macro names that don't collide is a real
> headache as long as this bug is in place because so name good names are
> already wasted on macro parameters.

Well, how is a limitation going to be removed if nobody in the past four years
complained about it?

It isn't a new limitation in 3.5 also you seem to give that impression.
Having the same name twice in the same namespace simply cannot work.  It is
definitely not a bug and the documentation explains the namespace rules.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Coridon Henshaw wrote:
> 
> This one is still present / back in part in Windows RC3 with regard to
> #macro names rather than functions.
> 
> Example scene:
> 
> #macro Center(obj)
> object {obj}
> #end
> 
> #include "shapes.inc"
> 
> Parsing fails on line 248 of shapes.inc when the Spheroid macro
> attempts to use 'Center' as a parameter name.
> 
> If this can't be fixed in the parser, could the standard includes be
> modified so their parameter names are all lower case (like all other
> Pov keywords) or otherwise mangled to reduce the chances of collisions
> with user macros?  Coming up with macro names that don't collide is a
> real headache as long as this bug is in place because so name good
> names are already wasted on macro parameters.

A consistent naming scheme will alleviate this problem.

For instance, I prefix vector names with a v, scalars with s,
index variables with i, and so on.

Regards,
John


-- 
Rusty is rendering!

Post a reply to this message

John VanSickle <evi### [at] hotmailcom> wrote in news:3CD46365.433CEFA3
@hotmail.com:

>> Parsing fails on line 248 of shapes.inc when the Spheroid macro
>> attempts to use 'Center' as a parameter name.
 
> A consistent naming scheme will alleviate this problem.
> 
> For instance, I prefix vector names with a v, scalars with s,
> index variables with i, and so on.

This is what I'd call putting the cart before the horse.

Given that shapes.inc and the other #macro-laden #includes are a standard 
part of the distribution, I tend to think it'd make far more sense for them 
to use a consistant naming scheme to stay out of the *users* hair rather 
than for the user to go through all kinds of contortions to stay out of the 
#include's hair.

I mean, you wouldn't like the idea of prefixing every name in a C program 
with an underscore (etc) so it wouldn't collide with names used by the C 
RTL, would you?  Of course not.  That's why the component names used by C 
RTL are prefixed with underscores: so the user gets virtually the rest of 
the non-defined namespace to himself/herself.

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in
news:3cd3a6f6@news.povray.org: 

> It isn't a new limitation in 3.5 also you seem to give that impression.

Try this on 3.1:

#macro Center(Obj)
object {Obj}
#end
#include "shapes.inc"
#declare X = sphere {0,1}
Center (X)

It won't choke.  Now try it on 3.5.  Now try to find anything in the 
documentation that says this code is no longer valid under 3.5.

(Yes, I know /why/ it won't choke 3.1...  The reason why it won't choke 3.1 
is irrelevant; the fact that it *does* choke 3.5 is the problem.)

> Having the same name twice in the same namespace simply cannot work. 

Please tell that to the RC3 binary.  It copes just fine with #declared/
#localed names that match macro parameters:

#local X = function(x,y,z) {x+y+z}
#macro A(X) #end

Given that there's no valid reason to use the output of a macro to 
determine the name of another macro's parameters, not performing macro 
expansion during this portion of parsing seems reasonable for consistancy's 
sake alone.  For instance, why should the code above work when #macro X() 
#end #macro A(X) #end doesn't?

> the documentation explains the namespace rules. 

In this specific case, telling the user that he/she can't do #macro A() 
#macro B(A, D) is rather pointless when the user doesn't know that #macro B
(A, D) exists in the first place.  The point is that the standard includes 
are consuming huge swaths of the namespace without any real documentation  
or regard for what they might be stepping all over.  Finding safe names was 
not a matter of luck with 3.1; it is very much a matter of luck with 3.5 as 
soon as one #includes anything.  I don't think this change is particularly 
rational or user friendly.

Again, if the parser cannot practically be fixed at this stage, could the 
standard includes at least be modified so their macro parameter names are 
all lower case (like all other Pov keywords), mangled to reduce the chances 
of collisions with user macros, or added to the reserved keywords list in 
docs section 6.1.1?

Post a reply to this message

In article <Xns### [at] 204213191226> , che### [at] sympaticoca
(Coridon Henshaw) wrote:

>> Having the same name twice in the same namespace simply cannot work.
>
> Please tell that to the RC3 binary.  It copes just fine with #declared/
> #localed names that match macro parameters:
>
> #local X = function(x,y,z) {x+y+z}
> #macro A(X) #end

But that is a completely different case!  X is known to be a variable in both
cases and the variable namespace is well-defined.

> Given that there's no valid reason to use the output of a macro to
> determine the name of another macro's parameters,

You would be surprised what one can do (also the above can't be done) inside
macro parameter lists...

> not performing macro
> expansion during this portion of parsing seems reasonable for consistancy's
> sake alone.  For instance, why should the code above work when #macro X()
> #end #macro A(X) #end doesn't?

Because macros are in a completely different namespace.  In particular are
#macros behaving like macros and not functions (see <http://www.povray.org/
working-docs/id000153.html#6_2_8_3>) here.

As you know, #locals have a scope that is limited to files or the current
block while #macros are in a global namespace not really shareable with
#declares.  As POV-Ray identifiers are typeless there is significantly more
ambiguity when parsing such constructs.

As for the actual problem, by disallowing #declares (and anything that
implicitly declares an identifier) in parameter lists of #macro definitions
one can allow #macro identifiers as parameter names.  Nevertheless, this might
break some old scenes...

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Coridon Henshaw wrote:
> 
> John VanSickle <evi### [at] hotmailcom> wrote in news:3CD46365.433CEFA3
> @hotmail.com:
> 
> >> Parsing fails on line 248 of shapes.inc when the Spheroid macro
> >> attempts to use 'Center' as a parameter name.
> 
> > A consistent naming scheme will alleviate this problem.
> >
> > For instance, I prefix vector names with a v, scalars with s,
> > index variables with i, and so on.
> 
> This is what I'd call putting the cart before the horse.
> 
> Given that shapes.inc and the other #macro-laden #includes are a
> standard part of the distribution, I tend to think it'd make far more
> sense for them to use a consistant naming scheme to stay out of the
> *users* hair rather than for the user to go through all kinds of
> contortions to stay out of the #include's hair.
> 
> I mean, you wouldn't like the idea of prefixing every name in a C
> program with an underscore (etc) so it wouldn't collide with names
> used by the C RTL, would you?  Of course not.  That's why the
> component names used by C RTL are prefixed with underscores: so the
> user gets virtually the rest of the non-defined namespace to
> himself/herself.

But I also use a consistent naming convention to avoid trampling
my own variables as well.

Regards,
John
-- 
Rusty is rendering!

Post a reply to this message