Adjacent breve and longa noteheads incorrectly positioned in chord

If we add another chord in voice 2 as reference point:

NOT FOUND: 1

would you expect:

A) the note head on the left side to move further to the left:

NOT FOUND: 2

or
B) the two note heads on the right side to move further on the right:

NOT FOUND: 3

Funny you say that!

For how much I like centred note heads, I would have said that, if there are note heads on both sides of the stem (actual or potential), stems should be aligned. Whence B !

Anybody else has an opinion?

Thanks,

M.

I think the question belongs here, as answering this question is important for knowing in which direction to solve the issue.

I had a look at this and it looks to me much less simple than it may seem.

1) The 'hanging' width of the breve head is different from the 'total' width, but both values are needed for proper horiz. alignment: the latter when there are heads on one side only of the stem (to centre them), and the former when there are heads on both sides of the stem (to overlap them). This might require some kind of deepish, internal re-factoring.

2) The whole matter is complicated by some (strange?) interaction between flipping and mirroring: for instance, when a chord is (automatically) flipped upside-down (say, a chord in the lower part of the staff and in voice 2), it is also mirrored left-right. I don't know if this is correct or not.

Given:

*) the above complexities,
*) the great rarity of chords with seconds of brevis (or longa) length,
*) the fact that, in those rare cases, it is possible to adjust the position of individual note heads manually (cumbersome, but possible),

I am inclined to left the matter as it is.

Perhaps it might make sense to label the issue as "minor" and/or close it as "Postponed", but I'll leave this for lasconic or Werner to decide.

Thanks,

M.

My previous post, #7, does not refer to a specific choice for solving the issue and it applies to practically any solution: A), B) or other.

I think that, with enough resources, any problem can be corrected.

But I believe the issue to be so rare that its priority is rather low (and the solution might be relatively complex). So, I proposed to close it as "Postponed".

(I work only on Renaissance and early Baroque music and I use breves every day, but I never stumbled on this case in years! And the great majority of users never use breves!).

M.

Fixed in 8fbfaba3f6

Miwarre was right - it was a surprising deep change for such a minor issue. But the other layout changes I made recently set the stage to make this possible. And addressing the core problem with breve mirroring also allowed a number of other issues to be fixed having to do with mixed notehead sizes. So it was time well spent.

However, I should note the fix I put in place results in the breves being separated - the vertical bars are not shared. To actually overlap the breves by just the right amount to share bars would require knowledge of the internal structure of the glyph that we just don't have. I guess in 1.3 there must have been a hardcoded magic number in place to work with Emmentaler, but we need to support multiple fonts now.

Given the extreme rarity of the situation, and the lack of supporting evidence beyond one example in Gould to even suggest they *should* share bars, I consider the matter closed. Here is the result:

BTW, the bars overlap very slightly on my system (and hence in the generated images) for the same reason that stems on upstem notes are slightly misaligned on my system - Qt seems to report a slightly-too-small bbox value for the notehead. Other systems apparently show slightly different results.

I'm glad this brought you to solve a number of other points; points which are probably more frequent and relevant than this one! So, kudos!

However, I don't think this specific issue is really 100% solved. About the non-overlapping breve side lines, I personally could not care less (no matter what the lady behind the bars has to say): I have never stumbled upon a breve chord of seconds and I do not expect to meet one in the foreseeable future...

However, the vertical alignment of breves with other chords is not what I would expect. Honestly, I cannot say which would be the 'right' solution; I can only say that some cases look strange. For instance, the following (admittedly rather contrived) example:
NOT FOUND: 1

• Meas. 1: I would expect the stem of half chord to line up with the (virtual) stem of the breve chord. Note that the same geometry (one note head hanging on one side in one chord and one note hanging on the other side in the other chord) happens with a semibreve chord + a minim chord as well; which is something one can actually find in music.
• Meas. 2: longae actually share side lines (and stem)! Great! But why this difference? Note that I can perfectly stand the difference itself (as I expect to never actually meet cases like these in 'real' music); I'm only wondering if this difference hints to some unmanaged case in the code...
• Meas. 3: this is a case one can potentially meet in 'real' music (if, for instance, the minim G is tied with a note in the previous measure); to my eye it looks strange; would I expect the minim chord to be centred with the breve chord? Perhaps.
• Meas 4: looks fine! But I think this explains the visual 'unbalance' in meas. 3: the 'hanging' second in meas. 3 is added to the 'balanced' stack as visible in meas. 4 without compensation (then well, should I prepare such a case for publication, even in meas. 4 I would probably shift the minim chord 1/10 sp to the left, for a better visual centring, but this is another level of paranoia...).

That said, I can only repeat: we are dealing with corner cases, which the user dealing with post-Renaissance music will never meet and even the Medieval and Renaissance aficionado is very unlikely to meet outside of theoretic treatises and can easily adjust by hand in those vvvvery few cases.

So, there is no real need to 'solve' these details. I'm only quoting them in case they ring some bells to the developers about unmanaged cases or 'shortcuts' in the code.

Thanks!

M.

P.S.: on another side, I don't like the breve rests across the staff line in meas. 1 and 2: they should 'hang' or 'sit'; but this is another issue, as I said.

Thanks for your comments, but unless rules for breves differ from other note values, these example are actually all correct. Consider if the breves had been minims, or any other note value using stems. Stems have a "normal" and "wrong" side. And chord involving a second will have notes on both sides. The rule for aligning such chords is, align the note on the "normal" side. And indeed, this means if the upper and lower voices both involves seconds, there is a note "sticking out" on both sides. Gould is clear enough in her examples that this applies to whole notes as well as to stemmed notes, and I can't see any reason to make an exception for breves. Of course, if any individual compser/arranger/publisher wishes to override this and align things differently, that can be done manually, but I think the defaults are correct.

Regarding the stems on the longae - that too is deliberate. The rule is for stemmed notes to always share a stem, and the width of the stem *is* known, so performing this alignment is easy. Longa thus share the same code as minim and crotchets. For that matter, even breves share the same code. The main distinction is whether the note has a stem or not, not note length. Take a pair of minims a second apart - these will share a stem - and then hide the stem. You will see the noteheads separate (this is actually shown in my vtest). The only special casing is for whole notes, whose shape allows their bboxes to overlap slightly (the code assumes they can overlap by a stem width) without actually overlapping ink.

So to me, the only issue with you example is the vertical position of the rests, which is totally separate. If that's definitely wrong and not just personal preference, file it and I'll take a look. I can't imagine that would be a difficult change.

Automatically closed -- issue fixed for 2 weeks with no activity.