NR3.2.2: erroneous example?
Hello all!
Since the only header fields that will be printed are piece and opus,
the example in Custom text formatting for title blocks should read
(line 802 of input.itely)
- subtitle = \markup { \italic (Excerpt) }
+ opus = \markup { \italic (Excerpt) }
Unless it is sympathetic ink?
May I change it myself, or?
Cheers,
Jean-Charles
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: NR3.2.2: erroneous example?
You should ask to James Lowe james.l...@datacore.comhttp://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=search;h=9bc65fa2efa4711ce96c648db6d703ae190f944c;s=james.l...@datacore.com;st=author It's one of his commits :9bc65fa2efa4711ce96c648db6d703ae190f944c Maybe it's to show something; there was a line title = title % not printed before this commit. Bertrand ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
FW: Custom Tuning creating space beneath the first system
Peter,
I've forwarded this to bug-lilypond, because it is a bug.
\contextStringTuning sets a context property for the FretBoards context.
This creates a FretBoards context if one doesn't exist.
I'll investigate possible fixes.
In the meantime, since you're not using FretBoards in this layout, put the
following in your file before the score:
contextStringTuning =
#(define-music-function (parser location tuning chord)
(symbol? ly:music?)
(_ Convert @{chord} to a string tuning stored in @code{tuning},
and set @code{stringTunings} of the current context to the
newly-defined tuning.
@{chord} must be in absolute pitches and should have the highest
string number (generally the lowest pitch) first. @code{tuning}
should be a string that will be converted to a symbol.)
(begin
(chord-tuning parser tuning chord)
#{
\set TabStaff.stringTunings = $(ly:parser-lookup parser tuning)
#}))
HTH,
Carl
-- Forwarded Message
From: Peter Crighton petecrigh...@googlemail.com
Date: Fri, 19 Aug 2011 06:58:05 -0600
To: LilyPond Mailing List lilypond-u...@gnu.org
Conversation: Custom Tuning creating space beneath the first system
Subject: Custom Tuning creating space beneath the first system
Hi everybody.
When I create a custom tuning via \contextStringTuning there is some
extra vertical space (only) beneath the first system. When creating it
via \set TabStaff.stringTunings everything's perfect.
Is this a bug? Can it be fixed? I'd like to use \contextStringTuning,
because it's more compact.
--
Peter Crighton | (mainly) Progressive Rock musician based in
Mainz/Wiesbaden, Germany
http://www.petercrighton.de
-- End of Forwarded Message
customTuning.ly
Description: customTuning.ly
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 982 in lilypond: web big-html and pdf look bad
Updates: Status: Fixed Labels: fixed_2_15_9 Comment #6 on issue 982 by philehol...@googlemail.com: web big-html and pdf look bad http://code.google.com/p/lilypond/issues/detail?id=982 Pushed as 0dab09bcbd2046e1dc38fb264ae8f7d2097d3d71 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1691 in lilypond: Ugly bars in PDF documents
Comment #36 on issue 1691 by philehol...@googlemail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 Request to push this change of 2.0 * %(exampleindent)s''' to 2.05 * . This will fix all the instances of black bars where the snippet is 1 line long, and [quote] is used in the snippet, as it should be. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1691 in lilypond: Ugly bars in PDF documents
Comment #37 on issue 1691 by reinhold...@gmail.com: Ugly bars in PDF
documents
http://code.google.com/p/lilypond/issues/detail?id=1691
Actually, the problem has nothing to do with the missing quote. E.g. simply
try this trivial snippet: (which has the quote and the verbatim, and still
produces overfull hboxes)
\input texinfo @c -*- coding: utf-8; mode: texinfo; -*-
@setfilename LineTest
@settitle PhilTest
@afourpaper
still problem:
@lilypond[verbatim,quote]
\repeat unfold 50 { c4 }
@end lilypond
@bye
It's actually a very general problem of lilypond-book. The reason why you
are not seeing it with @lilypond[verbatim,quote,relative=1] is that
relative=1 for some very strange reason also sets ragged-right=##t, so none
of the lines will use the full line-width (which is wider than the latex
width!) and therefore you won't see the bars. I don't think that this is
actually intended (why should relative imply ragged-right). So, you are
seeing a perfect example of two lilypond-book bugs offsetting each other:
Bug 1: lilypond-book uses a line-width that is too large
Bug 2: relative implies ragged-right, which will not use the full allowed
width in most cases.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1691 in lilypond: Ugly bars in PDF documents
Comment #38 on issue 1691 by philehol...@googlemail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 If [quote] is used, and the change I suggested is made, you no longer get overfull hboxes. In book_snippets.py we have this line: QUOTE: r'''line-width = %(line-width)s - 2.0 * %(exampleindent)s''', If you change the 2.0 to slightly more than 2.0 (and I suggested 2.05) then the output is no longer too wide. My presumption is that this is to do with rounding errors - taking exactly twice the indent from the linewidth doesn't narrow the resulting output quite enough. I understand that this doesn't fix every single problem with the docs or how lilypond-book works, but it does fix a lot of ugly output in the docs. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1691 in lilypond: Ugly bars in PDF documents
Comment #39 on issue 1691 by reinhold...@gmail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 Again, this would just be a workaround for a severe lilypond-book bug, namely that it creates images that are wider than allowed. By shrinking the line-width by an arbitrary (sufficiently large) amount, of course you will get images that fit, but that's not the real solution to the problem, rather painting over the rust and hoping that it won't surface somewhere else. Also, it won't fix the the problem when you don't use quote (which should be just a special case of a lilypond snippet, not a required snippet option!). ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1816 in lilypond: Lilypond-book music runs off right side of the page
Issue 1816: Lilypond-book music runs off right side of the page http://code.google.com/p/lilypond/issues/detail?id=1816 This issue is now blocking issue 1691. See http://code.google.com/p/lilypond/issues/detail?id=1691 -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1691 in lilypond: Ugly bars in PDF documents
Updates: Blockedon: 1816 Comment #40 on issue 1691 by percival.music.ca: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 The problem is not a rounding error. The first problem Reinhold identified is detailed in issue 1816, which has a patch. We know the problem, we know the solution, and we have the fix ready. If you would like to move forward on this, please test that patch. Otherwise we'll just wait for James to test it (to move the patch from Patch-new to Patch-review, at which point it can go through the countdown). ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1663 in lilypond: Images missing on web site
Comment #31 on issue 1663 by philehol...@googlemail.com: Images missing on web site http://code.google.com/p/lilypond/issues/detail?id=1663 Following this up, and the problem is less tractable than I thought. If you go to http://lilypond.org/doc/v2.15/Documentation/web-big-page.html you'll see that not only are all the example images missing, so are the images that are supposed to be on the menu bar at the top - so it's not obvious that you can click on the left hand edge of the bar to get back to the index, for example. The problem is that these image locations aren't specified in the source file, but rather in the style sheet. Fixing this would (AFAICS) mean making specific styles just for the web-big-page as opposed to web-normal, which would be a nightmare for maintenance. Fixing this properly would probably involve rethinking the directory structure of the web html files. If they were all in Documentation\web\filename.html rather than lots od subdirectories plus the root for big, it would make more sense. Don't know whether this is not justified investigating further, though. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1663 in lilypond: Images missing on web site
Comment #32 on issue 1663 by reinhold...@gmail.com: Images missing on web
site
http://code.google.com/p/lilypond/issues/detail?id=1663
Exactly. The problem is that the background is specified in CSS as
something like:
body{
background: url(../pictures/background-image.png) no-repeat scroll 0 0
#FF;
...
}
Now, all URLs in the CSS are relative to the CSS file, not to the main
lilypond file!
So the real problem is that web-big-page.html and web/index.html are NOT
using the same css files, but each of them is using its own copy:
http://lilypond.org/doc/v2.15/Documentation/lilypond-website.css
http://lilypond.org/doc/v2.15/Documentation/web/lilypond-website.css
The proper fix would be to handle the css just like all other included
files (i.e.images) and adjust the CSS path together with the images. In
particular that would mean that we only have one css file, and
web-big-file.html and web/index.html have different relative pathes to the
same CSS file.
That way we also get rid of css file duplications on the server.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1816 in lilypond: Lilypond-book music runs off right side of the page
Comment #7 on issue 1816 by philehol...@googlemail.com: Lilypond-book music runs off right side of the page http://code.google.com/p/lilypond/issues/detail?id=1816 I've tested this exhaustively. I've manually updated the book-snippets.py in my build tree, and run it against my test file, prior and post this update. Both outputs are attached. As you see, without the [quote] option, this does inded get rid of the black bars/overfull hbox. Not quite sure why, since these are quite wide compared to the snippets with [quote] but that's because I don't understand the working of -book, latex, etc. However, there's no effect on the lines compiled with [quote], which continue to have bars and overfull hbox warnings. However, if you make the change I'm suggesting (indeed, 2.05 only needs changing to 2.02) you get the 3rd result - with no bars at all. See the 3rd PDF. I've run the test file with multipliers of 1.95, 1.96, 1.97, 1.98, 1.99, 2.00, 2.01, 2.02 and 2.03. 1.95 to 1.98 give the same result in terms of the point size of the overfull hbox - 2.0635 to 4 decimal digits. 1.99 to 2.01 give the same result (1.05977), different from 1.96. 2.02 is zero, and hence no black bars. It seems beyond obvious that Reinhold has fixed one bug, and the [quote] bug is down to a rounding error. Please, please, please can we stop pointless arguing about angels on the head of a pin, and make a simple change that fixes a lot of horrible output in our documentation - make the multiplier of indent just bigger than 2. If this is not agreed, I'll give up and move on to other more valued work - other work than Lilypond. Attachments: LineLengthPre1819.pdf 169 KB LineLengthPre202.pdf 178 KB LineLengthPost202.pdf 178 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 620 in lilypond: It should be possible to specify more specific spanner bounds.
Updates: Labels: -Patch-needs_work fixed_2_15_9 Comment #13 on issue 620 by n.putt...@gmail.com: It should be possible to specify more specific spanner bounds. http://code.google.com/p/lilypond/issues/detail?id=620 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1691 in lilypond: Ugly bars in PDF documents
Comment #37 on issue 1691 by reinhold...@gmail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 It's actually a very general problem of lilypond-book. The reason why you are not seeing it with @lilypond[verbatim,quote,relative=1] is that relative=1 for some very strange reason also sets ragged-right=##t, so none of the lines will use the full line-width (which is wider than the latex width!) and therefore you won't see the bars. I don't think that this is actually intended (why should relative imply ragged-right). Are you sure relative=1 sets ragged-right? That would be silly. But ragged-right is set by LilyPond if there is only one system in the output. This seems quite sensible. Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3844 - Release Date: 08/19/11 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: NR3.2.2: erroneous example?
Jean-Charles, you wrote Friday, August 19, 2011 3:02 PM
Since the only header fields that will be printed are piece and
opus,
the example in Custom text formatting for title blocks should
read
(line 802 of input.itely)
- subtitle = \markup { \italic (Excerpt) }
+ opus = \markup { \italic (Excerpt) }
May I change it myself, or?
Please do.
When this section was changed quite a lot
of useful information was lost. I think
the following also needs to be reinserted
(properly formatted, of course) in Title
blocks explained:
-
If you define the \header inside the \score block,
then normally only the piece and opus headers will
be printed.
\score {
{ c'4 }
\header {
title = title % not printed
piece = piece
opus = opus
}
}
You may change this behavior (and print all the
headers when defining \header inside \score)
by using
\paper{
print-all-headers = ##t
}
-
At present print-all-headers is buried way
down in 4.1.6 under 4. Spacing issues!
Trevor
-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1392 / Virus Database: 1520/3844 - Release Date: 08/19/11
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1816 in lilypond: Lilypond-book music runs off right side of the page
Comment #8 on issue 1816 by percival.music.ca: Lilypond-book music runs off right side of the page http://code.google.com/p/lilypond/issues/detail?id=1816 I will put this patch on a countdown later tonight. I will cancel any new GOP proposals for the next two weeks. I am returning to the UK next week; flying away from Vancouver on the 24th, and arriving at 13:40 on the 25th (assuming that I catch my flight from Heathrow to Glasgow). I will probably sleep for 5-6 hours (jetlag), and be at university at approximately 00:01 on the 26th. If Reinhold (or anybody else) has not figured out what the problem is with [quote], I will absolutely give this my highest priority. Could you please wait a week? This is my last chance to see friends and family for the next few months. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1816 in lilypond: Lilypond-book music runs off right side of the page
Comment #9 on issue 1816 by percival.music.ca: Lilypond-book music runs off right side of the page http://code.google.com/p/lilypond/issues/detail?id=1816 To avoid misunderstandings: when I wrote this patch in comment 8, I was referring to Reinhold's patch which fixes the music-off-side-of-page for no [options]. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1691 in lilypond: Ugly bars in PDF documents
Comment #41 on issue 1691 by percival.music.ca: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 Trevor reminded us (by email) that lilypond automatically sets ragged-right=##t if the music is less than a full line. This might be the behavior Reinhold was seeing. If he was seeing it in a different context, then this sounds like another bug. There's no reason why relative=1 should imply ragged-right. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
