On 2016/02/29 11:25:37, dak wrote:
On 2016/02/29 11:22:32, dak wrote:

> Oh, didn't see it.  I definitely would refrain from modifying files
in any
way.

^This, and:

Besides, the main purpose of adding such files is that the recipient
is able to
recompile them on his own in the same manner.  If every recompilation
adds
another crud header to the included files, that will eventually become
annoying.

Yes, absolutely. (Then again, we can be smart about it and refrain from
adding a header whenever we detect an already-existing one.)

However, I’m not sure about that:

> If the author wants identifying information, he can add it to the
top of the
> files on her own.  Using this option should always be a conscious
choice, and
> that includes making the files suitable for exporting.

This is not a discussion we need to have right now, but I’d very much
like for us to consider eventually turning this option on by default
(just like we already do with point-and-click, which needs to be
deliberately disabled by the user to produce a "normal" PDF file).
Granted, this may well add security issues (but we already are producing
potentially unsafe PDF files).

Another option would be to embed an additional README (or NFO :-) text
file, which would only contain a couple of lines explaining what these
files are, why they’re there and how to download LilyPond. That way the
original source code would be left in a pristine state.

Then again, that may well be outside of the scope of this patch.

V.

https://codereview.appspot.com/225040043/
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Reply via email to