Add PDF metadata section to NR; indexing; minor error fix

Add PDF metadata section to NR; indexing; minor error fix

[ht, 2015-08-16 18:00:21]

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....
File Documentation/notation/input.itely (right):

https://codereview.appspot.com/256480043/diff/1/Documentation/notation/input....
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....
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....
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?

[PhilEHolmes, 2015-09-24 14:51:28]

Updated after comments and author patch