Re: font: change breve vertical lines (issue4748044)
2011/7/29 : >> Aww, i was so proud of this code... > > :-) > >> Frankly, i don't think we will gain anything from defining >> a global value. The algorithm i wrote is a bit complicated, >> but i thinks is easier to understand than what you suggest >> (if i understood your suggestion correctly). It keeps >> things in one place instead of values flying all around (at >> least that's how i see it). > > Just to make it clear: Let's call my hypothetical variable > `line-height'. Then we would have in file `feta-noteheads11.mf' the > line > > line-height := 10 > > in file `feta-noteheads13.mf' the line > > line-height := 15 > > etc. (the values are just for demonstration purposes). Not really > complicated or confusing IMHO. I understand. However, i prefer having it in one place. After all, it's not needed anywhere else, nothing depends on it (unlike design_size). > Just imagine that your algorithm yields the value 13 for size 13, but > you want to use 15 since this looks better. How would you deal with > that? On the other hand, if you wanted to make a systematic change (i.e. increase value by 2 everywhere), using algorithm is cleaner. > Add another exception to your algorithm, or redesign it completely? Probably redesign. Everything that can reasonably be described by an algorithm should be done so (in my opinion). If an algorithm exists, it explains why things are the way they are; it can also be applied in cases not originally predicted by the author. In this case i think the algorithm approach is reasonable, but I don't feel extremely strongly about that. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: font: change breve vertical lines (issue4748044)
Aww, i was so proud of this code... :-) Frankly, i don't think we will gain anything from defining a global value. The algorithm i wrote is a bit complicated, but i thinks is easier to understand than what you suggest (if i understood your suggestion correctly). It keeps things in one place instead of values flying all around (at least that's how i see it). Just to make it clear: Let's call my hypothetical variable `line-height'. Then we would have in file `feta-noteheads11.mf' the line line-height := 10 in file `feta-noteheads13.mf' the line line-height := 15 etc. (the values are just for demonstration purposes). Not really complicated or confusing IMHO. Just imagine that your algorithm yields the value 13 for size 13, but you want to use 15 since this looks better. How would you deal with that? Add another exception to your algorithm, or redesign it completely? My concern is that the algorithm decides how the value should look like, instead of doing the opposite... http://codereview.appspot.com/4748044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: font: change breve vertical lines (issue4748044)
A pdf proof file is attached to tracker issue http://code.google.com/p/lilypond/issues/detail?id=1767 The gap in smallest font sizes was reduced according to Bertrand's suggestion, and the line height was increased just a bit according to my friend's suggestion. I don't feel strong about these changes; for me both this version and previous version is good enough (and definately better than current Lily). http://codereview.appspot.com/4748044/diff/1/mf/feta-noteheads.mf File mf/feta-noteheads.mf (right): http://codereview.appspot.com/4748044/diff/1/mf/feta-noteheads.mf#newcode181 mf/feta-noteheads.mf:181: % when there is an interval of fourth. On 2011/07/27 05:03:15, lemzwerg wrote: Wouldn't it be simpler to explicitly specify the line length instead of using such a complicated algorithm? I mean a global variable to be added to the various feta-noteheadsXX.mf files. I know that none of the existing size driver files contain such a variable except the standard assignment of `design_size', but this shouldn't stop you to add something since it would be the logical place to add. Cf. similar control files in other MF fonts like TeX's Computer Modern, which are full of such meta-variables. Aww, i was so proud of this code... Frankly, i don't think we will gain anything from defining a global value. The algorithm i wrote is a bit complicated, but i thinks is easier to understand than what you suggest (if i understood your suggestion correctly). It keeps things in one place instead of values flying all around (at least that's how i see it). http://codereview.appspot.com/4748044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: font: change breve vertical lines (issue4748044)
http://codereview.appspot.com/4748044/diff/1/mf/feta-noteheads.mf File mf/feta-noteheads.mf (right): http://codereview.appspot.com/4748044/diff/1/mf/feta-noteheads.mf#newcode181 mf/feta-noteheads.mf:181: % when there is an interval of fourth. Wouldn't it be simpler to explicitly specify the line length instead of using such a complicated algorithm? I mean a global variable to be added to the various feta-noteheadsXX.mf files. I know that none of the existing size driver files contain such a variable except the standard assignment of `design_size', but this shouldn't stop you to add something since it would be the logical place to add. Cf. similar control files in other MF fonts like TeX's Computer Modern, which are full of such meta-variables. Han-Wen? http://codereview.appspot.com/4748044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
font: change breve vertical lines (issue4748044)
Reviewers: ,
Message:
Hi,
breve glyphs in Feta font need modification.
What is bad now: breves lying between the stafflines form a
hard-to-recognize clump, partly because the corners (marked in orange
here:
http://lilypond.googlecode.com/issues/attachment?aid=1767000&name=breve+dimensions.png&token=be66e1b143abc7ec3429340cd32103e3&inline=1)
are too small. Smaller font sizes and ledger lines intensify this.
Breves lying on stafflines are also not good - too stumpy.
Try printing this for example:
http://lilypond.googlecode.com/issues/attachment?aid=1767002&name=Miserere+current+Lily.pdf&token=63749404ea6a8c2d3447fb4080494627
Here is my homework :)
http://lilypond.googlecode.com/issues/attachment?aid=1767001&name=breve+examples.png&token=3c9237933bb9a936015f36fed35e1936&inline=1
As we can see:
- there is some variation
- majority of breves have lines higher than notehead
- if line height is similar to notehead height, fudge value is negative
or at least 0
Therefore i suggest to:
- make vertical lines higher
- decrease the fudge, especially in small font designs
- increase the gap for smaller design sizes
- decrease the line width in double-lined breves (the glyph looks less
fat then)
Tracker issue: http://code.google.com/p/lilypond/issues/detail?id=1767
I attached a bunch of test files showing differencies to the tracker
issue. If possible, try printing them instead of watching on-screen,
because this issue is quite specific to printed material.
How do you like it?
PS i'll have to cut down on issue descriptions and example researchig...
It takes much more time than writing a patch itself :(
Description:
font: change breve vertical lines
Put breve vertical lines farther apart
and make them longer to increase readability.
Please review this at http://codereview.appspot.com/4748044/
Affected files:
M mf/feta-noteheads.mf
Index: mf/feta-noteheads.mf
diff --git a/mf/feta-noteheads.mf b/mf/feta-noteheads.mf
index
c72522072195d2b9751158e12cd0014a333294c2..e574cc1cf52ff16e456031f634e40b4fab1d7cbd
100644
--- a/mf/feta-noteheads.mf
+++ b/mf/feta-noteheads.mf
@@ -157,24 +157,36 @@ if test > 0:
fi;
-%
-% dimensions aren't entirely right.
-%
-def draw_brevis (expr linecount) =
+def draw_brevis (expr linecount, line_thickness_multiplier) =
save stemthick, fudge;
- stemthick# = 2 stafflinethickness#;
+ stemthick# = line_thickness_multiplier * 2 * stafflinethickness#;
define_whole_blacker_pixels (stemthick);
- fudge = hround (blot_diameter / 2);
+ % Breves of smaller design sizes should have their lines
+ % farther apart (the overlap should be smaller).
+ fudge = hround (blot_diameter *
+ min (max (-0.3, (0.8 - (20 / (design_size + 4)) + .1
linecount)), 0.3));
draw_outside_ellipse (1.80, 0, 0.707, 0);
undraw_inside_ellipse (1.30, 125, 0.68, 2 stafflinethickness#);
pickup pencircle scaled stemthick;
- bot y1 = -d;
- top y2 = h;
+ % Breves of smaller design sizes should have their lines longer.
+ line_length := min (max (0.7, (31/30 - (design_size / 60))), 0.82);
+
+ % Line lengths between 0.72 and 0.77 are not nice
+ % because they are neither separate nor connected
+ % when there is an interval of fourth.
+ if line_length < 0.75:
+ quanted_line_length := min (0.72, line_length);
+ else:
+ quanted_line_length := max (0.77, line_length);
+ fi;
+
+ bot y1 = -quanted_line_length * staff_space;
+ top y2 = quanted_line_length * staff_space;
rt x1 - fudge = 0;
x1 = x2;
@@ -183,17 +195,22 @@ def draw_brevis (expr linecount) =
y4 = y2;
y3 = y1;
+ % Breves of smaller design sizes should have their lines
+ % farther apart.
+ line_distance := (1.95 - 0.008 * design_size) * stemthick;
for i := 0 step 1 until linecount - 1:
- draw_gridline (z1 - (1.5 * i * stemthick, 0),
- z2 - (1.5 * i * stemthick, 0), stemthick);
- draw_gridline (z3 + (1.5 * i * stemthick, 0),
- z4 + (1.5 * i * stemthick, 0), stemthick);
+ draw_gridline (z1 - (i * line_distance, 0),
+ z2 - (i * line_distance, 0),
+ stemthick);
+ draw_gridline (z3 + (i * line_distance, 0),
+ z4 + (i * line_distance, 0),
+ stemthick);
endfor;
enddef;
fet_beginchar ("Brevis notehead", "sM1");
- draw_brevis (1);
+ draw_brevis (1, 1);
draw_staff (-2, 2, 0);
fet_endchar;
@@ -201,7 +218,7 @@ fet_endchar;
if test > 0:
fet_beginchar ("Brevis notehead", "sM1");
- draw_brevis(1);
+ draw_brevis(1, 1);
draw_staff (-2, 2, 0.5);
fet_endchar;
@@ -209,7 +226,7 @@ fi;
fet_beginchar ("Double
