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 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
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 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
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 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 #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
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 #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 #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 #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 #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 #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 #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 #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
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 #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
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
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 #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
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
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 #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 #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 #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
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 #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 #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 #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
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
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
David Kastrup d...@gnu.org 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
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: 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: 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
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: 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
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 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: 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
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
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 #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
Issue 1691 in lilypond: Ugly bars in PDF documents
Status: Accepted Owner: Labels: Type-Documentation Priority-Medium New issue 1691 by philehol...@googlemail.com: Ugly bars in PDF documents http://code.google.com/p/lilypond/issues/detail?id=1691 In the documentation build it's common to see an error message beginning Overfull \hbox. Looking on the web for what this means, I found http://docs.freebsd.org/info/texinfo/texinfo.info.Overfull_hboxes.html which says: TeX is sometimes unable to typeset a line without extending it into the right margin unless told otherwise, TeX will print a large, ugly, black rectangle beside the line that contains the overfull hbox. There are quite a few of these in, say, the 2.14.0 NR - see the PDF page 33 and 37 for example. It would seem there are 2 options: either fix the text/diagram sizes, or compile as suggested in the page above: 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 The current consensus is that it would be better to start by looking at correcting the documentation to get the text correctly sized. Issue 1015 is related to this. ___ 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
