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

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

How long is a path? Alas currentdash is silent

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

Contents

  How long is a path? Alas currentdash is silent jdaw1 <jdawiseman@gmail.com> - 2016-04-05 16:34 -0700
    Re: How long is a path? Alas currentdash is silent tlvp <mPiOsUcB.EtLlLvEp@att.net> - 2016-04-05 21:45 -0400
      Re: How long is a path? Alas currentdash is silent luser- -droog <mijoryx@yahoo.com> - 2016-04-05 19:09 -0700
        Re: How long is a path? Alas currentdash is silent jdaw1 <jdawiseman@gmail.com> - 2016-04-06 01:26 -0700
          Re: How long is a path? Alas currentdash is silent jdaw1 <jdawiseman@gmail.com> - 2016-04-06 05:07 -0700
            Re: How long is a path? Alas currentdash is silent Scott Hemphill <hemphill@hemphills.net> - 2016-04-06 11:40 -0400
              Re: How long is a path? Alas currentdash is silent jdaw1 <jdawiseman@gmail.com> - 2016-04-06 09:52 -0700
                Re: How long is a path? Alas currentdash is silent sjprouty3765@gmail.com - 2016-04-06 12:05 -0700
                  Re: How long is a path? Alas currentdash is silent jdaw1 <jdawiseman@gmail.com> - 2016-04-06 14:55 -0700
                Re: How long is a path? Alas currentdash is silent Scott Hemphill <hemphill@hemphills.net> - 2016-04-06 17:12 -0400
                  Re: How long is a path? Alas currentdash is silent jdaw1 <jdawiseman@gmail.com> - 2016-04-06 14:34 -0700
          Re: How long is a path? Alas currentdash is silent Scott Hemphill <hemphill@hemphills.net> - 2016-04-06 11:35 -0400
            Re: How long is a path? Alas currentdash is silent jdaw1 <jdawiseman@gmail.com> - 2016-04-06 09:38 -0700
    Re: How long is a path? Alas currentdash is silent jdaw1 <jdawiseman@gmail.com> - 2016-04-07 01:39 -0700
    Re: How long is a path? Alas currentdash is silent Carlos <angus@quovadis.com.ar> - 2016-04-08 15:04 +0200
      Re: How long is a path? Alas currentdash is silent jdaw1 <jdawiseman@gmail.com> - 2016-04-08 14:32 -0700
        Re: How long is a path? Alas currentdash is silent Carlos <angus@quovadis.com.ar> - 2016-04-09 01:19 +0200
      Re: How long is a path? Alas currentdash is silent jdaw1 <jdawiseman@gmail.com> - 2016-04-08 14:57 -0700
        Re: How long is a path? Alas currentdash is silent Carlos <angus@quovadis.com.ar> - 2016-04-09 01:31 +0200

#2487 — How long is a path? Alas currentdash is silent

I would like to know how long is a path, in the current transformation matrix.

My plan, which has failed, was as follows. 

% ... arc ... curveto ... curveto etc closepath
[9999 dup] 0 setdash
gsave nulldevice stroke currentdash grestore exch pop
% The number on the stack, I had hoped, would be the length of the path. 
% Alas it is 0.0.

This fails, probably because, from PLRM3 p667:
> Each subpath of a path is treated independently; the dash pattern is restarted and the offset reapplied at the beginning of each subpath.

And even without the terminating closepath, currentdash returns 0.0.

The other obvious means of proceeding would be to do lots of arithmetic in three of the four code parameters passed to pathforall. What a painful slog. 

Please, has anybody a better plan?

[toc] | [next] | [standalone]

#2488

On Tue, 5 Apr 2016 16:34:24 -0700 (PDT), jdaw1 wrote:

> I would like to know how long is a path, in the current transformation matrix.
> 
> My plan, which has failed, was as follows. 
> 
> % ... arc ... curveto ... curveto etc closepath
> [9999 dup] 0 setdash
> gsave nulldevice stroke currentdash grestore exch pop
> % The number on the stack, I had hoped, would be the length of the path. 
> % Alas it is 0.0.
> 
> This fails, probably because, from PLRM3 p667:
>> Each subpath of a path is treated independently; the dash pattern is restarted and the offset reapplied at the beginning of each subpath.
> 
> And even without the terminating closepath, currentdash returns 0.0.
> 
> The other obvious means of proceeding would be to do lots of arithmetic in three of the four code parameters passed to pathforall. What a painful slog. 
> 
> Please, has anybody a better plan?

Before I'd even dream of devising a plan, I must ask: what are you actually
driving at -- what do you understand, conceptually -- by your question?

Do you expect an answer giving what a mathematician would call the
*arclength* of the path? if so, in what units? points? pixels? other?
Alternatively, do you want the total number of *component segments* (arcs,
linesto, etc.) the path is made up of (without regard to their length)?

Thanks in advance for such clarification(s). Cheers, -- tlvp
-- 
Avant de repondre, jeter la poubelle, SVP.

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

#2489

On Tuesday, April 5, 2016 at 8:45:27 PM UTC-5, tlvp wrote:
> On Tue, 5 Apr 2016 16:34:24 -0700 (PDT), jdaw1 wrote:
> 
> > I would like to know how long is a path, in the current transformation matrix.
> > 
> > My plan, which has failed, was as follows. 
> > 
> > % ... arc ... curveto ... curveto etc closepath
> > [9999 dup] 0 setdash
> > gsave nulldevice stroke currentdash grestore exch pop
> > % The number on the stack, I had hoped, would be the length of the path. 
> > % Alas it is 0.0.
> > 
> > This fails, probably because, from PLRM3 p667:
> >> Each subpath of a path is treated independently; the dash pattern is restarted and the offset reapplied at the beginning of each subpath.
> > 
> > And even without the terminating closepath, currentdash returns 0.0.
> > 
> > The other obvious means of proceeding would be to do lots of arithmetic in three of the four code parameters passed to pathforall. What a painful slog. 
> > 
> > Please, has anybody a better plan?
> 
> Before I'd even dream of devising a plan, I must ask: what are you actually
> driving at -- what do you understand, conceptually -- by your question?
> 
> Do you expect an answer giving what a mathematician would call the
> *arclength* of the path? if so, in what units? points? pixels? other?
> Alternatively, do you want the total number of *component segments* (arcs,
> linesto, etc.) the path is made up of (without regard to their length)?
> 
> Thanks in advance for such clarification(s). Cheers, -- tlvp

I'm almost certain that the reference to the Current Transformation
Matrix indicates that jdaw wants the length in User-Space points.

For that I'd do something like this:

/distance{ % x0 y0 x1 y1
    exch 4 1 roll % x1 x0 y0 y1
    sub dup mul 3 1 roll % dy^2 x1 x0
    sup dup mul % dy^2 dx^2
    add sqrt
} def

%...
    gsave
    flattenpath
    0  % length
    { } % moveto  % len x y
    {
        2 copy 6 2 roll  % len x1 y1 x0 y0 x1 y1
        distance      % len x1 y1 dist
        4 3 roll add  % x1 y1 dist+len
        3 1 roll      % len' x y
    } % lineto
    { } % curveto  % len x y
    { pop pop } % closepath  % len
    pathforall
    grestore

The value returned will depend on the value of `currentflat`.

A count of line segments could be done similarly
(but more simply).

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

#2493

Why?

A closed path is to be stroked dashed, approximately '[6 12] 0 setdash'. It would look better if the start of the path's and end of the path's dashes were in phase.

[PathLengthInPoints dup 18 div ceiling div 3 div dup 2 mul] 0 setdash

Which requires 'PathLengthInPoints'. 

Let's take a simple case: a circle. Adobe and GhostScript draw circles differently, with arc parameters 0.552 and 0.552282. So even these paths aren't quite identical. 
https://groups.google.com/forum/#!topic/comp.lang.postscript/YiuM6lj5ngY

As I hinted and luser droog has expanded, for a non-protected path it could be done with pathforall. Alas currentdash failed.

Computing the length with currentdash would have the extra advantage that it is the dash length computation that matters: I want whatever tricks are used by setdash stroke. 

% For a 90° piece and Distiller's 0.552, and assuming setflat is zero (which is impossible), Mathematica gives:
/BezierCircleRadiusMin 0.99984898859777819950 def  % 707 500 div 0.5 sqrt mul
/BezierCircleRadiusMax 1.00021212380215978618 def  % 7947863 sqrt 82 mul 231125 div
/BezierCircumference 6.28357227048930025 def  % Bigger than 2*Pi by only 0.0061587%.

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

#2494

And in case it wasn't obvious, the length of a curve has to be approximated numerically as it doesn't integrate analytically. :-(

Mathematica: 


KnotsFromCoeffs[{c0_, c1_, c2_, c3_}] = {c0, c0 + c1/3, c0 + (2 c1 + c2)/3, c0 + c1 + c2 + c3};
CoeffsFromKnots[{z0_, z1_, z2_, z3_}] = {z0, -3 z0 + 3 z1, 3 z0 - 6 z1 + 3 z2, -z0 + 3 z1 - 3 z2 + z3};

x = Table[t^i, {i, 0, 3}].CoeffsFromKnots[{x0, x1, x2, x3}];
y = Table[t^i, {i, 0, 3}].CoeffsFromKnots[{y0, y1, y2, y3}];

lengthPiece = Sqrt[Collect[D[x, t]^2 + D[y, t]^2, t]] // Simplify;
Print[lengthPiece];
length = Integrate[lengthPiece, {t, 0, 1}];
Print[length];

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

#2497

jdaw1 <jdawiseman@gmail.com> writes:

> And in case it wasn't obvious, the length of a curve has to be
> approximated numerically as it doesn't integrate analytically. :-(
>
> Mathematica: 
>
>
> KnotsFromCoeffs[{c0_, c1_, c2_, c3_}] = {c0, c0 + c1/3, c0 + (2 c1 +
> c2)/3, c0 + c1 + c2 + c3};
> CoeffsFromKnots[{z0_, z1_, z2_, z3_}] = {z0, -3 z0 + 3 z1, 3 z0 - 6 z1
> + 3 z2, -z0 + 3 z1 - 3 z2 + z3};
>
> x = Table[t^i, {i, 0, 3}].CoeffsFromKnots[{x0, x1, x2, x3}];
> y = Table[t^i, {i, 0, 3}].CoeffsFromKnots[{y0, y1, y2, y3}];
>
> lengthPiece = Sqrt[Collect[D[x, t]^2 + D[y, t]^2, t]] // Simplify;
> Print[lengthPiece];
> length = Integrate[lengthPiece, {t, 0, 1}];
> Print[length];

Did you let the integration complete?  In my case, I just integrated

  Sqrt[a + b*t + c*t^2 + d*t^3 + e*t^4]

You get an answer in terms of square roots, trig functions, elliptic
integrals, and roots of the quartic.  But the roots of the quartic are
analytical.  So I'd say that it does integrate analytically.  However, it
is so messy, I'd rather approximate it numerically.

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

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

#2499

On Wednesday, 6 April 2016 16:40:52 UTC+1, Scott Hemphill  wrote:
> Did you let the integration complete?  In my case, I just integrated
> 
>   Sqrt[a + b*t + c*t^2 + d*t^3 + e*t^4]

I did. And have just tried 
Integrate[Sqrt[a0 + a1 t + a2 t^2 + a3 t^3 + a4 t^4], {t, 0, 1}]
which also fails to integrate in Mathematica Home Edition 9.0.1.0. Not sure why. 
http://www.jdawiseman.com/2016/20160406_integration_failure.png 

And I have no PostScript means of evaluating an elliptic integral. 

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

#2500

On Wednesday, April 6, 2016 at 9:52:05 AM UTC-7, jdaw1 wrote:
> On Wednesday, 6 April 2016 16:40:52 UTC+1, Scott Hemphill  wrote:
> > Did you let the integration complete?  In my case, I just integrated
> > 
> >   Sqrt[a + b*t + c*t^2 + d*t^3 + e*t^4]
> 
> I did. And have just tried 
> Integrate[Sqrt[a0 + a1 t + a2 t^2 + a3 t^3 + a4 t^4], {t, 0, 1}]
> which also fails to integrate in Mathematica Home Edition 9.0.1.0. Not sure why. 
> http://www.jdawiseman.com/2016/20160406_integration_failure.png 
> 
> And I have no PostScript means of evaluating an elliptic integral.

currentdash does not compute any lengths.  It simply reports the dash parameters set in the current graphics state.  The offset parameter has nothing to do with computing the length of the path.  The code "[9999 dup] 0 setdash" sets the offset to 0, so that is what currentdash reports.

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

#2503

On Wednesday, 6 April 2016 20:05:28 UTC+1, sjprou...@gmail.com  wrote:
> currentdash does not compute any lengths.  It simply reports the dash parameters set in the current graphics state.

True, but it could have been otherwise. It could have been that dashes are dispensed along the path, and the dash phase updated. If it had worked thus then the dash phase would be the initial dash phase, plus the length of the path, modulo the sum of the elements of the dash array. Which would have allowed a neat way to calculate the length of the path.

As it is, even though the code must be able to calculate the length (to dispense dashes along that length), the PostScript isn't told. Alas.

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

#2501

jdaw1 <jdawiseman@gmail.com> writes:

> On Wednesday, 6 April 2016 16:40:52 UTC+1, Scott Hemphill  wrote:
>> Did you let the integration complete?  In my case, I just integrated
>> 
>>   Sqrt[a + b*t + c*t^2 + d*t^3 + e*t^4]
>
> I did. And have just tried 
> Integrate[Sqrt[a0 + a1 t + a2 t^2 + a3 t^3 + a4 t^4], {t, 0, 1}]
> which also fails to integrate in Mathematica Home Edition 9.0.1.0. Not
> sure why.
> http://www.jdawiseman.com/2016/20160406_integration_failure.png 
>
> And I have no PostScript means of evaluating an elliptic integral. 

Hmmm.  I have version 7.0 for Linux x86 (64-bit).

You'd need EllipticF and EllipticPi.  The indefinite integral produced
nearly 1800 lines of output.  The roots of the quartic were also pretty
long.

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

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

#2502

On Wednesday, 6 April 2016 22:12:22 UTC+1, Scott Hemphill  wrote:
> You'd need EllipticF and EllipticPi.  The indefinite integral produced
> nearly 1800 lines of output.

Me too -- the indefinite integral produced lots of useless output. The definite integral didn't. Strange.

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

#2496

jdaw1 <jdawiseman@gmail.com> writes:

> Why?
>
> A closed path is to be stroked dashed, approximately '[6 12] 0
> setdash'. It would look better if the start of the path's and end of
> the path's dashes were in phase.
>
> [PathLengthInPoints dup 18 div ceiling div 3 div dup 2 mul] 0 setdash
>
> Which requires 'PathLengthInPoints'. 
>
> Let's take a simple case: a circle. Adobe and GhostScript draw circles
> differently, with arc parameters 0.552 and 0.552282. So even these
> paths aren't quite identical.
> https://groups.google.com/forum/#!topic/comp.lang.postscript/YiuM6lj5ngY

[snip]

Does Adobe document the "0.552" anywhere?  It is interesting that
Distiller uses this (from your post) but that a presumably Adobe
implementation of PostScript in my printer uses something more akin to
GhostScript's value.

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

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

#2498

> Does Adobe document the "0.552" anywhere?

Not that I have seen. Revealed by pathforall in Distiller 8 and XI. 

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

#2504

Maybe my original question is flawed. 

The length of the path depends on how the curves are converted to straight lines. That is influenced but not entirely controlled by setflat. So Distiller might not know how long the path is. Distiller might merely convert to PDF, and it is the PDF's RIP that must compute the length to set out the dashes.

The Distiller could be pushed into doing the dashing itself with strokepath. But '... setdash strokepath fill' (set out by Distiller) might not paint identically to '... setdash stroke' (set out by the PDF engine).

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

#2506

On 06/04/2016 1:34, jdaw1 wrote:
> I would like to know how long is a path, in the current transformation matrix.
>
> My plan, which has failed, was as follows.
>
> % ... arc ... curveto ... curveto etc closepath
> [9999 dup] 0 setdash
> gsave nulldevice stroke currentdash grestore exch pop
> % The number on the stack, I had hoped, would be the length of the path.
> % Alas it is 0.0.
>
> This fails, probably because, from PLRM3 p667:
>> Each subpath of a path is treated independently; the dash pattern
>> is
restarted and the offset reapplied at the beginning of each subpath.
>
> And even without the terminating closepath, currentdash returns 0.0.
>
> The other obvious means of proceeding would be to do lots of
arithmetic in three of the four code parameters passed to pathforall.
What a painful slog.
>
> Please, has anybody a better plan? >

Here is a method:

Assume the path length is less than 2048.
Trace the path with a dash setting of 1024 white, 1024 black. If the 
last point of the path is black, you know the path length is at least 1024.
Trace the last part of the path (starting at 1024) with a dash setting 
of 512 white, 512 black. If the last point of the path is black, then 
the length is at least 1024+512. In that case, apply a dash of 215w/256b 
to the path starting at 1024+512.
Otherwise, the path is between 1024 and 1024+512. Apply the dash 
256w/256b starting at 1024.
Continue this way, halving the dash length every time, adding their 
lengths when necessary.

Looks like a sound algorithm. The length it returns will be a little 
short, because we'll stop halving and adding at some point, but just by 
a tiny fraction of a point.

Here is the code:

   /pathlength {
       0.0  % length so far
       20 -1 -10 { %for
           2 exch exp      % dash length = 2^i
           2 copy add      % length so far + dash length
           exch
           gsave
           2 setlinecap
           % [ 0 lengthsofar+dashlength dashlength ]
           1 index exch  [ 0  4 2 roll ]
             0.0 setdash
           currentpoint instroke {
               exch   % lengthsofar <- lengthsofar+dashlength
           } if
           pop
           grestore
       } for
   } bind def

Unfortunately it doesn't work very well, especially when curves are 
involved.

First of all, instroke has a weird behavior when applied at the end of 
curves. And, no matter what dash settings you use, even if nothing at 
all is drawn, this:

    300 300 moveto  290 300 10 0 360 arc
    [0 99999 99999] 0 setdash  % with this dash setting, the circle
                               % is completely white
    currentpoint instroke

always returns true (!). At least in Ghostscript.

Then, it apparently depends on the device. For this code:

   100 650 moveto 190 650 lineto   % 90
   200 650 10 180 0 arcn           % pi*10 = 31.4159
   300 650 lineto                  % 90
   pathlength                      % should be: 211.4159

Ghostscript/screen gives 210.749, Ghostscript/PDF gives 211.406, and 
GSView gives 211.368.

All this makes me think that dashes aren't painted so exactly that you 
can lay them out perfectly by knowing the path length. There is always 
some imprecision, especially when curves and lines meet.

Maybe (if your path doesn't end in a curve) you can try a similar 
technique, and using instroke try to approximate the dash settings where 
a small increase makes the last path point change from white to black.

-- 

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

#2507

I have never used 'instroke'. Cool.

Would this work if the path was self-intersecting? And a path ending in 'closepath' is, in effect, self-intersecting.

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

#2509

[jdaw1 <jdawiseman@gmail.com>, 2016-04-08 14:32]
> I have never used 'instroke'. Cool.
> 
> Would this work if the path was self-intersecting? And a path ending
> in 'closepath' is, in effect, self-intersecting.

You are right. It works for /pathlength, because we only have one big
black dash, and we are only interested on whether it started or not. It
doesn't matter which part of it touches the last point. What I
suggested in the last paragraph will probably fail with intersecting
paths.

By the way, I read about instroke and it is in fact device dependant,
so the imprecisions it shows are probably inside a device's pixel and
won't affect how the output looks. Maybe /pathlength is good enough for
your purposes after all.

BUT there was a bug in the code, and that was the reason why it didn't
work with a full circle, and why it doesn't work with closepath (I
didn't even notice that before).

I was setting the dash thus: [ 0 x x ] 0, and that 0-length black dash
at the beginning of the path was making instroke return true for the
first (= the last) point of the path.

Changing the dash settings to [ 1 x x ] 1 solves it.

Corrected code:

  /pathlength {
      0.0  % length so far
      20 -1 -10 { %for
          2 exch exp      % dash length = 2^i
          2 copy add      % length so far + dash length
          exch
          gsave
          2 setlinecap
          % [ 1 lengthsofar+dashlength dashlength ] 1
          1 index exch  [ 1  4 2 roll ]
            1 setdash
          currentpoint instroke {
              exch   % lengthsofar <- lengthsofar+dashlength
          } if
          pop
          grestore
      } for
  } bind def

-- 

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

#2508

> Ghostscript/screen gives 210.749, Ghostscript/PDF gives 211.406, and 
> GSView gives 211.368.

Do smaller values of setflat shrink the differences?


> 2 setlinecap 

Why? Surely something like '0 setlinecap 0.06 setlinewidth' (because I don't quite trust '0 setlinewidth').

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

#2510

[jdaw1 <jdawiseman@gmail.com>, 2016-04-08 14:57]
> > Ghostscript/screen gives 210.749, Ghostscript/PDF gives 211.406,
> > and GSView gives 211.368.  
> 
> Do smaller values of setflat shrink the differences?

I think it's related to instroke being device dependant, as I say in
the other message.
> 
> 
> > 2 setlinecap   
> 
> Why? Surely something like '0 setlinecap 0.06 setlinewidth' (because
> I don't quite trust '0 setlinewidth').

Well, I figured with 0 setlinecap the last point would be on the edge,
and there would be a 50/50 possibility of it being painted. I can catch
it with 2 setlinecap.

The path has only a first part which is invisible, and maybe a black
second part. If it has a black second part, it doesn't matter which
part of it touches the last point, we are just interested in that it
is there (so we can add the length of the invisible first part). So, it
isn't necessary to reduce the line width. In fact, enlarging it could
be more helpful.

-- 

[toc] | [prev] | [standalone]

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

csiph-web