clipka <ano### [at] anonymousorg> wrote:
> Am 13.01.2019 um 21:06 schrieb jr:
>
> >> I have no idea what a "'wget'able" URL is, but maybe this one qualifies:
> >
> > "man 1 wget", or "curl".  command-line tools to fetch stuff.
>
> Heh, don't expect me to know about any of that; I'm a Windows jockey and
> mouse pusher ;)

:-)  (or perhaps a frown.  really not sure)

on "the substance" then, you manage to reproduce the crash, I take it?


regards, jr.

Post a reply to this message

Am 13.01.2019 um 22:01 schrieb jr:

>> Heh, don't expect me to know about any of that; I'm a Windows jockey and
>> mouse pusher ;)
> 
> :-)  (or perhaps a frown.  really not sure)
> 
> on "the substance" then, you manage to reproduce the crash, I take it?

More like, "I'll get back to you on that".

That was the status when I wrote that post, anyway. Meanwhile I did find 
a bug that could conceivably cause a crash, and am in the process of 
submitting a fix.

Post a reply to this message

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.

If you encounter this problem, try inserting `cmap { 1,0 charsert 0 }` 
after the font file name. Alternatively, using `#version 3.7; 
global_setting { charset ascii }` should also be a viable workaround as 
long as you do indeed only use ASCII characters.

Post a reply to this message

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

Post a reply to this message

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)