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


Groups > comp.lang.postscript > #2116

Re: designing a data structure in C for PS paths.

From Carlos <angus@quovadis.com.ar>
Newsgroups comp.lang.postscript
Subject Re: designing a data structure in C for PS paths.
Date 2014-12-11 00:18 +0100
Organization A noiseless patient Spider
Message-ID <20141211001823.5fba2978@samara.DOMA> (permalink)
References (3 earlier) <42723e42-1270-414f-8204-ecfb17e18779@googlegroups.com> <m66uju$l44$1@dont-email.me> <9310cf17-3374-4706-8697-1245da90f41e@googlegroups.com> <5f156ba0-9db6-4927-bb7f-85aa80db4ad9@googlegroups.com> <450fe966-abb1-4604-a0b3-53241ac4de46@googlegroups.com>

Show all headers | View raw


[luser- -droog <mijoryx@yahoo.com>, 2014-12-09 10:49]
> On Tuesday, December 9, 2014 12:40:16 PM UTC-6, luser- -droog wrote:
> > On Tuesday, December 9, 2014 12:08:56 PM UTC-6, luser- -droog wrote:
> > > On Tuesday, December 9, 2014 7:49:05 AM UTC-6, Carlos wrote:
> > > > On 09/12/2014 8:32, luser- -droog wrote:
> > > > >
> > > > > Sure. I think I was using confusing terminology. I was using
> > > > > the same word 'path' to refer to a subpath (a sequence of
> > > > > `lineto` and `curveto` beginning with `moveto`, possibly
> > > > > ending with `closepath`), the currentpath (which can contain
> > > > > many subpaths), and the graphics-state stack.
> > > > >
> > > > > If I were to make the 'path' out of stacks then that would
> > > > > separate it from the rest of the graphics state, and I would
> > > > > need a top-level stack for `gsave/grestore` to operate on.
> > > > > The elements of the top-level path stack would be "normal"
> > > > > path stacks, the elements of which would be "subpath" stacks,
> > > > > the elements of which would be path operations (moveto, line,
> > > > > curveto, closepath).
> > > > >
> > > > 
> > > > OK, but if the elements of the "normal" path were the
> > > > operations themselves (just the concatenated operations of all
> > > > subpaths, without structuring), it would be conceptually the
> > > > same, right?
> > > 
> > > Yes, I suppose so. I think it would make `closepath` O(n),
> > > though, since it now has to search for the most recent
> > > `moveto`, whereas the two-level structuring makes it
> > > easier to find (and O(1)).
> > 
> > Hm. Maybe not `closepath` itself, if you're just accumulating the
> > data, but at some point during processing, all the `closepath`s
> > must be associated with `moveto`s to define the subpaths. If you
> > `stroke` the path, it must be processed several times: dashing,
> > tracing the outline, clipping, filling.

To avoid searching back on closepath, you can keep the subpath starting
point and angle in a variable, and on closepath "lineto" it (the stored
angle is to draw the join). On each path appending operation set the
variable if it's empty, and clear it after each closepath or moveto;
that should be enough for it to always hold the current subpath's
starting point.

> 
> On third thought, goddamit you're right!
> 
> My implementations of all these other processing steps don't make use
> of the structuring at all! They use knowledge of the element
> dictionaries, but they iterate through the current path using
> `pathforall` or xpost's non-standard `devpathforall` which skips the
> `transform/itransform` sandwich.
> 
> They can indeed be flat. Nice catch, dude.

I take no credit for that; it was just you using the old "Rubber Duck"
technique :)  (See http://c2.com/cgi/wiki?RubberDucking)

I guess structuring the path in subpaths could make sense if you
precalculate some values (bounding box, whether it's closed...) and
want to associate them with the subpath, or if your internal
representation requires it. But it's not necessary to do so---that's
what I wanted to make sure and you did.

-- 

Back to comp.lang.postscript | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

designing a data structure in C for PS paths. luser- -droog <mijoryx@yahoo.com> - 2013-12-26 11:27 -0800
  Re: designing a data structure in C for PS paths. luser- -droog <mijoryx@yahoo.com> - 2013-12-26 11:38 -0800
  Re: designing a data structure in C for PS paths. luser- -droog <mijoryx@yahoo.com> - 2014-12-07 22:09 -0800
    Re: designing a data structure in C for PS paths. Carlos <angus@quovadis.com.ar> - 2014-12-08 15:53 +0100
      Re: designing a data structure in C for PS paths. luser- -droog <mijoryx@yahoo.com> - 2014-12-08 23:32 -0800
        Re: designing a data structure in C for PS paths. Carlos <angus@quovadis.com.ar> - 2014-12-09 14:49 +0100
          Re: designing a data structure in C for PS paths. luser- -droog <mijoryx@yahoo.com> - 2014-12-09 10:08 -0800
            Re: designing a data structure in C for PS paths. luser- -droog <mijoryx@yahoo.com> - 2014-12-09 10:40 -0800
              Re: designing a data structure in C for PS paths. luser- -droog <mijoryx@yahoo.com> - 2014-12-09 10:49 -0800
                Re: designing a data structure in C for PS paths. Carlos <angus@quovadis.com.ar> - 2014-12-11 00:18 +0100

csiph-web