Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.postscript > #2041 > unrolled thread

Correct or error in GhostScript

Back to article view | Back to comp.lang.postscript

Contents

  Correct or error in GhostScript Cecil Westerhof <Cecil@decebal.nl> - 2014-09-12 23:31 +0200
    Re: Correct or error in GhostScript Scott Hemphill <hemphill@hemphills.net> - 2014-09-12 18:12 -0400
      Re: Correct or error in GhostScript Cecil Westerhof <Cecil@decebal.nl> - 2014-09-13 01:17 +0200
        Re: Correct or error in GhostScript tlvp <mPiOsUcB.EtLlLvEp@att.net> - 2014-09-12 21:04 -0400
          Re: Correct or error in GhostScript Scott Hemphill <hemphill@hemphills.net> - 2014-09-12 22:11 -0400
    Re: Correct or error in GhostScript tlvp <mPiOsUcB.EtLlLvEp@att.net> - 2014-09-12 20:59 -0400
    Re: Correct or error in GhostScript luser- -droog <mijoryx@yahoo.com> - 2014-09-13 00:05 -0700
      Re: Correct or error in GhostScript tlvp <mPiOsUcB.EtLlLvEp@att.net> - 2014-09-13 04:17 -0400
        Re: Correct or error in GhostScript luser- -droog <mijoryx@yahoo.com> - 2014-09-13 01:47 -0700
          Re: Correct or error in GhostScript tlvp <mPiOsUcB.EtLlLvEp@att.net> - 2014-09-13 13:27 -0400
            Re: Correct or error in GhostScript tlvp <mPiOsUcB.EtLlLvEp@att.net> - 2014-09-13 20:16 -0400
            Re: Correct or error in GhostScript luser- -droog <mijoryx@yahoo.com> - 2014-09-16 22:53 -0700
              Re: Correct or error in GhostScript luser- -droog <mijoryx@yahoo.com> - 2014-09-16 23:01 -0700
              Re: Correct or error in GhostScript tlvp <mPiOsUcB.EtLlLvEp@att.net> - 2014-09-17 14:37 -0400
                Re: Correct or error in GhostScript luser- -droog <mijoryx@yahoo.com> - 2014-09-17 21:33 -0700
                  Re: Correct or error in GhostScript tlvp <mPiOsUcB.EtLlLvEp@att.net> - 2014-09-18 03:04 -0400

#2041 — Correct or error in GhostScript

This produces nothing:
    30  30  10  360  0  arc stroke

While this draws a circle:
    30  30  10  0  360  arc stroke

Is this correct, or is it an error in GhostScript?
I am using Ghostscript 9.06.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [next] | [standalone]

#2042

Cecil Westerhof <Cecil@decebal.nl> writes:

> This produces nothing:
>     30  30  10  360  0  arc stroke
>
> While this draws a circle:
>     30  30  10  0  360  arc stroke
>
> Is this correct, or is it an error in GhostScript?
> I am using Ghostscript 9.06.

It's probably correct, or the operator "arcn" wouldn't exist.

Scott
-- 
Scott Hemphill	hemphill@alumni.caltech.edu
"This isn't flying.  This is falling, with style."  -- Buzz Lightyear

[toc] | [prev] | [next] | [standalone]

#2043

Op Saturday 13 Sep 2014 00:12 CEST schreef Scott Hemphill:

> Cecil Westerhof <Cecil@decebal.nl> writes:
>
>> This produces nothing:
>> 30  30  10  360  0  arc stroke
>>
>> While this draws a circle:
>> 30  30  10  0  360  arc stroke
>>
>> Is this correct, or is it an error in GhostScript?
>> I am using Ghostscript 9.06.
>
> It's probably correct, or the operator "arcn" wouldn't exist.

But:
    30  30  10  360  90  arc stroke
does draw a quarter circle.

