Как отключить или ограничить сжатие переполненных страниц в Lilypond?

Иногда lilypond пытается использовать меньше страниц для большего количества музыки, что не всегда нужно. Это можно легко исправить, добавив вручную \pageBreak, но иногда требуется автоматическое решение.

Когда происходит вертикальное сжатие, журнал lilypond показывает что-то вроде этого:

warning: compressing over-full page by 36.9 staff-spaces
warning: page 4 has been compressed

В моей конкретной ситуации сценарий lilypond генерируется программой анализа MusicXML, и ручная настройка позиций или разрывов страниц невозможна, потому что мы не знаем, какую музыку может загружать пользователь.

Как можно полностью отключить или ограничить сжатие, чтобы Lilypond пришлось добавлять разрывы страниц? Требуется автоматическое решение, которое не включает ручную настройку позиций элементов и разрывов страниц.

Извините, что публикую такой большой пример, но нужно много элементов, так что этой страницы уже недостаточно. Вот пример автоматически сгенерированного счета:

1. Автоматический разрыв строки приводит к чрезмерному сжатию первой страницы по вертикали (текстовые строки расположены слишком близко друг к другу, числа внутри партитуры сталкиваются с текстовыми гаечными ключами):

https://github.com/rualark/MGen/blob/master/MGen/configs/ly2/debug/compressing/compressed2.ly

https://github.com/rualark/MGen/blob/master/MGen/configs/ly2/debug/compressing/compressed2.pdf

Зеркало: http://lilybin.com/f7wjax/1

Зеркало: https://www.hacklily.org/?edit=rualark/sheet-music/overcompressed.ly

2. Добавление всего одной \pageBreakкоманды все исправляет:

https://github.com/rualark/MGen/blob/master/MGen/configs/ly2/debug/compressing/uncompressed2.ly

https://github.com/rualark/MGen/blob/master/MGen/configs/ly2/debug/compressing/uncompressed2.pdf

Зеркало: http://lilybin.com/7xlar8/1

Зеркало: https://www.hacklily.org/?edit=rualark/sheet-music/uncompressed.ly

Я уже выполнил поиск известных проблем в Google и посетил документацию lilypond, но пока без существенного прогресса:

http://lilypond.org/doc/v2.18/Documentation/notation/vertical-spacing http://lilypond.1069038.n5.nabble.com/warning-compressing-over-full-page-by-12-4 -staff-spaces-td168716.html

Пожалуйста помоги!

В вашем примере вы часто используете \once \overrideодни и те же свойства. Почему бы вам просто не использовать \overrideтолько один раз в начале? Если вы можете перемещаться по коду, это нормально, но его можно значительно упростить! И это помогло бы другим понять это. Теперь к вашему вопросу: вы изучали вертикальное позиционирование в документе: lilypond.org/doc/v2.18/Documentation/notation/…
@JasperHabicht извините, что я недостаточно ясно заявил, что в этом конкретном случае требуется автоматическое решение. Скрипт полностью генерируется программой, и человек не может помешать вручную добавить позиции или разрывы страниц (я обновил пост). Что касается '\once', я использую его, чтобы предотвратить переопределение свойств обратно на предыдущий цвет, что делает скрипт lilypond длиннее и усложняет программу анализа. Если вы считаете это важным вопросом, я постараюсь придумать лучшее решение.

Ответы (1)

Насколько я знаю, вы можете указать Lilypond, как размещать строки внутри одной разметки, но не между ними (за исключением, возможно, отступов). Это особенно проблематично, если эта разметка не встроена в контекст персонала. Хотя, возможно, я ошибаюсь…

Таким образом, вам, вероятно, не следует использовать много одиночных \markupмакросов, а вместо этого использовать a \markuplistи \wordwrap-lines. Это должно помешать Lilypond сжимать интервалы между отдельными markupкомандами. По крайней мере, стоит попробовать.

markuplistНапример, вы можете использовать по одному на абзац. В спецификации сказано, что markuplists может занимать несколько страниц, так что, возможно, вы даже можете использовать только одну. Я не знаю, как именно работает ваш скрипт, который генерирует этот вывод, но, может быть, это возможное решение?

Я добавил фрагменты из вашего кода и в следующем примере, но сократил его до наиболее важных частей:

