Re: Footer text from header

[Aaron Hill]

On 2024-03-19 11:15 am, Johannes Roeßler wrote:
> And I aim to separate content from style - but in order to have the 
> right (and changing) footer text for each piece in a book environment, 
> I need to get this information from the header and can't define it in 
> the common \paper env - or do I miss something?

You should be able to define oddFooterMarkup in a suitably generic 
manner.  All of the related markup paper variables are intended to work 
this way, so anything specific to a score lives in a \header block.


> And defining and adding your idea with the \as-string command seems not 
> to work:

The idea is that \as-string strips any commands for the markup you 
provide it.  But the usage you wrote is not what was intended.  
\as-string would be used just before the \fromproperty commands.  
Something closer to this:

>   oddFooterMarkup = \markup {
>     \fill-line {
>       \tiny {
>        { "Edited by Joei" }
>        \line {
>          \as-string \fromproperty #'header:composer " - "
>          \as-string \fromproperty #'header:title
>        }
>        "Copyright 2024"
>       }
>     }
>   }

NOTE: You should probably be using \header fields for copyright and 
editor.

Here's a more complete example with the goal of keeping the \header 
blocks free of \markup commands:

%%%%

\version "2.22.0"

\paper {
  bookTitleMarkup = \markup
    \override #'(baseline-skip . 1.75) \column {
      \fill-line {
        \override #'(font-name . "Lobster") \line {
          \fontsize #6 \fromproperty #'header:title
          \fontsize #3 \fromproperty #'header:subtitle
        }
        \bold \fromproperty #'header:composer
      }
      \override #'(thickness . 2) \draw-hline
    }

  oddFooterMarkup = \markup \tiny \fill-line {
    \line { Edited by \fromproperty #'header:editor }
    \line {
      \fromproperty #'header:composer
      – % en-dash
      \fromproperty #'header:title
    }
    \fromproperty #'header:copyright
  }
}

\header {
  editor = "Anon E. 🐭"
}

%% - - -

\header {
  title = "Lorem Ipsum"
  subtitle = "(dolor sit amet)"
  composer = \markup { "John Doe" \smallCaps (asdf) }
  copyright = "© 2024 John Doe Music"
}

\score { { b'1 } }

%%%%

In this case, the composer's affiliation with the fictitious ASDF group 
is written in small caps.  This markup command belongs in the \header 
block as we would ideally want it included anywhere that field is 
referenced.  Now, that is only one way to achieve things, as we could 
have just as easily defined a new header field instead:

%%%%
\header {
  title = "Lorem Ipsum"
  subtitle = "(dolor sit amet)"
  composer = "John Doe"
  affiliation = "ASDF"
  copyright = "© 2024 John Doe Music"
}
%%%%

Of course, the \paper block would need to be updated to support this new 
field.  (I'll leave that as an exercise for the reader.)

It will be up to you to determine where you are going to strike the 
balance between markup in the \paper block versus the \header block.  As 
in the example above, I think that it is perfectly fine to mix a little 
bit of useful formatting in the metadata, especially if such a thing is 
going to be relatively rare across the majority of your scores.  
Otherwise, anything that is shared should ideally be defined once, in 
some globally-referenced resource.

It can be a little tricky to plan out how to build your \paper markup 
variables, so that they function well when fields are defined or left 
undefined.  In the example I provided, the subtitle can be safely 
omitted.  However, note that I opted to put the parentheses within the 
subtitle field itself.  Had I put them in the \paper block, then you'd 
find an empty set of parens next to any title that did not also include 
a subtitle; not really what you'd want.  So, either one would need some 
clever custom \markup commands to automatically do the work, or we just 
"cheat" and put the parens in the header field.  Again, it comes back to 
that balancing act.

(The careful reader should observe that due to how the footer was 
defined, editor is effectively not an optional field.  The text "Edited 
by" will still appear even when the editor field is undefined.  I would 
encourage you to consider how you could improve this, assuming such 
flexibility is necessary.  The advanced exercise involves showing 
"Edited by" only when the editor field is defined without moving such 
text to the field itself.  Of course, consider your own real-world 
scenario.  Are you the editor for all of your scores?  If so, there may 
be no need to add complexity where it is otherwise wasted effort.)


-- Aaron Hill