More issues with F27.1: shifted beams

[sPretzel]

Thanks for clarifying, wessmusic.
I wonder why motet sees the issue in Finale but not in PDF (though that's for F2014.5 Windows).

This beam-stem problem seems to be yet another problem with F27.1 Win for which there is no workaround.

[wessmusic]

This sounds like Finale is doing fixed-point (integer) arithmetic with not enough precision.

To my greatest surprise this assumption is not very right, although at first I thought like you, Motet.

I propose to conclude this discussion by sending an informed appeal to MM that the above-mentioned problem exists. The only thing I can say for sure is that the thickness of the stem was not taken into account when programming the stem connection. It is true that in the Euclidean Elements the imaginary line has no thickness. I mention it on purpose. Because the last test I did, shows that stems and note heads, as well as stems and beams connect perfectly, if this (Euclidean) condition is met!

The mistake that has been made is that the Win version programmers have not considered that the connection should be calculated including the value of the stroke (i.e. stem thickness), not the imaginary point at which the components joint each other. This is an elementary linear equation. Hence, the stem should be moved 1/2 of its thickness into the notehead, depending on whether it is positioned from the left or right side of the note/beam (eventually flag!).

This condition was obviously overlooked, but the strange thing is that more than 2 (or already 3) years since version 26 went on sale (and now 27), no one has paid attention to this problem and only recently sPretzel, who in this regard reported other problems (in previous posts), raises this pressing issue.
________

In my last experiment (using Win Finale 27.1) I entered the thinest possible thickness and re-edited it to 0.001 mm — the minimum value in Illustrator. You can check the enlarged image at 64000% (below), ie. the note head (when printed) would look app.1,425 meters/4,674 feet wide, using as a guide 7 mm staff.



On the screenshot you can clearly see that the touch (stem connections) is accurate, but only according to Euclid!
In my opinion, this topic does not need more analysis and tests, because there is not more place for speculations, but an active attitude, because the examination of the situation is insignificant and awaits a satisfactory solution.

I believe that some of the Win users would write a complaint with a request for update of the Win version in this particular part.
There are also other serious weaknesses that need to be addressed, but they are not the subject of this discussion.
I want to believe that our observations and attached examples can be used as a reasoned starting point for MM.

I hope this helps.

[sPretzel]

Regarding the beam-stem horizontal offset, it is not related to stem thickness. Changing the stem thickness does not change the offset (or not much, I've only eyeballed it in Finale).

[dtoub]

Wow. Interesting and very concerning discussion.

I would not assume MM looks at these forums but I do suspect they do. But unless they weigh in, it can't be determined. I miss the days of Coda Technologies or even earlier in MM when many of us had productive back and forth with folks like Michael Johnson and others who are no longer with MM and/or who do not personally weigh in on the forums. Given that the dude who is the main project manager for Dorico comments all the time on their forums, it's disappointing that MM doesn't weigh in anymore on at least the official Finale Forum that they maintain. As mentioned, they used to.

What I'm going to suggest is that this get posted as a support request to MM. They do respond within a few days (I've been sending them a lot of things in the past month or two and they have been responsive, in some cases replicating the issues and working on a fix). That is just going to be the fastest and most direct/productive way to handle this.

[sPretzel]

I'm seeing this kind of horizontal shift elsewhere too, as in barlines. I see it for the left barline at the beginning of the staff (though I don't see it for the last barline of the staff).

[RVS Lee]

Re: Wessmusic's suggestion that the error is the result of calculations not taking into account the width of the stem line stroke... Isn't the Euclidean 0-width line the center of the physical stroke? Wouldn't that mean the beam is aligned to the center of the stem? If so, I would have expected stems to 'straddle' the beam at each end. However, what we see is a rightward offset at both ends. (Indeed, stems 'straddling' each end of a beam should create have a perfectly acceptable visual image, at least for flat beams.)

[BuonTempi]

Robert Puff mentions this problem in his blog.

https://www.rpmseattle.com/of_note/fina ... pressions/

He says he fixed it by installing an alternative type-rendering engine:

It bothered me enough that I looked up ways of dealing with poorly rendered text in Windows, and came across two freeware programs that replace Windows’ ClearType font rendering engine with the same Free-Type engine used by MacOS and Linux: GDIPP and MacType. I installed the latter, and now the new font looks great now.

https://www.mactype.net/

though, of course, installing (and relying on) something like this may not be without issues itself.

[sPretzel]

Interesting blog post.
Robert Puff // Correction: that blog post was written by Jacob Winkler // links this problem to SMuFL and Windows' font rendering engine. But wessmusic said he sees this problem with Finale 26.3, which doesn't have SMuFL font support.

[motet]

And I see with Finale 2014.5.