Vexflow: bad dots horizontal position for note(with flag?)

[sug1no]

please try:
https://jsfiddle.net/8vdxkfpm/1/

[gristow]

Yep, this is definitely a bug. I'm surprised we haven't caught this before. As you suggest, it's only an issue with a flag. I may have time to tackle this at the end of this week -- though if anyone else wants to tackle it, please go for it!

[sug1no]

• dot.js using note.getExtraRightPx() to calc shift value.
  https://github.com/0xfe/vexflow/blob/master/src/dot.js#L29

shift = (props.displaced ? note.getExtraRightPx() : 0);

• stavenote.setExtraRightPx() check if note hasFlag or not.
  https://github.com/0xfe/vexflow/blob/master/src/stavenote.js#L851

this.setExtraRightPx(
      !this.hasFlag() && this.displaced && this.stem_direction === Stem.UP
        ? this.getGlyphWidth()
        : 0
);

• !this.hasFlag() added by the following commit:
  https://github.com/0xfe/vexflow/commit/acdcfed723435c127d277f231420a4203675812c

[0xfe]

Good find! That's my commit. The comment at the top says:

// For upstems with flags, the extra space is unnecessary, since it's taken
// up by the flag.

... which implies that the space for the flag is already accounted for.

But we care about note displacement regardless of flag existence. I think this might be a straightforward bug to fix in dot.js, however I'd like to find the right logic fix in setExtraRightPx because it's probably affecting other elements too.

[sug1no]

Behind Bars: p55:

Every notehead in a chord must take a duration dot. Vertically align the dots after the chord.

Is this a bug or spec of vexlow?

[0xfe]

Not spec, and I'm fine with that proposed behaviour if @gristow and @mscuthbert agree. :-)

[gristow]

Yes — I agree, aligned dots would be better.

[mscuthbert]

yes -- new behavior fits Behind Bars. Should also have checks at some point for unison noteheads and dots for multiple simultaneous parts -- each of which have unique behavior that eventually we'll want. @sug1no is on a roll!

[mscuthbert]

(I'm trying to think if there is anything in Vexflow spec that has been agreed upon to disagree with Behind Bars, except the default gray color of the staff [which I really like]. I think that in general anything that conflicts with published notation books can be treated as a bug as a default assumption)

[sug1no]

@mscuthbert san:

except the default gray color of the staff [which I really like].

It means ?:

https://github.com/0xfe/vexflow/blob/557fe7db012a447789f2879b7380cd35dcdaf607/src/stave.js#L41

[mscuthbert]

yes -- I think this is one of the best adaptations that Vexflow has done for internet music publishing and it makes the notation really stand out. I believe Edward Tufte advocated for this too, but it has been impossible before the screen to do this well.

[sug1no]

filed #664.