Re: dynamic/beam/stem/tuplet number/tuplet number collisions

[James]

Hello,

On 24 March 2012 06:57, Jeffrey Trevino <address@hidden> wrote:
> Hi there,
>
> I'm rendering some dense notation, and there are lots of collisions between
> beams, stems, dynamics, tuplet numbers, and tuplet brackets. I'd like to be
> sure I'm aware of best practices with two questions:
>
> 1) What are the global actions I should take to keep this from happening
> upon render (I think there's something called "padding" for most of the
> grobs, according to the online documentation? Perhaps the order the things
> are engraved?)?

Yes you can use padding, however LilyPond should do most collision
avoidance out of the box. I'd also recommend making sure you are on at
least 2.14.2 - the latest stable and if possible try the latest dev
release (2.15.34) as there have been many improvements on layout since
then. If you are using 2.12.x you'd just be making more work for
yourself unnecessarily.

It is possible to have both dev and stable releases installed on a
system (with Windows, it is just a case of renaming the LilyPond dir
that is installed in 'Programs', ditto mac (just rename the .app) and
flick between the two types.

You don't give any tiny examples so it is hard to say if you want to
add 'padding' or not, and to what grob/glyph etc.

Give us a chance to 'see' your problem. Perhaps even just a small screenshot.

>
> 2) Failing #1, what are the best ways to solve these problems by locally
> moving these things around via position overrides after I see my mangled
> output?

Yes again that is possible, but really, unless you are hitting known bugs

http://code.google.com/p/lilypond/issues/list

It should just work(tm).

To be honest, I'd say these questions are too broad o give anything
other than 'possibly', 'maybe', 'it depends' or 'could do' answers,
and you'd do well to give us an 'idea' of specifics - without filling
the list with a hundred line .ly file.

I'd say the most common question we get from beginners about 'dense'
and 'colliding' things are either because of known bugs (which will
need overrides and tweaks) or because of incorrect usage of multiple
voices in the same staff.

For example NOT using explicit voices but trying to use < .. >
constructions or << // >> constructions with \xxxUp \xxxDown type
commands peppered all over.

Sorry I cannot give you more explicit instructions, but if you find
yourself having to make more and more overrides starting out, you may
not as I think you are guessing, be 'thinking in LilyPondese'.

James