(Dang, committed 3 or 4 minutes too late or 6 or 7 minutes too soon for 
a really neat pre-release tag number ;))

Please try this - I hope it solves the crashes:

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

Post a reply to this message

On 1/12/19 11:39 PM, clipka wrote:
> (Dang, committed 3 or 4 minutes too late or 6 or 7 minutes too soon for 
> a really neat pre-release tag number ;))

:-) ...

> 
> Please try this - I hope it solves the crashes:
> 
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.10011104

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> (Dang, committed 3 or 4 minutes too late or 6 or 7 minutes too soon for
> a really neat pre-release tag number ;))

development is now driven by numerology?!  :-)

>
> Please try this - I hope it solves the crashes:
>
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.10011104

will do, thanks.


regards, jr.

Post a reply to this message

Known issue:

User-defined functions may cause a hard crash on some platforms.

If you encounter this issue, pelase copy 
`source/parser/parser_function_utilities.cpp` from the current master 
branch.

The Windows binaries appear to be unaffected, so I'm not rushing out a 
new version for now.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Known issue:
>
> User-defined functions may cause a hard crash on some platforms.

I've tried with two scenes, one crashes, the other does not.  the only
difference, afaict, is that the first uses array syntax in both declaration and
in one of the function components, while the second has no array stuff.

> If you encounter this issue, pelase copy
> `source/parser/parser_function_utilities.cpp` from the current master
> branch.
>
> The Windows binaries appear to be unaffected, so I'm not rushing out a
> new version for now.


regards, jr.

Post a reply to this message

Am 13.01.2019 um 17:11 schrieb jr:

> I've tried with two scenes, one crashes, the other does not.  the only
> difference, afaict, is that the first uses array syntax in both declaration and
> in one of the function components, while the second has no array stuff.

Then the recommended workaround probably applies to your system and, by 
extension, presumably Unix systems in general.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 13.01.2019 um 17:11 schrieb jr:
> > I've tried with two scenes, one crashes, the other does not.  the only
> > difference, afaict, is that the first uses array syntax in both declaration and
> > in one of the function components, while the second has no array stuff.
>
> Then the recommended workaround probably applies to your system and, by
> extension, presumably Unix systems in general.

ok.  do you have a 'wget'able url for that file, please?

btw, the alpha (also) crashes when there's an "old-style" text primitive, ie
without cmap {}, irrespective of charset present in global_settings.  does the
above workaround fix that too?


regards, jr.

Post a reply to this message

Am 13.01.2019 um 18:23 schrieb jr:
> hi,
> 
> clipka <ano### [at] anonymousorg> wrote:
>> Am 13.01.2019 um 17:11 schrieb jr:
>>> I've tried with two scenes, one crashes, the other does not.  the only
>>> difference, afaict, is that the first uses array syntax in both declaration and
>>> in one of the function components, while the second has no array stuff.
>>
>> Then the recommended workaround probably applies to your system and, by
>> extension, presumably Unix systems in general.
> 
> ok.  do you have a 'wget'able url for that file, please?

I have no idea what a "'wget'able" URL is, but maybe this one qualifies:

https://raw.githubusercontent.com/POV-Ray/povray/master/source/parser/parser_functions_utilities.cpp


> btw, the alpha (also) crashes when there's an "old-style" text primitive, ie
> without cmap {}, irrespective of charset present in global_settings.  does the
> above workaround fix that too?

I thought you were confirming that v3.8.0-alpha.10011104 fixed your 
issue? Please clarify, and double-check the version you're running.

Those `text` primitive crashes you were observing are totally unrelated 
to the user-defined function crashes.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 13.01.2019 um 18:23 schrieb jr:
> > ok.  do you have a 'wget'able url for that file, please?
> 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.

>
https://raw.githubusercontent.com/POV-Ray/povray/master/source/parser/parser_functions_utilities.cpp

will do nicely.  thanks.

