On 12.01.2015 06:56, lemzw...@googlemail.com wrote:
https://codereview.appspot.com/194090043/diff/20001/Documentation/usage/running.itely File Documentation/usage/running.itely (right): https://codereview.appspot.com/194090043/diff/20001/Documentation/usage/running.itely#newcode187 Documentation/usage/running.itely:187: font data which can make significant reductions in file size. One point is missing: Why is the option called --bigpdfs if the we get significant reductions in file size?
We include up to three full copies (with different encoding vectors) for every emmentaler font used instead of one newly contructed font that includes only the subset of emmentaler glyphs used by the document. For all other fonts ghostscript is told to avoid subsettting whenever it is possible. That all means that the file size of the pdfs produced by lilypond itselb increases dramatically.
--bigpdfs is a name that describes the most visible effect of this code. It discourages the normal user, but that's not a bad effect. If you don't know why you want to use this option you probably don't have a reason to use it. --optpdfs would be misleading, and I have some ideas how to optimize pdf output. A class of possible names is related to the implementation details: Something like --dont_subset_fonts_use_emmentaler_via-encoding_vectors would be technically correct but much to long. --nofontsubsetting, --useencodings, --avoidglyphshow would emphasize only parts of the technical details. Another class of possible names would emphasize the intended use: --optimze_for_inclusion_in_TeX_if_you_include_multiple_lilypond_pdfs would be much to long but self-explanatory. --texsnip would be short enough and based on the intended use, and -t isn't used up to now.<http://dict.leo.org/#/search=self-explanatory&searchLoc=0&resultOrder=basic&multiwordShowSingle=on> A name that discourages Fred Foobar form using it unless he has read about it in the documentation and knows why he wants to use it is a good name, therefore I still like --bigpdfs. cu, Knut _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
