gregorio-project / gregorio

The Gregorio Project
http://gregorio-project.github.io
Other
162 stars 43 forks source link

Multiline initial #1491

Open rpspringuel opened 4 years ago

rpspringuel commented 4 years ago

With some significant refactoring and bug-fixing along the way, this PR is about supporting initials of an arbitrary number of lines explicitly.

Right now I've got two "modes" for doing so:

  1. manual - each line which wraps the initial must be manually ended in the gabc (z or Z). This is the way 2-line initials are currently supported and so is set as the default.
  2. semi-manual - the last line that wraps the initial must be manually ended in the gabc. Should be slightly easier to use, but can lead to the initial overlapping full width staves when the manual line ending is far too early.

I'd like to make something which is fully automatic, but have yet to come up with a good way of tracking the automatic line endings. I've identified a point in the post_linebreak function where the line numbers are increasing as expected, but I'm not sure how, or even if, I can resize the lines on the lua side. Hence, I'm posting this here for some feedback.

Note: This still needs some documentation work and so is not ready for merge.

rpspringuel commented 4 years ago

Hmm... Another thing I noticed that still needs fixing:

Right now the placement of the initial is based purely on the height of the first line (multiplied by the appropriate number of lines to lower the initial when the initial is wrapped by more than one line). Since the subsequent lines could be slightly taller or shorter, this means that 2 or more line initials may be slightly higher or lower than they ought to be (in the test case, they're all higher). Ideally I should access the actual heights of the second (and later) lines when they wrap the initial.

rpspringuel commented 3 years ago

I've done some more research on this and am rapidly coming to the conclusion that implementing the fully automatic multi-line initial may require changing how the lines are drawn: going from using \localleftbox to having post_linebreak do it. That's a bit beyond my current skills, but I'll keep plugging away at it.

rpspringuel commented 3 years ago

Full automation is going to require a full rewrite of how line drawing is handled, so I'm going to separate out that feature for now.

@henryso what's the easiest way to access the total height of a specific line of a score (as determined on the previous run)?

rpspringuel commented 3 years ago

I'm working on accounting for actual line heights and came across a "magic number" in the \gre@calculate@additionalspaces: 15750 sp (it also appears in \gre@calculate@glyphraisevalue).

Based on how it's being used, it appears to be like it's supposed to be the amount of additional space to add for excessively high/low elements. Does any one know why this calculation isn't using noteadditionalspacelinestext? @henryso @eroux? The value is not exactly the same (once scaled for the default 17 staff size) but is really close (0.1436cm vs the 0.14413cm in notesadditionalspacelinestext).

rpspringuel commented 3 years ago

After some painstaking traces through the git history concerning this magic number and noteadditionalspacelinestext it appears that the magic number was introduced when additional space above the lines for high notes was implemented while noteadditionalspacelinestext was introduced when additional space below the lines for low notes was implemented (the name being a variation of spacelinestext: the nominal distance between the lines and the lyrics baseline). It would thus appear that this magic number should be replaced by a new distance noteadditionalspaceabovelines (the name being a variation of spaceabovelines: the nominal distance above the lines). If there are no objections to this solution, I will implement it as part of this PR.

rpspringuel commented 3 years ago

Getting the line height adjustments for variable line heights right is proving much harder than expected. @henryso, can you look at the code in my most recent commit (39d9496) and see if I'm doing anything blatantly wrong. Things aren't lining up as I would expect them to and I'm trying to figure out if that's do to my not understanding the way the line height information is stored and used, or if it's because there's something more subtle in the way the spacing around lines works.

henryso commented 8 months ago

@rpspringuel I realize this is way late. I've been off the scene for a while due to family issues. I looked at your commit, and I can't tell why it's not working. Maybe it's some collapsed measurement in TeX, but I don't think I understand TeX at that level to give a good answer.