> > btw, the alpha (also) crashes when there's an "old-style" text primitive, ie
> > without cmap {}, irrespective of charset present in global_settings.  does the
> > above workaround fix that too?
>
> I thought you were confirming that v3.8.0-alpha.10011104 fixed your
> issue? Please clarify, and double-check the version you're running.
>
> Those `text` primitive crashes you were observing are totally unrelated
> to the user-defined function crashes.

yes, I appreciate that.

I used a reduced version of the 'pav-patt.pov' for the test, with the latest (ie
10011104) alpha.  it crashes when T2 "visible":

#version 3.8;
global_settings {assumed_gamma 1}

#declare S = "abcdef";

#declare T1 = text {
  ttf "arialbd.ttf" cmap { 1,0 charset 0 }
  S
  0.001 0
  pigment { color rgb<1.0, 0.6, 0.2>*1.25 }
  no_shadow
};

#if (0)
#declare T2 = text {
  ttf "arialbd.ttf"
  S
  0.001 0
  pigment { color rgb 0.1 }
  no_shadow
};
#end


regards, jr.

Post a reply to this message

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 ;)

Post a reply to this message

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)

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

On 1/14/19 11:39 AM, clipka wrote:
> 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.

Cool. Glad you found it.

Bill P.

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:
...
> 
> 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

> 

Stuff still running. I've turned up several more of the macro/include 
return type.

One of our standard shipped scene files fails due a form feed character 
'0c' very near the end the end of the file. That scene is:

.../distribution/scenes/objects/superel2.pov

and here I think we just need to update that scene file.

Bill P.

Post a reply to this message

Am 14.01.2019 um 18:15 schrieb William F Pokorny:

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

Let's put it this way: Going by the reference docs on numeric 
expressions - specifically FLOAT_LITERAL - the v3.7 behaviour would have 
to be considered broken, unless interpreting the syntax in a 
self-inconsistent manner.

The key question is under what circumstances a sequence of characters 
that matches the production rules of FLOAT_LITERAL, followed by some 
other character that does not fit in, constitutes a broken 
FLOAT_LITERAL, as opposed to a valid FLOAT_LITERAL token immediately 
followed by the next token.

The v3.6 behaviour can easily be interpreted as consistently treating 
such cases as valid, but erroneously implementing MANTISSA as:

     MANTISSA:
       DIGIT... [DECIMAL_POINT | [DIGIT2...] |
       DECIMAL_POINT DIGIT2...
     DIGIT2:
       DIGIT | DECIMAL_POINT

The v3.7 behaviour must be interpreted as treating such cases as broken 
if the non-matching character is a dot, but valid if it is any other 
character. That's a pretty arbitrary distinction.

The (new) v3.8 behaviour consistently treats all such cases as valid 
again, while implementing MANTISSA as documented.


> 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).

That would have to be `1.` followed by `.2`.

> Or where we specify lists of values separated 
> by commas or not. Can the latter get scrambled in ways that are confusing?

Dots don't constitute valid infix or postfix operators in numeric 
expressions, so there's no ambiguity there.

Post a reply to this message

On 1/14/19 1:41 PM, clipka wrote:
> Am 14.01.2019 um 18:15 schrieb William F Pokorny:
> 
>> Suppose my question was too whether we should consider the 3.7/3.8 
>> behavior broken - you seem to be saying it was.
> 
> Let's put it this way: Going by the reference docs on numeric 
> expressions - specifically FLOAT_LITERAL - the v3.7 behaviour would have 
> to be considered broken, unless interpreting the syntax in a 
> self-inconsistent manner.
> 
> The key question is under what circumstances a sequence of characters 
> that matches the production rules of FLOAT_LITERAL, followed by some 
> other character that does not fit in, constitutes a broken 
> FLOAT_LITERAL, as opposed to a valid FLOAT_LITERAL token immediately 
> followed by the next token.
> 
> The v3.6 behaviour can easily be interpreted as consistently treating 
> such cases as valid, but erroneously implementing MANTISSA as:
> 
>      MANTISSA:
>        DIGIT... [DECIMAL_POINT | [DIGIT2...] |
>        DECIMAL_POINT DIGIT2...
>      DIGIT2:
>        DIGIT | DECIMAL_POINT
> 
> The v3.7 behaviour must be interpreted as treating such cases as broken 
> if the non-matching character is a dot, but valid if it is any other 
> character. That's a pretty arbitrary distinction.
> 
> The (new) v3.8 behaviour consistently treats all such cases as valid 
> again, while implementing MANTISSA as documented.
> 
> 
>> 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).
> 
> That would have to be `1.` followed by `.2`.
> 
>> Or where we specify lists of values separated by commas or not. Can 
>> the latter get scrambled in ways that are confusing?
> 
> Dots don't constitute valid infix or postfix operators in numeric 
> expressions, so there's no ambiguity there.

