Cubic Beziers in glyf table

[simoncozens]

Easiest way to do this:

• Interpret flag bit 7 as a "this marks a qcurve" on off-curve points
• Bump glyf table version (glyphDataFormat) in head table

Things to think about:

• Implied on-curves?
• (Splines of) mixed dimensionality curves
• (Splines of) mixed dimensionality curves with no explicit off-curves between them 😱

[behdad]

Okay I opened OpenType/opentype-next#7
Just closed that one and copying my comment here.

[behdad]

Suggesting that we move cubics-for-glyf discussion here.

I see two ways:

Use flag bit 7 to add cubics in, without bumping any version or major bump. glyf table has its version in head table's glyphDataFormat; not sure if any software checks that. That might be good if they don't check if we choose the semi-backward-compatible way (more about that below).

Given that glyf table was the common thread we inherited from TrueType and has not changed in 30ish years, changing it drastically constitutes a new font format, so we might as well address many other issues at the same time, in particular: 1. 16bit GIDs, and 2. add versatile component reuse (including variations), particularly without consuming GIDs necessarily.

[NorbertLindenberg]

Do the cubic curves have to live in the glyf table, or could they be in a new table, say cube? The second option would allow a gradual transition, where fonts provide both cube and glyf tables, implementations that know about cube would prefer it, but others would still have glyf as a fallback. Yes, related data in other tables, such as for hinting, needs to be considered too.

[behdad]

Just want to leave this about cu2qu algorithm here, because it is relevant. I'll comment on the relevance later.
googlefonts/cu2qu#10

[simoncozens]

The nice thing about (ab)using bit 7 in the glyf table is that you get the potential to use cubic and quadratic curves in the same glyph. This may however create more potential for confusion than it is worth...

[Lorp]

Here is the messy Twitter thread where some discussion took place on 2020-09-16. Twitter makes it very difficult to follow the whole discussion.

[Lorp]

Coincidentally that afternoon I published a build of Samsa that handles an experimental version of TrueType: Samsa Cubic. Versions of MutatorSans as quadratic (standards compliant) and cubic (non-compliant) are included for convenient comparison.

The experimental “ttf-cubic” format is identical to TrueType, except:

• off-curve points are defined to be cubic, not quadratic
• off-curve points come in strict pairs, between on-curve points
• the first 4 bytes of the file are "CUBE" instead of 0x00010000

Design goals for ttf-cubic:

• faithful representation of the type designer’s cubic curves, like CFF2
• easy to make from cubic UFO sources

Follow these instructions if you want to make one:

1. Obtain cubic UFO font sources with .designspace that already makes a working variable font
2. Replace "curve" with "qcurve" in all .glif files — this fools fontmake that the font is quadratic, so no cu2qu
3. Run fontmake -o variable -m your.designspace on the .designspace as normal
4. Overwrite the first 4 bytes of the file with "CUBE" — this tells Samsa to treat the curves as cubic
5. Make the extension "ttf-cubic"

Remember the only environment that supports ttf-cubic is Samsa!

Note that there is nothing specifically relating to variable fonts in ttf-cubic, although currently Samsa does not handle static fonts.

If anyone has other prototype font/table formats that they would like to try out in Samsa, please let me know.

[Lorp]

Using bit 7 on every cubic off-curve point is safe, I think. To retain the benefits of sequences of smooth curves in cubic and quadratic, to avoid recoding existing fonts, and interpreting usefully all combinations of off-curve, on curve and bit7, we can allow cubics to be optionally defined by one off-curve point defining both tangents like a quadratic, its two mathematical control points at the same position.

Some examples (the 0 and 1 below represent bit 7):

• on-off0-on = simple quadratic curve
• on-off0-off0-on = two quadratic curves, with implied on-curve point between 2nd and 3rd point
• on-off1-off1-on = simple cubic curve
• on-off1-on = cubic curve with collocated control points
• on-off1-off1-off1-off1-on = two cubic curves, with implied on-curve point between 3rd and 4th point
• on-off1-off1-off1-on = two cubic curves, with implied on-curve point between 3rd and 4th point, the second cubic curve with collocated control points
• on-off1-off1-off0-on = cubic curve followed by quadratic curve with an implied on-curve point between the 3rd and 4th point
• on-off0-off1-off1-on = quadratic curve followed by cubic curve with an implied on-curve point between the 2nd and 3rd point
• off1-off1-off1-off1-off1-off1-off1-off1 = a smooth curved shape requiring 4 cubic bezier curves, such as a circle or O

Bit 7 set for an on-curve point is an error, or ignored for this table version.

Too complicated? One option might be to keep to one curve order per contour, so just one flag needed, which could be stolen from the endPts array (limiting point ids to max 32767 instead of 65535).