Re: Ledger lines have sharp corners
Patrick McCarty wrote Sunday, November 01, 2009 1:50 AM On Sat, Oct 31, 2009 at 6:31 PM, Dan Wilckens dwilck...@lavabit.com wrote: Examining the lilypond output pdf's at high magnification, and noticing all the trouble you've gone to in order to round the corners of the various flats and so forth, the square corners on the ledger lines seem to be an inconsistency. Wouldn't it be desirable to give them rounded corners just like every other symbol? What program are you using to view the PDF output? I don't see sharp corners at all in xpdf. See the attached image. Nor with Adobe Reader; see attached. Trevor attachment: ledger.jpg___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] lilycontrib.tcl
On Sat, Oct 31, 2009 at 08:51:24PM -0600, Carl Sorensen wrote:
I've now got a new version of lilycontrib.tcl.
Nice!
It will update the repository with or without rebasing.
What does that mean?
(I'm not asking you to explain it to me; I'd like the tool to do
this. Something like instead of having a rebase button, it says
nuke my changes! or whatever it is that rebase does)
I'm not being facetious here -- I honestly don't know, and don't
care, what rebase is. Even though people have tried to explain it
to me 3 or 4 times, as well as pointing me at fantastic
tutorials half a dozen times. People (especially me :) will
learn something if they *want* to learn it. But if *I* can be
useful to lilypond without knowing what rebase means, I
definitely don't think we should expect newbies to learn about it.
In other words, when would a user want to enable (or disable?) the
rebase thing? IIRC from the CG, we always want to use it unless
you're writing translations? If that's correct, then why not call
it Updating translations or something like that?
(or potentially we could have two different, but almost-identical
scripts? One for normal contributors, one for translators, with
the appropriate rebase stuff defined behind the scenes?)
It will run git mergetool to enable merge conflict resolution.
Clicking this gives me
Git aborted: child process exited abnormally
and in the console, it says
merge tool candidates: meld kiff3 ... blah blah...
opendiff: file not found
Again, I'm not totally clear about what reconcile merge errors
does... I mean, whenever git pull -r fails for me, I just move
my modified files away, do a git rebase --hard origin master,
then start looking at diffs.
For an introductory tool, I'm not certain we need anything more
complicated than this. These people will know even less about git
than me, after all. :)
It has an Abort changes button that will copy all of the locally changed
files to ./aborted_edits, then resets to origin/master.
Nice! I'd be tempted to call this nuke everything from orbit;
that's the only way to be certain, but that's a bit too long for
a button.
I think it's ready for release. Can any of you try testing it to see if you
think it works? I'd welcome any feedback you have.
I had to add:
git commit -a -m Update from lilycontrib
to the top of
proc patch_from_origin {} {
I'm not certain if you want it before the global vars, or before
the other config / rebase stuffs... but as far as I know, we
definitely need such a command.
If there's an easy way to prompt the user to type a commit message
from within the gui, then I'm certainly not opposed to that, but I
don't consider this a vital feature. The people receiving these
patches (me, you, Trevor, etc) can easily change the commit
messages.
NB: we *don't* need any git add or git rm. That would add too
much complexity; if a new contributor needs a new file, we can add
a stub for him or her.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB test-output file sizes: extra fonts embedded
I'm looking into why the test-output tarballs have quadrupled in size between January 2009 and now. It appears that some .eps files embed extra fonts now. For example, the 2 eps files made by input/regression/metronome-marking.ly are 8.1K in the 2.12.2 tarball, and 2129K in the 2.13.6 tarball. This is easily explained by the extra embedded font in the 2.13.6 eps files: %%DocumentSuppliedResources: font FreeSerif It's worth noting that not all files have this extra font -- some have other fonts. It seems correlated with the amount of text; one of the worst offenders is input/regression/markup-commands.ly, clocking in at 24 megs! The 2.13.6 version contains %%DocumentSuppliedResources: font CenturySchL-Bold %%DocumentSuppliedResources: font CenturySchL-Roma %%DocumentSuppliedResources: font Emmentaler-20 %%DocumentSuppliedResources: font FreeSerif %%DocumentSuppliedResources: font Sazanami-Mincho-Regular while the 2.12.2 version (only 25K!) contains: %%DocumentSuppliedResources: font CenturySchL-Bold %%DocumentSuppliedResources: font CenturySchL-Roma %%DocumentSuppliedResources: font Emmentaler-20 I haven't followed stuff about fonts, eps, ps, backends, etc. So I'm asking: 1) Is this text font embedding (if that's what it is) expected? I mean, did we add this deliberately to increase portability of eps files or something for regular lilypond files? 2) If it *is* deliberate, and a good idea in general, do we need it for the regtests? These are only used by people with a complete development environment set up, so any extra portability tweaks are probably not worth an extra 200 megs (-after- compression) 3) Do we really need a lily-123456.eps and lily-123456-1.eps ? if not, then at least I could look into trimming the extra -1.eps file. If anybody wants to look at these eps files in more detail, I could send them off-list (i.e. just those specific eps files, not the entire tarball). Note that the filenames changed between 2.12.2 and 2.13.6, but you can find the right matching by doing cd input/regresssion/out-test; grep REGTEST.ly */*.ly Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Alternative music font
On 2009-10-28, Patrick McCarty wrote: On 2009-10-28, Patrick McCarty wrote: On 2009-10-28, Neil Puttock wrote: 2009/10/20 Neil Puttock n.putt...@gmail.com: 2009/10/20 Patrick McCarty pnor...@gmail.com: This should be fixed now in latest git. Works for me. I guess I spoke a bit prematurely here, since the fix you pushed always loads aybabtu, even when font-defaults has been redefined. I've tried amending the code to allow switching to gonville-brace, but it still doesn't work properly. It seems that select_font () always selects the default font for fetaBraces (or the first entry in the node). Changing font-defaults to #(define font-defaults '((font-family . gonville) (font-encoding . fetaBraces))) only loads gonville-brace, and not gonville. So we need to override both encodings. I'm not entirely sure how to do that, but I'll look at it shortly. This isn't entirely true, now that I look at it again. In this case, gonville, gonville-brace, and aybabtu are all loaded, but aybabtu is used for the braces. Hi Neil, Can you see if the brace issue is fixed in latest git? The problem with \numericTimeSignature and the like is more complicated, but I'll try to look at it soon. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Alternative music font
2009/10/29 Patrick McCarty pnor...@gmail.com: This isn't entirely true, now that I look at it again. In this case, gonville, gonville-brace, and aybabtu are all loaded, but aybabtu is used for the braces. Thanks for fixing this, Patrick; now I can compare and contrast the ugliness of the braces at large point sizes. :) Are you sure about the extra font-defaults setting? It seems to overshadow the default for fetaMusic, resulting in failure to look up noteheads and clefs. Also, I checked \numericTimeSignature, and that's broken with gonville. Dynamics don't work either. Would this be related to the way feta-alphabet is loaded using Pango? Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Alternative music font
2009/11/1 Patrick McCarty pnor...@gmail.com: On 2009-11-01, Neil Puttock wrote: This is what I saw before reversing the settings (my latest commit), and now everything loads fine for me. Same here, but I can't see why you need to set font-defaults twice; surely the first setting is ignored? Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Alternative music font
On 2009-11-01, Neil Puttock wrote: 2009/11/1 Patrick McCarty pnor...@gmail.com: On 2009-11-01, Neil Puttock wrote: This is what I saw before reversing the settings (my latest commit), and now everything loads fine for me. Same here, but I can't see why you need to set font-defaults twice; surely the first setting is ignored? :-) You're right. The fetaBraces override was necessary when I first tried to fix the issue, but not anymore. Fixed in git. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Annotations for horizontal spacing (Issue #682)
Hi everybody,
I've posted a preliminary patch here,
http://codereview.appspot.com/143071/show
which adds support for annotating the paper variables listed in issue #682:
horizontal-shift
indent
left-margin
line-width
right-margin
paper-width
short-indent
Attached is an image produced by the following snippet, which should
give you an idea of how it looks so far:
\relative c' {
c1 \break
c1
}
\paper {
left-margin = 20\mm
right-margin = 15\mm
horizontal-shift = 10\mm
short-indent = 10\mm
annotate-x-spacing = ##t
}
While it's still in the embryonic stage, I'd appreciate any comments
you might have.
Here are my thoughts on a few aspects of the current patch:
-) I've split annotate-spacing into separate vertical and horizontal
options, mainly due to regression test requirements (I'm thinking
mainly of Michael's new margin support, where vertical annotations
would get in the way); a simple convert-ly would cover changing
annotate-spacing.
-) Since horizontal-shift is rarely used, and violates the usual
margins, I've decided to hide it unless set.
-) The annotations are currently positioned with paper-width as the
baseline, translated three-quarters of the way down a page.
Naturally, this is going to collide with systems depending on where
they're placed on a page.
-) indent and short-indent might be better off placed before systems.
-) For simplicity, the current annotation procedure
(annotate-y-interval) has been altered slightly so it can produce both
x- and y-annotations. Unfortunately, this means that the centred
labels on horizontal annotations sometimes run off the page
(particularly left- and right-margin with small or default margins).
Thanks,
Neil
attachment: annotate-x.png___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] lilycontrib.tcl
On 11/1/09 9:33 AM, Graham Percival gra...@percival-music.ca wrote:
On Sat, Oct 31, 2009 at 08:51:24PM -0600, Carl Sorensen wrote:
I've now got a new version of lilycontrib.tcl.
Nice!
It will update the repository with or without rebasing.
What does that mean?
(I'm not asking you to explain it to me; I'd like the tool to do
this. Something like instead of having a rebase button, it says
nuke my changes! or whatever it is that rebase does)
Thanks for the feedback. I'll try to get a shorter description of it.
I think that I'll just create two different buttons, rather than a
button with a checkbox.
It will run git mergetool to enable merge conflict resolution.
Clicking this gives me
Git aborted: child process exited abnormally
and in the console, it says
merge tool candidates: meld kiff3 ... blah blah...
opendiff: file not found
Again, I'm not totally clear about what reconcile merge errors
does... I mean, whenever git pull -r fails for me, I just move
my modified files away, do a git rebase --hard origin master,
then start looking at diffs.
For an introductory tool, I'm not certain we need anything more
complicated than this. These people will know even less about git
than me, after all. :)
Ahh, but if I can make git mergetool work automatically, it's magic. You
get a window containing both files side by side, and you can scroll from one
conflict to the next, and choose whether you want option A or option B with
a mouse click. It's much easier than your way of working, even for a
newbie. But obviously, it has to work right (so back to the drawing board).
It has an Abort changes button that will copy all of the locally changed
files to ./aborted_edits, then resets to origin/master.
Nice! I'd be tempted to call this nuke everything from orbit;
that's the only way to be certain, but that's a bit too long for
a button.
Thanks! It took me much longer than I expected to make that work, but I
think the final functionality is right.
I think it's ready for release. Can any of you try testing it to see if you
think it works? I'd welcome any feedback you have.
I had to add:
git commit -a -m Update from lilycontrib
to the top of
proc patch_from_origin {} {
See, my plan was to *not* have the GUI handle the commits. I was planning
to have the commit take place out of the GUI, because there's so much that
can be done with commits.
But now I think I'll have a text field for the commit message, and a Make
New Commit button, and an Amend Previous Commit button. That way, we can
take care of the two most common ways to handle commits. And we'll avoid
the commit editor.
NB: we *don't* need any git add or git rm. That would add too
much complexity; if a new contributor needs a new file, we can add
a stub for him or her.
Why not have an Add New File button with a filename text box?
I totally agree on the git rm.
It'll probably be a week before I can get the next version up due to work
commitments. But I'll get another version up as soon as I can.
Thanks again for the feedback.
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
