Re: How to report `FontForge` problems while creating LilyPond fonts

[Torsten Hämmerle]

Werner LEMBERG wrote
> The output produced by the `mf2pt1` script to convert METAFONT input files
> to Type1 PostScript fonts often contains overlapping glyphs.  This should
> be
> avoided in general.[1]  For this reason, `mf2pt1` by default calls
> `FontForge` in batch mode to remove overlaps.

Hello Werner,

Unfortunately, mf overlaps can hardly be avoided in many cases, because lots
of glyphs are being composed out of several overlapping predefined
components.
clefs.GG, for instance, consists of two overlapping clefs.G.
So I'm afraid we cannot save FontForge from dealing with overlaps in
general.

But, being harried by all the error messages currently produced (and
intrigued by your report), I've had a look at the specific errors and found
a way to solve all the issues without actually changing the final result
(well, except for an unnoticeable change to the TAB clef invisible to the
human eye).

I agree that FontForge should be able to cope with theses cases, but, as it
doesn't seem to be easy to solve, It'd probably be a good idea to change our
mf files in such a way that they can be processed without lamenting even
using the current FontForge release.

Just to start off with the "turn" example in *feta-scripts.mf*:
The turn glyphs consist of a rather fancy implementation of the S-shape with
and overlay of "ploop" at both ends.  The meet in mf control point 4l with
an "infinitesimal" deviation of slope.
I could circumvent this by junking the "ploop", just inserting two points
(5l and 6l) into the S-shape path.
Now we have replaced the overlapping objects by a self-intersecting path,
but FontForge does not complain anymore, but yielding the exact same result.

Picking up a pencircle and switching mf from "fill" to "draw" for seeing
what mf actually does, we get:

<http://lilypond.1069038.n5.nabble.com/file/t3887/example-turn.png> 

I absolutely dislike corners without a clearly defined intersection point,
but that's the way the glyph has been designed and changing this may
slightly change the resulting outline.

That's just one of many similar cases.

*feta-arrowheads.mf*
The arrowhead glyph can be cured by making one single path out of the two
superimposed components.

*feta-clefs.mf*
The G clef and all its derivatives can be immunized by inserting one
auxiliary point within the intersection area.
The (handwriting) TAB clef has a problem joining the two curvy strokes in
the B and just changing the starting angle of one of the parts by, say, 1
degree, will help. Unnoticeable change (and, after all, it's a "handwritten"
B).


*feta-timesignatures.mf*,
lastly, the common time glyph C can be processed flawlessly when shifting
the direction instruction in z2r from one side to the other. This is only
possible when replacing a straight connection by a rounded one within the
overlapping area.

All in all *minimal changes* that *do not affect the resulting mf outline*
at all but help FontForge to better handle the font conversion without any
complaints..

What do you think? Should I prepare a patch?

Regards,
Torsten

example-turn.png
<http://lilypond.1069038.n5.nabble.com/file/t3887/example-turn.png>  



--
Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html