https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.10013324

This version should fix crashes from user-defined functions, `text` 
primitives and recursive macro invocations.

Post a reply to this message

On 1/14/19 11:58 AM, clipka wrote:
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.10013324
> 
> This version should fix crashes from user-defined functions, `text` 
> primitives and recursive macro invocations.

Given you are looking at the parser, the text object and fonts I want to 
pass along an old signature scene file which has not never run correctly 
for me unless I create a COUR.TTF file.

I've made a couple runs at trying to find where the COUR.TTF default 
comes from in the code - including again just now - and failed. Guessing 
at some point just using the string ttf caused some defaulting to a font 
called COUR.TTF and some string perhaps. Think it something which should 
be cleaned up (just 'ttf' should fail parsing I think). The latest 
alpha.10013324 still generates:

File 'Sig34_LookAtWeirdDefaultAndFailSomeday.pov' line 2: Possible Parse 
Error:
  Text may not be displayed as expected. Please refer to the user manual
  regarding changes in POV-Ray v3.8 and later.
File 'Sig34_LookAtWeirdDefaultAndFailSomeday.pov' line 3: Possible Parse 
Error:
  Cannot find file 'COUR.TTF', even after trying to append file type 
extension.
File 'Sig34_LookAtWeirdDefaultAndFailSomeday.pov' line 3: Possible Parse 
Error:
  Cannot open font file.
Fatal error in parser: Cannot open file.
Render failed

Bill P.

Post a reply to this message

Attachments:
Download 'sig34_lookatweirddefaultandfailsomeday.pov.txt' (1 KB)

On 1/14/19 1:29 PM, William F Pokorny wrote:
> On 1/14/19 11:58 AM, clipka wrote:
>> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.10013324
>>
>> This version should fix crashes from user-defined functions, `text` 
>> primitives and recursive macro invocations.
> 
> Given you are looking at the parser, the text object and fonts I want to 
> pass along an old signature scene file which has not never run correctly 
> for me unless I create a COUR.TTF file.
> 
> I've made a couple runs at trying to find where the COUR.TTF default 
> comes from in the code - including again just now - and failed. Guessing 
> at some point just using the string ttf caused some defaulting to a font 
> called COUR.TTF and some string perhaps. Think it something which should 
> be cleaned up (just 'ttf' should fail parsing I think). The latest 
> alpha.10013324 still generates:
> 
> File 'Sig34_LookAtWeirdDefaultAndFailSomeday.pov' line 2: Possible Parse 
> Error:
>   Text may not be displayed as expected. Please refer to the user manual
>   regarding changes in POV-Ray v3.8 and later.
> File 'Sig34_LookAtWeirdDefaultAndFailSomeday.pov' line 3: Possible Parse 
> Error:
>   Cannot find file 'COUR.TTF', even after trying to append file type 
> extension.
> File 'Sig34_LookAtWeirdDefaultAndFailSomeday.pov' line 3: Possible Parse 
> Error:
>   Cannot open font file.
> Fatal error in parser: Cannot open file.
> Render failed
> 
> Bill P.
> 
> 
And I walk to get a coffee and it pops into my head what is happening 
here.... chr() Never mind. I spent all my time looking in the source 
code instead of the SDL...

Bill P.

Post a reply to this message

Am 14.01.2019 um 19:29 schrieb William F Pokorny:

> I've made a couple runs at trying to find where the COUR.TTF default 
> comes from in the code - including again just now - and failed. Guessing 
> at some point just using the string ttf caused some defaulting to a font 
> called COUR.TTF and some string perhaps.

The text is encoded in only mildly obfuscated form in the R vector:

     #local R=<7084844682857967,0787982,826975826580>

     70 84 84 46 82 85 79 67   78 79 82   82 69 75 82 65 80
     F  T  T  .  R  U  O  C    N  O  R    R  E  K  R  A  P

Both text objects use macro `L(P)` to decode R.x into "COUR.TTF" as the 
font name, and R.y and R.z respectively into "RON" and "PARKER" as the 
text string.


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.

Post a reply to this message

I've at least tried the text-object example that was crashing the previous
alpha-version, and it works fine now. Kudos!

[Clipka wrote]:
>
> The text is encoded in only mildly obfuscated form in the R vector:
>
>      #local R=<7084844682857967,0787982,826975826580>
>
>      70 84 84 46 82 85 79 67   78 79 82   82 69 75 82 65 80
>      F  T  T  .  R  U  O  C    N  O  R    R  E  K  R  A  P
>
> 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!

I just spent several hours going through that code-- which is really brilliant--
to dissect it. I understand *most* of it now, but there are some particular
pieces of code syntax that I'm not quite grasping. (Sorry to go off-topic, but
the code is fascinating.)

BTW, #debugging  mod(P,100) in the #while loop gives me these values (i.e.,
in reversed order from yours):

        67 79 85 82 46 84 84 70   82 79 78   80 65 82 75 69 82
        C  O  U  R   . T  T  F    R  O  N    P  A  R  K  E  R

..... along with some less-than-1.0 fractional values.

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?

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.

Post a reply to this message

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

clipka <ano### [at] anonymousorg> wrote:
>
> 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.

I have to admit my ignorance: That's a true revelation to me, after all this
time working with POV-Ray! I've always assumed that strings *required*
double-quotes, no matter how they were created or how they were used.

Thanks for taking the time to give such a clear and detailed explanation. It
will go into my archive of 'most-useful' discoveries :-)

And thanks to Bill Pokorny for posting the intriguing code. I would not have
thought to ask my questions otherwise.

Post a reply to this message