Thanks for the detail. I've been playing with variations for the last 
hour or so and created some new parser test cases in my collection to 
track this change. While 1..2 gets treated as two numbers .1..2 and the 
like do not - so even the exposure to period over comma typos is small.

Not picked up anything new and have switched over to your latest code - 
it fixed all the recursive return fails I had. Should finish up tomorrow 
sometime and will post again only if something new turns up.

For the record I'm only checking the parser with my tests. I'm not doing 
image to image compares. Image compares will happen over time after I 
rebase my branches onto the current master head and continue other 
efforts.

Bill P.

Post a reply to this message

Am 14.01.2019 um 21:29 schrieb William F Pokorny:

> For the record I'm only checking the parser with my tests. I'm not doing 
> image to image compares. Image compares will happen over time after I 
> rebase my branches onto the current master head and continue other efforts.

I think that's perfectly fine; I don't expect any parser issues to be 
subtle enough to make it to the rendering stage - with the exception of 
string and text handling, specifically non-ASCII stuff.

Post a reply to this message

Am 14.01.2019 um 18:23 schrieb William F Pokorny:

> One of our standard shipped scene files fails due a form feed character 
> '0c' very near the end the end of the file. That scene is:
> 
> ..../distribution/scenes/objects/superel2.pov
> 
> and here I think we just need to update that scene file.

Page breaks used to be common in ASCII files a while ago; I feel somehow 
inclined to just allow them as whitespace.

The only thing that's holding me back is that I'm not exactly sure what 
effect they should have on column and line counting.

Post a reply to this message

On 1/14/19 3:54 PM, clipka wrote:
> Am 14.01.2019 um 18:23 schrieb William F Pokorny:
> 
>> One of our standard shipped scene files fails due a form feed 
>> character '0c' very near the end the end of the file. That scene is:
>>
>> ..../distribution/scenes/objects/superel2.pov
>>
>> and here I think we just need to update that scene file.
> 
> Page breaks used to be common in ASCII files a while ago; I feel somehow 
> inclined to just allow them as whitespace.
> 
> The only thing that's holding me back is that I'm not exactly sure what 
> effect they should have on column and line counting.

Yeah, suppose they could be as whitespace. Then we'd want to provide the 
same treatment for some other printer(system bell?) oriented encodings 
too if you go that route. Vertical-tab comes to mind & expect there are 
a few more.

Even in the old days it was printer dependent in terms of real world 
space(1) so not sure treating those special characters as something 
other than a single white space makes sense. I say this, though, not 
knowing what the POV-Ray windows editor does which such characters?

As for having these kind of characters in sample scene files we ship, 
suppose I'd argue they shouldn't exist. In my editor/font I get some odd 
fill-in character for it. I'm not sure what others might or might not see.

Bill P.

(1) - Do I admit my earliest college programming classes used teletype 
computer terminals... Ah, the noise. :-)

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 1/14/19 3:54 PM, clipka wrote:
> > Am 14.01.2019 um 18:23 schrieb William F Pokorny:
> >
> >> One of our standard shipped scene files fails due a form feed
> >> character '0c' very near the end the end of the file. That scene is:
> >>
> >> ..../distribution/scenes/objects/superel2.pov
> >>
> >> and here I think we just need to update that scene file.
> >
> > Page breaks used to be common in ASCII files a while ago; I feel somehow
> > inclined to just allow them as whitespace.
> >
> > The only thing that's holding me back is that I'm not exactly sure what
> > effect they should have on column and line counting.
>
> Yeah, suppose they could be as whitespace. Then we'd want to provide the
> same treatment for some other printer(system bell?) oriented encodings
> too if you go that route. Vertical-tab comes to mind & expect there are
> a few more.
>
> Even in the old days it was printer dependent in terms of real world
> space(1) so not sure treating those special characters as something
> other than a single white space makes sense. I say this, though, not
> knowing what the POV-Ray windows editor does which such characters?

At the very least, it seems logical to increment the line count.  I don't think
it would be necessary--or, at this late date, prudent--to assume a certain
number of lines per page.

[...]

> (1) - Do I admit my earliest college programming classes used teletype
> computer terminals... Ah, the noise. :-)

You make me feel young, now.  I had VT-100s in college.

Although at my co-op job, I actually had to deal with punched cards and IBM's
JCL.

Post a reply to this message

On 1/15/19 8:21 AM, Cousin Ricky wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
> At the very least, it seems logical to increment the line count.  I don't think
> it would be necessary--or, at this late date, prudent--to assume a certain
> number of lines per page.

Not sure. The common unix line counting command shows the line count 
(and character) as if the form feed and vertical tab characters are just 
spaces.

Editors seem to be different. GVim (1) is showing ^L and ^K stand in 
sequences and then columns after in each line as a range, 10-11 say, 
instead of a fixed 10. Gedit shows single undefined unicode characters 
breaking the mono-space width. Others tried create a mono-space stand at 
least indicating some odd character is present and the visual 
representation stays aligned. Expect some of the editor behavior is 
driven by the font in use. Though in trying a few different fonts with 
gvim, fixed and not, it is always showing the ^L or ^K sequence and some 
visual miss-alignment.

(1) - all vi based editors I expect

> 
> [...]
> 
>> (1) - Do I admit my earliest college programming classes used teletype
>> computer terminals... Ah, the noise. :-)
> 
> You make me feel young, now.  I had VT-100s in college.
> 
> Although at my co-op job, I actually had to deal with punched cards and IBM's
> JCL.
> 
> 
JCL :-). How do we want the file xyz to physically exist on the drive... 
I worked with it a fair bit early in my work career.

Post a reply to this message

Le 19-01-15 à 06:03, William F Pokorny a écrit :
> On 1/14/19 3:54 PM, clipka wrote:
>> Am 14.01.2019 um 18:23 schrieb William F Pokorny:
>>
>>> One of our standard shipped scene files fails due a form feed 
>>> character '0c' very near the end the end of the file. That scene is:
>>>
>>> ..../distribution/scenes/objects/superel2.pov
>>>
>>> and here I think we just need to update that scene file.
>>
>> Page breaks used to be common in ASCII files a while ago; I feel 
>> somehow inclined to just allow them as whitespace.
>>
>> The only thing that's holding me back is that I'm not exactly sure 
>> what effect they should have on column and line counting.
> 
> Yeah, suppose they could be as whitespace. Then we'd want to provide the 
> same treatment for some other printer(system bell?) oriented encodings 
> too if you go that route. Vertical-tab comes to mind & expect there are 
> a few more.
> 
> Even in the old days it was printer dependent in terms of real world 
> space(1) so not sure treating those special characters as something 
> other than a single white space makes sense. I say this, though, not 
> knowing what the POV-Ray windows editor does which such characters?
> 
> As for having these kind of characters in sample scene files we ship, 
> suppose I'd argue they shouldn't exist. In my editor/font I get some odd 
> fill-in character for it. I'm not sure what others might or might not see.
> 
> Bill P.
> 
> (1) - Do I admit my earliest college programming classes used teletype 
> computer terminals... Ah, the noise. :-)

Treating form feed as just line feed or new line should be correct.

Post a reply to this message