[smufl-discuss] Re: Notehead Metrics

[Glenn Linderman]

On 12/24/2014 3:10 PM, Daniel Spreadbury wrote:
> Glenn wrote:
>
>> Not sure if my note regarding the suggestion for a unison whole notehead
>
>> came through.
>
> I don't think it did: please resend your suggestion when you get the
> chance.


OK, I did. And also a followup about leger line width in BravuraText,
which had an attachment. The blurb at the bottom of each message is long
enough it ought to also say "no attachments" since the list manager
doesn't bounce them, but apparently just sends them to the bitbucket.

>> So if I properly created a formula from your instructions, given the
>> point of placement of the note ( X, Y ) I should place the SW point of
>> an upward stem at:
>>
>> ( X + stemUpSE[0] - stemThickess,  Y + stemUpSE[1] )
>>
>>
>> When I did so, at larger sizes, it protruded awkwardly from the note.
>> So I "fiddled around" with the stemUpSE[0] numbers, until I got a stem
>> that was tangent to the note at the attachment point.
>
> This is a bit weird. I don't believe we're specifying the wrong point in
> the metadata, because we don't even calculate the stemUpSW point!

Sure, specifying stemUpSE makes the most sense, but during engraving you
need either stemUpSW or stemUpSCentral, in order to place the line. And
stemUpSW[0] is exactly where the flag should be placed to, so it makes
most sense to calculate the StemUpSE, and that's also what is needed
when drawing downward stems and flags. So that's what I was trying to
achieve to place the stem.

> You can
> see the points we have defined for noteheadHalf in this picture:
>
> https://imgur.com/vM2sqqW
>
> I place these anchors by hand in the font application, and they are
> exported by way of our Python scripts as coordinates in font design units
> (Bravura is 1000UPM), then converted into the stave space values by
> dividing by 250. We don't impose any limitations on the precision of the
> resulting floating point number.

And dividiing by 250 should give a number that has no more than 3
decimal places, and your numbers have 3 decimal places. So there should
be no loss of accuracy, if the stemUpSE number starts out accurately.
The picture you show indicates that the stemUpSE point is an anchor
point on the curve, so it shouldn't move with varying resolution, as I
was speculating might be a possibility.


> We're not using these metadata directly in our renderer yet, though, so it
> is possible that something is going wrong. Are you able to share an
> example code snippet and/or SVG?


Yes, although it took me a little while to extract a self-contained
example.  Here is a link: http://nevcal.com/temporary/stem-align.html

Now for testing you should save that file locally, and find the first
instruction in the file that says "font-size: 23pt;"  This is the
primary scaling instruction... raise or lower it and redisplay to see
the effects at different sizes.  The top note uses the metadata number,
and the bottom note uses my empirical number. Those numbers are encoded
in the definition of my "notehead plus stem" SVG <g> items, called
"quspec" and "quadj"... the numbers there are in font design units, and
have the stem width subtracted from them.

The reason I started it at 23pt, is that this is the smallest size at
which I can visually detect the problem. Below that, I can see no
difference in the rendering on screen, although I wouldn't swear that
there isn't one.

For all font-sizes above that, I can see a difference, and it gets worse
with size.

With this smaller example, I'm able to zoom higher than I did with a
larger one, and I saw that at 3000pt and up, a little bit of effect I
got with the numbers from the metadata, and so I've adjusted my number
again at 5000pt, and it seems to work down to 10pt still.  The current
number is 1.448 for noteheadBlack.  This still is deficient and 9000pt,
though. Much beyond 9000pt, and the browser displays gibberish, so that
seems to be about the limit of testing.  When I adjust the number to
look good at 9000pt, it starts sticking out from the side of the note at
lower sizes, which looks goofy in a different way than the numbers from
the metadata.

I think I'll run this test with a half note also, to get a better number
for it.... 1.484 is my conclusion from
http://nevcal.com/temporary/stem-align-half.html

After watching the way things behaved up to 9000pt, and after seeing in
your picture of the control points from the font design how precisely
the anchor point was placed in the font, I generated one more
speculative explanation for why the metadata number seems to be off...
but again, I am a programmer with a math degree, not a font designer, so
I may be all wet.  I'm wondering if you both stroke and fill your
lines... and if half the width of the stroke might be to the right of
the anchor point like it is with stroking SVG lines/curves... and that
if the stroke width of the stem is different than the stroke width used
for the notes, then there would never be a single number that would work
perfectly for all font sizes... it would have to be a formula including
a term that scales with the font size.

If it is that sort of thing, it may explain some of the problems with
other scalable font and vector drawings that I have seen, both in music
and other complex diagramming... it looks good at one size, but when
scaled significantly, it falls apart... lines separate or overlap or
protrude, and similar effects.  Perhaps stroke width is a bad
simplifying assumption... perhaps lines should be filled rectangles,
rather than strokes. This would, of course, approximately double the
work to draw a line, as it would need twice the control points.
Similarly for other curves. But it would force people to be more
concerned about the edges than the central part of a line/curve.

I don't know if you can correlate the empirical numbers I came up with
at 5000pt with your stroke width or other concepts that may be used in
the design, but if you can, that would greatly aid in understanding the
problem and perhaps confirm or deny my speculations.

At least the numbers I have now work well from 10-5000pt, and don't look
too bad as far up as 9000pt.

#############################################################
This message is sent to you because you are subscribed to
  the mailing list <[hidden email]>.
To unsubscribe, E-mail to: <[hidden email]>
To switch to the DIGEST mode, E-mail to <[hidden email]>
To switch to the INDEX mode, E-mail to <[hidden email]>
Send administrative queries to  <[hidden email]>