Formatting order needs to be rethought

[Silverwolf90]

Ok so now that we'll soon have staves set on elements before formatting, we'll be able to freely convert between pixels/staff spaces and do all positioning of elements in Formatter#format and the various formatting hooks.

Unfortunately, we still have some major issues around this:

1. We can't format modifiers (ie: articulations) vertically until stem tips have been finalized
2. Stem tips can't be finalized until beam slopes have been calculated
3. Beams slopes can't be calculated without x positions on the notes
4. We only have x positions after all modifiers have been formatted, and the tick contexts have been formatted (This is why stem tips are currently calculated in Formatter#postFormat)

I'm fleshing out some thoughts on this, but they'll likely be pretty radical :P

[Silverwolf90]

Well here it goes:

How about we rip out all formatting-centric code and start from scratch with a more rigorous set of test cases.

I realize this is not a practical solution, but since formatting is really naive and doesn't correctly consider dependencies between objects, I think it's flawed at a fundamental level and a complete redesign is the ideal solution.

Ignoring this issue of dependencies, it's not like formatting in VexFlow is robust in the first place and it doesn't even include spanning elements (eg: hairpins, tuplets) nor does it include higher-level formatting (ie: multiple staves/measures) . And as I've mentioned before I find the ModifierContext difficult to understand.

[0xfe]

It would be a pretty big effort. Want to write up a rough design proposal in the wiki? (we could iterate on that)

[Silverwolf90]

Yeah, I'll do that at some point. It seems like it's a lot more work than it actually is. While every element has its own formatting hook, this is unnecessary. Yes, some groups of elements have specialized formatting like dots and accidentals. But after these have been formatted as a group they remain static and the group as a whole can be treated as a single element. As a result, a single formatting algorithm that does advance-by-width or an advance-by-height is probably sufficient for all single-point modifiers (this is a slight oversimplification since positions within the staff might need refinement, but this is just detail).

Basically, we should format by direction (ie: left, right, top, bottom), not by element type. This is simpler, less opinionated, and more flexible, because now the order of elements (ie: if a fermata should appear above or below an annotation) can be arbitrarily different for each direction.

So a really coarse order would be:

• left modifiers
• right modifiers
• notes
• top modifiers
• bottom modifiers

[gristow]

Just a word to say, @Silverwolf90, that your idea of an advance-by-width/advance-by-height algorithm makes a lot of sense and seems promising intuitively to me. (It matches how I was taught to do manuscript by hand in college, anyway!), and I'd be curious to see an idea of how that might be fleshed out.

[0xfe]

The ordering sounds good, though where would the logic for modifier-specific formatting belong? E.g., accidental rules. Part of the reason for the element-specific hooks was so new elements can encode their own internal rules.

[Silverwolf90]

Good question, not sure. I'd guess that they'll mainly remain as is, just that we hook into them a different way. The formatting hooks for things like Ornament and Annotation, which are nearly identical, are the one's that will get factored out because they can be handled generically.

[SalahAdDin]

@Silverwolf90 what's about it?