lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Add PDF metadata section to NR; indexing; minor error fix (issue 2564800


From: ht . lilypond . development
Subject: Add PDF metadata section to NR; indexing; minor error fix (issue 256480043 by address@hidden)
Date: Sun, 16 Aug 2015 18:00:21 +0000

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/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]