Up-stem notes in Emmentaler font have stem a tiny bit too far to the left
When printing directly from MuseScore, up-stem notes in Emmentaler font have stem a tiny bit too far to the left:
Only in Emmentaler, not in Gonville and only if printing direclty, not when saving as PDF and then print that.
Seen with 725882f, on Win XP pro with HP PhotoSmart 2610 and Win7 with Canon LBP-810.
See also http://musescore.org/en/node/20835
Comments
I can't reproduce with a PDF printer. I don't have a printer at hand yet to try with it. It could be a problem of resolution in the printer driver. Is the printer setup in a low resolution mode?
I didn't change the printer settings, so it was in 'normal' mode. I have the choice of Draft, Normal (fast), Normal, Optimal and Maximum Resolution.
Just now I printed in in Max. Res.: same result
Try attached score, I have increased the space setting by quite a bit
Confirmed issue with 6be7450, Windows 8 64-bit, an a networked HP LaserJet 4250. PDF export looks OK.
OK. Printing this one with PDF creator, and I can't reproduce either... It's probably something very specific. With the same printers, you don't have any problem with MuseScore 1.3?
No problem with 1.3
No issues in 1.3 either.
In fact, I obtain quite a similar result even in MuseScore on-screen display without any pirinting involved, if looked at high zoom:
NOT FOUND: 1
Note that, when up-stem, both the half and the quarter note heads extend slightly to the right of the right edge of the stem (or the stem is slightly displaced to the left), while they align rather well to the left edge of the stem when down-stem.
Has this something to do with data in the
fonts/mscore20.xml'magic' file?M.
Things are getting more and more complex. I looked at the font data and at the mscore20.xml data.
Note on units
1) While not documented anywhere, from some data easy to understand (like the height of a C clef, which is 4sp high in MuseScore, 1024 FU high in the font and 20 (pt?) high in the .xml file), I am convinced that sizes (<attach> and <bbox> tags) in mscore20.xml are in pt, for a design font size of 20pt. 20(pt) is then the height of a 5-line staff and 5(pt) the height of a spatium.
2) As the mscore-20 font design height is 1024 FU, this gives the following equivalences:
1024FU (in the font) = 20pt (in the font.xml file) = 4 sp (in MuseScore)
1pt = 51.2 FU
1sp = 5pt = 256 FU
Data
Let's look at the four glyphs to which a stem can be attached. Current situation:
From these data, 'expected' .xml widths can be computed (FU width / 51.2) and 'working' .xml widths can be found by fine tuning them and recompiling until stems match the rightmost position of the glyph:
The middle point of the deltas is ca. +1.44%, which is too much to be simply a consequence of rounding errors (which statistically could result in increase as well as in decrease). It looks like:
the final, actual width of a glyph is slighly wider than the font design (in general, 1.0144 times wider).
Note that this does NOT seem to affect heights, only widths.
Question
I don't know how to go ahead in this path. Does anybody know more and/or has suggestions?
Notes
1) By "glyph widht" I used the Y coordinate of the rightmost point in the glyph; this can be different from the glyph advance; in fact, it IS different in the two "breve" glyphs (round and squared).
2) This difference should advise to use the <attach> Y datum to compute the stem position, rather than the <bbox> width datum, as done currently.
M.
Great research. Could you mention whcih mention of Qt + which OS you carried it on.
Oooops: Linux Mint 14, Qt lib 4.8.3 (default on my distro).
This is a similar summary for Gonville. As Gonville lacks the square breve, there are only 3 relevant glyphs. Also, as the Goville font design height is 1000, rather than 1024 as for Emmentaler, the conversions between units are:
1000 FU (in the font) = 20pt (in the font .xml file) = 4sp (in MuseScore)
1pt = 50 FU
1sp = 5pt = 250 FU
M.
Fixed in 38afa5ee40
Automatically closed -- issue fixed for 2 weeks with no activity.