[CFF] Encoding supplements are not yet supported

[tkacvins]

I have converted some of the CM fonts to OTF format, and was wanting to run ttx on it to see what type of work AFDKO did for subroutines generation. But the CM fonts use an encoding supplement the CM fonts don't use one of the typical encodings), which ttx doesn't support these yet. Any timeline for when this will be supported?

[khaledhosny]

Please add more details about what you are trying to do and how exactly this is failing.

[tkacvins]

I have converted the Computer Modern font cmbx10.pfb to cmbx10.otf using the AFDKO tools makeotf. Then, I ran the latest fonttools ttx tool on the file, as follows ttx cmbx10.otf, and got the following Python trace back

Dumping 'CFF ' table...
ERROR: Unhandled exception has occurred
Traceback (most recent call last):
  File "/Users/tjk/afdko_env/lib/python3.7/site-packages/fontTools/ttx.py", line 397, in main
    process(jobs, options)
  File "/Users/tjk/afdko_env/lib/python3.7/site-packages/fontTools/ttx.py", line 370, in process
    action(input, output, options)
  File "/Users/tjk/afdko_env/lib/python3.7/site-packages/fontTools/misc/loggingTools.py", line 372, in wrapper
    return func(*args, **kwds)
  File "/Users/tjk/afdko_env/lib/python3.7/site-packages/fontTools/ttx.py", line 268, in ttDump
    newlinestr=options.newlinestr)
  File "/Users/tjk/afdko_env/lib/python3.7/site-packages/fontTools/ttLib/ttFont.py", line 212, in saveXML
    self._saveXML(writer, **kwargs)
  File "/Users/tjk/afdko_env/lib/python3.7/site-packages/fontTools/ttLib/ttFont.py", line 267, in _saveXML
    self._tableToXML(tableWriter, tag, splitGlyphs=splitGlyphs)
  File "/Users/tjk/afdko_env/lib/python3.7/site-packages/fontTools/ttLib/ttFont.py", line 298, in _tableToXML
    table.toXML(writer, self)
  File "/Users/tjk/afdko_env/lib/python3.7/site-packages/fontTools/ttLib/tables/C_F_F_.py", line 41, in toXML
    self.cff.toXML(writer)
  File "/Users/tjk/afdko_env/lib/python3.7/site-packages/fontTools/cffLib/__init__.py", line 213, in toXML
    font.toXML(xmlWriter)
  File "/Users/tjk/afdko_env/lib/python3.7/site-packages/fontTools/cffLib/__init__.py", line 2585, in toXML
    BaseDict.toXML(self, xmlWriter)
  File "/Users/tjk/afdko_env/lib/python3.7/site-packages/fontTools/cffLib/__init__.py", line 2489, in toXML
    value = getattr(self, name, None)
  File "/Users/tjk/afdko_env/lib/python3.7/site-packages/fontTools/cffLib/__init__.py", line 2481, in __getattr__
    value = conv.read(self, value)
  File "/Users/tjk/afdko_env/lib/python3.7/site-packages/fontTools/cffLib/__init__.py", line 1221, in read
    return self._read(parent, value)
  File "/Users/tjk/afdko_env/lib/python3.7/site-packages/fontTools/cffLib/__init__.py", line 1687, in _read
    raise NotImplementedError("Encoding supplements are not yet supported")
NotImplementedError: Encoding supplements are not yet supported

I am attaching the OTF file for further analysis.

cmbx10.otf.zip

[khaledhosny]

This is explained in Technical Note #5176 p.20. I don’t know what CFF Encodings are used for, but they seem pretty useless for OpenType fonts. I think we should just relax this assert and make it a warning, the font loads otherwise and looks rather functional to me.

[anthrotype]

/cc @josh-hadley

[tkacvins]

Page 19 of the CFF spec says

A few fonts have multiply-encoded glyphs which are not supported directly by any of the above formats

Where the "above formats" are Format0 and Format1.

The Computer Modern fonts do indeed have multiply-encoded glyphs. AFKDO adds a supplemental encoding table to the CFF data in an OTF font when the input Type 1 PFA has multiply-encoded glyphs, so I think it is important that typetools handles this case - that is, don't issue a warning and do not throw an exception. I want to say a long time ago I had discussed this with Just, but that was about 17 years ago, so the exact details of that conversation are lost.

[khaledhosny]

I don’t understand the implication of these “multiply-encoded glyphs” in an OpenType font, where character to glyph mapping is handled by the cmap table and any “encoding” information in CFF table is probably unused.

[tkacvins]

I understand the cmap table is the entry point in an OTF font for glyph mapping. But I currently cannot disassemble the CFF section of an OTF font. I can see adding support for disassembling the supplemental encoding, or not disassembling it and leaving it as hexadecimal data, but the rest of the CFF section is disassembled. Either works, as long as I can use ttx to disassemble the majority of the CFF data. Or, I can make a fork of fonttools and attempt a patch at disassembling the supplemental encoding. There is plenty of code that relates to obtaining data from the CFF section from which I can start.

[tkacvins]

I have created a fork and am thinking about this. Read/writing the binary data from/to the CFF table in one thing, but I am tripped up on a round-robin issue. When it comes to an encoding, it can be Format 0 or 1, and with or without a supplemental encoding. I was thinking it would nice for the encoding tag in the XML file would have subelements, something like this (totally made up):

<Encoding>
  <Format type=X>
    <map code="0x0" name="Gamma"/>
    <map code="0x1" name="Delta"/>
    <map code="0x2" name="Theta"/>
    <map code="0x3" name="Lambda"/>
    <map code="0x4" name="Xi"/>
  </Format>
  <Supplements>
    <map code="0x80" name="Gamma"/>
    <map code="0x81" name="Delta"/>
    <map code="0x82" name="Theta"/>
    <map code="0x83" name="Lambda"/>
    <map code="0x84" name="Xi"/>
  </Supplements>  
</Encoding>

where X above is 0, 1, 0x80 or 0x81. This would make ttx have fidelity to the original font when it compiles the XML into a font. But this introduces a compatibility issue with older *.ttx files.

Thoughts? There are fonts out there that have supplemental encodings, and without the supplemental encoding parsed, I can't use ttx to round-robin as I don't have a complete CFF table.