Re: tab characters in the source code
Op dinsdag 07-04-2009 om 15:28 uur [tijdzone -0600], schreef Carl D. Sorensen: > LilyPond programming standards call for no tabs in the files. Not so. http://www.gnu.org/prep/standards/html_node/index.html Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: html errors in navigation bar for snippets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mittwoch, 8. April 2009 06:39:48 Mark Polesky wrote: > On this page: > http://lilypond.org/doc/v2.13/input/lsr/lilypond-snippets/index > > scroll down to the Staff notation of the navigation bar, and > hover over some links. There are some errors here. For example, > all of the following links point to "Nesting-staves" > > * Non-traditional key signatures > * Printing metronome and rehearsal marks below the staff > * Quoting another voice with transposition Yes, that's a known issue, which I don't know how to solve. The problem is that several snippets are included more than once on the snippets page. Now, the first time it gets the correct label attached (e.g. the non- traditional key signatures are included in Pitches as well as in Staff notation), see Pitches->Non-traditional key signatures. However, the second time it is included, it wants the same node name again, which texinfo does not allow (all node names SHOULD be unique), so texinfo will not use the node name of the snippet and create a new node, but re-use the node name of the previous section (Nesting-staves in this case)... This is also the cause for the long list of warnings when you run "make web" in the input/lsr directory... The only solution I can see is to copy each of the multiply included snippets and change their node name so that each file is included only once and each node appears only once. Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJ3GzjTqjEwhXvPN0RArrzAJ973PQEs2xUfNofO38LpoU4gsI7SACffkhE CCMfitM95w5gZKV69ZX6Axg= =zMQ2 -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: html errors in navigation bar for snippets
On Wed, Apr 08, 2009 at 11:22:42AM +0200, Reinhold Kainhofer
wrote:
> The only solution I can see is to copy each of the multiply
> included snippets and change their node name so that each file
> is included only once and each node appears only once.
Ouch, and I also can't think of any other solutions. Something like:
${snippet_name}-${tag_name}
?
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: reducing ps file size (please comment)
On Tue, Apr 7, 2009, Mark Polesky said: > Short version: I made some changes to output-ps.scm > that can safely reduce the file size of ps files. In > a simple experiment, I was able to reduce non-binary > ps-code by up to 10%. PS code is notorious for being voluminous. Most of the time the stream volatizes in the printer and noone cares beyond maybe some foot tapping at the printer waiting. binary inclusions such as fonts or illos are usually the biggest cause of bloat. now that so many cheap laser printers sans PS rips are on the market even that is less of an issue as the computer/printserver RIPs the PS code and sends image data to the printer. A significant reduction in actual code can be had with careful use of a private dictionary, sometimes just using shorter names for common operators can help a lot (eg, mt for moveto), but also creating new operators for common operations (such as positioning note heads). -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: reducing ps file size (please comment)
Han-Wen Nienhuys wrote: > The ly:format routine was created as a C++ one because we had > significant memory blowup due to the use of format routines that ran > in Scheme. You may want to submit a simple patch to make it strip > trailing zeroes from decimals; then you get a simple reduction in file > size. Han-Wen, It sounds simple, but I don't know C++, so I couldn't do it myself. Dana Emery wrote: > A significant reduction in actual code can be had with careful use of a > private dictionary, sometimes just using shorter names for common > operators can help a lot (eg, mt for moveto), but also creating new > operators for common operations (such as positioning note heads). Would reducing ps excess reduce compilation time? Or would the difference be negligible? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: reducing ps file size (please comment)
On Wed, Apr 8, 2009, Mark Polesky said: Would reducing ps excess reduce compilation > time? Or would the difference be negligible? PS code is not usually compiled, it is transmitted, parsed, and executed. Adobes manuals make it clear that the defined operators are deliberatly given long spelledout names for clarity of semantics and efficient use would include the use of private suites of operators, even if only to provide concise aliases for the most used operators. Several of the early Macintosh PS-aware applications took advantage of this to some degree, including the Laserwriter print driver. One of my projects used Deluxe Music Construction Set as a WYSIWIG front end to produce EPSF of short musical excerpts for inclusion in a MS Word produced DMA defense document. Printing to disk gave me files of PS code which included several fonts as well as the illustration code. Original files were about a megabyte in length, final EPSF was usualy less than a kilobyte; a good thing because Word had an unadvertised limit (even second echelon TS didnt know about it) for how much PS code you could have on a page. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: reducing ps file size (please comment)
On Wed, Apr 8, 2009 at 12:40 PM, Mark Polesky wrote: >> A significant reduction in actual code can be had with careful use of a >> private dictionary, sometimes just using shorter names for common >> operators can help a lot (eg, mt for moveto), but also creating new >> operators for common operations (such as positioning note heads). > > Would reducing ps excess reduce compilation > time? Or would the difference be negligible? It would not be measurable. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Move left-broken line-spanner check to after-line-breaking callback
Hi, Currently left-broken line spanners and hairpins are removed automatically if they end on the first note. Though this is usually appropriate for trills, glissandi and hairpins, there are situations where it would be useful to override this default behaviour, for example when using text spans. This patch moves the hard-coded check from Line_spanner::print () to a new callback, ly:spanner::after-line-breaking, which can be set as required. Please review the patch here: http://codereview.appspot.com/32148/show Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Fix #670: Chained trills
lgtm http://codereview.appspot.com/32142 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Move left-broken line-spanner check to callback.
One minor comment, otherwise lgtm http://codereview.appspot.com/32148/diff/1/7 File lily/spanner.cc (right): http://codereview.appspot.com/32148/diff/1/7#newcode426 Line 426: Spanner::after_line_breaking (SCM grob) Can you think of a name that describes what the function actually does? Like Spanner::suicide_if_spanned_time_is_empty, but maybe less verbose... http://codereview.appspot.com/32148 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tab characters in the source code
On Tue, Apr 7, 2009 at 8:18 PM, Carl D. Sorensen wrote: >> As to LY not accepting tabs, thats a shame, tabs should be treated as >> white space, along with and other now-disused >> characters from the days of teletypes which sometimes find their way into >> ascii files from odd unix and dos systems; this is done in the postscript >> language. Except perhaps in lyrics, where they might well be used to >> demarcate syllables. > > LilyPond accepts tabs just fine; they're whitespace. If you want to put tab > characters in your LilyPond source you can do so. > > Programming standards for LilyPond call for avoiding the tab character. > We're free to choose whatever programming conventions we want for our source > code. I don't think it is a standard, but I would not mind making it a standard. Han-Wen (being trained to avoid tabs during daytime) -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
