lyluatex icon indicating copy to clipboard operation
lyluatex copied to clipboard

Reliably determine indent single- and two-system scores

Open uliska opened this issue 7 years ago • 6 comments
trafficstars

When a score is indented with the new indent option (#95) it protrudes in the left margin if it is a single-system score.

The reason is that LilyPond cuts the indented space off by offsetting the bounding box (visible in the *.eps output). With multi-system scores this is not an issue. This offset is interpreted as a negative protrusion and incorrectly "adjusted".

I'll have to somehow calculate this offset against the nominal indent (in pt) in order to also deal with actual protrusion

uliska avatar Feb 06 '18 17:02 uliska

Score indentation makes real sense only for multi-system scores where the first system is indented (which is actually what the lilypond-book docs say).

Wouldn't it be a better option to silently (but of course documented) deactivate indent for scores that produce a single system? One could check from the intermediate files and trigger a re-run with changed options. We will have to implement a control structure for re-running LilyPond anyway, in the context of the "max protrusion" option.

So the only argument against suppressing the indent for single-line scores is that users might be surprised. Opinions, @jperon @rpspringuel ?

uliska avatar Feb 08 '18 07:02 uliska

I agree with that, but don't think a re-run is necessary: it could be implemented within Score:write_tex and Score:protrusion. For example, Score:protrusion could have a nsystems argument, and if it's equal to 1, take off self.indent from protrusion. The user could be warned through warn().

jperon avatar Feb 08 '18 09:02 jperon

Incidentally, this could be an occasion to add a noprotrusion option, and perhaps a protrusion to let the user force its value.

jperon avatar Feb 08 '18 10:02 jperon

I think this issue should be solved by #123. Is it OK ?

jperon avatar Feb 12 '18 15:02 jperon

There's one limitation where this behaviour will produce suboptimal results, but I'm not sure if this corner case warrants further development (or if it's sufficient to document it).

  1. Consider a score that is just a little bit too long to fit in one indented system - but it would fit in a single system if it were not indented. In that case it will stay indented and be printed on two systems.
  2. Or if we want to include the first system of a multi-system score it would be better to actually compile an unindented version

Regarding 1. I think one could trigger an unindented re-run if the system count is exactly 2. If the result still has two systems the original score will be used, otherwise the new single-system score.

Regarding 2. it is probably OK to expect the user to disable the indent if they actually want to do that.

I would say we should look for a solution to 1. and keep this issue open but remove the "bug" label and the Release v1 milestone. What do you think?

uliska avatar Feb 13 '18 11:02 uliska

That's OK for either 1. or let it as it is (the user having the option to force noindent in corner cases).

jperon avatar Feb 13 '18 23:02 jperon