<HTML>
<HEAD>
<!-- Created with AOLpress/2.0 -->
<!-- AP: Created on: 6-Dec-2000 -->
<!-- AP: Last modified: 27-Mar-2009 -->
<TITLE>FontForge -- An outline font editor for PostScript®, TrueType
and OpenType fonts</TITLE>
<LINK REL="icon" href="fftype16.png">
<LINK REL="stylesheet" TYPE="text/css" HREF="FontForge.css">
</HEAD>
<BODY id="menued">
<P ALIGN=CENTER>
<IMG SRC="fontforge-banner-420.jpeg" WIDTH=420 HEIGHT=80>
<DIV class="menucontainer">
<UL class="menubar">
<LI class="menu">
<A href="http://sourceforge.net/projects/fontforge/files/">Download</A>
<UL>
<LI>
<A href="http://sourceforge.net/projects/fontforge/files/fontforge-docs/"
>Documentation</A>
<LI>
<A href="http://sourceforge.net/projects/fontforge/files/fontforge-source/"
>Source</A>
</UL>
<LI>
<A HREF="overview.html#TOC">Introduction</A>
<LI>
<A href="editexample.html">Tutorial</A>
<LI class="menu">
<A href="fontview.html">Windows</A>
<UL>
<LI>
<A href="fontview.html" >Font</A>
<LI>
<A href="charview.html" >Outline Glyph</A>
<LI>
<SMALL><A href="charview.html#Debugging" > Debugging
TrueType</A></SMALL>
<LI>
<SMALL><A href="multilayer.html" > Type3 Glyphs</A></SMALL>
<LI>
<A href="bitmapview.html" >Bitmap Glyph</A>
<LI>
<A href="metricsview.html" >Metrics</A>
</UL>
<LI class="menu">
<A href="fontinfo.html">Dialogs 1</A>
<UL>
<LI>
<A href="fontinfo.html" >Font Information</A>
<LI>
<SMALL><A href="histogram.html" > Histogram Dialog</A></SMALL>
<LI>
<A href="charinfo.html" >Glyph Information</A>
<LI>
<A href="getinfo.html" >Point, Reference Information</A>
<LI>
<A href="multilayer.html#Layer" >Type3 Layer Information</A>
<LI>
<A href="bdfinfo.html" >Bitmap Properties</A>
<LI>
<A href="baseline.html" >Baseline Information</A>
<LI>
<A HREF="justify.html">Justification Information</A>
<LI>
<A href="math.html" >Math Information</A>
<LI>
<A href="multiplemaster.html" >Multiple Master Information</A>
<LI>
<HR>
<LI>
<A href="lookups.html" >Lookups & subtables</A>
<LI>
<A href="metricsview.html#kernpair" >Kerning glyph pairs 1</A>
<LI>
<A href="kernpairs.html" >Kerning glyph pairs 2</A>
<LI>
<A href="metricsview.html#kernclass" >Kerning by classes</A>
<LI>
<A href="anchorcontrol.html" >Anchor Control</A>
<LI>
<A href="contextchain.html" >Contextual lookup dialog</A>
<LI>
<A href="statemachine.html" >Apple State Machine dialog</A>
<LI>
<A href="showatt.html" >Show Advanced Typography</A>
<LI>
<HR>
<LI>
<A href="problems.html" >Potential Problems dialog</A>
<LI>
<A href="validation.html" >Font Validation dialog</A>
</UL>
<LI class="menu">
<A href="generate.html">Dialogs 2</A>
<UL>
<LI>
<A href="filemenu.html#Open" >Open Fonts dialog</A>
<LI>
<A href="oflib.html" >Browsing OFLib dialog</A>
<LI>
<A href="generate.html" >Generate Fonts dialog</A>
<LI>
<A href="generate.html#Mac" >Generate Mac Family dialog</A>
<LI>
<HR>
<LI>
<A href="display.html" >Print & Display dialog</A>
<LI>
<A href="prefs.html" >Preferences dialog</A>
<LI>
<A href="groups.html" >Groups dialog</A>
<LI>
<HR>
<LI>
<A href="elementmenu.html#Bitmaps">Manage Bitmap Strikes</A>
<LI>
<A href="elementmenu.html#Regenerate">Re-Rasterize Bitmap Strikes</A>
<LI>
<HR>
<LI>
<A href="search.html" >Search & Replace dialog</A>
<LI>
<A href="Styles.html" >Style Transformation dialogs</A>
<LI>
<A href="transform.html" >Transformation dialog</A>
<LI>
<A href="elementmenu.html#Expand" >Expand Stroke dialog</A>
<LI>
<A href="tilepath.html" >Tile Path dialog</A>
<LI>
<A href="InsertTextDlg.html" >Insert Text dialog</A>
<LI>
<HR>
<LI>
<A href="metricsmenu.html#Width">Set width dialogs</A>
<LI>
<A href="metricsmenu.html#Width">Set left/right bearings</A>
<LI>
<A href="autowidth.html" >Auto Width & Kern dialogs</A>
<LI>
<HR>
<LI>
<A href="hintsmenu.html#Review" >Review PS Hints dialog</A>
<LI>
<A href="ttfinstrs.html" >TrueType Instruction Editor</A>
<LI>
<A href="ttfinstrs.html#cvt" >TrueType 'cvt ' Editor</A>
<LI>
<HR>
<LI>
<A href="selectbyatt.html" >Select by feature dialog</A>
<LI>
<A href="elementmenu.html#MassRename" >Rename Glyphs dialog</A>
<LI>
<A href="elementmenu.html#CompareFonts" >Compare Fonts dialog</A>
</UL>
<LI class="menu">
<A href="filemenu.html">Menus</A>
<UL>
<LI>
<A href="filemenu.html" >File</A>
<LI>
<A href="editmenu.html" >Edit</A>
<LI>
<A href="pointmenu.html" >Point</A>
<LI>
<A href="elementmenu.html">Element</A>
<LI>
<A href="toolsmenu.html">Tools</A>
<LI>
<A href="hintsmenu.html" >Hints</A>
<LI>
<A href="encodingmenu.html" >Encoding</A>
<LI>
<A href="viewmenu.html" >View</A>
<LI>
<A href="metricsmenu.html" >Metrics</A>
<LI>
<A href="cidmenu.html" >CID</A>
<LI>
<A href="mmmenu.html" >Multi Master</A>
<LI>
<A href="windowmenu.html" >Window</A>
<LI>
<A href="helpmenu.html" >Help</A>
</UL>
<LI>
<A href="faqFS.html">FAQ</A>
<LI>
<A href="IndexFS.html">Index</A>
<LI>
<A href="GlossaryFS.html">Glossary</A>
<LI>
<A href="http://fontforge.wiki.sourceforge.net/">Wiki</A>
</UL>
</DIV>
<DIV id="in">
<H1 Align=Center>
FontForge<BR>
<SMALL>An Outline Font Editor</SMALL><A HREF="ja/overview.html"><BR>
<IMG SRC="flags/Nisshoki-Japan.png" WIDTH="39" HEIGHT="26"></A>
</H1>
<H2>
<I><IMG SRC="FontForgeSplash.png" WIDTH="379" HEIGHT="375" ALT="Gaudiamus ligature!"
ALIGN="Right"></I><A NAME="TOC">Table</A> of Contents
</H2>
<UL>
<LI>
<A HREF="#Overview">Overview</A>
<UL>
<LI>
<A HREF="#Installing">Installing</A>
<LI>
<A HREF="#Starting">Starting the program</A>
<LI>
<A HREF="overview.html#What">What is a font editor?</A>
<LI>
<A HREF="#intro">Introductory concepts: fonts, splines, lines, points and
paths</A>
<LI>
<A HREF="overview.html#PT">Font Formats</A>
<LI>
<A HREF="#Hints">Hints</A>
<LI>
<A HREF="#References">References</A>
<LI>
<A HREF="#Layers">Layers</A>
<LI>
<A HREF="#Scripts">Scripts</A>
<LI>
<A HREF="overview.html#Glyph-names">Glyph names & Namelists</A>
<LI>
<A HREF="#Lookups">Lookups, Features, Scripts and Languages</A>
<LI>
<A HREF="#Anchors">Anchor Points and Classes</A>
<LI>
<A HREF="#Baseline">Baselines</A>
<LI>
<A HREF="#FontView">Font View</A>
<LI>
<A HREF="#CharView">Outline Glyph View</A>
<LI>
<A HREF="#BitmapView">Bitmap Glyph View</A>
<LI>
<A HREF="#MetricsView">Metrics View</A>
</UL>
<LI>
<A HREF="editexample.html">Example</A>
<UL>
<LI>
<A HREF="editexample.html">Tutorial</A> & User Guide
<LI>
<A HREF="scriptnotes.html#Special">Special thoughts for special scripts</A>
</UL>
<LI>
<A HREF="fontview.html">Font View</A>
<UL>
<LI>
<A HREF="fontview.html#Encodings">Encodings</A>
<LI>
<A HREF="fontview.html#Unicode">Unicode</A>
<LI>
<A HREF="fontview.html#CID">CID keyed fonts</A>
<LI>
<A HREF="fontview.html#MM">Multiple Master fonts</A>
<LI>
<A HREF="fontview.html#Vertical-Metrics">Vertical Metrics</A>
</UL>
<LI>
<A HREF="charview.html">Outline Glyph View</A>
<UL>
<LI>
<A HREF="charview.html#Layers">Layers</A>
<LI>
<A HREF="charview.html#Tools">Tools</A>
<LI>
<A HREF="charview.html#Vertical">Vertical view</A>
<LI>
<A HREF="charview.html#Debugging">Debugging TrueType glyphs</A>
<LI>
<A HREF="charview.html#MM">Multiple Master </A>
</UL>
<LI>
<A HREF="bitmapview.html">Bitmap Glyph View</A>
<UL>
<LI>
<A HREF="bitmapview.html#Layers">Layers</A>
<LI>
<A HREF="bitmapview.html#Tools">Tools</A>
<LI>
<A HREF="bitmapview.html#AA">Anti-Aliased Glyphs</A>
<LI>
<A HREF="bitmapview.html#Shades">Shades</A>
</UL>
<LI>
<A HREF="metricsview.html">Metrics View</A>
<UL>
<LI>
<A HREF="metricsview.html#Entering">Entering non-ASCII characters</A>
</UL>
<LI>
<A HREF="filemenu.html">Menu Commands</A>
<UL>
<LI>
<A HREF="filemenu.html">File</A>
<LI>
<A HREF="editmenu.html">Edit</A>
<LI>
<A HREF="pointmenu.html">Points</A>
<LI>
<A HREF="elementmenu.html">Element</A>
<LI>
<A HREF="toolsmenu.html">Tools</A>
<LI>
<A HREF="hintsmenu.html">Hints</A>
<LI>
<A HREF="encodingmenu.html">Encoding</A>
<LI>
<A HREF="viewmenu.html">View</A>
<LI>
<A HREF="metricsmenu.html">Metrics</A>
<LI>
<A HREF="cidmenu.html">CID</A>
<LI>
<A HREF="mmmenu.html">MM</A>
<LI>
<A HREF="windowmenu.html">Window</A>
<LI>
<A HREF="helpmenu.html">Help</A>
<LI>
<A HREF="HotKeys.html">Hot Keys</A>
</UL>
<LI>
<A HREF="scripting.html">Scripting</A>
<LI>
Appendices...
<UL>
<LI>
<A HREF="PfaEdit-TeX.html">Using FontForge with TeX</A>
<LI>
<A HREF="uitranslationnotes.html">Localization</A>
<LI>
<A HREF="errrecovery.html">Error Recovery</A>
<LI>
<A HREF="xres.html">X Resources</A>
<UL>
<LI>
<A HREF="xres.html#Keyboards">Keyboards and Mice</A>
</UL>
<LI>
<A HREF="cliargs.html">Command line arguments</A>
<UL>
<LI>
<A HREF="cliargs.html#Environment">Environment Variables</A>
</UL>
<LI>
<A HREF="files.html">Files</A>
<LI>
Internals
<UL>
<LI>
<A HREF="src.html">Source file overview</A> (out of date, but goes over the
basics)
<LI>
<A HREF="sfdformat.html">Spline Font Database File Format</A> (also out of
date)
<LI>
<A HREF="plugins.html">Plugins</A>
<LI>
<A HREF="bezier.html">PostScript <-> TrueType Conversions</A>
<LI>
<A HREF="corpchar.html">FontForge's use of the Unicode Private Use Area</A>
</UL>
<LI>
<A HREF="sfds/index.html">Font samples</A>
</UL>
<LI>
<A HREF="faqFS.html">Frequently Asked Questions</A>
<LI>
<A HREF="HotKeys.html">Hot Keys</A>
<LI>
<A HREF="GlossaryFS.html">Typographical glossary</A>
<LI>
<A HREF="IndexFS.html">Index</A>
<LI>
<A HREF="nvd.html">File List</A>
<LI>
<A HREF="bibliography.html">Bibliography</A>
<LI>
<A HREF="license.html">License and Copyright</A>
<LI>
<A HREF="nix-install.html">Download</A>
<LI>
<FORM method=GET action="http://www.google.com/search">
Searching the documentation:
<INPUT type=hidden name="as_sitesearch" value="fontforge.sourceforge.net">
<INPUT type=text name="as_q">
<INPUT type=submit name="btnG" value="Search">(Powered by
<A HREF="http://www.google.com/">Google</A>)
</FORM>
</UL>
<H2>
See Also
</H2>
<UL>
<LI>
<A HREF="sfddiff.html">sfddiff man page</A>
<LI>
<A HREF="acorn2sfd.html">acorn2sfd man page</A>
</UL>
<P>
<BLOCKQUOTE ID="lit">
<TABLE>
<TR VALIGN="Bottom">
<TD COLSPAN=2>Eeyore had <A NAME="three-sticks">three</A> sticks on the ground,
and was looking at them. Two of the sticks were touching at one end, but
not at the other, and the third stick was laid across them. Piglet thought
that perhaps it was a Trap of some kind.</TD>
</TR>
<TR>
<TD COLSPAN=2>``Oh, Eeyore,'' he began again, ``just ---''</TD>
</TR>
<TR>
<TD COLSPAN=2>``Is that little Piglet?'' said Eeyore, still looking hard
at his sticks.</TD>
</TR>
<TR>
<TD>``Yes, Eeyore, and I---''</TD>
</TR>
<TR>
<TD COLSPAN=2>``Do you know what this is?''</TD>
</TR>
<TR>
<TD COLSPAN=2>``No,'' said Piglet.</TD>
</TR>
<TR>
<TD COLSPAN=2>``It's an A.''</TD>
</TR>
<TR VALIGN="Bottom">
<TD>``Oh,'' said Piglet.</TD>
<TD ROWSPAN=2><P ALIGN=Right>
-- A. A. Milne, 1928<BR>
The House At Pooh Corner</TD>
</TR>
<TR>
<TD>``Not O, A,'' said Eeyore severely.</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
<P>
Font design can be a Trap, but I find it a rather pleasant one. <EM>Caveat
utor</EM>.
<H2>
<A NAME="Overview">Overview</A>
</H2>
<P>
FontForge allows you to create and modify postscript, truetype and opentype
fonts. You can save fonts in many different outline formats, and generate
bitmaps.
<H3>
<A NAME="Installing">Installing</A> or building fontforge
</H3>
<TABLE CELLSPACING="6" CELLPADDING="2">
<CAPTION>
System specific install procedures
</CAPTION>
<TR>
<TD><P ALIGN=Center>
<A HREF="nix-install.html">Unix/Linux</A></TD>
<TD> <A HREF="mac-install.html">Mac</A></TD>
<TD> <A HREF="ms-install.html">MS/Windows</A></TD>
<TD> <A HREF="vms-install.html">VMS</A></TD>
<TD> <A HREF="source-build.html">from source</A></TD>
<TD> <A HREF="uninstall.html">Uninstalling</A></TD>
</TR>
</TABLE>
<P>
<A HREF="running.html">Running fontforge</A>
<H3>
Er... <A NAME="What">What</A> is a font editor?
</H3>
<P>
A font editor is a progam designed to creat and modify fonts.
<P>
The most obvious aspect is that it is a drawing program like FreeHand, Inkscape
or Illustrator which lets you draw the outlines of your letters. Unlike other
drawing progams it expects you to draw many pictures at once (one or more
for each letter) and collects them into a database.
<P>
It allows you to describe the way these pictures interact with each other
(if you put one picture after the other then they should normally be separated
by a certain distance -- the font's metrics, or if these two pictures are
placed adjacent to one another then they turn into a third -- the font's
ligatures, and so on).
<P>
Finally a font editor will bundle up all the pictures you have drawn, and
all the metadata about how those pictures fit together, and will turn that
bundle of stuff into a font that your computer can use to display text.
<H3>
<A NAME="intro">Introductory</A> concepts: Fonts, Splines, Lines, Points,
Paths and the em-unit
</H3>
<P>
Most simply a font is a collection of glyphs. But computer fonts must contain
more than this, at the least they must also contain information on how to
map an input string of bytes into an output display of visual glyphs. This
mapping is called an encoding. Many fonts will also contain rules for how
adjacent glyphs should be arranged. For instance, in fonts for the latin
alphabet, there is often a rule saying that if "f" and "i" are adjacent then
a special glyph, a ligature of "f" and "i" should be used instead. Fonts
for latin letters generally do not require such rules (but can be enhanced
by them), fonts for other scripts like arabic require them.
<P>
What's the difference between a character and a glyph?
<P>
A character is a concept and a glyph is a reification of that concept. The
letter "A" is a character, while<IMG SRC="As.png" WIDTH="220" HEIGHT="33">
are all glyphs that represent an "A". In latin fonts there is often a single
glyph for every character and a single character for every glyph, but not
always -- in renaissance printing there were two glyphs for a lower-case
s, <IMG SRC="short-long-s.png" WIDTH="17" HEIGHT="12">the short and the long
s. Whereas a ligature is an example of a glyph that represents two (or more)
characters. In arabic most of the letters (characters) have at least four
different glyphs, the appropriate glyph being determined by the letters around
it. Here are four forms of the arabic character "seen"
<IMG SRC="arabic-seen.png" WIDTH="108" HEIGHT="17" ALIGN="Middle">.
<P>
What is an outline font? What is a bitmap font?
<P>
Each glyph in a font has a shape and there are various ways of describing
that shape on a computer. PostScript and truetype fonts generally describe
the outline of the shape and then color in the interior of that outline,
this coloring process is called rasterizing. On the other hand a bitmap font
describes each glyph by drawing a picture of that character on a rectangular
grid of pixels. There is a third type, a stroked font, where each stem of
the glyph is represented by one line down the center of the stem, and the
line is later drawn with a certain width. Most of the time we will not deal
with stroked fonts directly (the <A HREF="elementmenu.html#Expand">Expand
Stroke</A> command can be used to turn them into outlines), but if you wish
to edit stroked fonts, see the section on
<A HREF="multilayer.html">multi-layered editing</A>.
<TABLE BORDER CELLPADDING="2">
<TR VALIGN=Top>
<TD><P ALIGN=Center>
<I><IMG WIDTH="117" HEIGHT="201" SRC="outlinechar.png"></I><BR>
A glyph's outline</TD>
<TD><P ALIGN=Center>
<IMG SRC="bitmapchar.png" WIDTH="117" HEIGHT="201"><BR>
A glyph's bitmap</TD>
<TD><P ALIGN=Center>
<IMG SRC="strokechar.png" WIDTH="208" HEIGHT="198"><BR>
A stroked glyph<BR>
(showing the equiv. outline in grey)</TD>
</TR>
</TABLE>
<P>
An outline is composed of a set of contours or paths. In the picture on the
above left the letter A is described by three different paths. The main one
is on the outside and the two smaller ones are internal. Each of these paths
is composed of a series of (Bézier) splines and line segments. FontForge
can handle cubic and quadratic splines. PostScript fonts use cubic splines,
TrueType fonts use quadratic (SVG fonts can be either).
<P>
Each cubic <A NAME="spline">spline</A> is defined by four points, two of
which mark the end points of the spline and two more to describe the slope
of the spline at those end points. Here are <A HREF="bezier.html">two cubic
splines</A> with all their points shown:
<P>
<IMG SRC="splines.gif" WIDTH="172" HEIGHT="179" ALIGN="Left">
<P>
The points which describe the slope are called control points. They are
represented here (and in fontforge) by little colored x's. Moving a control
point will change the shape of the spline, but it will not alter where the
spline begins or ends.
<P>
<IMG SRC="pnts.gif" WIDTH="169" HEIGHT="165" ALIGN="Right">A series of splines
and lines are joined together to make a path. There are several possible
ways to make these joins as is shown in the example to the right. In each
case we have three points in approximately the same relative positions. The
three points are joined by splines or lines, but the type of joins alters
the appearance of the connections.
<P>
In the first case there are no control points and the result is two straight
lines, in the second case there is a line and a curved spline which are tangent
at their point of intersection, in the third case there are two splines which
are again tangent at their point of intersection. The point of intersection
in the first case is called a corner point, and the incoming and outgoing
splines or lines may be in any orientation with respect to each other. This
is represented in fontforge by a square box. In the second case the point
of intersection is called a tangent point, it is represented by a triangle.
The third case is a curved point and is represented by a circle.
<P>
<IMG SRC="quadraticspline.gif" WIDTH="127" HEIGHT="92" ALIGN="Left">FontForge
can also edit <A NAME="quadratic">quadratic</A> splines (the splines used
in truetype fonts), here there is only one control point and it controls
the slopes at both end-points. Because of this quadratic splines cannot bend
in as many ways as cubic splines (the first spline above left would need
at least two quadratic splines to draw), and you will often need more splines
to achieve the same curve. You can control whether a font contains cubic
or quadratic splines with the
<A HREF="fontinfo.html#PS-General">Element->Font Info </A>command.
<P>
There are many different types of splines in the world. The ones described
above are Béziers -- these are numerically simple and have a number
of nice properties -- which is why they are used internally in fonts. However,
there are some even nicer splines. It is easy to give Bézier splines
the same slope on either side of a point, but a curve will look much nicer
if it has the same curvature on either side of a point. Clothoid splines
have this property.
<P>
<A HREF="http://www.levien.com/">Raph Levien </A>has kindly donated to the
open source community a <A HREF="http://libspiro.sf.net/">library</A> for
converting clothoid splines into Béziers.
<P>
Clothoid splines are much easier to work with than Béziers -- there
are no control points, just a sequence of on-curve points, and magically
a beautiful curve will appear between them. FontForge can
<A HREF="charview.html#spiro-mode">either</A> edit a curve as a set of
Béziers or as a set of clothoids.
<P>
A path is closed when it comes back and joins its start. All paths in an
outline font should be closed. Once a path is closed in may be said to have
a direction, essentially this may be thought of as "Was the path created
in a clockwise or a counter-clockwise fashion?" (this is actually a little
simplistic, if a path intersects itself, as in a figure 8, then the direction
cannot be described as either clockwise or counter-clockwise, but most paths
do not self-intersect (and paths in a font <STRONG>SHOULD NOT
</STRONG>self-intersect) and we will simplify our life by pretending that
we can call paths clockwise or counter).
<P>
When time comes to draw our outline glyph we want to make dark everything
in the interior of the outline. But let's look at the outline of our A above.
We have two paths inside the main outline path, and we want the interior
of those two paths to be white rather than dark. How do we make this distinction?
We do it by the direction of the paths. Consider any point in the glyph.
If we draw an imaginary line from that point out to infinity (in any direction)
and count the number of times we cross a path, each time we cross a clockwise
path we add one to our count, each time we cross a counter clockwise path
we subtract one. If the result of our count is non-zero then we color the
point dark, otherwise we leave it white. So to make the A above work we make
the outer path be clockwise and the two inner ones be counter-clockwise (Things
could be done the other way around, but the convention is that the outer
path should be clockwise).
<P>
All of these points (both the end points and the control points) are described
mathematically. Each point is positioned on a cartesian coordinate system
which has its origin on the glyph's <A HREF="#Baseline">baseline</A> (the
line on which letters without descenders rest). Most font formats expect
coordinates to be integers between -32768 and 32767, FontForge uses real
numbers internally but (usually) rounds to the nearest integer when generating
a font file.
<P>
Generally it is a good idea to restrict yourself to integral coordinates.
TrueType fonts can only contain integral coordinates so if you use a non-integral
value FontForge will be forced to round it to an integer and this will alter
the shape of the curve. PostScript fonts can contain non-integral values,
but the various formats are optimized for integers. So use integers when
you can. If you need more precision you can increase the "em-size" of the
font.
<P>
When displaying a font we use the word "<A NAME="em-unit">em</A>" to represent
the size of the font. If a font is displayed at 12points then 1em will be
12points. If the font is displayed at 18points then an em will be 18points.
(traditionally a 12 point font is one where the metal slugs are 12 points
tall -- or where the baseline to baseline spacing of unleaded text is 12
points, so an em was the size of the metal.).
<P>
When designing an outline font, you can no longer think in terms of points
-- these fonts are scalable and can be any pointsize. You must think in terms
of the em and fractions of the em. When you create a font you choose how
many internal units (called "em-units") to use to represent 1 em -- this
number is called the "em-size". In most PostScript fonts there are 1000 units
to the em, TrueType fonts often have either 1024 or 2048 units to the em
(TrueType recommends that you use a power of two). But you can choose any
(positive) number you like (well, as long as it is less than 32767), the
numbers above are conventions not requirements).
<P>
Suppose you have a dash in a PostScript font, and that dash is 500 units
long, and the font has 1000 units to the em. Suppose a someone displays that
dash at 12 points. Then that dash will be drawn with a length of 500/1000
* 12 = 6 points. On a 72 dot per inch screen where a pixel is almost exactly
one point, the dash will be 6 pixels long.
<P>
<IMG SRC="sidebearings.png" WIDTH="111" HEIGHT="191" ALIGN="Right">Every
glyph has its own coördinate system. The font's
<A HREF="#Baseline">baseline</A> (the line upon which most latin glyphs will
rest) is 0 in the vertical direction. The horizontal origin is where the
glyph will start being drawn (what is "drawn" will usually be empty space
for a short while -- as there is usually some space between the origin and
the edge of the glyph). This horizontal distance between the origin and the
leftmost edge of the glyph is called the left side bearing (it may be negative,
positive or zero). All glyphs have a width (sometimes called an advance width),
this is the distance from the origin of the current glyph to the origin of
the next. The distance between the right edge of the glyph and the width
is called the right side bearing.
<P>
CJK text (Chinese, Japanese or Korean) can be written either vertically or
horizontally, and so CJK fonts usually have a vertical advance width as well
as the more common horizontal advance (and concomittant top and bottom side
bearings).
<P>
A glyph like "g" or "y" extends below the baseline, this is called a descender,
while a glyph like "k" or "l" extends above the x-height, this is called
an ascender. Most latin (and greek and cyrillic) fonts have certain standard
heights: the height of a lower case letter (without an ascender) is called
the x-height, the height of a capital letter is called the cap-height, the
height of the ascenders is called the ascender height (some, but not all,
fonts have the ascenders and capitals at the same approximate height). Often
these will not be exactly the same for all glyphs, the letter "O" is usually
slightly taller than the letter "I", but they both are within the range of
the cap height for the font.
<P>
The font itself has an ascent and descent associated with it. In the old
days of metal type nothing could ascend above or descend below these values,
nowadays accents and ascenders may reach above the font-wide ascent and
descenders below the descent, but the concept is still a convenient one to
retain. It is true that in almost all cases the glyphs will not ascend above
or descend below the font-wide ascent and descent. The sum of the ascent
and descent is the size of the font. The point size of a piece of metal type
was determined by this value (essentially the height of the metal block holding
the glyph). In a postscript font the local coordinate system is independent
of the final size at which the font will be drawn.
<H3>
<A NAME="PT">TrueType</A> vs. PostScript vs OpenType vs SVG fonts
</H3>
<P>
FontForge can produce many font types. What's the difference?
<P>
PostScript is based on a <A HREF="bezier.html">cubic spline</A> technology,
while TrueType is based on a <A HREF="bezier.html">quadratic</A> technology.
Cubic splines are generally easier to edit (more shapes are possible with
them). Any quadratic spline can be converted to a cubic spline with essentially
no loss. A cubic spline can be converted to a quadratic with arbitrary precision,
but there will be a slight loss of accuracy in most cases.
<P>
Within FontForge a font may contain either cubic or quadratic splines. These
are converted to the appropriate format when a font is generated.
<P>
The other major difference between the two is how they solve the problem
of drawing nice images at small pointsizes. PostScript calls this "Hinting",
while TrueType calls it "Instructing" a font.
<H4>
What's OpenType?
</H4>
<P>
Unfortunately the word "OpenType" has come to have several meanings.
<P>
The first meaning describes the glyph (and spline) format of the font. In
this sense Open Type is just a postscript font put into a truetype file format
-- From the outside it looks like a truetype font except that the outline
descriptions are postscript Type2 font descriptions rather than TrueType.
Technically it is a <A HREF="glossary.html#CFF">CFF</A> font inside an
<A HREF="glossary.html#SFNT">sfnt</A> wrapper.
<P>
In a second sense of the word OpenType refers to a set of tables containing
advanced typographic information. These tables may be added to either fonts
specified with quadratic splines (truetype) or fonts with cubic splines.
<P>
Finally MS Windows uses an OpenType icon for a font if that font contains
a 'DSIG' (Digital Signature) table.
<P>
To make things even more confusing the OpenType specification includes the
old TrueType specification, so technically any TrueType font can be called
an OpenType font.
<P>
FontForge does not support the DSIG table (if you want one there is a free
tool from MS which will add one). When generating a font, FontForge uses
the term "OpenType (CFF)" to represent a PostScript (CFF) font inside an
sfont wrapper. To include OpenType typography tables you would press the
<CODE>[Options] </CODE>button and select the <CODE>[] OpenType</CODE> check
box.
<H4>
What's SVG?
</H4>
<P>
SVG (Scalable Vector Graphics) provides a relatively new font format, written
in an xml dialect. SVG fonts can be either cubic or quadratic (or can use
both, but FontForge is limited and will force a font to be either all cubic
or all quadratic). SVG allows for two different types of fonts, one corresponds
roughly to PostScript Type1 fonts, and the other, roughly to PostScript Type3
fonts.
<H4>
What are Type3 fonts?
</H4>
<P>
Back in the early days of PostScript, the Type1 format was proprietary, only
Adobe could make Type1 fonts, but anyone could make Type3 fonts. Type3 fonts
were unhinted, but could include any postscript command and so could produce
a wider range of pictures (multi-colored glyphs, stroked glyphs, glyphs based
on scaled images, etc.). Most of the time these extensions are unnecessary,
and the disadvantage of being unhinted is onerous -- but sometimes you want
to play. If you compile FontForge with multilayer set you will be able to
create type3 fonts.
<H4>
What are Type1 fonts?
</H4>
<P>
These were the standard stand-alone PostScript fonts of the '80s and '90s.
<H4>
What are Type2 fonts?
</H4>
<P>
These use a slightly different internal format (a more compact one) to express
the same information as type1. This is the format that lives inside a CFF
font which lives inside an OpenType font.
<H4>
What are CFF fonts?
</H4>
<P>
This is the font format that is designed to store PostScript Type2 information.
It is most commonly found inside an OpenType (PostScript) font.
<H4>
What is Apple Advanced Typography?
</H4>
<P>
This is another way of specifying typographic information (like ligatures,
kerning, glyph substitutions). It appeared before OpenType and is only used
on Apple computers. It is based on state machines and is a little harder
to work with than OpenType.
<H3>
<A NAME="Hints">Hints</A>
</H3>
<P>
At small pixel sizes, the process of drawing the interior of an outline font
is quite difficult to do well. PostScript and TrueType have different approaches
to the problem of providing extra information to the rasterizer about how
to draw small fonts.
<TABLE BORDER CELLPADDING="2" ALIGN="Center">
<CAPTION>
<SMALL>Rasterization improvements<BR>
from hinting TrueType.<BR>
18pt font rasterized by Windows<BR>
(scaled by a factor of 2)</SMALL>
</CAPTION>
<TR>
<TD><P ALIGN=Center>
<IMG SRC="HI.nohints.png" WIDTH="44" HEIGHT="28"> <BR>
no hints</TD>
<TD><P ALIGN=Center>
<IMG SRC="HI.hints.png" WIDTH="44" HEIGHT="28"> <BR>
hints</TD>
</TR>
</TABLE>
<DL>
<DT>
<H4>
PostScript
</H4>
<DD>
Adobe incorporated several different ways of providing hints for the rasterizer
about how things should be treated. The most obvious of these are the horizontal
and vertical stem hints. Each glyph has its own set of hints to tell the
rasterizer where to find stems. FontForge can usually figure out a reasonable
set of stem hints (a process called
<A HREF="hintsmenu.html#AutoHint">autohinting</A>), but some glyphs are too
complex for it and it can make bad choices. It also provides a mode for you
to override its choices.
<P>
Adobe also has a mechanism for handling dished serifs called flex hinting.
This means a curve that is only slightly deformed from the horizontal (or
vertical) will display as a line at small point sizes and as a curve at larger
ones. FontForge will use these when it seems appropriate.
<P>
The original version of hints did not allow them to overlap, this meant that
most serifs could not be described, Adobe then developed a mechanism called
hint substitution which allows for different sets of non-overlapping hints
to exist in different parts of the glyph. There are still shapes which cannot
be fully hinted, but hint substitution is an improvement. The
Hints->AutoHint command will figure out what stems overlap and where to
change the current set of hints. The Hints->Hint Substitution Pts command
will also figure where hint changes should occur, and the Hint Mask pane
of the Point Info dialog gives the user direct control over this.
<P>
Most recently Adobe has provide a means to control the counters, the spaces
between stems, in a glyph. The original Type1 description provided support
for the horizontal counters in "m" and the vertical counters in "E" but more
complex shapes could not be dealt with. Counter Hints (in a type1 font) may
only be used with non-latin (non-greek, non-cyrillic) glyph sets, in type2
(OpenType) things are a bit more complicated,. FontForge will generate counter
hints when appropriate.
<P>
Adobe provides some font-wide hinting mechanisms. The two most obvious are
the BlueValues and StemSnap settings in the
<A HREF="fontinfo.html#Private">private dictionary</A>. BlueValues provides
a list of vertical zones in which interesting things happen (so in a latin
font this might include the ascender height, the cap-height, the x-height,
the baseline and the descender height. At small point sizes everything within
one of these zones will snap to the same height, while at larger point sizes
the heights will be slightly different (for instance an "o" and an "x" usually
have slightly different heights, but displaying that at a small point size
would be ugly). Similarly the StemSnap variables specify standard stem widths
for the font. FontForge will try to guess reasonable values for these. It
also allows you to override these guesses and
<A HREF="fontinfo.html#Private">specify your own values</A>. For a more
comprehensible description of the private dictionary and what it can do,
look at
<A HREF="http://partners.adobe.com/asn/developer/PDFS/TN/T1_SPEC.PDF">Adobe's
Type1 font specification</A>.<BR>
<A NAME="HintOrder">FontForge</A>'s
<A HREF="hintsmenu.html#AutoHint">AutoHint</A> command will work better if
the BlueValues have been set. So before running AutoHint go to
<A HREF="fontinfo.html#Private">Element-> FontInfo-> Private</A> to
set this array. After AutoHinting you should regenerate the StemSnaps (also
at Element-> FontInfo-> Private).
<DT>
<H4>
<A NAME="TrueType">True</A> Type
</H4>
<DD>
<TABLE ALIGN=Right>
<TR>
<TD ALIGN=Center><IMG SRC="GridFitM.png" WIDTH="246" HEIGHT="241"><BR>
Grid Fit M</TD>
</TR>
</TABLE>
<P>
On the other hand, True Type says that figuring out what pixels to turn on
would be a lot simpler if only the points and the splines were in the right
place (ie. at pixel boundaries). And so True Type provides a set of instructions
that move points around until they are positioned appropriately for a given
size.
<P>
FontForge's hinting of True Type (properly called "instructing") is based
on the stem hints also used by PostScript and on diagonal hints. It uses
these hints to determine which points to move and where to move them.
<P>
When FontForge reads in a TrueType font it will store the instructions used,
and when it next generates that font it will use those instructions -- provided
no significant change has happened to a glyph.
</DL>
<P>
Most of my <A HREF="hinting.html">hinting user interface</A> is designed
with PostScript fonts in mind.
<H3>
<A NAME="References">References</A>
</H3>
<P>
In addition to a set of outlines (splines) glyphs may be built out of references
to other glyphs. This is especially handy for the accented glyphs, "à"
can be made up of a reference to the "a" glyph and another reference to the
"`" glyph. This can result in significant space savings, and in ease of design
(if you change the "a" glyph after making a reference to it the "à"
glyph will automatically change too, whereas if you just copied the "a" you
would have to recopy it.
<P>
FontForge has three commands for manipulating references, and one higher
level command for building accented glyphs. The
<CODE><A HREF="editmenu.html#Reference">Edit->Copy Reference</A></CODE>
command will put a reference to the current glyph into the clipboard, which
a subsequent
<CODE><A HREF="editmenu.html#Paste">Edit->Paste</A></CODE> command will
install as a reference. The
<CODE><A HREF="editmenu.html#Unlink">Edit->Unlink Reference</A>
</CODE>command will turn a reference in a glyph into it's component splines.
The <CODE><A HREF="elementmenu.html#Info">Element->Get Info</A>
</CODE>command (when applied to a reference) will bring up a dialog showing
you what glyph is referred to, and allowing you to bring up an editing window
on that glyph. Finally the
<CODE><A HREF="elementmenu.html#Accented">Element->Build->Accented
Glyphs</A></CODE> command will figure out what glyphs should be refered to
to build this composite glyph, and then will make those references and position
them appropriately. So if "à" were selected and you did a
<A HREF="elementmenu.html#Accented"><CODE>Element->Build->Accented
Glyphs</CODE> </A>command, FontForge would make a reference to "a" and another
to "`", and place the accent above the letter, and centered on it.
<P>
Some bitmap formats (OK, only one that I'm aware of) support references,
so FontForge allows references in bitmap glyphs as well as in outline glyphs.
<P>
Sadly life is not always that simple. The references FontForge uses internally
cannot always be converted into something equivalent in the output font.
Generally this causes no problems (FontForge will simply unlink the reference
in the output, which just makes the font a little bigger, but it has implications
for instructing TrueType, and, to a lesser extent, hinting PostScript. Most
people can ignore this, but if you are interested
<A HREF="ref-caveats.html">follow this link</A>).
<P>
Most font formats require that a glyph contain either a set of outlines (or
bitmap rasters) or a set of references. FontForge allows glyphs with a
combination of the two, but, as above, when it comes time to output the results,
FontForge will clean up the glyph (generally by unlinking references) so
that it can be output in the current format.
<H3>
<A NAME="Layers">Layers</A>
</H3>
<P>
A font may have several layers. When FontForge creates a new font it will
have 2 real layers (the foreground and background layers) and a sort of
half-layer for guidelines which is shared by all glyphs. In normal fonts
all glyphs have the same number of layers (This is not true of Type3 fonts,
and <A HREF="#Type3">I'll talk about them later.</A>)
<P>
Both the foreground layer and the background layer have certain predefined
meanings: The foreground layer is the default layer for dialogs where there
is no clear way to specify a layer. The background layer can contain all
sorts of stuff, basically whatever you want it to, but any images in it may
be autotraced into the foreground layer.
<P>
You may add other layers with the
<CODE><A HREF="fontinfo.html#Layers">Element->Font Info->Layers
</A></CODE>pane. Each layer may have a name and a different kind of splines
(quadratic or cubic).
<P>
One potential use of addtional layers: Many people find it easier to edit
using cubic splines but like to produce truetype fonts with quadratic splines.
You can use one layer to hold the cubic splines and another to hold the
quadratics. There are commands for comparing layers
(<CODE><A HREF="elementmenu.html#CompareL2L">Element->Compare Layer To
Layer</A></CODE>) and others for copying one layer to another (and adjusting
the splines to fit the new layer:
<CODE><A HREF="editmenu.html#CopyL2L">Edit->Copy Layer To
Layer</A></CODE>).
<P>
It seems a shame to have both a valid cubic and a valid quadratic font in
a database and only be able to produce a font from one of them, so the font
view will allow you to switch between layers
(<CODE><A HREF="viewmenu.html#FVLayers">View->Layers->*</A></CODE>)
and <CODE><A HREF="generate.html">File->Generate Fonts</A> </CODE>command
will allow you to output whatever layer you want into the font. (Note that
all layers will share the same hints, instructions, character set, bitmaps,
etc. It is only the outlines which differ.) Furthermore, you may choose to
store all the layers of a font into an sfnt (TrueType / OpenType font) with
the <A HREF="generate.html#Options"><CODE>[]Layers</CODE> checkbox of the
PfaEdit table of the <CODE>[Options]</CODE></A><CODE> </CODE>dialog.
<H4>
<A NAME="Type3">Type3 Fonts</A>
</H4>
<P>
Most people aren't interested in editing <A HREF="multilayer.html">Type3
PostScript fonts </A>(nor the equivalent SVG font), but if you want to, FontForge
can (you must configure it to do so however, but default it won't). Here
each layer represents a different drawing operation, and may specify a different
color, stroke, fill, etc. Layers are not font-wide, each glyph has its own
set of layers (which are not named). You can
<A HREF="multilayer.html#Layer">create new layers with a popup menu </A>in
the layers pane of the outline view.
<H4>
Guidelines
</H4>
<P>
In FontForge guidelines live in their own mini-layer (it isn't a full layer
because all glyphs share the same set of guidelines rather than having an
individual layer for each glyph). It can be edited just like any other layer
and you may have guidelines of any shape you desire. You may also drag out
horizontal and vertical guidelines from the edges of the outline glyph view.
<H3>
<A NAME="Scripts">Scripts</A>
</H3>
<P>
A script is a collection of letter shapes and rules for putting letters together.
For instance the latin script consists of the letters A-Z, written left to
right, along with a transformation from upper to lower case, a few ligatures
and rules for generating accents. Arabic is a script consisting of its own
character set, written right to left, along with transformations for initial,
medial, final and isolated forms, many ligatures and rules for placing vowel
marks.
<H3>
<A NAME="Glyph-names">Glyph names & Namelists</A>
</H3>
<P>
Within fontforge every glyph will have a name. Generally the glyph name will
be something that provides information about what the glyph looks like so
the name for the glyph representing "9" is "nine". Adobe has established
a
<A HREF="http://partners.adobe.com/public/developer/en/opentype/aglfn13.txt">standard
for what names may be assigned to what glyphs</A>, and when producing a font
for general use it is best to stick to that standard (Acrobat uses the glyph
names and recognizes the standard ones. If you try and use "neuf" for "nine"
Acrobat will not recognize it and surprising things will fail).
<P>
Adobe's standard provides reasonably mnemonic names for most latin and greek
glyphs (to English speakers anyway), some rather incomprehensible names for
cyrillic and hebrew (afiiXXXXX) and identifies most other glyphs by unicode
code point (uniXXXX or uXXXXX where "X" represents a hex digit and XXXX is
the unicode code point in hex).
<P>
If you are an english speaker and you are working with latin glyphs this
is fine and dandy. But if you are French you might wish that "adieresis"
were named "atréma" -- for that matter even if you are an English
speaker you might prefer it to be named "aumlaut". No matter who you are
you might prefer more mnemonic names for the code block you are working on.
<P>
FontForge has a concept called a
<A HREF="encodingmenu.html#namelist">namelist</A>, each of which is simply
a mapping from unicode code point to name. Several namelists may be defined,
different lists may apply to different fonts and a font may have all its
glyphs renamed from one namelist to another.
<P>
Namelists can also help navigating in a font. Even if a list does not apply
to a given font its names may be used in the goto dialog to find glyphs.
So if you've loaded a french namelist you can search for "atréma"
and FontForge will show you the glyph "adieresis" or "uni00E4" or "aumlaut"
or whatever.
<P>
A few caveats: Adobe's glyph name standard expects all glyph names to be
in ASCII characters. Syntactically postscript permits a wider range of glyph
names, but if you use non-ASCII characters some rasterizers might have problems.
Best to keep non-ASCII names within fontforge (and rename glyphs to adobe's
standard names before generating a font).
<H3>
<A NAME="Lookups">Lookups,</A> Features, Scripts and Languages
</H3>
<P>
OpenType (and Apple Advanced Typography) allow various transformations to
be applied to the input glyph stream to produce an output glyph stream. These
transformations might include forming ligatures, kerning glyphs closer to
each other, attaching vowel marks or diacritics to letters, conditionally
replacing one glyph with another depending on the glyphs around it, etc.
<P>
The commands for each transformation are stored in what are called lookups.
If you were designing a set of lookups to handle latin ligatures, you might
have one lookup for ff, fl and ffl -- ligatures that happen almost all the
time, another for fi and ffi -- ligatures which don't happen in Turkish but
do in other languages, and lookups for ct and st -- ligatures which rarely
happen in English but are more frequent in German (I think).
<P>
A Feature is a tagged collection of lookups. The tags are all 4 letter sequences
(like 'liga') with standardized meanings. The 'liga' tag means standard
ligatures. The 'dlig' tag means discretionary ligatures, and 'kern' means
kerning. There are many others.
<P>
Every script (latin, cyrillic, han ideographs, ...) will have its own set
of features that are meaningful to it. Sometimes things will be even more
complicated, and each language within a script will have it's own set of
features. In the example above we might assign scripts, languages, features
and lookups thusly:
<TABLE BORDER CELLPADDING="2">
<TR>
<TH>Script</TH>
<TH>Language</TH>
<TH>Feature</TH>
<TH>Lookups</TH>
<TH>Comments</TH>
</TR>
<TR>
<TD ROWSPAN=7>latn</TD>
<TD ROWSPAN=3>default</TD>
<TD ROWSPAN=2>liga (standard)</TD>
<TD>lookup for ff, fl and ffl</TD>
<TD></TD>
</TR>
<TR>
<TD>lookup for fi and ffi</TD>
<TD></TD>
</TR>
<TR>
<TD>dlig (discretionary)</TD>
<TD>lookup for ct and st</TD>
<TD></TD>
</TR>
<TR>
<TD>Turkish</TD>
<TD>liga</TD>
<TD>lookup for ff, fl and ffl</TD>
<TD>Lookups may be shared, so this can be the same lookup as above<BR>
(Turkish distinguishes between i and dotlessi and fi ligatures hide this
distinction.)</TD>
</TR>
<TR>
<TD ROWSPAN=3>German</TD>
<TD ROWSPAN=3>liga</TD>
<TD>lookup for ff, fl and ffl</TD>
<TD></TD>
</TR>
<TR>
<TD>lookup for fi and ffi</TD>
<TD></TD>
</TR>
<TR>
<TD>lookup for ct and st</TD>
<TD>Lookups may even be shared by a different feature type, so for English
and Spanish ct might count as a discretionary ligature, one rarely used,
while in German it mght be more common and be part of the standard ligature
set.</TD>
</TR>
</TABLE>
<P>
The default language means any language in the script which is not specifically
named. So in the above example the default language would be any language
except Turkish and German that might use the latin script.
<P>
It is also possible to have a default script. The digits 0-9, are used in
many writing systems, not just Latin and are considered Common to most scripts.
If you have lookups which apply to the digits (conversion to oldstyle digits,
or to proportional digits, or to superscripts...) you should attach those
lookups to features in all scripts (and languages) that could use them, and
to the default script (just in case).
<TABLE BORDER CELLPADDING="2">
<TR>
<TH>Script</TH>
<TH>Language</TH>
<TH>Feature</TH>
<TH>Lookups</TH>
<TH>Comments</TH>
</TR>
<TR>
<TD ROWSPAN=9>latn</TD>
<TD ROWSPAN=3>default</TD>
<TD>pnum</TD>
<TD>proportional number lookup</TD>
<TD></TD>
</TR>
<TR>
<TD>onum</TD>
<TD>old style number lookup</TD>
<TD></TD>
</TR>
<TR>
<TD>subs</TD>
<TD>subscript lookup</TD>
<TD></TD>
</TR>
<TR>
<TD ROWSPAN=3>Turkish</TD>
<TD>pnum</TD>
<TD>proportional number lookup</TD>
<TD></TD>
</TR>
<TR>
<TD>onum</TD>
<TD>old style number lookup</TD>
<TD></TD>
</TR>
<TR>
<TD>subs</TD>
<TD>subscript lookup</TD>
<TD></TD>
</TR>
<TR>
<TD ROWSPAN=3>German</TD>
<TD>pnum</TD>
<TD>proportional number lookup</TD>
<TD></TD>
</TR>
<TR>
<TD>onum</TD>
<TD>old style number lookup</TD>
<TD></TD>
</TR>
<TR>
<TD>subs</TD>
<TD>subscript lookup</TD>
<TD></TD>
</TR>
<TR>
<TD ROWSPAN=3>cyrl</TD>
<TD ROWSPAN=3>default</TD>
<TD>pnum</TD>
<TD>proportional number lookup</TD>
<TD></TD>
</TR>
<TR>
<TD>onum</TD>
<TD>old style number lookup</TD>
<TD></TD>
</TR>
<TR>
<TD>subs</TD>
<TD>subscript lookup</TD>
<TD></TD>
</TR>
<TR>
<TD ROWSPAN=3>DFLT</TD>
<TD ROWSPAN=3>default</TD>
<TD>pnum</TD>
<TD>proportional number lookup</TD>
<TD></TD>
</TR>
<TR>
<TD>onum</TD>
<TD>old style number lookup</TD>
<TD></TD>
</TR>
<TR>
<TD>subs</TD>
<TD>subscript lookup</TD>
<TD></TD>
</TR>
</TABLE>
<P>
There are roughly 15 different types of lookups which contain different
information. Different kinds of lookup are needed to specify ligature data,
glyph substitution data and kerning data.
<P>
Lookups may be specified with the
<A HREF="fontinfo.html#Lookups">Element->Font Info</A> dialog
<H4>
Lookup subtables
</H4>
<P>
I talk above about lookups as if they were simple things. Unfortunately they
aren't. Each lookup is composed of "Subtables" which actually do the work.
<P>
A lookup may contain several subtables. Most contain exactly one. (If a lookup
contains no subtables it will do nothing).
<P>
I said there were about 15 kinds of lookup, there are even more kinds of
subtable. For instance a subtable which specifies glyph to glyph kerning
is different from one which specifies glyph class to glyph class kerning.
<P>
At first glance the subtable may seem an unnecessary complication, but it
turns out to be desirable for one lookup to contain several kinds of sub-table
data. For instance, a kerning lookup might include one subtable providing
glyph class kerning, and then another subtable providing exceptions to that
on a glyph by glyph basis.
<H4>
How lookups are applied
</H4>
<P>
When a word processor deals with text, it will figure out what script is
in use in the text. Somehow it will figure out what the language is (maybe
it will just assume the "DFLT" language, maybe the user told it the text
was in French, maybe the locale is Spanish, ...).
<P>
In any script/language some features are applied by default, while others
may be applied at the user's discression. So in English the "liga" feature
should always be applied, while the "dlig" feature should only be applied
if the user asked for it. (Not all programs follow this at the moment, but
that's the theory).
<P>
The word processor will build up a list of features that might be active.
Then it looks in the font and sees which of those features are available
for this script and language. In turn each feature is composed of lookups,
and all lookups in all active features will be marked as active.
<P>
Lookups will be executed in the order in which they occur in the lookup list
(which is also the order shown in the Font Info->Lookup pane, but may
be quite different from the order in which the features were listed). And
all active lookups will be executed.
<P>
This ordering can be important. If you have both a small-caps lookup and
a ligature lookup active, and the text is "fi" then the order of the lookups
will probably matter. If the small-caps lookup happens first then the "fi"
will become "<SMALL>FI</SMALL>" and the ligature feature will not be applied.
If the ligature happens first then you will see an "fi" ligature for which
there is probably no small-caps glyph. In one case you get small-caps, in
another a ligature. Probably, here, you would like the small-caps lookup
to happen first.
<P>
Lookup subtables make life even more interesting. When a lookup is executed
the subtables within that lookup are activated in turn <EM>until one
succeeds</EM>. After that no further subtables will be applied.
<P>
So in the kerning example mentioned above, you would want to put the special
case glyph to glyph subtable first, and then the glyph class to class subtable
second. When a special case combination occurs the first subtable will succeed
(and kern the combination) and the class subtable will not be used. For
combinations which aren't special cases, then the first subtable will fail,
and the second will be applied.
<H4>
GPOS and GSUB
</H4>
<P>
Up till now I have spoken as there were one list of lookups. That was a
simplification. There are two broad classes of lookup, and two lists. There
are those involved in manipulating the glyphs themselves (glyph substitution,
ligation, decomposition, etc.) and those involved in positioning glyphs relative
to others (kerning, mark attachment, etc.).
<P>
The GSUB table contains all the glyph substitution lookups and <EM>all</EM>
of them will be processed before any positioning lookups are attempted.
<P>
The GPOS table contains all the glyph positioning lookups.
<H3>
<A NAME="Anchors">Anchor Points and Classes</A>
</H3>
<P>
Anchor points allow fine control of the positioning of two (or several) glyphs.
There are several different styles of attachment based on anchors: cursive,
mark to base, mark to ligature and mark to mark positioning. The first style
is used to join glyphs in flowing scripts (cursive) where the exit from one
glyph joins the entry point of the next. In the second style one of the glyphs
is the base glyph, and it will be positioned normally, the other glyph which
will often be a diacritic or vowel mark will be positioned so that the anchor
points in each glyph are coincident. Mark to ligature behaves similarly to
mark to base except that there may be more that one attachment point on the
ligature depending on which component a given mark is connected to. Finally,
mark to mark allows you to position two marks with respect to each other
(as you might need to do in vietnamese or hebrew where you may get several
marks for one glyph).
<P>
That is badly said. Consider the following two glyphs and how they are joined
to make the final result:
<TABLE>
<TR>
<TD><IMG SRC="a_with_anchor.png" WIDTH=104 HEIGHT=208></TD>
<TD>+</TD>
<TD><IMG SRC="grave_with_anchor.png" WIDTH=66 HEIGHT=208></TD>
<TD>=></TD>
<TD><IMG SRC="agrave_anchored.png" WIDTH=104 HEIGHT=208></TD>
</TR>
</TABLE>
<P>
The grave accent has been raised and moved to the right so that its anchor
point is positioned where the anchor from "a" was.
<P>
FontForge does not compose these glyphs (well, it can, but that's a completely
different area), instead it provides information within the
<A HREF="gposgsub.html">font</A> to a text layout program so that the program
can do the composition.
<P>
The example above is unlikely to be very useful since most latin fonts contain
pre-composed a-grave glyphs, but the same concepts apply to arabic and hebrew
where the number of variants is larger and the precomposed glyphs fewer.
<P>
That's roughly how anchor points are used. Now the mechanics.
<P>
Each of the different attachment styles mentioned above (cursive, mark to
base, mark to ligature and mark to mark) is a different type of GPOS lookup.
If you want to do attachment positioning you must first create the appropriate
lookup (<A HREF="fontinfo.html#Lookups">Element->Font
Info->Lookups->GPOS</A>, then a lookup subtable, and then an anchor
class within the lookup subtable. An anchor class is specified by providing
a name for it (in the above example the class was called "Top").
<P>
Cursive attachments are a little different from the other attachment types.
Each glyph has two attachment points, an entry and an exit (instead of just
the one shown in the mark to base example above). The text layout program
will attach the exit point of one glyph to the entry point of the next.
<P>
A glyph may contain several Anchor Points, but only one for each mark to
base anchor class (ligatures may have more than one for a class, and 'curs'
and 'mkmk' classes will usually have two). Inside a glyph may create a point
with the <A HREF="pointmenu.html#AddAnchor">Point->Add Anchor command</A>.
You must specify an anchor class, and whether this point is in a base glyph
or in a mark glyph, and a location. So in the example above the anchor point
in "a" has class "Top" and is a base glyph, while the anchor point in "grave"
also has class "Top" but is a mark glyph. There may be many base glyphs with
an anchor point named "Top" and many mark glyphs also with "Top" anchor points.
Any base glyph with a "Top" anchor point maybe composed with any mark glyph
with a "Top" anchor point. So instead of specifying the exact composed form
for all possible combinations we specify far fewer anchor points for the
same effect.
<P>
But life is not really that simple. Ligatures may need several anchor points
of the same class (one above each component for example). When you create
your anchor point you may say that it is to be in a ligature, in which case
you will also be asked for a ligature index -- a number running from 0 to
the number of components in the ligature -1. This allows you to position
several anchor points with the same class. The text layout program will place
the first mark over the first anchor point, the second mark over the second
and so on (this is a gross simplification).
<P>
Finally you may need to position two marks based on the same anchor point,
for example the glyph <IMG SRC="a_dieresis_macron.png" WIDTH=9 HEIGHT=14>
has a diaeresis and a macron over it. Both of which might normally be positioned
with the Top anchor class. Instead we define a special class for positioning
one mark with respect to another. When creating the anchor class specify
a tag of 'mkmk' (mark to mark) and call it something like "TopMark". When
you create a new anchor point for diaeresis you specify that it is a <EM>base
mark</EM> and you position it above the glyph, while the new anchor point
in macron should be of type mark and should be positioned at the same place
as the "Top" anchor point. Thus when given the sequence of glyphs "a diaeresis
macron" the text layout program should position "a" normally, position
"diaeresis" so that the its Top anchor point is where "a"'s is, and position
macron so that its TopMark anchor point is where "diaeresis"'s is.
<P>
Anchor points may be selected, dragged, transformed, cut, copied and pasted.
<H3>
<A NAME="Baseline">Baseline</A>s
</H3>
<P>
To a user of the latin alphabet it makes sense for the vertical origin of
a glyph to be the baseline on which most letters
rest<IMG SRC="latinBaseline.png" WIDTH="93" HEIGHT="45">. This means that
if you change the pointsize of a glyph it will still line up
properly<IMG SRC="latinNormalBaseline.png" WIDTH="91" HEIGHT="21">. This
is so obvious we don't even think about it. But if you put the vertical origin
at the top of the letter then the letters will be aligned quite differently,
and to our eyes,
unexpectedly<IMG SRC="latinHangBaseline.png" WIDTH="90" HEIGHT="21">.
<P>
Different scripts have different expectations of how glyphs should be aligned.
In latin (cyrillic, greek, arabic, hebrew, etc.) the alignment point, the
baseline, is somewhere in the middle of the possible extent of a glyph --
that is the script has both ascenders above the baseline and descenders below
it.
<P>
But not all scripts are like that. In Devanagari the alignment point is near
the top of the glyph -- indeed most glyphs will draw in the baseline
explicitly<IMG SRC="devaBaseline.png" WIDTH="97" HEIGHT="46">. If you change
the pointsize you want glyphs to line up on this
line<IMG SRC="devaHangBaseline.png" WIDTH="82" HEIGHT="21">, and not down
at the bottom of the glyph
<IMG SRC="devaLatinBaseline.png" WIDTH="76" HEIGHT="18">.
<P>
In CJK ideographs the baseline is usually drawn at the bottom edge of the
square which contains the glyph.
<P>
However if you try and typeset these different scripts together with their
baselines in the same place you get a mess:
<IMG SRC="misalignedBaselines.png" WIDTH="65" HEIGHT="38">. It would be much
nicer if it were possible to say that these different scripts have their
baselines in different places so that the glyphs can fit together
reasonably:<IMG SRC="alignedBaselines.png" WIDTH="65" HEIGHT="23">. Both
Apple Typography and OpenType allow for this. There is a
<A HREF="baseline.html">baseline table </A>which says how the baselines for
each script (or each glyph) should be aligned with respect to other baselines.
<H3>
<A NAME="FontView">Font View</A>
</H3>
<P>
The <A HREF="fontview.html">font view</A> displays all the glyphs in the
font (or all that will fit in the window). Every line has two parts, at the
top is a label, often small clear letters, underneath that, somewhat larger
is a 24 pixel rasterization of the font you have designed. As you edit a
glyph in an <A HREF="#CharView">outline glyph view</A> its small version
in the font view will change as you work.
<P>
Double-clicking on a glyph will bring up an outline glyph view of that glyph
which will allow you to edit it.
<P>
Selecting several glyphs will allow you to apply various operations to all
of them, or to cut and paste them.
<P>
<IMG SRC="AmbrosiaFV.png" WIDTH="423" HEIGHT="226">
<P>
Fonts do not need to be for the latin alphabet alone. Below is a view of
one of <A HREF="ftp://ftp.ipl.t.u-tokyo.ac.jp/Font/">Wadalab</A>'s public
domain Kanji fonts...
<P>
<IMG SRC="kanjifont.png" WIDTH="423" HEIGHT="212">
<P>
Another Wadalab font encapsulated in a CID keyed font
<P>
<IMG SRC="fontview-cid.png" WIDTH="573" HEIGHT="226">
<H3>
<A NAME="CharView">Outline Glyph View</A>
</H3>
<P>
The <A HREF="charview.html">outline view</A> is probably the most complex
view in FontForge. This is where you actually edit the splines
(<A HREF="bezier.html">Bézier splines</A>) that make up your glyphs.
<P>
You may have a background image loaded into the view to help you trace out
the shape you are working on (it is displayed in grey). There are various
grid lines visible, some created by default (the baseline, the ascent line,
the descent line, and a line at x=0), you may add others yourself.
<P>
There is a layer showing the glyph's hints.
<P>
In the foreground are the splines and points of the glyph itself, and the
width line (you may adjust the glyph's width by moving this line). If a point
is selected then its control points will be displayed.
<P>
To the left of the main window (the image below shows them on the right,
that was just to keep them from crowding things, you can move them around)
are two palettes, one a palette of tools, and the other a palette controlling
what layers (foreground, background, grid, hints) are visible and editable.
<P>
<IMG SRC="charview2.png" WIDTH="544" HEIGHT="656">
<H3>
<A NAME="BitmapView">Bitmap View</A>
</H3>
<P>
The <A HREF="bitmapview.html">bitmap view</A> is similar to the outline view
above. It also has a tools and layer palette.
<P>
This allows you to edit bitmap versions of the outline glyphs you create
above.
<P>
In the background is a small rendition of the outline, and in the foreground
are the bits of the image. You may make the program calculate which bits
should be set by pressing the "Recalculate button", the results usually need
to be tweaked by hand. In the upper left corner is a full sized image of
your bitmap glyph.
<P>
<IMG SRC="BitmapView.png" WIDTH="254" HEIGHT="273">
<H3>
<A NAME="MetricsView">Metrics View</A>
</H3>
<P>
The <A HREF="metricsview.html">metrics view</A> allows you to see how the
glyphs look together.
<P>
You can change the width and left/right bearings of a glyph, either by dragging
in the upper part of the window or by entering an appropriate number in the
lower.
<P>
You can also provide kerning information for any two adjacent glyphs. You
can view how various OpenType features affect the glyph stream
<TABLE>
<TR>
<TD><IMG SRC="MetricsView.png" WIDTH="479" HEIGHT="331"></TD>
<TD><IMG SRC="MetricsView-features.png" WIDTH="463" HEIGHT="330"></TD>
</TR>
</TABLE>
<P>
<IMG SRC="VerticalMetrics.png" WIDTH="270" HEIGHT="573" ALIGN="Right">Note
that in Hebrew, or Arabic (or any other right to left alphabet) the glyphs
will start on the right and run to the left. While in CJK fonts you may want
to see things arranged vertically.
<P>
<IMG SRC="HebrewMetrics.png" WIDTH="511" HEIGHT="323">
<P>
<P>
<P ALIGN=Center>
-- <A HREF="editexample.html">Next</A> --
</DIV>
</BODY></HTML>
distrib
>
Mageia
>
5
>
i586
>
media
>
core-release
>
by-pkgid
>
6b465285c9860724a695461ac61807f4
>
files
>
596
