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 <address@hidden> 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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/lilypond-devel