Some code for polygons

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Some code for polygons

David Feuer-2
I've written code to do rounded polygons /properly/ in both PostScript
and SVG.  The SVG was a bit tricky because SVG doesn't have
PostScript's arct.  I would greatly appreciate some help changing the
code in lookup.cc to match my new drawing procedures.  I'm still not
sure whether the polygon drawer should take a list of vertices or an
array of vertices.  A list makes more sense for the PostScript
backend, an array makes more sense for the SVG backend.  The attached
implementation takes an array.

The essential advantage of the new code over the old is that it
explicitly draws the outline of the rounded polygon rather than
fudging it by shrinking a polygon and stroking it with a certain line
thickness.  This provides several advantages over the current LilyPond
code:

1.  Full support for non-convex, and even self-intersecting, polygons.
 Currently, Lilypond can't round concave corners.
2.  Intuitive implementation.
3.  Much more flexibility.  In particular, corners can be rounded
differently depending on their geometry.  The current code and the
code I attach give strange results when corners are very sharp or
sides are very short.  I think it would probably be good to make the
rounding radius vary smoothly with the angle, using the exact
specified radius only for 90 degree corners.  I haven't experimented
with it yet, but I have a couple of ideas for how it might vary.

David Feuer

_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel

polygon-ps.scm (280 bytes) Download Attachment
polygon.ps (525 bytes) Download Attachment
polygon-svg.scm (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Some code for polygons

Jan Nieuwenhuizen
David Feuer writes:

> I've written code to do rounded polygons /properly/ in both PostScript
> and SVG.  The SVG was a bit tricky because SVG doesn't have
> PostScript's arct.  I would greatly appreciate some help changing the
> code in lookup.cc to match my new drawing procedures.

That's great.  I'll have a look as soon as possible, but as you may
have noticed, I currently have very little time to work on Lily
related stuff.  I have a daytime job, two small twin girls and just
bought a house :-)

Jan.

--
Jan Nieuwenhuizen <[hidden email]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some code for polygons

Johannes Schindelin
Hi,

On Tue, 11 Apr 2006, Jan Nieuwenhuizen wrote:

> I currently have very little time to work on Lily related stuff.

That's a pity.

>  I have a daytime job, two small twin girls and just bought a house :-)

Congratulations!

Ciao,
Dscho



_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some code for polygons

Jan Nieuwenhuizen
In reply to this post by David Feuer-2
David Feuer writes:

> I would greatly appreciate some help changing the code in lookup.cc
> to match my new drawing procedures.  I'm still not sure whether the
> polygon drawer should take a list of vertices or an array of
> vertices.

It seems that you changed the polygon interface from (prefixing type name
to parameter for clarity)

    (define (polygon list-of-points blot-diameter filled?)

to

  (define (polygon vector-of-points blot-radius)

What is the reason to change the interface?  I appreciate that radius
makes more sense than diameter, but blot-diameter is used throughout
lily.  So why not keep the scm interface as it was, ie, change your
polygon code to

  (define (polygon list-of-points blot-diameter)
    (let ((vector-of-points (list->vector))
          (blot-radius (/ blot-diameter 2)))

          ...


Btw, what about the the filled? parameter, is it never used?

Btw2, why the defines

  ...
  (define n (vector-length points))
  (define startpoint (v* 0.5 (v+ (vector-ref points (- n 1)) (vector-ref points 0))))
 
  (entity 'path ""
  ...

instead of let* ?

    (let* ((n (vector-length vector-of-points))
           (start-point (v* 0.5 (v+ (vector-ref vector-of-points (- n 1))
           (vector-ref vector-of-points 0)))))
   
Could you send a next version as a unified diff please?

Jan.

--
Jan Nieuwenhuizen <[hidden email]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some code for polygons

Jan Nieuwenhuizen
David Feuer writes:

> I didn't even think about that.  I just wrote the functions
> and gave them the interface that made the most sense to me at the
> time.  I'll change it in the next version.

Ok.

>> Btw, what about the the filled? parameter, is it never used?
>
> As far as I can tell from grepping the source, polygons are only drawn
> filled.

Ok, I'll add an assert in the c++ code and remove the parameter to match
your next polygon scheme code.

> I would suggest that the current code be put on a shelf somewhere in
> case someone needs it in the future,

Just remove it; shelve is what cvs's Attic is for ;-)

>> instead of let* ?
>
> Just a matter of style.  Internal defines are equivalent to letrec (it
> looks like they'll be equivalent to letrec* in R6RS), which is
> technically unnecessary, but I thought the code was more readable that
> way.  If you'd prefer let*, I can change to that.

Yes, please do.  Nicholas?

>> Could you send a next version as a unified diff please?
>
> Sure.

Thanks.

Please keep discussions on the list (cc'd), thanks.
Jan.

--
Jan Nieuwenhuizen <[hidden email]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some code for polygons

David Feuer-2
On 4/12/06, Jan Nieuwenhuizen <[hidden email]> wrote:

> Ok, I'll add an assert in the c++ code and remove the parameter to match
> your next polygon scheme code.

I'm not sure where you'll add it.  The code in lookup.cc always calls
the scheme function with filled?=#t

> > I would suggest that the current code be put on a shelf somewhere in
> > case someone needs it in the future,
>
> Just remove it; shelve is what cvs's Attic is for ;-)

Okay.

> > way.  If you'd prefer let*, I can change to that.
>
> Yes, please do.  Nicholas?

Okay.

> Please keep discussions on the list (cc'd), thanks.

Oops!  Didn't mean to take that off list.

David


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some code for polygons

Jan Nieuwenhuizen
David Feuer writes:

> I'm not sure where you'll add it.  The code in lookup.cc always calls
> the scheme function with filled?=#t

Indeed; no need for an assert.  But in that case ... found it

define-markup-command.scm:
(define-markup-command (triangle layout props filled) (boolean?)
  "A triangle, filled or not"

we use it to draw `white' triangles for chords...

Jan.

--
Jan Nieuwenhuizen <[hidden email]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some code for polygons

David Feuer-2
On 4/12/06, Jan Nieuwenhuizen <[hidden email]> wrote:
> Indeed; no need for an assert.  But in that case ... found it
>
> define-markup-command.scm:
> (define-markup-command (triangle layout props filled) (boolean?)
>   "A triangle, filled or not"
>
> we use it to draw `white' triangles for chords...

Yuck.  This makes a great argument for my proposal to get the
arbitrary Scheme code out of stencils (so there's only -one- place in
the source that produces output code).  The easiest way to keep this
working the same as it does now is to name my new functions
filled-polygon and retain the old (really simple) polygon drawers in
the backends.  The polygon procedure in lookup.cc can still go away.
I'm a bit curious, though, why the triangles are done that way, which
lets the blot exceed the normal bounds.  If that behavior is a bug,
then something else will need to be done.  One option might be to make
triangle-shrinking code, which would be a bit icky, but not as icky as
general polygon-shrinking code, because triangles have some pretty
nice geometric properties.  I have another couple ideas, but I'm still
working those out.

David


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some code for polygons

Juergen Reuter
Hi,

maybe I should also comment on this topic, since I originally contributed
the whole polygon stuff in order to implement clusters, and thus still
feel (very) little responsible for it. ;-)

As for the triangle, yes, I also think it _is_ abuse to use the
blot-diameter in order to control the line thickness of an unfilled
polygon.  In fact, an unfilled polygon should ideally have two separate
parameters for controlling line thickness and blot-diameter.  However,
implementing such a drawing routine for unfilled polygons appears quite
complicated to me.  At least, you could re-use the polygon shrinking
algorithm in lookup.cc in order to calculate the edges of the inner path
of the polygon outline.  However, the restrictions mentioned in lookup.cc
would unfortunately also apply.

BTW, I just noticed, that in define-markup-command.scm, markup commands
draw-cricle and beam have an explicit thickness parameter, while all other
markup commands retrieve the thickness value from the props parameter.
Maybe this could be made more consistent.

Greetings,
Juergen


On Wed, 12 Apr 2006, David Feuer wrote:

> On 4/12/06, Jan Nieuwenhuizen <[hidden email]> wrote:
>> Indeed; no need for an assert.  But in that case ... found it
>>
>> define-markup-command.scm:
>> (define-markup-command (triangle layout props filled) (boolean?)
>>   "A triangle, filled or not"
>>
>> we use it to draw `white' triangles for chords...
>
> Yuck.  This makes a great argument for my proposal to get the
> arbitrary Scheme code out of stencils (so there's only -one- place in
> the source that produces output code).  The easiest way to keep this
> working the same as it does now is to name my new functions
> filled-polygon and retain the old (really simple) polygon drawers in
> the backends.  The polygon procedure in lookup.cc can still go away.
> I'm a bit curious, though, why the triangles are done that way, which
> lets the blot exceed the normal bounds.  If that behavior is a bug,
> then something else will need to be done.  One option might be to make
> triangle-shrinking code, which would be a bit icky, but not as icky as
> general polygon-shrinking code, because triangles have some pretty
> nice geometric properties.  I have another couple ideas, but I'm still
> working those out.
>
> David
>
>
> _______________________________________________
> lilypond-devel mailing list
> [hidden email]
> http://lists.gnu.org/mailman/listinfo/lilypond-devel
>


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some code for polygons

Jan Nieuwenhuizen
In reply to this post by David Feuer-2
David Feuer writes:

> The easiest way to keep this working the same as it does now is to
> name my new functions filled-polygon and retain the old (really
> simple) polygon drawers in the backends.

Hmm.  I'd much rather just have a simple dedicated white-triangle
function, if we must.

> The polygon procedure in lookup.cc can still go away.

Ok.

> I'm a bit curious, though, why the triangles are done that way, which
> lets the blot exceed the normal bounds.  If that behavior is a bug,

Yes, I guess so.

Jan.

--
Jan Nieuwenhuizen <[hidden email]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some code for polygons

David Feuer-2
On 4/12/06, Jan Nieuwenhuizen <[hidden email]> wrote:
> David Feuer writes:
>
> > The easiest way to keep this working the same as it does now is to
> > name my new functions filled-polygon and retain the old (really
> > simple) polygon drawers in the backends.
>
> Hmm.  I'd much rather just have a simple dedicated white-triangle
> function, if we must.

Is it really necessary to adjust the line thickness of the triangles,
or can they be made into glyphs?

David


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel