Hi, Thank you for the quick response to this documentation request, here are some comments.
I'd like to inform also that the patch (issue 4539) for setting the "sequence name" for MIDI files, using the "midititle" (if set) or "title" header variables, got added to the master source tree, so this closely related feature now needs to be documented as well – if you think it doesn't make sense to expand this patch to handle this change, please let me know so I can try to make a documentation patch myself (after the current issue has first been closed). Regards, Heikki https://codereview.appspot.com/256480043/diff/1/Documentation/notation/input.itely File Documentation/notation/input.itely (right): https://codereview.appspot.com/256480043/diff/1/Documentation/notation/input.itely#newcode1210 Documentation/notation/input.itely:1210: PDF document to @q{Symphony I}. If I've understood the behavior correctly, I think that initializing PDF metadata from \header fields normally occurs completely automatically, so to emphasize that this is actually the default behavior (and nothing special needs to be done to have the PDF metadata set), the above paragraph could be written as In addition to being shown in the printed output, the @code{\header} variables will also be used to set PDF metadata (the information displayed by PDF readers as the properties of the PDF file). For example, setting the @code{title} property of a @code{\header} block to @q{Symphony I} will give this title also to the PDF document. https://codereview.appspot.com/256480043/diff/1/Documentation/notation/input.itely#newcode1234 Documentation/notation/input.itely:1234: (or @code{pdfcomposer} if this is also set). Again, continuing with the above viewpoint (that the PDF metadata will be set automatically using the \header fields affecting the printed output), I'd consider changing the first sentence of the above paragraph to Each of the variables @code{title}, @code{subject}, @code{keywords}, @code{subtitle}, @code{composer}, @code{arranger}, @code{poet} and @code{copyright} can be prefixed with @q{pdf} to set a PDF property corresponding to the variable to a different value from the printed output. Also, the outcome of issue 4563 (currently in review) may change the behavior of the "composer" header variable... https://codereview.appspot.com/256480043/diff/1/Documentation/notation/input.itely#newcode1239 Documentation/notation/input.itely:1239: @code{moddate} (or @code{pdfmoddate}) to a valid date string. What's a "valid" date string in this context (does this mean the format defined in the PDF specification)? Without linking to external resources, would "a valid _PDF_ date string" suffice here? https://codereview.appspot.com/256480043/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
