Open type Glyph table version 1

mitradranirban
mitradranirban Posts: 141
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,658
    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,533
    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: 141
    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.


  • Dave Crossland
    Dave Crossland Posts: 1,533
    Ah, excellent correction Peter :) 
  • John Hudson
    John Hudson Posts: 3,658
    Now wondering if anyone has made a CFF COLR font, and where/if it works correctly? I can totally see that, in theory, it should work and there is no reason within the COLR format that it shouldn’t. But software makers love an erroneous format assumption. :)
  • mitradranirban
    mitradranirban Posts: 141
    For colr v0 it is possible to easily create .otf with cff/cff2 with current toolchain such as fontmake, and infact I am doing so in ColrPak,  but for v1 the tools are absent and needed to be created from scratch for cff/cff2 support. And after glyph1 becomes well accepted, cff / cff2 may become of historical interest, just like Type1 or MultipleMaster format

Categories