lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to prevent Lilypond from cutting off markup?


From: David Kastrup
Subject: Re: How to prevent Lilypond from cutting off markup?
Date: Sun, 22 Jan 2012 09:24:58 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

James <address@hidden> writes:

> Hello,
>
> On 21 January 2012 23:36, Thomas Morley <address@hidden> wrote:
>> Hi Phil,
>>
>> 2012/1/21 Phil Holmes <address@hidden>:
>>> ----- Original Message ----- From: "Tobias Leupold" <address@hidden>

>>>> \relative c' {
>>>> c4 c c c c c c c c c c c c c c c c c c
>>>> c ^\markup { \large \bold "Abgeschnitten" }
>>>> c c c c c c c c c c c c c c c c c c c
>>>> }
>>
>> as Leopold wrote this was discussed already in the (german)
>> lilypond-forum. Of course the upgrade was suggested. But it doesn't
>> solve the problem.
>> 2.12.3 cuts off the markup (see the first attached png)
>> 2.14.2 moves the NoteColumn (see the second png). This is ugly, too.
>> (same with 2.15.20)
>
> Improve to what?
>
> While cutting off is not acceptable, if you are tying something to a
> note (which is what the ^ markup does) and that is long what else do
> you expect?

A likely more acceptable solution would be a combination of
a) allow some limited spillage room to the right of the regular space
b) reduce the size of the StaffGroup (!) to make the markup fit.

> If we take your example where should the 4th note sit? Left aligned?
> Centre? then what happens with the other notes or why not just use
> \mark and break-align accordingly? or do you expect the text to hang
> over the end of the measure?

Hanging over the end of the measure is acceptable in some other
contexts.  The end of the line is somewhat special, of course.

> The 2.14 example is *exactly* what I would expect to happen if you are
> tying something to a note.
>
> I don't understand what you expect, other than you don't 'like' it.

In my experience, programming typesetting tasks based on user
specifications and feedback sometimes is reduced to "This is totally
ugly.  I don't care that it formally meets the specs we made at the
start of the project.  Make it go away".

And where the ugliness is totally obvious, there is not much sense in
arguing around it because the case has not been thought of while the
specs were agreed on.  The trick is to make sure one is able to _bill_
the additional work without upsetting the customer and getting a "you
can't be serious" reaction.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]