embedding CFF-based OpenType fonts via FontFile3CIDType0

[seehuhn]

When running the attached PDF file through TestGrammar, I get the error message

Error: wrong value for possible values: Subtype (FontFile3CIDType0) should be: name [CIDFontType0C] in PDF 1.7 and is name==OpenType

My reading of the PDF spec is, that OpenType is in fact allowed, and possibly even required here: The FontFile3 entry of Table 124 lists three possible values for Subtype, one of which is OpenType. This subtype, in turn, can be used in three different situations, one of which is described as

A CIDFontType0 CIDFont dictionary, if the embedded font program contains a "CFF " table [...] with a Top DICT that uses CIDFont operators (this is equivalent to subtype CIDFontType0C).

This is the type of font embedded in the attached PDF file. I don't completely understand the meaning of the "is equivalent" clause cited above, but in my reading the table definitely allows, and possibly required use of the OpenType subtype for this font.

fonts09.pdf

For reference, here is a decoded version of the relevant dictionaries:

• The Type 0 font dictionary (object 1):

  <<
  /Type /Font
  /Subtype /Type0
  /BaseFont /IPSVQA+Go-Regular-Seehuhn-4de0580189d4bfc2
  /DescendantFonts [3 0 R]
  ...
  >>
  

• The CIDFont dictionary (object 3):

  <<
  /Type /Font
  /Subtype /CIDFontType0
  /BaseFont /IPSVQA+Go-Regular
  /FontDescriptor 4 0 R
  ...
  >>
  

• The Font Descriptor (object 4):

  <<
  /Type /FontDescriptor
  /FontName /IPSVQA+Go-Regular
  /FontFile3 5 0 R
  ...
  >>
  

• The embedded font stream dictionary (object 5):

  <<
  /Filter /FlateDecode
  /Length 1812
  /Subtype /OpenType
  >>
  

[petervwyatt]

Looks like we didn't turn the page... FontFile3 is split into 3 separate rows on pages which is unique in 32K: every other key is always a single row. Thus also a formatting error in 32K!