\version "2.18.2"
\language "english"
\paper { 
  #(include-special-characters) 
  bottom-margin = 0.27\in
}
% Your definitions here
\markup \wordwrap {
  \bold { "#"2 (from test-vocal-range) Key: G mixolydian }
  \tiny { "Lyrics:" "sp1." }
}
<<
% Your notes and formatting here
\new Staff = "staff1" {
  \set Staff.instrumentName = \markup { \teeny \override #'(baseline-skip . 2.0) \center-column{ "Part"  ""  "[Soprano]" } }
  \new Voice { \override NoteHead.color=#(rgb-color 1.000 0.000 0.000)
  d'1
  }
}
% etc.
>>
\markuplist {
  \wordwrap-lines { \tiny \bold "Part [bar 1, beat 1] note D" }
  \wordwrap-lines { \smaller \with-color #(rgb-color 1.000 0.000 0.000) "1 - Melody: Stagnation (5 notes <m3)" }
  \wordwrap-lines { \smaller \with-color #(rgb-color 1.000 0.000 0.000) "1 - Melody: Stagnation (5 notes <m3)" }
}
\markuplist {
  \wordwrap-lines { \tiny \bold "Part [bar 1, beat 1] note D" }
  \wordwrap-lines { \smaller \with-color #(rgb-color 1.000 0.000 0.000) "1 - Melody: Stagnation (5 notes <m3)" }
  \wordwrap-lines { \smaller \with-color #(rgb-color 1.000 0.000 0.000) "1 - Melody: Stagnation (5 notes <m3)" }
}
% ... and so on
Спасибо за идею! Тем не менее, не странно ли, что мы не можем предотвратить чрезмерное сжатие блоков? Например, lilypond показывает, сколько мест для персонала было сжато в логе выше. Вероятно, это значение можно ограничить, но я не могу найти, как это сделать.
Я попробовал это решение, но \markuplist \workwrap-linesмежду записями в несжатом виде слишком большой интервал (см. стр. 2). Я пытался \override #'(baseline-skip . 2)безуспешно. Основная проблема с этим подходом заключается в том, что разметка внутри счета по-прежнему сталкивается с текстовыми ключами из-за сжатия: github.com/rualark/MGen/blob/master/MGen/configs/ly2/debug/… github.com/rualark/MGen/blob /мастер/MGen/configs/ly2/отладка/…
Ты прав. Я нашел другой возможный подход: вы можете добавить #(define page-breaking ly:page-turn-breaking)в \paperмакрос. Это позволяет Lilypond переключиться на другой алгоритм разрыва страниц. Возможно, это помогает в некоторых случаях. Проблема сжатия до сих пор толком не решена. Что касается расстояний: попробуйте добавить \override #'(baseline-skip . 2)перед каждой \wordwrap-linesкомандой. А расстояния внутри партитуры, наверное, можно регулировать с помощью отступов?
Я обнаружил, что добавление #(define page-breaking ly:page-turn-breaking)в \paperмакрос полностью решает проблему. Я читал об этом варианте раньше, но даже не пробовал, потому что это было непросто. Очевидно, что есть ошибки , optimal-breakingкоторые minimal-breakingдают плохие результаты для этой тестовой оценки. К сожалению, page-turn-breakingимеет тенденцию генерировать больше страниц, потому что оставляет больше пустого пространства, а иногда и много ненужного пустого пространства, как на странице 1 в этом примере:
Пример слишком большого пустого места на странице 1: github.com/rualark/MGen/blob/master/MGen/configs/ly2/debug/… github.com/rualark/MGen/blob/master/MGen/configs/ly2/debug /… Выглядит намного лучше с optimal-breaking: github.com/rualark/MGen/blob/master/MGen/configs/ly2/debug/… Это очень неудачно, потому что один метод чрезмерно сжимает, а другой чрезвычайно разреженный
И minimal-breakingимеет тенденцию давать наиболее сжатые результаты без сжатия, пока не выйдет из строя с тем же тестовым примером выше - с тем же результатом чрезмерно полного сжатия. Вот пример лучших minimal-breakingрезультатов: github.com/rualark/MGen/blob/master/MGen/configs/ly2/debug/…