hi,

clipka <ano### [at] anonymousorg> wrote:
> Users building their own binaries (most notably Unix users) may also use
> `source/core/shape/truetype.cpp` from the latest master, which should
> fix the issue:
>
https://raw.githubusercontent.com/POV-Ray/povray/master/source/core/shape/truetype.cpp

thanks.  got the files, will recompile etc by midweek or so.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

>
> I used a reduced version of the 'pav-patt.pov' for the test, with the
> latest (ie 10011104) alpha.  it crashes when T2 "visible":
>
> #declare T2 = text {
>   ttf "arialbd.ttf"
>   S
>   0.001 0
>   pigment { color rgb 0.1 }
>   no_shadow
> };
>

T2 when used also hard-crashes in Windows (Win7 Ultimate). But the behavior is
strange-- sometimes it doesn't crash for the first 4 out of 5 runs (for
example), sometimes on the first run-- then with a Windows message "... a memory
access violation has occured at ..."

Otherwise, I've run approximately 40 of my own scenes-- with arrays,
user-defined functions, and other text objects in the mix-- and everything works
fine, so far. But my own text objects are of this form...

text{
internal 1 "my text here"

.....rather than
text{
ttf "arielbd.ttf"
S

Post a reply to this message

Am 14.01.2019 um 01:43 schrieb Kenneth:

> T2 when used also hard-crashes in Windows (Win7 Ultimate). But the behavior is
> strange-- sometimes it doesn't crash for the first 4 out of 5 runs (for
> example), sometimes on the first run-- then with a Windows message "... a memory
> access violation has occured at ..."

Yeah, memory access violations do that: Sometimes the memory accessed 
happens to hold something that the process can legally read.


> Otherwise, I've run approximately 40 of my own scenes-- with arrays,
> user-defined functions, and other text objects in the mix-- and everything works
> fine, so far. But my own text objects are of this form...
> 
> text{
> internal 1 "my text here"

You shouldn't use that syntax. Quoth the docs:

"It should be noted that this is only a preliminary solution so the 
benchmark program will run without installing POV-Ray. Future versions 
may lack this mechanism, so in scene files (other than the built-in 
benchmark) you should continue to reference the external font files as 
before."

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> > ...But my own text objects are of this form...
> >
> > text{
> > internal 1 "my text here"
>
> You shouldn't use that syntax. Quoth the docs...

Funny thing about that: I started using the 'internal' syntax sometime over the
past year(?), because using the font NAME (like JR's example of  ttf "arielbd")
suddenly no longer worked for me-- causing a fatal error, or a crash (I can't
remember which-- or which alpha/beta verson of POV I was running at the time.)
Then I promptly forgot why I changed it! (And never changed it back.)

Thanks for the documentation reminder.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

>
> Funny thing about that: I started using the 'internal' syntax sometime over the
> past year(?), because using the font NAME (like JR's example of  ttf "arielbd")
> suddenly no longer worked for me-- ...

..... or it could have been good ol' human error on my part, like misspelling the
ttf font name.  :-(  The simple error message I *probably* got at the time was,
"Cannot find font file"

Post a reply to this message

On 1/13/19 5:07 PM, clipka wrote:
> Am 13.01.2019 um 23:04 schrieb clipka:
>> Another known issue:
>>
>> Scenes making use of `text` primitives may cause a parse error or even 
>> hard crash under certain circumstances. This time the Windows version 
>> must also be considered vulnerable.
> 
> Users building their own binaries (most notably Unix users) may also use 
> `source/core/shape/truetype.cpp` from the latest master, which should 
> fix the issue:
> 
>
https://raw.githubusercontent.com/POV-Ray/povray/master/source/core/shape/truetype.cpp

> 
Running master at commit f9e8bce or I believe with the change above. The 
attached file (Someone's signature scene) from my parser testing 
collection gives:

==== [Parsing...] ==========================================================
File 'Sig00.pov' line 2: Parse Warning: Float value promoted to full 
color vector where both filter and transmit >0.0.
File 'Sig00.pov' line 1: Parse Error: End of file reached but #end expected.
Fatal error in parser: Cannot parse input.
Render failed

It renders fine in other versions OK.

Unfortunately a change in my own tcl code base caused problems running 
the complete set of test cases... Off to fix that and try the complete 
set again.

Bill P.

Post a reply to this message

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

On 1/14/19 9:07 AM, William F Pokorny wrote:
> On 1/13/19 5:07 PM, clipka wrote:
...
> 

Just noticed another interesting thing in the tests that did run. The 
attached file has not parser cleanly since v3.6.1. Generating the 
following error with v3.7:

File 'Sig07_works_v361_earlier.pov' line 1: Parse Error: Unexpected 
additional
  '.' in floating-point number
Fatal error in parser: Cannot parse input.
Render failed


It parses and runs cleanly again with the updated parser. Intentional?

Bill P.

Post a reply to this message

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

Am 14.01.2019 um 16:18 schrieb William F Pokorny:

> Just noticed another interesting thing in the tests that did run. The 
> attached file has not parser cleanly since v3.6.1. Generating the 
> following error with v3.7:

I presume you mean to say that it worked in v3.6.1, but not in v3.7, 
correct?

> File 'Sig07_works_v361_earlier.pov' line 1: Parse Error: Unexpected 
> additional
>   '.' in floating-point number
> Fatal error in parser: Cannot parse input.
> Render failed

Those are some mean pieces of scene code; no surprise they catch the 
parser with its pants down ;)

> It parses and runs cleanly again with the updated parser. Intentional?

No, just a lucky punch. Turns out sometimes throwing away and rewriting 
old code fixes things you didn't even know were broken.

Post a reply to this message

Am 14.01.2019 um 15:07 schrieb William F Pokorny:

> File 'Sig00.pov' line 2: Parse Warning: Float value promoted to full 
> color vector where both filter and transmit >0.0.
> File 'Sig00.pov' line 1: Parse Error: End of file reached but #end 
> expected.
> Fatal error in parser: Cannot parse input.
> Render failed

Traced this down to a bug in the scanner that kicks in whenever two 
consecutive returns from a macro or include file jump back to the same 
binary offset in (formally) different input streams

One such scenario is the return from a macro that has called itself 
recursively and hasn't called other macros since.

Post a reply to this message

On 1/14/19 10:54 AM, clipka wrote:
> Am 14.01.2019 um 16:18 schrieb William F Pokorny:
> 
>> Just noticed another interesting thing in the tests that did run. The 
>> attached file has not parser cleanly since v3.6.1. Generating the 
>> following error with v3.7:
> 
> I presume you mean to say that it worked in v3.6.1, but not in v3.7, 
> correct?

Yes, I did! You are getting good at understand my gibberish. :-)

> 
...
> 
>> It parses and runs cleanly again with the updated parser. Intentional?
> 
> No, just a lucky punch. Turns out sometimes throwing away and rewriting 
> old code fixes things you didn't even know were broken.

Suppose my question was too whether we should consider the 3.7/3.8 
behavior broken - you seem to be saying it was.

Folks can again cause parsing to separate values by using extra decimal 
points in numeric strings. Has me wondering what might happen with typos 
like 1..2 (not tried it). Or where we specify lists of values separated 
by commas or not. Can the latter get scrambled in ways that are confusing?

I'll go try some things I guess to better understand what can again 
happen with this reversion in parser behavior.

Bill P.

Post a reply to this message