Default top/bottom minimum margins

[dominicus]

Comparing some of the older Mutopia PDF's to newer-published ones, I suspect the default top/bottom margins have been reduced on later LilyPond versions. Looking at the references, default margin is now 6mm for top/bottom.

I tested printing some of our later reviewed pieces on couple HP laserjet printers and got truncated output when I used the "actual size" printing option instead of "fit to printable area". These printers have ~7mm non-printable area from the page edges.

Acrobat turns on the "Fit to printable area" printing option whenever a larger-than-possible document is loaded, but the Ubuntu default pdf viewer doesn't. Another concern is loss of printout quality when downscaled by the PDF reader.

I think we should strive to engrave sheet music having 7-8mm minimum top/bottom margins for new publications to ensure printer compatibility.

That being said, any ideas on best way to reliably implement this?

[glenl]

By "reliable" you mean something that accomplishes this without actually adding it to each file submitted?

\paper {
   top-margin = 8\mm
   bottom-margin = 8\mm
}

[dominicus]

Right. LilyPond has more than one command to set distance from edges, so parsing through code could get complicated. Another (impractical) option is to directly change the default values within the installation files, so these would take over in case of no margin settings in code. I bet these could be added to the lilypond command-line invocation during compile, but this will likely supersede the values stated in the source, which may be undesirable if the typesetter has already set these. At this point, I just add this check to the workflow to set as you show above if the typesetter didn't set other values. If we agree the better practical option is visually check source, be good to update the UsefulScripts page.

[doughdemon]

I'm very sure that they could be set on the command line. What is set on the command line is overridden from what's in the score. (e.g. the paper size)

EDIT: It's not as easily achievable as I thought. Since each book might have its own paper block one would need to hook in something which is applied to all books at some point. But I don't know how/whether it is possible to detect whether the user has set the margins explicitely then.

On the other hand I don't think that we should be overriding lilyponds standards by default. It's an issue of lilypond if the the margins are to small for many printers, isn't it?

I'm note sure how the downscaling should affect the quality of the score. Do you mean the proportions might change?

Just to mention it one might also want to think about how it interacts with manual line and page breaks.

[dominicus]

@doughdemon I think the key issue is, without stated margins on the score, the title is being engraved too high on the page even when printed with "Fit to page" downscaling. Compare these two pieces engraved with default top/bottom margins:

v2.10

v2.16

Seems at some point between these versions, LilyPond adopted narrower default margins, most noticeably the top margin.

Acrobat's "fit-to-page" function will retain the aspect-ratio, making the music shorter and narrower at the same time. Ubuntu's eVince on my PC defaults to actual size and will truncate a sliver of the title, requiring a reprint with "Fit" setting. Nevertheless, I think it's better to adopt wider/safer minimum margins than the Lilypond default of 6mm.

I found this post on LilyPond user group, where they measured the top margins used by the major engraving houses at 10-15mm.

Can you restate how a command line with top-margin works when top-margin setting is found in the score? Will the setting in the source file win? If so, this may be a viable solution. We'd want to respect manually-set margins in the source .ly. If not set, maybe the command-line can take over and force top to be around 10mm and bottom to 8mm.

[glenl]

I understand the problem but I wonder about the appropriate solution. What is our role? Are we publishers who edit and apply some style to the works we present or simply an archive of contributed works? I'd suggest we are somewhere in between but I recommend caution.

Consider the E Ink music stand or iKlip where a user might want music closer to the edge.

I agree the defaults present an issue especially with typical home inkjet printers. I took a quick look at the LilyPond --init command line switch thinking we might come up with a set of "style files" that we could apply but its usefulness eluded me.

[chrissawer]

Personally I would prefer to stick with the LilyPond defaults. If the default margins are too small for most printers then that should be raised as a LilyPond bug.

Some contributors may have carefully formatted their pieces to give good line/page breaks avoiding orphans. If we override the margins using the command line or some other method, then we could end up disrupting the contributor's layout. I think this would be undesirable.

[dominicus]

I agree with comments above:

1. Preference to retain the typesetter's overall layout (i.e. page-breaks).
2. No change to Mutopia scripts: allow LilyPond defaults to continue enforcing minimum margins when none are stated in source file.

I looked up LilyPond v2.16 default margins on paper-defaults-init.ly system file:

top-margin-default = 5\mm
bottom-margin-default = 6\mm

top-margin-default affects all pages, and setting a top-margin of 9mm creates too much space for pages 2+, as page numbers consume vertical space below the top margin. This was a bad idea on my part to start with, and explains why LilyPond sets these to 5mm by default.

My outstanding recommendation is to agree on a preferred minimum distance for the title page of 9mm from paper edge, as 5mm appears too close aesthetically for the (large) title font. This can be accomplished by adding the following line to submitted source files when not already stated by the typesetter, and assuming pagebreaks are not altered:

\paper {
       %... 
       top-markup-spacing  #'basic-distance = 4\mm
       %...
}

This builds an additional offset to the title on page 1 only (~9mm from edge).

On pages 2+, staves keep a satisfactory distance from edge, as the page number takes vertical space below the top-margin, effectively keeps music >9mm from top edge.

@glenl brings up a good point on the increasing use of tablets to display music, which reminded me of an interesting video I saw on iPad app with automatic page turns. I could see this turning into yet another output format for Mutopia: [A4], [Letter], [Tablet] ... why would one need titles on a tablet, when the tablet software can pick up the titles from metadata? :smiley: