Re: Issue 1691 in lilypond: Ugly bars in PDF documents
Comment #45 on issue 1691 by pkx1...@gmail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 Learning Manual has been taken care of with regard to this. Thanks to Phil. James ___ 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: Labels: -Priority-Medium Comment #44 on issue 1691 by pkx1...@gmail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 (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 #43 on issue 1691 by philehol...@googlemail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 I would expect the changes you made to -book will have fixed almost all of these, although I've not checked. As you say, there are a few left-over, which I hope to look at in the not-too-distant future. ___ 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 #42 on issue 1691 by reinhold...@gmail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 Is this still an issue or was the problem fixed with my fix to issues 1816 and 1836? Looking at today's LM and NR, I don't see any bars in the LM and only very few in the NR. In particular: -) Several lilypond code lines are too long -) Some eyecatcher examples at the begin of a section are too wide -) One example for accidental styles ('teaching' style) is too wide, but that is inside a list, so the width is really hard to determine... -) The table-of-contents examples are too large, and the example in 3.2.3 -) The chord name charts in appendix A.1. Problem is the "instrumentName" before the ChordNames context -) fretboards in appendix A.4 ___ 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
Am Friday, 19. August 2011, 23:06:36 schrieb Trevor Daniels: > 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. Yes, relative=1 implies fragment, which on the other hand implies ragged-right (see also the docs for lilypond-book). This made sense when single-line files in lilypond didn't automatically switch to ragged-right. But now this fallback (fragmend implying ragged-right to prevent stretching for simple snippets) is no longer needed... Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ 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
On Sat, Aug 20, 2011 at 01:18:23PM +0200, Reinhold Kainhofer wrote: > While this behavior is indirectly explained in the AU, it > does not really make sense from a user's standpoint that relative should > automatically imply ragged-right (having "fragment" imply ragged-right makes > sense to make it easier for documentation writers) [fragment] is either discouraged or forbidden in the docs. With the docs doing auto-ragged-right for short ones, and in any case it's easy enough to add [ragged-right] if you really want. We should remove that behavior. [fragment] should simply add the {...} container; nothing more, nothing less. > To be honest, the whole snippet option handling seems to be a real mess right > now. I'll probably take a look at the whole snippet options handling system > in > lilypond-book during the next few days. Probably we can properly analyze each > option's effects and make them more predictable (and correct). That would be great! Cheers, - Graham ___ 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
Am Saturday, 20. August 2011, 06:25:26 schrieben Sie: > 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. No, it was not the implicit ragged setting for one-line snippets. Rather, the snippets' ly files have an exmplicit ragged-right=##t inserted. The issue is that the relative snippet option implies the fragment option, which seems to set the ragged-right=##t in all its snippets... Attached is a simple example to show this, using three snippets with identical contents, but different snippet options. The first snippet will not have ragged-right, but the other two will get an explicit ragged-right=##t in the snippet's .ly file. While this behavior is indirectly explained in the AU, it does not really make sense from a user's standpoint that relative should automatically imply ragged-right (having "fragment" imply ragged-right makes sense to make it easier for documentation writers) This deserves a bug report on its own. To be honest, the whole snippet option handling seems to be a real mess right now. I'll probably take a look at the whole snippet options handling system in lilypond-book during the next few days. Probably we can properly analyze each option's effects and make them more predictable (and correct). Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org \input texinfo @c -*- coding: utf-8; mode: texinfo; -*- @setfilename LineTest @settitle PhilTest @letterpaper still problem: @lilypond[] \repeat unfold 50 { c'4 } @end lilypond @lilypond[fragment] \repeat unfold 50 { c'4 } @end lilypond @lilypond[relative=1] \repeat unfold 50 { c4 } @end lilypond @bye___ 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
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: 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 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 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 #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 #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 #35 on issue 1691 by philehol...@googlemail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 I know this very well. My example pointed it out to you. If you want to deliberately avoid the instructions in the CG, then you'll get crap output. The CG says: •Most LilyPond examples throughout the documentation can be produced with: @lilypond[verbatim,quote,relative=1] where's your [quote]? If you want to raise a separate issue called "Liylpond-book produces bad output unless quote is used" (or want me to) then let's do this. But again, I emphasise - this patch fixes many, many problems with bad doc output. Let's push this one, and move on to the other problems it doesn't fix. ___ 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 #34 on issue 1691 by percival.music.ca: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 The 2.05 is completely irrelevant -- it's not used at all in this example, which still has the overflow black bars. Without using any bar numbers or instrument names! Something is fundamentally broken in lilypond-book. Don't try to sandpaper over it. If we wanted a cosmetic solution, we could just add @finaloutput, or whatever it was that Werner suggested. \input texinfo @c -*- coding: utf-8; mode: texinfo; -*- @setfilename LineTest @settitle PhilTest @afourpaper still problem: @lilypond[] \layout { \context { \Score \remove "Bar_number_engraver" } } \repeat unfold 50 { c'4 } @end lilypond @bye ___ 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 #33 on issue 1691 by philehol...@googlemail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 I can break the docs in a number of ways, including using incorrect syntax and by putting long unbreakable lines in. However, we tell people not to do this. The point of this fix is that it improves the docs by fixing almost all the examples where line breaks occur. There are exceptions (instrument names, ridiculous bar numbers), but we can fix them manually to start with and then tell people how to fix them if they see them in new images that they put in. This change improves the situation considerably and should be pushed. It's like a code change that adds collision avoidance code. We don't junk that because it doesn't fix all collisions; we welcome it as a welcome improvement. This is the same. ___ 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 #32 on issue 1691 by percival.music.ca: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 I can break your 2.05 "solution" with the following example. The problem is that line-width is NOT the same thing as the width of the image. Until that is addressed, you're stuck with picking random values that are big enough for "reasonable" line widths. That's do-able for bar numbers, but how large do you want to hard-code an instrument name? Always reserve 5cm in case somebody wants to write "Clarinet in B flat" all on one line? that'll look silly if somebody doesn't use any instrument name. Always reserve 2cm, and document that nobody is allowed to use longer instrument names inside lilypond-book? Tell people they need to manually set an indent=0 or 3 or 10\cm depending on their instrument name? --- \input texinfo @c -*- coding: utf-8; mode: texinfo; -*- @setfilename LineTest @settitle PhilTest @afourpaper Test Lorem ipsum dolor sit amet, consectetur adipisicing elit. @lilypond[relative=2] \repeat unfold 100 { c4 } @end lilypond Test Lorem ipsum dolor sit amet, consectetur adipisicing elit. @lilypond[relative=2] \set Score.currentBarNumber = \repeat unfold 100 { c4 } @end lilypond Test Lorem ipsum dolor sit amet, consectetur adipisicing elit. @bye ___ 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
QUOTE: r'''line-width = %(line-width)s - 2.0 * %(exampleindent)s''', It's the value of exampleindent. It seems that the rationale is that if you subtract 2* the indent from the linewidth, then you get a usable linewidth. Given how close this is to correct, I was concluding the it's essentially a rounding error, so that we should go with subtracting just more than twice the indent from the linewidth. The factor 2 in this line was introduced by Jan on 2004-03-20 in commit bdc3b32b8cdf1300d37fe9c4966e155979d2c766: + QUOTE : r''' +linewidth = %(linewidth)s - 2.0 * %(exampleindent)s +''', The commit comment says * Documentation/user/tutorial.itely: Use quote ly-option instead of explicit @quotation. This fixes too long lilypond linewidths resulting in overful hboxes. So I'm with Phil here. Either Jan didn't quite get the factor right, or something else has changed since then. Let's move to 2.05. That's the only way to see if it introduces any subtle problems. It's a long time for Jan to remember, but I'll copy him in in case he does. Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3829 - Release Date: 08/12/11 ___ 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 #31 on issue 1691 by philehol...@googlemail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 The 0.4\in comes from this: QUOTE: r'''line-width = %(line-width)s - 2.0 * %(exampleindent)s''', It's the value of exampleindent. It seems that the rationale is that if you subtract 2* the indent from the linewidth, then you get a usable linewidth. Given how close this is to correct, I was concluding the it's essentially a rounding error, so that we should go with subtracting just more than twice the indent from the linewidth. I've attached my line length test file, together with the resulting output, having reverted my update changing 2.0 to 2.05. As you see, you get black bars for 2 perfectly reasonable bits of -book syntax. I believe this is a bug in -book - it seems to me that, for music which wraps to more than one system, -book will never produce acceptable output. As you say, that's another bug. This one is about the bars in _our_ docs. We/I now know how to take them out, and in the situation where users adopt the [quote] option, how to help users. Please comment, but I am pretty convinced that the change I'm suggesting will improve our docs and -book generally. Attachments: LineLength.tely 740 bytes LineLength.pdf 168 KB ___ 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 #30 on issue 1691 by percival.music.ca: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 More generally: could you create a Tiny example (of a full .tely document, not just @lilypond[verbatim,quote] \repeat unfold 100 { c'4 } @end lilypond ) which shows the black bars? and maybe even make that a new issue? Fundamentally, this has nothing to do with the documentation. As far as I understand, you can reliably produce bad output (i.e. black bars) from a completely reasonable example. We should treat that as a programming problem, not a documentation one. On a programming note, the question is "why does lilypond produce an image of music which (apparently) cannot fit in the space provided". But that's a comment that can be attached to the new issue, not this one. ___ 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 #29 on issue 1691 by percival.music.ca: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 I'm not convinced that an ad-hoc solution is the way forward. Where does the extra .05 come from? For that matter, where does the 0.4\in come from? Is this just a problem of converting units? ___ 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 #28 on issue 1691 by philehol...@googlemail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 OK. Thanks. On my local system, I've changed the multiplier to 2.05 rather than 2.0, nuked build, rebuilt and the black lines where they used to be on line-wrapped music have mostly gone. I've also checked other output and can't see any other noticeable differences. I don't think we can claim fixed, since there are other black lines which need fixing - for example, the expressive-headword.ly has a fixed paper width of 16cm, which is too wide. There are also examples of things like LilyPond code which are too wide. However, it's a step forward. You want a patch? I see two ways forward. I could work my way through each doc and make a list of the black bars for a "proper" doc editor to correct, or I could make corrections to the best of my ability and submit (what could be quite a large) patch for each manual. Also see my note on Issue 1015. ___ 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 #27 on issue 1691 by percival.music.ca: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 Excellent! You now pretty much know all I do about the situation: - for most intents and purposes, lilypond-book has NOTHING to do with the documentation or the build system. - you have a minimal test case for which you can experiment, with both texi2html and texi2pdf (without involving the build system!) - you see that lilypond-book produces a .ly file, and you've noticed the difference between the values in that .ly file with various options. (there's probably a few more different options you can toss in there to see different \paper{} settings, but that's a minor detail compared to noticing those differences in the first place!) IIRC the 3mm comes from an attempt to "reserve" space for bar numbers, which would otherwise stick out into the left-hand margin. I re-iterate that a complete solution will need to involve the "dealing with instrument names (and bar numbers)" issue. At it currently stands, lilypond-book deals with a **staff line-width**, but material to the left of the staff line takes additional space. I think we need some programmer way of defining a **system width** (including left material like instrument name and bar numbers), and then change lilypond-book to set that value instead of line-width. The bad news it that such an addition is completely outside of your and my area of expertise. The good news is that we have a couple of programmers now who work on such things, and maybe if you ask them politely to work on it, you'll get some interest. Also, if we end up having a Type-maintainability (which seems likely), that could help attract attention to such problems. ___ 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
Phil, you wrote Thursday, August 11, 2011 5:32 PM I now understand this quite a bit better, and you were clearly quite right about my previous suggestion! I think the mechanism of reducing the line width of quoted snippets by 2 times the indent takes off _just_ too little width - if we replace 2 * exampleindent with 2.05 *, the problem is again solved for these snippets. This sounds like the right approach. I guess the only way to test it is to make the change, build all the docs and eyeball them in html and pdf :( Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3827 - Release Date: 08/11/11 ___ 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 #26 on issue 1691 by philehol...@googlemail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 OK. Further updates. I started my testing today using this: @lilypond[fragment] \repeat unfold 100 { c'4 } @end lilypond I now realise that this is generally not used for the docs, but hadn't caught on earlier. It produces a lily source file with this paper block: \paper { indent = 0\mm line-width = #(- paper-width left-margin-default right-margin-default ) ragged-right = ##t force-assignment = #"" line-width = #(- line-width (* mm 3.00)) } Note the lack of numeric varibles in the line-width. This produces a snippet of a normal size for output to PDF, but much too wide for the docs - it goes way over the right of the page. Note also the minor reduction in width - it looks to me like the bottom line takes 3mm off the line width, for some reason. It's set in the definition PREAMBLE_LY = I then looked at @lilypond[verbatim,quote] \repeat unfold 100 { c'4 } @end lilypond This gives us this paper block: \paper { indent = 0\mm line-width = 160\mm - 2.0 * 0.4\in force-assignment = #"" line-width = #(- line-width (* mm 3.00)) } which comes from the line: QUOTE: r'''line-width = %(line-width)s - 2.0 * %(exampleindent)s''', This gives black bars, but is only just too wide. which is not reset to the value above, since that's only done if the snippet is not quoted. Following the earlier work testing which line-width I tried: @lilypond[verbatim,quote,line-width=15.5\cm] \repeat unfold 100 { c'4 } @end lilypond which gives the paper block: \paper { indent = 0\mm line-width = 15.5\cm line-width = 15.5\cm - 2.0 * 0.4\in force-assignment = #"" line-width = #(- line-width (* mm 3.00)) } which gives no black bars. I now understand this quite a bit better, and you were clearly quite right about my previous suggestion! I think the mechanism of reducing the line width of quoted snippets by 2 times the indent takes off _just_ too little width - if we replace 2 * exampleindent with 2.05 *, the problem is again solved for these snippets. ___ 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 #25 on issue 1691 by percival.music.ca: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 what happens if somebody wants to make a document with usletter ? ok, it's a totally stupid size of paper, but that's the only type I can buy in Canada in regular stores. Much worse, what happens if somebody wants to make a document with that "big orchestral music" size? or an a1 poster? or an a8 business card? Hard-coding a value is not the answer. ___ 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 #24 on issue 1691 by philehol...@googlemail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 I honestly think the simplest and best answer is just to hard code the 155mm value - it's just a magic figure that we happen to know works, so trying to create it from other variables seems pointless. I'd be willing to look at what the values are, but can't do it now - make doc is still grinding. But still think we should use the figure we know works. ___ 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 #22 on issue 1691 by philehol...@googlemail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 I'll not be learning scheme just to fix this. If someone could explain it, it would be a help. I don't believe the line: override[LINE_WIDTH] = '5\\in' # = texinfo_line_widths['@smallbook'] does actually set the line width in this case. 2 reasons: 1) 5 inches is 127mm, which is too small to create the black bars. 2) As stated, if I replace the line with the scheme in with the line I proposed, the black bars disappear. FWIW, the code I cited has this before it: # Set a default line-width if there is none. We need this, because # lilypond-book has set left-padding by default and therefore does # #(define line-width (- line-width (* 3 mm))) # TODO: Junk this ugly hack if the code gets rewritten to concatenate # all settings before writing them in the \paper block. ___ 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: Owner: --- Comment #21 on issue 1691 by pkx1...@gmail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 (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 #20 on issue 1691 by percival.music.ca: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 The line you found was not the main one. To understand that line, please read the scheme tutorial in the documentation. Keep looking for a different line in that python/ directory. (hint: it uses \\in for inches, instead of cm or mm) ___ 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 #18 on issue 1691 by philehol...@googlemail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 OK. The value is defined in book_snippets.py in the following way: self.option_dict[LINE_WIDTH] = "#(- paper-width \ left-margin-default right-margin-default)" I haven't a clue what this does - paper-width, for example isn't mentioned in this file. However, if I output the value for self.option_dict[LINE_WIDTH] after this line, I get 160\mm. The easiest way to fix this would therefore be to change the line above to self.option_dict[LINE_WIDTH] = '155\\mm' This is the way INDENT is defined: self.option_dict[INDENT] = '0\\mm' and it would save lots of messing about. ___ 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 #19 on issue 1691 by philehol...@googlemail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 I've just tested the change above, and it gets rid of almost all the barred images in learning. I've not tested, but would assume the same would apply for the other manuals. There would then be a few samples of code requiring manual tweaking - either to get a smaller image, or to break/shorten lines in non-breaking code. ___ 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 #17 on issue 1691 by percival.music.ca: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 oops, it's actually in python/ instead of scm/ or ly/. And to find the relevant part, search for LINE_WIDTH in capitals. (at least, I _think_ that's the relevant part. I haven't tested changing it. Please try changing it, but only test it with lilypond-book on the command-line -- don't try rebuilding 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 #16 on issue 1691 by philehol...@googlemail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 Any idea how to start looking for where the line-width is set? I've grepped 'line-width' but the results didn't mean much to me. ___ 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 #15 on issue 1691 by percival.music.ca: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 I'd suggest leaving a bit more "reserve" space, i.e. using a line-width of 15.5\cm. We will not be specifying a width inside @lilypond[options]. Instead, we would alter the default line-width. IIRC that's in one of the scm/ files, but I wouldn't swear to that. It might be inside ly/ instead. However, to deal with instrument names, we'll need a solution to issue 766. And that issue is meandering around in the limbo of postponed issues, and nobody is specifically looking at label:maintainability issues. This kind of problem is why I'm arguing for increased priority for "hinders developer work" issues in GOP-8. ___ 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
"David Kastrup" wrote in message news:87pqkitzk8@fencepost.gnu.org... lilyp...@googlecode.com writes: Comment #14 on issue 1691 by philehol...@googlemail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 OK - I've done some more looking at this, following up James's work documented in Issue 1015. FWIW, music without instrument names does not produce black bars with @lilypond[verbatim,quote,line-width=15.984\cm], but does with a line width of 15.985. With the lower figure, any added instrument name does indeed push the image out and again produces black bars. However, if we were to work to a guideline of "Where quoted musical images exceed one line in length, use line-width=15.9\cm. If instrument names are used, this will need to be reduced to avoid black bars in the right margin of the PDF output." (info "(texinfo) Overfull hboxes") states at the end For what overfull boxes you have, however, TeX will print a large, ugly, black rectangle beside the line that contains the overfull hbox unless told otherwise. This is so you will notice the location of the problem if you are correcting a draft. To prevent such a monstrosity from marring your final printout, write the following in the beginning of the Texinfo file on a line of its own, before the `@titlepage' command: @finalout -- David Kastrup Yep. See the initial bug report. -- Phil Holmes Bug Squad ___ 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
lilyp...@googlecode.com writes: > Comment #14 on issue 1691 by philehol...@googlemail.com: Ugly bars in > PDF documents > http://code.google.com/p/lilypond/issues/detail?id=1691 > > OK - I've done some more looking at this, following up James's work > documented in Issue 1015. FWIW, music without instrument names does > not produce black bars with > @lilypond[verbatim,quote,line-width=15.984\cm], but does with a line > width of 15.985. With the lower figure, any added instrument name > does indeed push the image out and again produces black bars. > However, if we were to work to a guideline of "Where quoted musical > images exceed one line in length, use line-width=15.9\cm. If > instrument names are used, this will need to be reduced to avoid black > bars in the right margin of the PDF output." (info "(texinfo) Overfull hboxes") states at the end For what overfull boxes you have, however, TeX will print a large, ugly, black rectangle beside the line that contains the overfull hbox unless told otherwise. This is so you will notice the location of the problem if you are correcting a draft. To prevent such a monstrosity from marring your final printout, write the following in the beginning of the Texinfo file on a line of its own, before the `@titlepage' command: @finalout -- David Kastrup ___ 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 #14 on issue 1691 by philehol...@googlemail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 OK - I've done some more looking at this, following up James's work documented in Issue 1015. FWIW, music without instrument names does not produce black bars with @lilypond[verbatim,quote,line-width=15.984\cm], but does with a line width of 15.985. With the lower figure, any added instrument name does indeed push the image out and again produces black bars. However, if we were to work to a guideline of "Where quoted musical images exceed one line in length, use line-width=15.9\cm. If instrument names are used, this will need to be reduced to avoid black bars in the right margin of the PDF output." ___ 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: Status: Accepted Comment #13 on issue 1691 by percival.music.ca: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 What? I don't follow. This issue cannot be resolved until issue 1015 is fixed, and that is in turn blocked by issue 766. Some work can certainly be done (such as fixing any "black bars" in pure text), but the bulk of this relies on those other issues being fixed. ___ 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: Status: Comment #12 on issue 1691 by pkx1...@gmail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 Is this blocked by issue 1015? We've got a chain here I think and possibly a merge? ___ 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: 1015 Comment #11 on issue 1691 by percival.music.ca: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 (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 #10 on issue 1691 by pkx1...@gmail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 Done some experimenting in the LM for this - see http://code.google.com/p/lilypond/issues/detail?id=1015#c12 James ___ 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: Labels: -Patch-review Comment #9 on issue 1691 by pkx1...@gmail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 CG edits done. 849aad2af76768b4884c6dfaaf5907c17408d6e6 Moving onto the other manuals ___ 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: Labels: -Patch-new Patch-review Comment #7 on issue 1691 by colinpkc...@gmail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 (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
Updates: Owner: pkx1...@gmail.com Comment #8 on issue 1691 by colinpkc...@gmail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 (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
Updates: Labels: Patch-new Comment #6 on issue 1691 by pkx1...@gmail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 Patch uploaded for CG http://codereview.appspot.com/4641074 Hope its not too big. Most of it is editing Phil's 'dumping' of build stuff anyway, I could have ignored that but it seemed silly to not tidy that up where appropriate as well. James ___ 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: Status: Started Comment #5 on issue 1691 by pkx1...@gmail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 @smallexample seems to work quite well for URLs, I'll go through the CG for now and clear up as many as I can. I also think that while using \ is preferable, if you did that on Pg 72 (Normal Maintenance) I'm not sure that having those 5 lines only with '\' would be as readable as making the whole section as an @smallexample. I'll see what it looks like in both cases and make a decision if that's ok :) The NR us a bit more complicated because most ugly bars seem to be caused by snippets both in the LSR and in snippets/new/ or by single line examples that might be more work to get shorter, but will have to be done probably on a case-by-case basis. ___ 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 #4 on issue 1691 by percival.music.ca: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 We can change @example...@end example to @smallexample...@end smallexample, but my preference would be to split up long lines (by adding \ to the ends of lines) In the case of a single URL, that's not possible, so I guess @smallexample is the way to go. ___ 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 #3 on issue 1691 by philehol...@googlemail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 Just been taking a passing look at some of these. In the CG, for example, most of the problems are caused by fixed width single lines, for stuff like URLs or command lines. See page 70 for example. How would these be fixed? ___ 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 #2 on issue 1691 by percival.music.ca: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 Technically I suppose that somebody could just manually tweak the line widths of all examples which are too wide, thereby fixing this issue without fixing issue 1015 (which asks for a general solution to line-width). So no, I wouldn't say that it was blocked on 1015 / 766. It would certainly be nice if those issues could be resolved, though. ___ 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 #1 on issue 1691 by pkx1...@gmail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 Extra note http://code.google.com/p/lilypond/issues/detail?id=1015 is blocked on http://code.google.com/p/lilypond/issues/detail?id=766 which is postponed I haven't looked at either in detail but is it likely that this issue is also going to be blocked on 766? ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond