LSR: another update for new dirs.

[lilypond.git] / mf / README

diff --git a/mf/README b/mf/README
index 1d6c4c74e50fc3912ae51e640acfbf44ac6e9c91..89eef4ee22bb5c80ce5a6dec0e90c58cb83bed03 100644 (file)
--- a/mf/README
+++ b/mf/README
@@ -1,27 +1,28 @@
 
-This is a font of music symbols.  All MF sources are original.  Most
-of the documentation is in comments in the MF code.
+This is a font of music symbols.  All MF sources are original.  Most of the
+documentation is in comments in the MF code.
 
 Non-square pixels are not supported; with other words, the horizontal and
 vertical resolution of the output device must be the same.
 
 Currently, outline fonts are created by using `autotrace', but we are
-already in the process to convert the MF code directly to PostScript code
+already in the process of converting the MF code directly to PostScript code
 with a tool called `mf2pt1', which in turn calls `FontForge' to postprocess
 the output (mainly to remove outline overlaps and to add hints).
 
 The recommended calling sequence of mf2pt1 is
 
-  mf2pt1 --rounding=0.001 <font>
+  mf2pt1 --rounding=0.001 <other options> <font>
 
 You need mf2pt1 version 2.1 or newer.
 
+
 Here some guidelines to assure a clean conversion.
 
 . Never use `---'.  Replace it with `--' together with explicit path
   directions (if necessary).
 
-. Don't use self-intersecting outlines in general since it can confuse
+. Don't use self-intersecting outlines in general since they can confuse
   mf2pt1's algorithm to get the orientation of a closed path.  Note that
   MetaPost's implementation of the `turningnumber' primitive (which would
   immediately give the orientation of a path) is severely broken before
@@ -29,7 +30,7 @@ Here some guidelines to assure a clean conversion.
   to work around this bug.
 
 . If outlines intersect, avoid grazing intersections.  In case two outlines
-  intersect in an explicitly defined point, include this point into both
+  intersect in an explicitly defined point, include this point in both
   intersecting paths to avoid problems due to rounding errors.
 
 . Don't use `draw' with a polygonal pen but for straight lines (consisting
@@ -43,6 +44,25 @@ Here some guidelines to assure a clean conversion.
   overlaps.
 
 
+Some glyph name rules:
+
+. Most glyph names have the form <group>.<name>, where <group> is defined
+  with the `fet_begingroup' command, and <name> is given with
+  `fet_beginchar' (within a `fet_begingroup' block).  Example:
+  `clefs.vaticana.fa'.
+
+. Sometimes it would be sensible to use negative numbers in glyph names. 
+  However, the `-' character shouldn't be used in a glyph name.  Replace it
+  with `M'.  For example, write `rests.M3mensural' instead of
+  `rests.-3mensural'.
+
+. Glyphs which exist in both an `up' and `down' version should start the
+  <name> part with either `u' or `d', respectively.  Example: `flags.d3',
+  `flags.u3'.  Glyphs which are neutral w.r.t. the direction, and where
+  members of the glyph group exist which have `up' and `down' versions,
+  should start with an `s'.  Example: `noteheads.s0re'.
+
+
 Some design rules:
 
 . Always use smooth curve transitions.  Since this is difficult to see in
@@ -57,7 +77,7 @@ Some design rules:
 . Use rounded corners.
 
 
-Finally, some rules to assure that rasterization at low resolutions give
+Finally, some rules to assure that rasterization at low resolutions gives
 good results.  Today, this is a minor issue, but in some cases it might show
 design flaws.