font: change breve vertical lines

font: change breve vertical lines

Put breve vertical lines farther apart
and make them longer to increase readability.

[Janek Warchol, 2011-07-17 10:22:13]

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=17670000000&name=breve+d...)
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=17670000002&name=Miserer...

Here is my homework :)
http://lilypond.googlecode.com/issues/attachment?aid=17670000001&name=breve+e...

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 :(

[lemzwerg, 2011-07-27 05:03:15]

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?

[Janek Warchol, 2011-07-28 21:17:43]

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).

[lemzwerg, 2011-07-29 20:29:20]

> 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...

[Janek Warchol, 2011-07-30 16:36:29]

2011/7/29  <lemzwerg@googlemail.com>:
>> 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