POV-Ray : Newsgroups : povray.beta-test : POV-Ray v3.8.0-alpha.10013324 : Re: POV-Ray v3.8.0-alpha.10013324 Server Time
24 Apr 2024 17:21:00 EDT (-0400)
  Re: POV-Ray v3.8.0-alpha.10013324  
From: clipka
Date: 15 Jan 2019 14:58:09
Message: <5c3e3b51$1@news.povray.org>
Am 15.01.2019 um 14:31 schrieb Kenneth:

>> I actually found it pretty easy to untangle: Knowing that there is no
>> such default, I looked for /some/ mechanism that could conjure strings
>> out of thin air. `chr` was my hottest candidate, and once I spotted it
>> in macro `L(P)`, the rest almost trivially fell into place.
> 
> Trivial??!  :-O  Nice detective work!

Note that I'm not looking at the details; the general idea is all I'm after.

> The syntax questions:
> 1) In the #while loop, the value of mod(P,100) eventually falls below 1.0 to a
> decimal fraction (before P itself finally reaches such a small value as to be
> considered zero or 'false', to end the loop.) But what does   chr(...)  'see'
> when it sees a fraction like
>           0.70848?
> Or rather, does mod(...) truncate fractions to zero? Whatever ASCII character
> that  chr(...) *does* return in such a case would seem to be part of the final
> text string (via the #while loop); but I'm wondering how that affects the final
> text object, if at all?

The `mod()` does not truncate fractions. The `chr()` function does 
truncate fractions first, then converts the resulting integer value to a 
character (according to the UCS-2 character set, of which ASCII is a 
subset).

The result would be U+0000, which happens to be the value used 
internally to mark the end of the string; so even if other characters 
were to follow, downstream code would truncate the string at that 
position. For all other intents and purposes, the U+0000 character 
itself is ignored.

> I'm also wondering how the code's #macro construct adds the required
> double-quotes around the #while-loop's created strings (for final use in the
> text objects). The syntax used there is new to me. There's a pair of
> double-quotes near the end of the macro that *looks* like it's just an 'empty
> string', but I don't grasp what it's doing.

There is no need for double quotes. You only need those when you specify 
strings literally, not when using any other mechanism that gives you a 
string.

Consider the following code:

     #declare LetterA = chr(65);

This gives you a string consisting of only the uppercase letter `A`. No 
need for quotes - you got the string already. It is equivalent to:

     #declare LetterA = "A";

There, you need the quotes to tell POV-Ray that you want the `A` to be 
taken as a string containing that letter, as opposed to the value of an 
identifier named `A`.

Now consider the following code:

     #declare S = concat(LetterA,LetterB)

This will take the strings currently stored in `LetterA` and `LetterB`, 
and pass them to the function `concat`, which will compose a new string 
containing the concatenation of those strings. Again no quotes 
necessary, because at no point do you mean the literal character 
sequences `concat`, `LetterA` or `LetterB`, but rather the function 
asssociated with the keyword and the values stored in the variables, 
respectively.

Now consider the following:

     text { ttf "MyFont", "MyText", ... }

This means a text object with a font literally named `MyFont`[.ttf], and 
with the literal text `MyText`. Compare this to:

     text { ttf MyFont MyText ... }

This instead means a text object with a font name as per the current 
value of the variable named `MyFont` and with the same text as currently 
stored in the variable named `MyText`.

Now back to the functions:

     text { ttf concat(chr(65),chr(66))
                concat(chr(67),chr(68)) ... }

This means a text object with a font whose name is the concatenation of 
the characters 65 and 66 of the ASCII character set (that would be the 
literal string `AB`[ttf]), and a text which is the concatenation of the 
characters 67 and 68 (that would be `CD`).

If you were to place double quotes around it, like so:

     text { ttf "concat(chr(65),chr(66))"
                "concat(chr(67),chr(68))" ... }

then this would mean a text object with a font literally named 
`concat(chr(65),chr(66)).ttf` and literally the text 
`concat(chr(67),chr(68))`. I'm not even sure whether the font name would 
be a valid file name, but that's what POV-Ray would try.

If you want to use quotes but have the same result as the earlier code, 
you'd instead have to use:

     text { ttf "AB" "CD" ... }

I hope this gives you a clearer picture.


So, to sum up: Quotes are only necessary where you want to specify a 
string by literally spelling out the string's content. If you construct 
the string's content in any other way, quotes would only be in the way.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.