Control: tags -1 - wontfix Hi Karl,
Thank you for your follow up. On Tue, Jan 31, 2017 at 10:22 AM, Karl O. Pinc <k...@meme.com> wrote: > On Mon, 30 Jan 2017 22:29:46 -0700 Anthony Fok <f...@debian.org> wrote: >> Rather, the officially documented method is outlined in >> http://lilypond.org/doc/v2.18/Documentation/notation/paper-size-and-automatic-scaling, >> i.e., by setting the paper size in the .ly file itself: >> >> \paper { >> #(set-paper-size "letter") >> } > > Ok. I probably went to the man page first, to wind up using the > command line option. > >> I use Frescobaldi (a great GUI editor for LilyPond) myself, and its >> Score Wizard feature automatically generates needed skeleton LilyPond >> code for you, together with the set-paper-size command above. >> >> I highly recommend that you do the same instead, i.e. using >> Frescobaldi (sudo apt-get install frescobaldi) and setting the paper >> size inside your .ly file. > > Thanks. But I'm not interested in a GUI. Sorry for my poor choice of words. Frescobaldi is actually more a text editor with the added benefits of creating the overall structure of the .ly file, things like \header, \paper, lyrics, \score section etc. for you. After that, the end user still needs to go to the appropriate sections and enter notes like "c2 d4 e | f2 g" manually. It is none of those GUI entering-notes-by-clicking-with-the-mouse things which I am not used to myself either. Of course, LilyPond is self-sufficient on its own, and you definitely don't need Frescobaldi per se. But yes, it is very handy for both newbies and professional music engravers like Frescobaldi's author who organized and coordinated the production of a professionally-printed Dutch hymnal called "Liedboek" a few years ago. It is a tremendous time-saver and learning aid, and that is why I highly recommended that you at least give it a try. >> Changing the paper size on-the-fly using -dpaper-size is unreliable >> IMHO. You yourself may remember to add the "-dpaper-size letter" >> option, but others who receive the same .ly file with are not obliged >> to do so, and would get unexpected results such as extra page, ugly >> line-breaks, etc. due to unexpectedly different page width and page >> height. > > Good advice. Makes sense to me that every lilypond input file > contain a paper size specification. > > (Perhaps this should be a recommendation in the lilypond manual.) It *is* in the manual (info page, HTML and PDF). As a matter of fact, it is the only documented method, so I guess that would count as a recommendation? :-) Seriously though, I have gotten used to using on-line search engines, and thankfully, a search on "LilyPond paper size" on Google or DuckDuckGo.com gives me the correct LilyPond HTML documentation page as its first result. I find it easier than to search through the locally installed documentation, actually. :-) >> The fact that LilyPond does not read /etc/papersize is by design, and >> I think it is a good thing. Ignoring user environment variations like >> /etc/papersize helps ensure that the same .ly would produce the >> exactly same result everywhere. > > This sounds laudable, but unrealistic. I don't have any a4 paper, > the default, and this is probably true for almost everybody in North > America. > > My feeling is that if the author of the lilypond file did not > explicitly specify a paper size then lilypond should be free > to print on the paper available. Even if it means > that the result comes out looking different. If the composer wants > to ensure conformity in print output it's up to the composer > to do so. Otherwise, the composer should be allowed to distribute > music to be printed on whatever paper the musician has available. You have a good point there, but it is a design decision that both LilyPond (default: A4) and TeX/LaTeX (default: US Letter) have made. Another user has brought up the same issue some years ago. Check out the following conversations for an interesting read: http://lilypond.1069038.n5.nabble.com/LC-PAPER-and-default-paper-size-td131547.html > Speaking as a novice, I'd like to be able to typeset some music > and print it with minimum effort. It's bad enough having to figure > out lilypond itself without having > oh-my-!-now-I-have-to-deal-with-paper-size issues. Haha, been there, done that. (Oh yes, the learning pain.) > If you're expecting everybody to use a GUI that takes care of paper > size issues that's one thing, but it seems to me that the lilypond > packaging should at least have some options available for non-GUI > users. No, it wasn't the GUI with preset template, it was that Google search on "LilyPond paper size" or other creative searches to find helpful documentation or forum posts and useful snippets. Otherwise, how do you think I would come up with the following "monstrosity" to be able to change the "paper size" to fit 1280x720 (16:9 aspect ratio) for screen projection? #(set! paper-alist (cons '("1280x720" . (cons (* 9.16 in) (* 5.1525 in))) paper-alist)) \paper { #(set-paper-size "1280x720") } Scary stuff, but LilyPond, while easy to learn in the beginning, being such a powerful program, it allows you to tweak just about anything, but those tweaks may not look too user-friendly. But the good thing is you only need to look it up once, and you can keep using the same snippets for future scores. > My conclusion for the moment, if I've not convinced you > to change anything, No, I can't really change any code to modify LilyPond's default behaviour. I am not LilyPond's upstream author, and changing LilyPond's default behaviour, i.e., creating a fork, will invariably break all the other users who expect the current behaviour for many years now. It is not my call to make. Here is the answer from the current main upstream author, and the reply from the original poster: > More often than not, the global staff size and manual tweaks are set > to achieve a certain page layout. If LilyPond changed its behavior > on different computers, stuff would stop working without the user > having a clue that this was not intended output. Now that's a strong argument against LC_PAPER. I'm guilty of making such tweaks too. > is that there should at least be a note > in lilypond's README.Debian that lilypond does not follow > the Debian convention and honor /etc/papersize. Great idea! That I can do. :-) > A note about what to do to get your music to print would also be helpful. > > Perhaps the following section could be added to the README.Debian: > > LilyPond Paper Size On Debian > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > LilyPond does not honor /etc/papersize, the system preferred page > size. Instead it typesets for it's default, the A4 paper size, > when no paper size is otherwise specified. > > A composer who wishs to ensure consistency in typeset output should > always specify a paper size in their *.ly input file. This can be > done with a ``set-paper-size`` declaration in a ``\paper`` block, > as follows: > > :: > \paper { > #(set-paper-size "letter") > } > > A user who wishes to override the LilyPond default paper size may > do so from the command line with the ``-d`` option, as follows: > > :: > lilypond -dpaper-size='"letter"' foo.ly Looks good! I will include your suggested text (with minor modifications) to README.Debian on my next upload, likely 2.18.2-8. Thank you so much for your contribution, Karl! Removing the "wontfix" tag. :-) Cheers, Anthony
