Thanks for doing this. I think this looks quite good.
As I mention below, I think it might be best to eliminate the "style" arguments and make them part of the properties. We already have 'thickness as a property, and we could add 'path-details. Or we could make 'path-thickness part of 'path-details, and the all the things needed to control the path would be part of 'path-details. Thanks, Carl http://codereview.appspot.com/1730044/diff/1/2 File scm/define-markup-commands.scm (right): http://codereview.appspot.com/1730044/diff/1/2#newcode622 scm/define-markup-commands.scm:622: (number? number? number? boolean? string?) Can (and/or should) cap, join, and fill become part of a path-details property? It's convenient when creating a new markup type to put all the arguments needed into an argument list. But it's more consistent with LilyPond syntax to have all the things that affect appearance be properties that can have default values set (and documented) in the code. http://codereview.appspot.com/1730044/diff/1/2#newcode668 scm/define-markup-commands.scm:668: \" I think this inline snippet is fine. What characteristics of the snippet need to be "better" in your opinion? http://codereview.appspot.com/1730044/diff/1/2#newcode684 scm/define-markup-commands.scm:684: (cons 0 0))) Is it possible to have the path command estimate reasonable extents, rather than using (0 . 0) and (0 . 0)? Since we know the thickness of the line, and we have a list of points, it seems we should be able to keep track of the maximum and minimum X and Y coordinates during the path creation. http://codereview.appspot.com/1730044/show _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
