Re: [PyX-devel] Re: [PyX-checkins] pyx/test/experimental brace.py,NONE,1.1

[Andre W. <wo...@us...>]

Hi,

On 31.08.05, Joerg Lehmann wrote:
> Btw: I'd really like to get comments on this issue from other people,
> as well, especially since most PyX users would be affected if we adopt
> such a new hierarchy

Hmm!

> On 31.08.05, Michael Schindler wrote:
> > Two points + orientation sign are sufficient to orient a brace.
> > Next, the brace yields one point + orientation vector for aligning
> > something to the brace (some text, some connectors, another brace?)
> > It should also be possible to align a brace the other way round:
> > one point + orientation vector --> Two points + orientation sign
> 
> Ok, this would imply that there are different factory methods for a
> brace (in fact there already is one, namely straightbrace). But that's
> no problem.

Also a brace decorator build out of a brace factory living in paths
can additionally hide some of the complicated internal parametrization
by some simplification of the usecase. That's good news, not bad one.

> > The boxes, when I have understood André right, should orient
> > themselves relative to other boxes, too. Their orientation relative to
> > one point + orientation vector is already there.
> > 
> > The connectors, on the other hand, need more information than just
> > points. They only work if they also have some distance information
> > (for cuts at their ends), so I have chosen boxes (point + outline
> > path) to be the alignment base for the connectors.
> 
> Ok, but still they yield a path, no matter what things you use to build
> them [1]. Btw, that's why the connectors module should probably also be
> moved into a "paths" package.

I don't think so. Connectors are connecting boxes and take into
account a box center (or whatever this will become in the future) and
the box boundary. However, there might be quite some basic path
creators in the paths module, which help to construct those paths. An
great example would be the bezier curves created from the end points,
the tangents and the curvatures, which is currently hidden somewhere
in the deformer ... where it really doesn't belong to. Still it's
controversal, whether this is really something we want to have in the
paths module, since its just another parametrization to create a
bezier pathitem. OTOH all allowed pathitems are defined in the path
module and the path module should not grow to something with
complicated numerical stuff in. A solution would be a pathitems module
as well, but no ... this is would be strange too. And the bezier path
constructed out of the end points and some restrictions is a real path
... it clearly has a starting point.

> Really? It didn't seem to be like that, at least at the moment.

I think building a brace along an arbitrary path will be quite
difficult. The best you could do (and maybe that's an option), would
be to use the parallel deformer, add some small line segments and run
a smoother on top of it. Its not that good as a real curved brace, but
its actually not that bad, as we've recently learned (especially after
our smoother rework we did last weekend). So still, may be a brace
along an arbitrary path is not that unlikely to be constructable.

> And how
> do you want to decorate an arbitrary path with a brace. I don't think
> this makes sense. On the other hand, arrow heads could go into such a
> module (but not the arrows decorators).

Right. The arrow head path construction could go into a paths module.


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/