Open type Glyph table version 1

mitradranirban
mitradranirban Posts: 137
in Type Design Technique & Theory
Is the proposal to include cubic bezier in .ttf fonts accepted by OpenType?
If enabled, what will be its pros and cons over cff/cff2? 
Tagged:

Best Answers

  • John Hudson
    John Hudson Posts: 3,652
    Answer ✓
    I don’t know what the status of this idea is, but I have not heard anything about it for a long time. One of the key attractions of the idea was to make the TrueType instruction (hinting) model applicable to cubic outlines and, of course, avoiding having to convert outlines from the type industry’s overwhelmingly cubic design sources to quadratic production output.

    The CFF2 fornat is in some ways an improvement on CFF, which was really just a separate font file format stuck in an OpenType sfnt wrapper. CFF2 is better integrated into the overall OT format. So I am not sure whether there is the same level of interest in cubic outlines in the Glyph table as there was 10+ years ago.
  • Dave Crossland
    Dave Crossland Posts: 1,527
    edited April 28 Answer ✓
    Glyf v1 is included in the (as of writing) 'next' edition of the ISO MPEG Open Font Format, which is likely to be published within a month or two (along with avar2, beyond 64k glyphs, and the "VARC" file format for variable components, which currently Fontra.xyz can output).

    I'm glad you see some of the reasons why this is attractive; for me CFF2 was not better integrated into the overall format, because it remains just as much as "separate font file format stuck in an sfnt wrapper" as CFF v1. Neither work with COLR tables or any other sfnt tables besides GPOS/GSUB. And then SVG-in-OT has color support but no variations, due to the same root issue.

    But glyf v1 works with all sfnt tables, same as v0! :)

    However, it is "necessary but not sufficient" for the changes first proposed in https://github.com/harfbuzz/boring-expansion-spec to be accepted into an institutional specification. What matters is widespread implementation, and afaik there's been none of that for glyf v1 yet. Of the 4 'boring' things, only avar2 has shipped widely - in Android, in iOS and macOS, and on May 5th, in Chrome stable; leaving only Firefox on Windows as a major platform without run-time support.

    But design and text authoring apps is a different story, and what really matters for real world adoption; Sketch is good because it uses the macOS text subsystem, and web apps that use browser text engines will be good for avar2 after the Chrome launch with that Firefox Windows exception (unless they use the Samsa Polyfill), but Figma, Adobe apps, Affinity, etc are all yet to support...


Answers

  • mitradranirban
    mitradranirban Posts: 137
    Actually I modified fontra-compile to generate color v1 fonts in ColrPak. But fontra-compile is originally created to make glyph1 table, and colrv1 font with glyphv1 table is not accepted by any browser. So had to remodify the code so that glyph0 table is generated in color v1 fonts. It seems it will take a long time for glyph1 to be acceptable.
  • Peter Constable
    Peter Constable Posts: 277
    Dave Crossland said:
    ...for me CFF2 was not better integrated into the overall format, because it remains just as much as "separate font file format stuck in an sfnt wrapper" as CFF v1. Neither work with COLR tables or any other sfnt tables besides GPOS/GSUB. And then SVG-in-OT has color support but no variations, due to the same root issue.
    Well, the SVG table doesn't integrate with much else in the spec at all.

    But as for CFF(2) and COLR, what Dave says is incorrect. The COLR table spec says the following:

    For both version 0 and version 1, shapes are obtained from glyph outlines in the 'glyf', 'CFF ' or CFF2 table, referenced by glyph ID.


Categories