The Feta font has a parameter designed to adjust the notehead height. In 2.19.36 it is set to be exactly the staff space + the staff line thickness. I assume that when the ps is converted to type 1 with hinting, it can get infinitesimally bigger.
I have created a new version of the feta font with the notehead height being staff_space + 0.8 * staff_line_thickness. It appears to solve the problem. If this seems OK, I will prepare a patch.
Because 0.95 still showed the problem and 0.8 didn't. I haven't tried to
be any more precise in terms of finding the optimal value. If I knew how to
check the size of the notehead in ems I could find the largest note head
that gives a size of 275 instead of 276. But I don't know how to do
that. Help would be appreciated.
Carl
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Following up with David Kastrup and Paul Morris, I've created pdf files at three different settings: overdone=0, overdone = -.1, overdone=-.2.
Overdone=0 is the current behavior. Overdone = -.1 reduces the notehead height in metafont by 10% of the staff line thickness. Overdone = -0.2 reduces the notehead height in metafont by 20% of the staff line thickness. As can be seen, the notehead still extends beyond the staff line at overdone=-.1
The size changes are so slight that I can't see them (and I doubt anybody can) when the note is on a staff line; it's only by comparing the overlap on the staff line when the note is in a space that we can see it.
I've now done a closer look at the issue; it is indeed a rounding issue, as far as I can see. mf2pt1 doesn't produce extremum outline points by itself; it is FontForge which does that. The vertical coordinates of the extremum points in notehead.s2 are ±137.5 units; however, FontForge then rounds the coordinates to integers, making them ±138 units, which is the largest delta possible to the unrounded coordinates. I guess this is exactly the observed effect.
So: LGTM to Carl's change.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the careful review, Werner. After reading your review, I can see that my patch is, in fact, a hack.
Feta has built into its parameters a process for rounding stafflinethickness toward the center. I'm currently trying a patch with stafflinethickness_rounded used to determine noteheight instead of stafflinethickness. I am hopeful this will fix the problem without any magic numbers.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Greetings Carl,
This reminds me of the old (unrelated) 1/72.27 rounding problem: http://lists.gnu.org/archive/html/lilypond-devel/2007-07/msg00075.html
Since you’re adding a regtest, would it be advisable to make the regtest render several staves in various sizes? Or would increasing the staff-size (and therefore the rendering precision) defeat the purpose?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't believe that there is any necessity to display at various staff sizes. The default staff size has an odd number of points in the staffspace * staffline interval, so when the notehead height is divided in half, there is an extra .5 hanging around that rounds to 1. We can never be worse than that. If we have an extra 0.8 hanging around and round to 1, there is less growth. if there is an extra .4 hanging around and rounds to 0, we have a little bit of shrinkage, which is undetectable absent a comparision with a staff line.
Since the current condition is the worst possible case, I think it is fine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2016-03-16
Patch: countdown --> push
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2016-03-16
Patch counted down - please push
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
FWIW, it's the same as far back as 2.12. A very slight extension above the staff line can also be seen in highly magnified PDF versions.
The Feta font has a parameter designed to adjust the notehead height. In 2.19.36 it is set to be exactly the staff space + the staff line thickness. I assume that when the ps is converted to type 1 with hinting, it can get infinitesimally bigger.
I have created a new version of the feta font with the notehead height being staff_space + 0.8 * staff_line_thickness. It appears to solve the problem. If this seems OK, I will prepare a patch.
Why 0.8 and not, say, 0.9?
On Feb 14, 2016 3:51 AM, "Werner LEMBERG" wlemb@users.sf.net wrote:
Because 0.95 still showed the problem and 0.8 didn't. I haven't tried to
be any more precise in terms of finding the optimal value. If I knew how to
check the size of the notehead in ems I could find the largest note head
that gives a size of 275 instead of 276. But I don't know how to do
that. Help would be appreciated.
Carl
Following up with David Kastrup and Paul Morris, I've created pdf files at three different settings: overdone=0, overdone = -.1, overdone=-.2.
Overdone=0 is the current behavior. Overdone = -.1 reduces the notehead height in metafont by 10% of the staff line thickness. Overdone = -0.2 reduces the notehead height in metafont by 20% of the staff line thickness. As can be seen, the notehead still extends beyond the staff line at overdone=-.1
The size changes are so slight that I can't see them (and I doubt anybody can) when the note is on a staff line; it's only by comparing the overlap on the staff line when the note is in a space that we can see it.
Thanks,
Carl
To my eye, 10% is good - it stops the noteheads hitting the line edges, but keeps them nice and tight.
I cannot see any Rietveld to test against
I'm sorry -- git-cl didn't work so I did things manually and missed that.
Here's the Rietveld:
https://codereview.appspot.com/284650043/
Carl
I've now done a closer look at the issue; it is indeed a rounding issue, as far as I can see. mf2pt1 doesn't produce extremum outline points by itself; it is FontForge which does that. The vertical coordinates of the extremum points in
notehead.s2are ±137.5 units; however, FontForge then rounds the coordinates to integers, making them ±138 units, which is the largest delta possible to the unrounded coordinates. I guess this is exactly the observed effect.So: LGTM to Carl's change.
Thanks for the careful review, Werner. After reading your review, I can see that my patch is, in fact, a hack.
Feta has built into its parameters a process for rounding stafflinethickness toward the center. I'm currently trying a patch with stafflinethickness_rounded used to determine noteheight instead of stafflinethickness. I am hopeful this will fix the problem without any magic numbers.
Trying after installing ca-certificates
http://codereview.appspot.com/283550043
passes make, make check and a full make doc.
There are a lot of reg test diffs here:
https://drive.google.com/open?id=0B9nZ5LHV2Ds6cWc0T2NpTnpkR3M
This is about 30mb to download.
Patch on countdown for March 16 th.
Reg test diffs here:
https://drive.google.com/open?id=0B9nZ5LHV2Ds6cWc0T2NpTnpkR3M
This is about 30mb to download.
Greetings Carl,
This reminds me of the old (unrelated) 1/72.27 rounding problem:
http://lists.gnu.org/archive/html/lilypond-devel/2007-07/msg00075.html
Since you’re adding a regtest, would it be advisable to make the regtest render several staves in various sizes? Or would increasing the staff-size (and therefore the rendering precision) defeat the purpose?
I don't believe that there is any necessity to display at various staff sizes. The default staff size has an odd number of points in the staffspace * staffline interval, so when the notehead height is divided in half, there is an extra .5 hanging around that rounds to 1. We can never be worse than that. If we have an extra 0.8 hanging around and round to 1, there is less growth. if there is an extra .4 hanging around and rounds to 0, we have a little bit of shrinkage, which is undetectable absent a comparision with a staff line.
Since the current condition is the worst possible case, I think it is fine.
Patch counted down - please push
Pushed to staging as 25ff85f..87eb2f9