TTF to OTF is on hold On hold

This conversion is not available

Not implemented and not faked. Producing OpenType/CFF outlines from TrueType requires a CFF charstring writer this build does not have.

The quadratic-to-cubic direction is mathematically exact, so unlike OTF to TTF this conversion loses no curve accuracy. What it does require is an entire CFF writer: a Type 2 charstring encoder, the INDEX and DICT structures, a charset built from glyph names, a Private DICT with correct default and nominal widths, and a "maxp" downgraded to version 0.5 as CFF-flavoured fonts require.

It also drops things. TrueType hinting bytecode ("fpgm", "prep", "cvt ", "gasp") has no CFF equivalent and disappears. Composite glyphs have to be flattened, because CFF has no component references, which makes accented glyph sets larger rather than smaller.

The honest question is why you would want it. A .otf is not better than a .ttf; the extension only signals which outline model is inside. Both install identically on every desktop operating system, and both compress to WOFF2 for the web. Most requests for this conversion come from a tool or a client that asked for "an OTF" when it meant "a font".

If a real need for CFF outlines appears — a print workflow that requires PostScript curves, for instance — the writer is tracked in BACKLOG.md alongside the interpreter needed for the reverse direction.

What to do instead

• Ship the .ttf as-is — Confirm with the inspector that your file is valid TrueType. If it is, nearly every consumer of "an OTF" accepts it unchanged.
• Build a web font instead — For web use, the outline model is irrelevant. The web-font pack emits WOFF2 plus WOFF, the CSS and a preload tag from your .ttf directly.
• Read what the two formats actually differ on — The formats page lays out glyf versus CFF, what each one supports, and when the distinction matters.