search

jperon / lyluatex

Alternative à lilypond-book pour lualatex
MIT License
58 stars 12 forks source link

Reliably determine indent single- and two-system scores #98

Open uliska opened 6 years ago

uliska commented 6 years ago

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 commented 6 years ago

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 ?

jperon commented 6 years ago

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 commented 6 years ago

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

jperon commented 6 years ago

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

uliska commented 6 years ago

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?

jperon commented 6 years ago

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