Re: where X-extent of noteheads is set?
2011/7/17 Janek Warchoł : > I've searched in note-head.cc, note-column.cc, note-heads-engraver.cc > but found nothing... I believe it defaults to ly:grob::stencil-width (probably in grob.cc). Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Creates callback for stem-begin-position. (issue4752048)
LGTM There is some code that adjusts for the shape of the notehead as well (look for calls to Note_head::stem_attachment_coordinate). Can you have a look if you can work that into your code too? http://codereview.appspot.com/4752048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: changing shape of the G clef (issue4664070)
2011/7/16 Janek Warchoł : >> This is exactly the thin edge of the \override glyph >> wedge I was worried about earlier :( We already have >> too many overrides. > > I think we shouldn't delete it immediately. We sometimes leave old > syntax for some time; let's keep old clef glyph until 2.18. Then > we'll reconsider deleting it permanently. It's only a glyph. We can just delete it directly. That also helps combat the inevitable code duplication between the MF code of the old and new clef. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Checks for grobs with circular parentage in the regtests. (issue4747045)
On Sat, Jul 16, 2011 at 12:31 PM, m...@apollinemike.com wrote: > > I'm gonna pull this patch out of consideration - both you and Neil are right > about checking parents on an axis-by-axis basis. My desire to do this comes > from an incomplete understanding of what "parent" means in LilyPond speak. I > now understand that grob A can be grob B's X parent while grob B is grob A's > Y parent. In this case, the approach in my tuplet patch holds because I only > check along the Y_AXIS (as Carl suggested), which eliminates the recursive > problem. Also, code that actually creates loops would never finish compiling. We do obj->relative_coordinate(system, axis) in some place, and if there were a loop, this would never exit. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: Adds glissando stems to Lilypond. (issue4661061)
Hello, From: lilypond-devel-bounces+james.lowe=datacore@gnu.org [lilypond-devel-bounces+james.lowe=datacore@gnu.org] on behalf of mts...@gmail.com [mts...@gmail.com] Sent: 17 July 2011 19:22 To: pkx1...@gmail.com; gra...@percival-music.ca; n.putt...@gmail.com; m...@apollinemike.com; hanw...@gmail.com; bernardobarr...@gmail.com; c_soren...@byu.edu; carl.d.soren...@gmail.com; reinh...@kainhofer.com Cc: re...@codereview.appspotmail.com; lilypond-devel@gnu.org Subject: Re: Adds glissando stems to Lilypond. (issue4661061) I've paired this down to a minimal implementation that only contains: 1) Init file stuff for syntax (this could be made much better...) 2) Modifications to the glissando engraver to ID glissando stems. 3) A function that links them up to glissandi in stem.hh 4) The triggering of this function via a callback in stem-end-position in two places in the code (it'd be in one place save that the beam code doesn't completely behave nicely with stems). I think my university-based research for the next year will be on dynamical systems in typesetting: I am getting results that resemble more and more a Lorenz attractor as I try to navigate all of the internal dependencies that arise when one implements a horizontal spacing algorithm whose constituent members' widths are dependent on the results of said algorithm. --- Don't you just get an ellipse? :) James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR Added new Node for Footnotes (issue4751045)
http://codereview.appspot.com/4751045/diff/8001/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
http://codereview.appspot.com/4751045/diff/8001/Documentation/notation/input.itely#newcode1038
Documentation/notation/input.itely:1038: where the @code{\markup
@{indicator@}} is printed. One line is drawn
The @code{\markup @{indicator@}} is printed offset from the center of
the grob that is being footnoted by the value of the @code{#'(x . y)}
argument.
[I don't think we need the bit about lines and the position of the
footnote - these should be obvious from the following @lilypond.]
http://codereview.appspot.com/4751045/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Move \RemoveEmptyStaves to new file for context modifications (issue #1760) (issue4664076)
Pushed: cf2da187b5b99e963346e5944311bb77e2e52ff1 http://codereview.appspot.com/4664076/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: changing shape of the G clef (issue4664070)
http://codereview.appspot.com/4664070/diff/8001/lily/clef.cc File lily/clef.cc (right): http://codereview.appspot.com/4664070/diff/8001/lily/clef.cc#newcode51 lily/clef.cc:51: str = str + "_" + clef_style; you can't add clef_style unless you know glyph == "clefs.G" http://codereview.appspot.com/4664070/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR Added new Node for Footnotes (issue4751045)
http://codereview.appspot.com/4751045/diff/8001/Documentation/notation/input.itely File Documentation/notation/input.itely (right): http://codereview.appspot.com/4751045/diff/8001/Documentation/notation/input.itely#newcode1105 Documentation/notation/input.itely:1105: A way to make them not collide with bordering staves is to give them Y-extents (currently they are set to have no Y extent). http://codereview.appspot.com/4751045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: where X-extent of noteheads is set?
2011/7/17 Janek Warchoł : > I've searched in note-head.cc, note-column.cc, note-heads-engraver.cc > but found nothing... You don't need to know this (though if you're curious, any grob without a default is set to ly:grob::stencil-width; see the constructor in grob.cc). If you want to know the extent, just use Grob::extent (). Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR Added new Node for Footnotes (issue4751045)
http://codereview.appspot.com/4751045/diff/8001/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
http://codereview.appspot.com/4751045/diff/8001/Documentation/notation/input.itely#newcode1024
Documentation/notation/input.itely:1024: for top-level @code{\markup}s
and @code{\footnoteGrob} for individual
for for
\footnote is two separate commands; one for top-level markup (defined as
a markup command) and the other a \balloon-style music function. The
latter is the only way to add a footnote to an individual notehead in a
chord, e.g.,
\relative c' {
1
}
http://codereview.appspot.com/4751045/diff/8001/Documentation/notation/input.itely#newcode1031
Documentation/notation/input.itely:1031: \footnoteGrob #'@var{Layout
Object} #'@var{(x . y)}
remove extra space before #
http://codereview.appspot.com/4751045/diff/8001/Documentation/notation/input.itely#newcode1053
Documentation/notation/input.itely:1053: \markup { \teeny 2 } \markup {
2. \bold Forte }
remove extra space before \markup
http://codereview.appspot.com/4751045/diff/8001/Documentation/notation/input.itely#newcode1074
Documentation/notation/input.itely:1074: \markup { " " }
\markup { \null }
http://codereview.appspot.com/4751045/diff/8001/Documentation/notation/input.itely#newcode1079
Documentation/notation/input.itely:1079: The order in which LilyPond
creates each grob, determines the order that
don't mention LilyPond
remove comma
http://codereview.appspot.com/4751045/diff/8001/Documentation/notation/input.itely#newcode1094
Documentation/notation/input.itely:1094: Notation Reference:
Add Internals Reference links:
FootnoteEvent
FootnoteItem
FootnoteSpanner
Footnote_engraver
http://codereview.appspot.com/4751045/diff/8001/Documentation/notation/input.itely#newcode1102
Documentation/notation/input.itely:1102: attached to the @emph{first
instance} of a clef, time or key signature
Sure they can:
\new Staff \with {
\consists "Footnote_engraver"
}
\relative c' {
\footnoteGrob #'Clef #'(0 . 2) "1." "1. Treble clef"
\footnoteGrob #'KeySignature #'(0 . -2) "2." "2. G flat major"
\footnoteGrob #'TimeSignature #'(0 . 2) "3." "3. Common time"
\key ges \major
des1
}
http://codereview.appspot.com/4751045/diff/8001/Documentation/notation/input.itely#newcode1103
Documentation/notation/input.itely:1103: nor @code{TextScript} objects,
barlines or @code{MultiMeasureRests} and
TextScript and BarLine work fine via \footnoteGrob
http://codereview.appspot.com/4751045/diff/8001/Documentation/snippets/new/footnote-break-visibility.ly
File Documentation/snippets/new/footnote-break-visibility.ly (right):
http://codereview.appspot.com/4751045/diff/8001/Documentation/snippets/new/footnote-break-visibility.ly#newcode5
Documentation/snippets/new/footnote-break-visibility.ly:5: Footnotes
attached to grobs that have their break visibility set, will
remove comma
http://codereview.appspot.com/4751045/diff/8001/Documentation/snippets/new/footnote-break-visibility.ly#newcode6
Documentation/snippets/new/footnote-break-visibility.ly:6: be printed on
both grob resulting in duplicate footnotes but this
grobs
http://codereview.appspot.com/4751045/diff/8001/Documentation/snippets/new/footnote-break-visibility.ly#newcode29
Documentation/snippets/new/footnote-break-visibility.ly:29: \once
\override Staff.FootnoteItem #'break-visibility = ##(#f #f #t)
#'break-visibility = #end-of-line-invisible
http://codereview.appspot.com/4751045/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds glissando stems to Lilypond. (issue4661061)
I've paired this down to a minimal implementation that only contains: 1) Init file stuff for syntax (this could be made much better...) 2) Modifications to the glissando engraver to ID glissando stems. 3) A function that links them up to glissandi in stem.hh 4) The triggering of this function via a callback in stem-end-position in two places in the code (it'd be in one place save that the beam code doesn't completely behave nicely with stems). I think my university-based research for the next year will be on dynamical systems in typesetting: I am getting results that resemble more and more a Lorenz attractor as I try to navigate all of the internal dependencies that arise when one implements a horizontal spacing algorithm whose constituent members' widths are dependent on the results of said algorithm. Cheers, MS http://codereview.appspot.com/4661061/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR Added new Node for Footnotes (issue4751045)
LGTM. Maybe wait a day for Trevor to comment, then push. http://codereview.appspot.com/4751045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds redirect-lilypond-output option to lilypond-book(issue4664060)
On Sun, Jul 17, 2011 at 03:59:37PM +0100, Phil Holmes wrote: > - Original Message - From: > >During a recent sudo make install I got this error. I'm not sure > >if it has to do with recent pushes in the python code, but I > >figured I'd pass it along: > > Mike - is this only with make install? (i.e. have you tried make, > or make doc, or anything else like that? I'm not suggesting you do, > just gathering information). Also - is this with a build completely from scratch? That's the first thing to try. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git-cl is down
2011/7/17 Carl Sorensen : > On 7/16/11 5:37 PM, "Graham Percival" wrote: > >> On Sat, Jul 16, 2011 at 05:13:29PM -0600, Carl Sorensen wrote: >>> >>> IMO, we should be aiming at one commit per Rietveld issue, rather than a >>> series of commits per Rietveld issue. >> >> That's beside the point, at least as far as I understand it. >> >> - Bertrand writes some code. >> - Bertrand makes a git commit. That commit has a nice message, it >> has his name, etc. >> - Bertrand gets this patch onto Rietveld using git-cl. > > More common, patch needs some changes. So Bertrand makes some changes and > then makes a git commit. This commit reflects the changes. Then Bertrand > pushes a new patch set. > > This happens a couple of times. > > Now Bertrand's repository doesn't have one commit on this branch, he has > three or four commits on his branch. And the first two or three are not > right -- they haven't passed code review. > > The final patch set passes code review. > > Graham wants to push this patch set. But he can't, unless he writes his own > commit message and sets the author. > > But if Bertrand has been uploading as he did with his test issue, there are > *3* patches, not *1*. And the first 2 are not accepted, so we don't want > them in our source tree. They might even break compiling; if so, they'd > mess up git bisect. > > Since we're only ready for committing after getting approval, we need to > combine into a single commit after approval. Either you can do it (creating > your own metadata, as you said) or he can do it (using git rebase -i). But > somebody needs to make the change to the commits in order get them ready for > pushing. Just for the record: i often make typos or style mistakes (in addition to regular fixes needed), so i often have more than 5 commits for a single issue, many of them with the message "blalah", "fix" or something like that. I usually do rebase -i when i feel the patch is finished and there are no unsolved comments; it's usually during countdown. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds redirect-lilypond-output option to lilypond-book(issue4664060)
On Jul 17, 2011, at 4:59 PM, Phil Holmes wrote: > - Original Message - From: > To: ; ; > ; > Sent: Sunday, July 17, 2011 3:43 PM > Subject: Re: Adds redirect-lilypond-output option to > lilypond-book(issue4664060) > > >> Hey all, >> >> During a recent sudo make install I got this error. I'm not sure if it has >> to do with recent pushes in the python code, but I figured I'd pass it along: > > [snip] > > Mike - is this only with make install? (i.e. have you tried make, or make > doc, or anything else like that? I'm not suggesting you do, just gathering > information). This is only with make install and only after the version change - I think it may have something to do with where lilypond-book gets installed on my machine. I'll do my best to track it down on my machine in a couple days. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds redirect-lilypond-output option to lilypond-book(issue4664060)
- Original Message - From: "Phil Holmes" To: ; ; ; ; Sent: Sunday, July 17, 2011 3:59 PM Subject: Re: Adds redirect-lilypond-output option to lilypond-book(issue4664060) - Original Message - From: To: ; ; ; Sent: Sunday, July 17, 2011 3:43 PM Subject: Re: Adds redirect-lilypond-output option to lilypond-book(issue4664060) Hey all, During a recent sudo make install I got this error. I'm not sure if it has to do with recent pushes in the python code, but I figured I'd pass it along: [snip] Mike - is this only with make install? (i.e. have you tried make, or make doc, or anything else like that? I'm not suggesting you do, just gathering information). -- Phil Holmes Mike - I'm thinking that lilylib.py and lilypond-book might have got out of step in your build directory. Does build/python/out/lilylib.py contain the lines: def subprocess_system (cmd, ignore_error=False, progress_p=True, be_verbose=False, redirect_output=False, log_file=None): ? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
where X-extent of noteheads is set?
I've searched in note-head.cc, note-column.cc, note-heads-engraver.cc but found nothing... If i knew this i could probably fix http://code.google.com/p/lilypond/issues/detail?id=1546 Thanks in advance, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds redirect-lilypond-output option to lilypond-book(issue4664060)
- Original Message - From: To: ; ; ; Sent: Sunday, July 17, 2011 3:43 PM Subject: Re: Adds redirect-lilypond-output option to lilypond-book(issue4664060) Hey all, During a recent sudo make install I got this error. I'm not sure if it has to do with recent pushes in the python code, but I figured I'd pass it along: [snip] Mike - is this only with make install? (i.e. have you tried make, or make doc, or anything else like that? I'm not suggesting you do, just gathering information). -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds redirect-lilypond-output option to lilypond-book (issue4664060)
Hey all,
During a recent sudo make install I got this error. I'm not sure if it has to
do with recent pushes in the python code, but I figured I'd pass it along:
Compiling
/Users/mikesolomon/devel/lilypond/Documentation/out/notation/notation.texi...
/Users/mikesolomon/devel/lilypond/Documentation/out/notation/notation.texi is
up to date.
Processing include: notation/pitches.itely
Reading notation/pitches.itely...
Dissecting...
Writing snippets...
Processing...
Traceback (most recent call last):
File "../scripts/lilypond-book.py", line 693, in
main ()
File "../scripts/lilypond-book.py", line 675, in main
chunks = do_file (files[0])
File "../scripts/lilypond-book.py", line 585, in do_file
chunks))
File "../scripts/lilypond-book.py", line 581, in process_include
return do_file (name, included=True)
File "../scripts/lilypond-book.py", line 585, in do_file
chunks))
File "../scripts/lilypond-book.py", line 581, in process_include
return do_file (name, included=True)
File "../scripts/lilypond-book.py", line 569, in do_file
do_process_cmd (chunks, input_fullname, global_options)
File "../scripts/lilypond-book.py", line 437, in do_process_cmd
options.formatter, options.lily_output_dir)
File "../scripts/lilypond-book.py", line 390, in process_snippets
logfile)
File "../scripts/lilypond-book.py", line 367, in system_in_directory
progress_p=1)
TypeError: subprocess_system() got an unexpected keyword argument
'redirect_output'
make[1]: *** [out/notation.texi] Error 1
make: *** [install] Error 2
Cheers,
MS
On Jul 3, 2011, at 2:02 PM, philehol...@googlemail.com wrote:
> Reviewers: Graham Percival,
>
> Message:
> Please review the patch set to add the redirect option.
>
> Description:
> Adds a new option to lilypond-book that causes the lilypond
> output to be directed to logfiles. The option is:
> --redirect-lilypond-output.
>
> This is a possible pre-cursor to further build work, but
> only possible.
>
> Test cases and further information at:
> http://www.holmessoft.co.uk/homepage/private/lilypond/
>
> Please review this at http://codereview.appspot.com/4664060/
>
> Affected files:
> M python/lilylib.py
> M scripts/lilypond-book.py
>
>
> Index: python/lilylib.py
> diff --git a/python/lilylib.py b/python/lilylib.py
> index
> dac53c16cf4dd5d83c2111e4ba49e28701f410b0..06bb5c361b835a78779c2bb1038c2b033cea99e2
> 100644
> --- a/python/lilylib.py
> +++ b/python/lilylib.py
> @@ -23,6 +23,7 @@ import re
> import shutil
> import sys
> import optparse
> +import time
>
>
> # Users of python modules should include this snippet
> @@ -118,6 +119,7 @@ def subprocess_system (cmd,
>ignore_error=False,
>progress_p=True,
>be_verbose=False,
> + redirect_output=False,
>log_file=None):
> import subprocess
>
> @@ -125,34 +127,52 @@ def subprocess_system (cmd,
> name = command_name (cmd)
> error_log_file = ''
>
> -if be_verbose:
> - show_progress = 1
> - progress (_ ("Invoking `%s\'") % cmd)
> +if redirect_output:
> +progress (_ ("Processing %s.ly") % log_file)
> +progress ('\n')
> else:
> - progress ( _("Running %s...") % name)
> -
> +if be_verbose:
> +show_progress = 1
> +progress (_ ("Invoking `%s\'") % cmd)
> +else:
> +progress ( _("Running %s...") % name)
>
> stdout_setting = None
> +stderr_setting = None
> if not show_progress:
> - stdout_setting = subprocess.PIPE
> +stdout_setting = subprocess.PIPE
> +
> +if redirect_output:
> +stdout_filename = ''.join([log_file, '.log'])
> +stderr_filename = ''.join([log_file, '.err.log'])
> +stdout_setting = open(stdout_filename, 'w')
> +stderr_setting = open(stderr_filename, 'w')
>
> proc = subprocess.Popen (cmd,
> shell=True,
> universal_newlines=True,
> stdout=stdout_setting,
> - stderr=stdout_setting)
> + stderr=stderr_setting)
>
> log = ''
>
> -if show_progress:
> - retval = proc.wait()
> +if redirect_output:
> +while proc.poll()==None:
> +time.sleep(1)
> +retval = proc.returncode
> +stdout_setting.close()
> +stderr_setting.close()
> else:
> - log = proc.communicate ()
> - retval = proc.returncode
> -
> +if show_progress:
> +retval = proc.wait()
> +else:
> +log = proc.communicate ()
> +retval = proc.returncode
>
> if retval:
> print >>sys.stderr, 'command failed:', cmd
> +if redirect_output:
> +print >>sys.stderr, "Look in logfile", stderr_filename
> if retval
Re: print transposed guitar chords on piano sheets (issue4626094)
On 2011/07/17 10:35:20, Janek Warchol wrote: Hi all, as acting Frog Meister i'm worried that nothing happens here :( Wol, how can i help you? Neil, Carl: do i understand correctly that Wol could've done this using a more elegant solution, but nevertheless his patch doesn't brake anything and works correctly (i don't remember any problems when i tried it)? Can i label it patch-review? I think it should be patch-needs-work. The proper way to do the capo-chord has been proposed (in Anthony's words -- a "shim"). A sample patch (by Neil) has been referenced. Anthony's patch should be revised to be consistent with Neil's proof-of-concept patch. Thanks, Carl http://codereview.appspot.com/4626094/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: print transposed guitar chords on piano sheets (issue4626094)
Hi all, as acting Frog Meister i'm worried that nothing happens here :( Wol, how can i help you? Neil, Carl: do i understand correctly that Wol could've done this using a more elegant solution, but nevertheless his patch doesn't brake anything and works correctly (i don't remember any problems when i tried it)? Can i label it patch-review? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: change in treble clef - do you accept?
2011/7/17 Reinhold Kainhofer : > On So., 17. Jul. 2011 09:41:02 CEST, Jan Warchoł > wrote: > >> 2011/7/17 David Kastrup : >> > Reinhold Kainhofer writes: >> > > There is no particular reason I used a scaled regular clef, IIRC. We >> > > might just as well use a scaled change clef... Feel free to change >> > > that. >> > >> > What clef then to use for clef changes in a cue voice? >> >> I didn't know that it's possible to have clef changes in cue voice... >> But if it is, it might indeed be more clean to leave it as it is (i.e. >> use scaled regular clef for cue notes). > > I have never tried it, but I don't think clef changes in cue notes work > properly. I think they will mess up the original clef of the staff... Still, we might want to support it someday, so better leave this as is, i.e. use scaled down regular clef as the CueClef. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
font: change breve vertical lines (issue4748044)
Reviewers: ,
Message:
Hi,
breve glyphs in Feta font need modification.
What is bad now: breves lying between the stafflines form a
hard-to-recognize clump, partly because the corners (marked in orange
here:
http://lilypond.googlecode.com/issues/attachment?aid=1767000&name=breve+dimensions.png&token=be66e1b143abc7ec3429340cd32103e3&inline=1)
are too small. Smaller font sizes and ledger lines intensify this.
Breves lying on stafflines are also not good - too stumpy.
Try printing this for example:
http://lilypond.googlecode.com/issues/attachment?aid=1767002&name=Miserere+current+Lily.pdf&token=63749404ea6a8c2d3447fb4080494627
Here is my homework :)
http://lilypond.googlecode.com/issues/attachment?aid=1767001&name=breve+examples.png&token=3c9237933bb9a936015f36fed35e1936&inline=1
As we can see:
- there is some variation
- majority of breves have lines higher than notehead
- if line height is similar to notehead height, fudge value is negative
or at least 0
Therefore i suggest to:
- make vertical lines higher
- decrease the fudge, especially in small font designs
- increase the gap for smaller design sizes
- decrease the line width in double-lined breves (the glyph looks less
fat then)
Tracker issue: http://code.google.com/p/lilypond/issues/detail?id=1767
I attached a bunch of test files showing differencies to the tracker
issue. If possible, try printing them instead of watching on-screen,
because this issue is quite specific to printed material.
How do you like it?
PS i'll have to cut down on issue descriptions and example researchig...
It takes much more time than writing a patch itself :(
Description:
font: change breve vertical lines
Put breve vertical lines farther apart
and make them longer to increase readability.
Please review this at http://codereview.appspot.com/4748044/
Affected files:
M mf/feta-noteheads.mf
Index: mf/feta-noteheads.mf
diff --git a/mf/feta-noteheads.mf b/mf/feta-noteheads.mf
index
c72522072195d2b9751158e12cd0014a333294c2..e574cc1cf52ff16e456031f634e40b4fab1d7cbd
100644
--- a/mf/feta-noteheads.mf
+++ b/mf/feta-noteheads.mf
@@ -157,24 +157,36 @@ if test > 0:
fi;
-%
-% dimensions aren't entirely right.
-%
-def draw_brevis (expr linecount) =
+def draw_brevis (expr linecount, line_thickness_multiplier) =
save stemthick, fudge;
- stemthick# = 2 stafflinethickness#;
+ stemthick# = line_thickness_multiplier * 2 * stafflinethickness#;
define_whole_blacker_pixels (stemthick);
- fudge = hround (blot_diameter / 2);
+ % Breves of smaller design sizes should have their lines
+ % farther apart (the overlap should be smaller).
+ fudge = hround (blot_diameter *
+ min (max (-0.3, (0.8 - (20 / (design_size + 4)) + .1
linecount)), 0.3));
draw_outside_ellipse (1.80, 0, 0.707, 0);
undraw_inside_ellipse (1.30, 125, 0.68, 2 stafflinethickness#);
pickup pencircle scaled stemthick;
- bot y1 = -d;
- top y2 = h;
+ % Breves of smaller design sizes should have their lines longer.
+ line_length := min (max (0.7, (31/30 - (design_size / 60))), 0.82);
+
+ % Line lengths between 0.72 and 0.77 are not nice
+ % because they are neither separate nor connected
+ % when there is an interval of fourth.
+ if line_length < 0.75:
+ quanted_line_length := min (0.72, line_length);
+ else:
+ quanted_line_length := max (0.77, line_length);
+ fi;
+
+ bot y1 = -quanted_line_length * staff_space;
+ top y2 = quanted_line_length * staff_space;
rt x1 - fudge = 0;
x1 = x2;
@@ -183,17 +195,22 @@ def draw_brevis (expr linecount) =
y4 = y2;
y3 = y1;
+ % Breves of smaller design sizes should have their lines
+ % farther apart.
+ line_distance := (1.95 - 0.008 * design_size) * stemthick;
for i := 0 step 1 until linecount - 1:
- draw_gridline (z1 - (1.5 * i * stemthick, 0),
- z2 - (1.5 * i * stemthick, 0), stemthick);
- draw_gridline (z3 + (1.5 * i * stemthick, 0),
- z4 + (1.5 * i * stemthick, 0), stemthick);
+ draw_gridline (z1 - (i * line_distance, 0),
+ z2 - (i * line_distance, 0),
+ stemthick);
+ draw_gridline (z3 + (i * line_distance, 0),
+ z4 + (i * line_distance, 0),
+ stemthick);
endfor;
enddef;
fet_beginchar ("Brevis notehead", "sM1");
- draw_brevis (1);
+ draw_brevis (1, 1);
draw_staff (-2, 2, 0);
fet_endchar;
@@ -201,7 +218,7 @@ fet_endchar;
if test > 0:
fet_beginchar ("Brevis notehead", "sM1");
- draw_brevis(1);
+ draw_brevis(1, 1);
draw_staff (-2, 2, 0.5);
fet_endchar;
@@ -209,7 +226,7 @@ fi;
fet_beginchar ("Double
Re: change in treble clef - do you accept?
On So., 17. Jul. 2011 09:41:02 CEST, Jan Warchoł wrote: > 2011/7/17 David Kastrup : > > Reinhold Kainhofer writes: > > > There is no particular reason I used a scaled regular clef, IIRC. We > > > might just as well use a scaled change clef... Feel free to change > > > that. > > > > What clef then to use for clef changes in a cue voice? > > I didn't know that it's possible to have clef changes in cue voice... > But if it is, it might indeed be more clean to leave it as it is (i.e. > use scaled regular clef for cue notes). I have never tried it, but I don't think clef changes in cue notes work properly. I think they will mess up the original clef of the staff... Cheers, Reinhold ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 5: build system output (update)
- Original Message - From: "Graham Percival" >>I think there should be an option to turn it all back on if you want >>- a sort of inverse of QUIET_BUILD. We should also get rid of the >>QUIET_BUILD variable completely. > >Agreed. Maybe using the V=1 thing that Jan was talking about? That sort of thing. I'd propose a variable called VERBOSE that would have to be set to get the output on screen. I think we should use whatever variable is normally used for this task. That may well be VERBOSE, but if it's something else, I think we should use that something else. Or maybe it's normally done with either VERBOSE or V ? I'd be happy with anyone to say what is standard. LilyPond uses -V/--verbose. Make uses -d/-debug. That said, it wouldn't be a command line switch in this case - it would be a variable definition. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: change in treble clef - do you accept?
2011/7/17 David Kastrup : > Reinhold Kainhofer writes: > >> On Sa., 16. Jul. 2011 21:05:37 CEST, Janek Warchoł >> wrote: >> >>> 2011/7/16 Han-Wen Nienhuys : >>> > 2011/7/15 Janek Warchoł : >>> > > Surprisingly, CueClef currently uses regular clef glyph scaled down >>> > > 1.5874 times (font-size -4), not a scaled down change clef. >> >> There is no particular reason I used a scaled regular clef, IIRC. We >> might just as well use a scaled change clef... Feel free to change >> that. > > What clef then to use for clef changes in a cue voice? I didn't know that it's possible to have clef changes in cue voice... But if it is, it might indeed be more clean to leave it as it is (i.e. use scaled regular clef for cue notes). cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git-cl is down
On Sat, Jul 16, 2011 at 07:35:50PM -0600, Carl Sorensen wrote: > Now Bertrand's repository doesn't have one commit on this branch, he has > three or four commits on his branch. And the first two or three are not > right -- they haven't passed code review. oh, I see. I personally always just modify the original commit -- in lily-git.tcl, it's option 2b instead of 2a. So I don't think in terms of multiple commits for each rietveld issue. > Since we're only ready for committing after getting approval, we need to > combine into a single commit after approval. Either you can do it (creating > your own metadata, as you said) or he can do it (using git rebase -i). But > somebody needs to make the change to the commits in order get them ready for > pushing. If one keeps separate commits like this, then yes, somebody needs to manually make those changes. I now understand why you were foucsing on the "multiple commits" aspect of this problem. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: modifying default behaviour of tremolo slashes (issue4636081)
Finally - new patch set uploaded. Now it's possible to easily switch between different tremolo behaviours. 'Style' property is no longer used to choose between rectangular and beam-like slashes - this is now done using 'shape' property. 'Style' property now influences both 'shape' and 'slope' of the slashes: - style=constant produces beam-like slashes with slope .4 in case of downstem flagged notes and slope .25 in all other cases, - style=varying is equal to current default behaviour. It's possible to choose a combination of those by setting both 'style' and 'shape' properties. Pdf demonstrating new behaviour: http://lilypond.googlecode.com/issues/attachment?aid=17350003001&name=tremolo+new.pdf&token=4f500aee754e0419a28c61dc1a2abf6d Please review. Suggestions on value names are most welcome! http://codereview.appspot.com/4636081/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: change in treble clef - do you accept?
Reinhold Kainhofer writes: > On Sa., 16. Jul. 2011 21:05:37 CEST, Janek Warchoł > wrote: > >> 2011/7/16 Han-Wen Nienhuys : >> > 2011/7/15 Janek Warchoł : >> > > Surprisingly, CueClef currently uses regular clef glyph scaled down >> > > 1.5874 times (font-size -4), not a scaled down change clef. > > There is no particular reason I used a scaled regular clef, IIRC. We > might just as well use a scaled change clef... Feel free to change > that. What clef then to use for clef changes in a cue voice? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