Maybe from the first parameter 360 is subtracted until it is lower as
360 (or lower equal the second parameter). Then it becomes:
    30  30  10  0  0  arc stroke

and that would not draw anything.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#2045

On Sat, 13 Sep 2014 01:17:22 +0200, Cecil Westerhof wrote:

> But:
>     30  30  10  360  90  arc stroke
> does draw a quarter circle.

And just so 30 30 10 360 0 arc stroke draws a zero-fraction circle.
One point. That at the far right on the equator, at elevation 360 (or, if
you prefer, at elevation 0). Probably too thin to see. (Cf. my response
just moments ago to your OP :-) .) Cheers, -- tlvp
-- 
Avant de repondre, jeter la poubelle, SVP.

[toc] | [prev] | [next] | [standalone]

#2046

tlvp <mPiOsUcB.EtLlLvEp@att.net> writes:

> On Sat, 13 Sep 2014 01:17:22 +0200, Cecil Westerhof wrote:
>
>> But:
>>     30  30  10  360  90  arc stroke
>> does draw a quarter circle.
>
> And just so 30 30 10 360 0 arc stroke draws a zero-fraction circle.
> One point. That at the far right on the equator, at elevation 360 (or, if
> you prefer, at elevation 0). Probably too thin to see. (Cf. my response
> just moments ago to your OP :-) .) Cheers, -- tlvp

Which you can see on the standard output like so:

GS>/m { = = (moveto) = } def
GS>/l { = = (lineto) = } def
GS>/c { = = = = = = (curveto) = } def
GS>/cl { (closepath) = } def
GS>30 30 10 360 0 arc /m load /l load /c load /cl load pathforall
29.999
39.9987
moveto
29.999
39.9987
29.999
39.9987
29.999
39.9987
curveto

(I did't bother reversing the order of the arguments.)

Scott
-- 
Scott Hemphill	hemphill@alumni.caltech.edu
"This isn't flying.  This is falling, with style."  -- Buzz Lightyear

[toc] | [prev] | [next] | [standalone]

#2044

On Fri, 12 Sep 2014 23:31:43 +0200, Cecil Westerhof wrote:

> This produces nothing:
>     30  30  10  360  0  arc stroke
> 
> While this draws a circle:
>     30  30  10  0  360  arc stroke
> 
> Is this correct, or is it an error in GhostScript?
> I am using Ghostscript 9.06.

I suspect it is correct. 

Remember that the /arc/ operator "appends a counterclockwise arc ... to the
current path."[1]

For a clockwise arc, use negative arc, or /arcn/ , operator.

Thus you should find that 30 30 10 360 0 arcn stroke delivers the same
apparent image as does 30 30 10 0 360 arc stroke .

In fact, using the standard generic notation x y r a_0 a_1 arc for the
/arc/ operator and its arguments, it's commonly expected that the ending
angle a_1 be = to or > than the starting angle a_0 -- and that, if < holds
instead, then a_1 will get replaced by what results from repeatedly adding
360 to a_1 until that sum is = to or > than a_0.

Thus 30 30 10 0 360 arc is already in expected form, but your other variant
30 30 10 360 0 arc will be replaced by 30 30 10 360 360 arc, which
delineates the single point at 30 30 10 add exch (i.e.,  at 40 30).

(No I've not tested that by stroking it using a fat line with rounded end.
Nor by stroking the infinitesimally longer variant, 30 30 10 360 1 arc .)

HTH. Cheers, -- tlvp
----
[1]  The Adobe PostScript Red Book (LRM).
-- 
Avant de repondre, jeter la poubelle, SVP.

[toc] | [prev] | [next] | [standalone]

#2047

the PLRM sez:

If angle2 is less than angle1, it is increased by multiples of 360 until it becomes
greater than or equal to angle1. No other adjustments are made to the two angles.
In particular, the angle subtended by the arc is not reduced modulo 360; if the difference
angle2 - angle1 exceeds 360, the resulting path will trace portions of the
circle more than once.

[toc] | [prev] | [next] | [standalone]

#2049

On Sat, 13 Sep 2014 00:05:02 -0700 (PDT), luser- -droog wrote:

> the PLRM sez:
> 
> If angle2 is less than angle1, it is increased by multiples of 360 until it becomes
> greater than or equal to angle1. No other adjustments are made to the two angles.
> In particular, the angle subtended by the arc is not reduced modulo 360; if the difference
> angle2 - angle1 exceeds 360, the resulting path will trace portions of the
> circle more than once.

Yes. I'd always been in awe of how great was the respect of the PostScript
designer(s) for the classic complex variables concept of "winding number",
which the behavior you describe corroborates :-) . Cheers, -- tlvp
-- 
Avant de repondre, jeter la poubelle, SVP.

[toc] | [prev] | [next] | [standalone]

#2050

On Saturday, September 13, 2014 3:17:43 AM UTC-5, tlvp wrote:
> On Sat, 13 Sep 2014 00:05:02 -0700 (PDT), luser- -droog wrote:
> 
> > the PLRM sez:
> > 
> > If angle2 is less than angle1, it is increased by multiples of 360 until it becomes
> > greater than or equal to angle1. No other adjustments are made to the two angles.
> > In particular, the angle subtended by the arc is not reduced modulo 360; if the difference
> > angle2 - angle1 exceeds 360, the resulting path will trace portions of the
> > circle more than once.
> 
> Yes. I'd always been in awe of how great was the respect of the PostScript
> designer(s) for the classic complex variables concept of "winding number",
> which the behavior you describe corroborates :-) . Cheers, -- tlvp

Wait, what? Winding number is a concept in complex variables?? That's one of 
the points I still haven't figured out how to implement for xpost. Oh great
math teacher, dixi molto! :)

To corroborate (and abuse) this feature of postscript, here's a way to 
draw a spiral.

300 400 translate
0 0 250 0 3600 arc 
flattenpath
{}{}{}{} pathforall
count -2 roll moveto
count 2 idiv {
    .99 dup scale
    count -2 roll lineto
} repeat
stroke

Of course, with this method your acceleration value (.99 here)
is intimately connected to the flatness parameter used by flattenpath
to produce line segments.

[toc] | [prev] | [next] | [standalone]

#2052

On Sat, 13 Sep 2014 01:47:05 -0700 (PDT), luser- -droog wrote:

> On Saturday, September 13, 2014 3:17:43 AM UTC-5, tlvp wrote:
>> 
>> ... I'd always been in awe of how great was the respect of the PostScript
>> designer(s) for the classic complex variables concept of "winding number" ...
> 
> Wait, what? Winding number is a concept in complex variables?? That's one of 
> the points I still haven't figured out how to implement for xpost. Oh great
> math teacher, dixi molto! :)

To save a few electrons/pixels, and to spare you my interminable hot air,
let me just point you to <http://en.wikipedia.org/wiki/Winding_number>,
which strikes me as a touches-nearly-all-bases exposition of the topic,
from <http://en.wikipedia.org/wiki/Winding_number#Intuitive_description> on
through just about all the more precise alternative formulations.

Or find your own sources, using as lure [ inurl:wiki winding number ] :-) .

Or, if that's not enough, do feel free to ask again.

> To corroborate (and abuse) this feature of postscript, here's a way to 
> draw a spiral.
> 
> 300 400 translate
> 0 0 250 0 3600 arc 
> flattenpath
> {}{}{}{} pathforall
> count -2 roll moveto
> count 2 idiv {
>     .99 dup scale
>     count -2 roll lineto
> } repeat
> stroke

Neat -- no abuse -- 3600 degrees amounts to 20{/pi} radians, or a winding
number (how many times around the "center") of 10 (= (20{/pi})/(2{/pi}) ).
 
