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 <[EMAIL PROTECTED]> 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
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel