Menu
▾
▴
#1691 Ugly bars in PDF documents
Originally created by: *anonymous
Originally created by: PhilEHol...@googlemail.com
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.
Originally posted by: pkx1...@gmail.com
Extra note
https://code.google.com/p/lilypond/issues/detail?id=1015
is blocked on
https://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?
Originally posted by: percival.music.ca@gmail.com
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.
Originally posted by: PhilEHol...@googlemail.com
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?
Originally posted by: percival.music.ca@gmail.com
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.
Originally posted by: pkx1...@gmail.com
@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.
Status: Started
Originally posted by: pkx1...@gmail.com
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
Labels: Patch-new
Originally posted by: ColinPKC...@gmail.com
(No comment was entered for this change.)
Labels: -Patch-new Patch-review
Originally posted by: ColinPKC...@gmail.com
(No comment was entered for this change.)
Owner: pkx1...@gmail.com
Originally posted by: pkx1...@gmail.com
CG edits done.
[r849aad2af76768b4884c6dfaaf5907c17408d6e6]
Moving onto the other manuals
Labels: -Patch-review
Originally posted by: pkx1...@gmail.com
Done some experimenting in the LM for this - see
https://code.google.com/p/lilypond/issues/detail?id=1015#c12
James
Originally posted by: percival.music.ca@gmail.com
(No comment was entered for this change.)
Blockedon: 1015
Originally posted by: pkx1...@gmail.com
Is this blocked by issue 1015?
We've got a chain here I think and possibly a merge?
Status:
Originally posted by: percival.music.ca@gmail.com
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.
Status: Accepted
Originally posted by: PhilEHol...@googlemail.com
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."
Originally posted by: percival.music.ca@gmail.com
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.
Originally posted by: PhilEHol...@googlemail.com
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.
Originally posted by: percival.music.ca@gmail.com
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!)
Originally posted by: PhilEHol...@googlemail.com
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.
Originally posted by: PhilEHol...@googlemail.com
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.
Originally posted by: percival.music.ca@gmail.com
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)
Originally posted by: pkx1...@gmail.com
(No comment was entered for this change.)
Owner: ---
Originally posted by: PhilEHol...@googlemail.com
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.
Originally posted by: percival.music.ca@gmail.com
hmm, I thought that 5\\in was actually it. Ok, then maybe it's using the defaults in
ly/paper-defaults.ly
which define left-margin-default and right-margin-default, and then maybe it gets paper-width from latex itself ?
To be honest, I'm not certain how lilypond-book works, particularly with respect to latex and/or the underlying scheme stuff and/or the lilypond spacing engine.
Originally posted by: PhilEHol...@googlemail.com
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.
Originally posted by: percival.music.ca@gmail.com
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.