> Of course, with this method your acceleration value (.99 here)
> is intimately connected to the flatness parameter used by flattenpath
> to produce line segments.

There should be a way to do a chain of inductive (or recursive) little
1-degree fragments of arc, each of the form, say,

0 0 250x(0.999)^n n n+10 arc

(meaning more like

0 0 250 (0.999)^n mul n dup 10 add arc ),

as integer n grows (by 10, say) from 0 through 3600. In fact, that's the
sort of recursive scheme I'd have thought you more than anyone else would
have come up with first :-) . 

Cheers, -- tlvp
-- 
Avant de repondre, jeter la poubelle, SVP.

[toc] | [prev] | [next] | [standalone]

#2053

On Sat, 13 Sep 2014 13:27:33 -0400, tlvp suggested:

> <http://en.wikipedia.org/wiki/Winding_number>,
> which strikes me as a touches-nearly-all-bases exposition of the topic,
> from <http://en.wikipedia.org/wiki/Winding_number#Intuitive_description> on
> through just about all the more precise alternative formulations.

Also impressive is PostScript's designers' having had the good sense to
distinguish /fill/ from /eofill/ by using winding number parity :-) . 

Cheers, -- tlvp
-- 
Avant de repondre, jeter la poubelle, SVP.

[toc] | [prev] | [next] | [standalone]

#2055

On Saturday, September 13, 2014 12:27:35 PM UTC-5, tlvp wrote:
> On Sat, 13 Sep 2014 01:47:05 -0700 (PDT), luser- -droog wrote:
> 
> > On Saturday, September 13, 2014 3:17:43 AM UTC-5, tlvp wrote:
> 
> >> 
> >> ... I'd always been in awe of how great was the respect of the PostScript
> >> designer(s) for the classic complex variables concept of "winding number" ...
> > 
> > Wait, what? Winding number is a concept in complex variables?? That's one of 
> > the points I still haven't figured out how to implement for xpost. Oh great
> > math teacher, dixi molto! :)
> 
> To save a few electrons/pixels, and to spare you my interminable hot air,
> let me just point you to <http://en.wikipedia.org/wiki/Winding_number>,
> which strikes me as a touches-nearly-all-bases exposition of the topic,
> from <http://en.wikipedia.org/wiki/Winding_number#Intuitive_description> on
> through just about all the more precise alternative formulations.
> 
> Or find your own sources, using as lure [ inurl:wiki winding number ] :-) .
> 
> Or, if that's not enough, do feel free to ask again.
> 
> > To corroborate (and abuse) this feature of postscript, here's a way to 
> > draw a spiral.
> > 
> > 300 400 translate
> > 0 0 250 0 3600 arc 
> > flattenpath
> > {}{}{}{} pathforall
> > count -2 roll moveto
> > count 2 idiv {
> >     .99 dup scale
> >     count -2 roll lineto
> > } repeat
> > stroke
> 
> Neat -- no abuse -- 3600 degrees amounts to 20{/pi} radians, or a winding
> number (how many times around the "center") of 10 (= (20{/pi})/(2{/pi}) ).
>  
> > Of course, with this method your acceleration value (.99 here)
> > is intimately connected to the flatness parameter used by flattenpath
> > to produce line segments.
> 
> There should be a way to do a chain of inductive (or recursive) little
> 1-degree fragments of arc, each of the form, say,
> 
> 0 0 250x(0.999)^n n n+10 arc
> 
> (meaning more like
> 
> 0 0 250 (0.999)^n mul n dup 10 add arc ),
> 
> as integer n grows (by 10, say) from 0 through 3600. In fact, that's the
> sort of recursive scheme I'd have thought you more than anyone else would
> have come up with first :-) . 
> 

Well, mostly I thought of it as "hijacking" the existing machinery. 
Knowing that arcs become curves which become lines, and how to grab
the points of those lines instead of drawing them. That's the kind of 
stuff I find exciting about postscript (and wanted to know what I started).
For the rest, I still don't view myself as "good at math". I'm competent
with the stuff I know, but I have a looming sense of how much I don't know.

Since scaling is a multiplication step, inverting your formula (.999)^(1/N) 
should give the "per-segment" scaling. And it appears to work:

% reduce N radius center-x center y
/spir { % red n r x y 
    gsave
        translate % red n r 
        0 0       % red n r 0 0 
        3 2 roll  % red n 0 0 r 
        0         % red n 0 0 r a0
        5 4 roll  % red 0 0 r a0 n
        360 mul   % red 0 0 r a0 a1
        arc       % red 
        4 dict begin
            /red exch def        %

            flattenpath          %
            {}{}{}{} pathforall  % x0 y0 x1 y1 ... xN yN
            count -2 roll moveto % x1 y1 ... xN yN

            count 2 idiv /N exch def % x1 y1 ... xN yN
            1 red sub 1 N div exp /sv exch def 

            N {
                sv dup scale
                count -2 roll lineto
            } repeat                 %

        end
        stroke
    grestore
} def 

%rdx N rad x   y
.99 10 250 300 400 spir

[toc] | [prev] | [next] | [standalone]

#2056

On Wednesday, September 17, 2014 12:53:02 AM UTC-5, luser- -droog wrote:
> 
> Since scaling is a multiplication step, inverting your formula (.999)^(1/N) 
> should give the "per-segment" scaling. And it appears to work:
> 

Teased-out one more parameter: whether to draw the outer circle or not.


% circle? reduce N radius center-x center y
/spir { % bool red n r x y 
    gsave
        translate % bool red n r 
        0 0       % bool red n r 0 0 
        3 2 roll  % bool red n 0 0 r 
        0         % bool red n 0 0 r a0
        5 4 roll  % bool red 0 0 r a0 n
        360 mul   % bool red 0 0 r a0 a1
        arc       % bool red 
        4 dict begin
            /red exch def        %
            /circ exch def 

            flattenpath          %
            {}{}{}{} pathforall  % x0 y0 x1 y1 ... xN yN
            circ not { newpath } if
            count -2 roll moveto % x1 y1 ... xN yN

            count 2 idiv /N exch def % x1 y1 ... xN yN
            1 red sub 1 N div exp /sv exch def 

            N {
                sv dup scale
                count -2 roll lineto
            } repeat                 %

        end
        stroke
    grestore
} def 

false .75 10 250 300 400 spir

[toc] | [prev] | [next] | [standalone]

#2057

On Tue, 16 Sep 2014 22:53:01 -0700 (PDT), luser- -droog wrote:

> ...
>             flattenpath          %
>             {}{}{}{} pathforall  % x0 y0 x1 y1 ... xN yN
> ...

Wow! It's invocations like the one after "flattenpath" that leave me
gasping for air ... and the comment leaves me sadly unenlightened, too. 

Care to expostulate on what's happening there, and how you dreamed it up?

Thanks. Cheers, -- tlvp
-- 
Avant de repondre, jeter la poubelle, SVP.

[toc] | [prev] | [next] | [standalone]

#2058

On Wednesday, September 17, 2014 1:37:55 PM UTC-5, tlvp wrote:
> On Tue, 16 Sep 2014 22:53:01 -0700 (PDT), luser- -droog wrote:
> 
> > ...
> >             flattenpath          %
> >             {}{}{}{} pathforall  % x0 y0 x1 y1 ... xN yN
> > ...
> 
> Wow! It's invocations like the one after "flattenpath" that leave me
> gasping for air ... and the comment leaves me sadly unenlightened, too. 
> 
> Care to expostulate on what's happening there, and how you dreamed it up?
> 

Sure. `pathforall`, like `forall`, is a looping operator. And it
loops over elements of the path. It receives 4 procedure bodies
as its arguments: the first is called for a `moveto` element 
(after pushing the x and y coordinate pair), the second for a
`lineto` element (with a coordinate pair), the third for a 
`curveto` element (with 3 coordinate pairs as arguments), and
the fourth for a `closepath` element (with no arguments).

So, this would be a more informative set of comments:

    flattenpath %     convert curves to lines
    { % x y (moveto)
        %     leave on stack
    } % {move-proc}
    { % x y (lineto)
        %     leave on stack
    } % {move-proc} {line-proc}
    { % x1 y1 x2 y2 x3 y3 (curveto)
        %     leave on stack
    } % {move-proc} {line-proc} {curve-proc}
    { % (closepath)
    } % {move} {line} {curve} {close}
    pathforall % dump path coordinates on the stack

And since we've already called `flattenpath` we know there
are no curve elements. And since we did not call `closepath`
we know there are no close elements. So after the `arc flattenpath`,
there should be just one `moveto` coordinate pair, and lots of 
`lineto` pairs, all on the stack bottom-to-top.

I've used similar "do-nothing, just leave it on the stack"
procedures with the editable bitmap program, that uses
the `image` looping operator. Although there, it was more
like "do-nothing, yield data already on stack".

https://groups.google.com/forum/#!topic/comp.lang.postscript/Rvu76u4AxQU

[toc] | [prev] | [next] | [standalone]

#2059

On Wed, 17 Sep 2014 21:33:48 -0700 (PDT), luser- -droog wrote:

> On Wednesday, September 17, 2014 1:37:55 PM UTC-5, tlvp wrote:
>> On Tue, 16 Sep 2014 22:53:01 -0700 (PDT), luser- -droog wrote:
>> 
>>> ...
>>>             flattenpath          %
>>>             {}{}{}{} pathforall  % x0 y0 x1 y1 ... xN yN
>>> ...
>> 
>> Wow! It's invocations like the one after "flattenpath" that leave me
>> gasping for air ... and the comment leaves me sadly unenlightened, too. 
>> 
>> Care to expostulate on what's happening there, and how you dreamed it up?
>> 
> 
> Sure. `pathforall`, like `forall`, is a looping operator. And it
> loops over elements of the path. It receives 4 procedure bodies
> as its arguments: the first is called for a `moveto` element 
> (after pushing the x and y coordinate pair), the second for a
> `lineto` element (with a coordinate pair), the third for a 
> `curveto` element (with 3 coordinate pairs as arguments), and
> the fourth for a `closepath` element (with no arguments).
> 
> So, this would be a more informative set of comments:
> 
>     flattenpath %     convert curves to lines
>     { % x y (moveto)
>         %     leave on stack
>     } % {move-proc}
>     { % x y (lineto)
>         %     leave on stack
>     } % {move-proc} {line-proc}
>     { % x1 y1 x2 y2 x3 y3 (curveto)
>         %     leave on stack
>     } % {move-proc} {line-proc} {curve-proc}
>     { % (closepath)
>     } % {move} {line} {curve} {close}
>     pathforall % dump path coordinates on the stack
> 
> And since we've already called `flattenpath` we know there
> are no curve elements. And since we did not call `closepath`
> we know there are no close elements. So after the `arc flattenpath`,
> there should be just one `moveto` coordinate pair, and lots of 
> `lineto` pairs, all on the stack bottom-to-top.
> 
> I've used similar "do-nothing, just leave it on the stack"
> procedures with the editable bitmap program, that uses
> the `image` looping operator. Although there, it was more
> like "do-nothing, yield data already on stack".
> 
> https://groups.google.com/forum/#!topic/comp.lang.postscript/Rvu76u4AxQU

Thanks. That sheds considerable much-needed light on things. I doubt I
could ever dream up such nifty routines, though I've noticed you seem
almost to specialize in them ... and in unfathomable recursions :-) .

Cheers, -- tlvp
-- 
Avant de repondre, jeter la poubelle, SVP.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.postscript

csiph-web