Glyph Outlines: TrueType vs CFF
Understand how TrueType quadratic curves and CFF cubic Bezier curves differ, and what happens when converting between them.
Key Takeaways
- • TrueType uses quadratic Bezier curves (glyf table)
- • CFF uses cubic Bezier curves (CFF/CFF2 table)
- • Cubic to quadratic conversion increases point count
- • Quadratic to cubic conversion is mathematically exact
In this article
The visual appearance of every character in a font is defined by its outline—a mathematical description of curves and lines that bound the glyph shape. The two major outline formats in OpenType fonts use different mathematical representations, with implications for quality, file size, and conversion.
TrueType outlines were developed by Apple in 1987 as the mathematical basis for their operating system's font rendering. Microsoft adopted TrueType for Windows, and it became the standard for system fonts on both platforms. Adobe, meanwhile, had been using cubic Bézier curves in its PostScript and Type 1 fonts since the early 1980s. When OpenType was jointly developed by Adobe and Microsoft in 1996, it unified both outline types under a single container format: a font can use TrueType quadratic curves (the glyf table) or PostScript cubic curves (the CFF table), but not both simultaneously within one font. This historical split is the direct reason why converting between TTF and OTF involves a mathematical curve-type transformation, not just a file-format change.
The choice of curve type has practical consequences beyond file format compatibility. Quadratic curves, with their single off-curve control point per segment, require more segments to approximate complex shapes—the bowl of an "a", the ink trap at the junction of a serif, or the terminals of a script "g". Cubic curves, with two control points per segment, can represent inflection points in a single segment and offer more expressive control over tangent directions. Type designers who work in vector illustration tools like Illustrator or Figma use cubic curves natively, making CFF-based OTF a natural output format. Those working in dedicated font applications like Glyphs.app can work in either format, with the application handling conversion as needed.
Quadratic vs Cubic Bezier Curves
TrueType (Quadratic)
Uses quadratic Bezier curves with 3 control points: start point, one off-curve control point, and end point.
B(t) = (1-t)²P0 + 2(1-t)tP1 + t²P2
- • Stored in glyf table
- • Faster to rasterize
- • Needs more points for complex curves
- • Uses on-curve and off-curve points
CFF (Cubic)
Uses cubic Bezier curves with 4 control points: start point, two control points, and end point.
B(t) = (1-t)³P0 + 3(1-t)²tP1 + 3(1-t)t²P2 + t³P3
- • Stored in CFF/CFF2 table
- • More expressive per segment
- • Fewer points needed overall
- • Based on PostScript Type 1
On-Curve vs Off-Curve Points
TrueType outlines distinguish between on-curve points (points the outline actually passes through) and off-curve points (control points that attract the curve without touching it). When two consecutive off-curve points appear in a TrueType contour, the renderer implies an on-curve point exactly at their midpoint. This implicit midpoint rule allows compact storage of smooth curves—a circular arc can be approximated with just four explicit off-curve points and four implied on-curve midpoints.
TrueType Point Flag Byte: Bit 0 = 1: On-curve point (outline passes here) Bit 0 = 0: Off-curve quadratic control point Implicit on-curve rule: Sequence [OFF, OFF] in contour data → Renderer inserts ON* at midpoint of OFF1 and OFF2 → Actual path: [OFF1] → [ON*] → [OFF2] Circle approximation (8 total points): 4 explicit OFF points at compass positions (N, E, S, W) 4 implied ON points at 45° positions (NE, SE, SW, NW) Result: smooth quadratic approximation of a circle
CFF outlines use only explicit control points—the implicit midpoint rule does not apply. Every on-curve and off-curve point must be declared explicitly in the charstring. This means a TrueType font may appear to have fewer listed points than its CFF counterpart, even when representing identical shapes.
Winding Rules and Contour Direction
TrueType and CFF use opposite conventions for contour direction to define filled regions:
TrueType (Non-Zero Winding)
Outer contours run clockwise (↻). Inner contours (holes, as in "O") run counter-clockwise (↺). The rasterizer counts directional crossings: non-zero = filled region.
CFF (Even-Odd / PostScript)
Outer contours run counter-clockwise (↺). Inner contours run clockwise (↻). Exactly opposite to TrueType. Converting outlines requires reversing all contour directions.
Incorrect contour direction is one of the most common validation errors. A letter like "O" with the wrong inner contour direction fills solid instead of showing the center hole. Font Bakery's check/correct_contour_direction catches this; FontForge's Element → Correct Direction fixes it automatically.
Rasterizers implement winding rules at the pixel level using scan-line ray casting. For each pixel center, the renderer fires a horizontal ray leftward and counts how many contour segments it crosses, weighted by direction. Each clockwise crossing contributes +1; each counter-clockwise crossing contributes −1. The non-zero winding rule fills a region if the final count is non-zero. This is why TrueType outer contours run clockwise (contributing +1) and inner contours run counter-clockwise (contributing −1): pixels within the inner contour see both crossings and sum to zero, correctly rendering as unfilled holes. Reversing the inner contour makes it contribute +1, totaling +2, and the "hole" fills solid—the visual defect in a letter like "O" or "D" rendered as a black rectangle.
Practical outline quality matters beyond validation compliance. Outlines with unnecessary points, very short segments, or near-duplicate coordinates that differ by only one or two units can produce visual artifacts at specific rendering sizes. These micro-irregularities are invisible at large sizes but can produce subtle bumps or inconsistent anti-aliasing at 12–14px where individual pixels have significant visual weight. Professional font production includes outline cleanup steps: removing redundant on-curve points on straight segments, resolving near-coincident points, and simplifying overly complex curves while staying within the tolerance thresholds that make conversion quality imperceptible.
Outline Conversion
| Conversion | Quality | File Size |
|---|---|---|
| Quadratic → Cubic | Exact (lossless) | Slightly smaller |
| Cubic → Quadratic | Approximation | 20-50% larger |
Cubic to Quadratic Conversion
A single cubic curve may require 2-4 quadratic segments to approximate accurately. This increases point count and file size. Quality loss is usually imperceptible except at extreme magnification, but high-quality fonts may notice subtle differences in curve smoothness.
Conversion Quality Thresholds
When converting cubic CFF curves to quadratic TrueType, tools like fontTools use an error tolerance to determine how many quadratic segments to generate per cubic. The default tolerance is approximately 0.001 font units per em—well below the threshold of visual perception at any normal rendering size.
| Curve Shape | Quadratic Segments Needed | Approx. Point Increase |
|---|---|---|
| Gentle arc (C, c, open bowl) | 2 segments | ~1.5–2× |
| S-curve (s, z diagonals) | 3–4 segments | ~2.5–3× |
| Tight cusp or inflection | 4–6 segments | ~3–4× |
| Straight line segment | 1 segment | No increase |
A typical Latin font converted from OTF to TTF sees overall glyph point counts increase by 20–35%. At rendering sizes up to 400px, no visual difference is perceptible. Conversion artifacts (slight polygon edges at curve peaks) are only visible at extreme magnification (2,000%+) in design software—they have no impact on screen or print rendering.
Composite Glyphs
Both TrueType and CFF support composite glyphs—characters built from references to other glyphs. For example, "e" can reference the base "e" glyph plus an acute accent glyph with positioning data.
Composite glyph example: é (U+00E9) ├── Component 1: Glyph "e" (ID: 72) │ └── Transform: none (identity) ├── Component 2: Glyph "acutecomb" (ID: 302) │ └── Transform: translate(0, 180) └── Result: Shared outlines, smaller file
Composite glyphs are fully supported in both TrueType and CFF outline formats, but their interaction with hinting differs between the two systems. TrueType's bytecode hinting operates on the final composed outline, while CFF hints are stored per-component and applied independently. When components are scaled, rotated, or flipped in composite definitions, hinting instructions designed for the original orientation may produce suboptimal results.
Composite Glyph Trade-offs
Advantages
- • Shared outline data reduces file size
- • Changes to base glyph propagate to composites
- • Reduces design inconsistencies across accented sets
- • pyftsubset preserves composites when components are included
Trade-offs
- • Hinting quality degrades with transforms applied
- • Some subsetting tools decompose composites to simple glyphs
- • Font Bakery flags composites with shifted component origins
- • CFF2 variable fonts require decomposing composites for variations
Convert Fonts with Quality Control
Our tools handle outline conversion with optimal quality settings.
Try Font Converter
Written by
Sarah Mitchell
Product Designer, Font Specialist
Verified by
Marcus Rodriguez
Lead Developer
Glyph Outlines FAQs
Common questions about TrueType and CFF outline formats