cvXX featureNames yields corrupt binary code

[adrientetar]

I tried to add featureNames to my cvXX features in the same way it is done with ssXX, here is a sample code:

feature cv01 {
    featureNames {
        name "Superscript \00AE"; # Windows English
        name 1 0 0 "Superscript \A8"; # Mac English
        name 3 1 0x040c "\00AE \00E0 l\2019exposant"; # Windows French
        name 1 0 1 "\A8 \88 l\D5exposant"; # Mac French
    };
    [...]
}

The AFDKO gives no warning or error whatsoever yet ttx decompilation errors:

           File "/home/adrien/bin/FDK/Tools/linux/Python/lib/python2.7/site-packages/FontTools/fontTools/ttLib/__init__.py", line 391, in __getitem__
             table.decompile(data, self)
           File "/home/adrien/bin/FDK/Tools/linux/Python/lib/python2.7/site-packages/FontTools/fontTools/ttLib/tables/otBase.py", line 44, in decompile
             self.table.decompile(reader, font)
           File "/home/adrien/bin/FDK/Tools/linux/Python/lib/python2.7/site-packages/FontTools/fontTools/ttLib/tables/otBase.py", line 568, in decompile
             table[conv.name] = conv.read(reader, font, table)
           File "/home/adrien/bin/FDK/Tools/linux/Python/lib/python2.7/site-packages/FontTools/fontTools/ttLib/tables/otConverters.py", line 245, in read
             table.decompile(reader, font)
           File "/home/adrien/bin/FDK/Tools/linux/Python/lib/python2.7/site-packages/FontTools/fontTools/ttLib/tables/otBase.py", line 563, in decompile
             l.append(conv.read(reader, font, table))
           File "/home/adrien/bin/FDK/Tools/linux/Python/lib/python2.7/site-packages/FontTools/fontTools/ttLib/tables/otConverters.py", line 182, in read
             table.decompile(reader, font)
           File "/home/adrien/bin/FDK/Tools/linux/Python/lib/python2.7/site-packages/FontTools/fontTools/ttLib/tables/otBase.py", line 568, in decompile
             table[conv.name] = conv.read(reader, font, table)
           File "/home/adrien/bin/FDK/Tools/linux/Python/lib/python2.7/site-packages/FontTools/fontTools/ttLib/tables/otConverters.py", line 245, in read
             table.decompile(reader, font)
           File "/home/adrien/bin/FDK/Tools/linux/Python/lib/python2.7/site-packages/FontTools/fontTools/ttLib/tables/otBase.py", line 568, in decompile
             table[conv.name] = conv.read(reader, font, table)
           File "/home/adrien/bin/FDK/Tools/linux/Python/lib/python2.7/site-packages/FontTools/fontTools/ttLib/tables/otConverters.py", line 245, in read
             table.decompile(reader, font)
           File "/home/adrien/bin/FDK/Tools/linux/Python/lib/python2.7/site-packages/FontTools/fontTools/ttLib/tables/otBase.py", line 563, in decompile
             l.append(conv.read(reader, font, table))
           File "/home/adrien/bin/FDK/Tools/linux/Python/lib/python2.7/site-packages/FontTools/fontTools/ttLib/tables/otConverters.py", line 141, in read
             return reader.readUInt24()
           File "/home/adrien/bin/FDK/Tools/linux/Python/lib/python2.7/site-packages/FontTools/fontTools/ttLib/tables/otBase.py", line 162, in readUInt24
             value, = struct.unpack(">l", b'\0'+self.data[pos:newpos])
         error: unpack requires a string argument of length 4

I may or may not be using wrong syntax or whatnot (I did not find relevant documentation on Adobe's website) but in any case, I don't think that the compiler should pull off what seems to be an alignment error in the generated code.

cc @TiroTypeworks

[benkiel]

Adrien,

As far as I know/remember, featureNames is just supported for ssXX.

Best,
Ben Kiel

[kenlunde]

What is stated in the OpenTypeFeatureFileSpecification.html file agrees.

[adrientetar]

• The OpenType registry mandates a name field. Is it not supported by the AFDKO? If so, does Adobe intend to add support for it?
• Secondly, and if this name field is not supported for this feature, why doesn't the compiler error in this case?

[kenlunde]

What does the "spot -tname" output look like, in terms of showing these featureNames strings?

[benkiel]

It is worth pointing out, that currently, nothing supports names for ssXX. I don’t know what support is for cvXX.

[kenlunde]

After consulting the OpenType Specification, it is also worth pointing out that a featureNames string is not required for either 'cvXX' nor 'ssXX' GSUB features.

[adrientetar]

Ken,

I pasted that info here: https://gist.github.com/adrientetar/8123f8b015d7f685f7ad, I notice the first lines "Unknown tag with FeatureParam".

You are right with these being optional, I went too strongly worded when I said "mandates".

[kenlunde]

Please do the same for the 'name' table, because that is where these strings are actually specified. Though, the first few lines of the "spot -tGSUB" output suggest that something went awry.

[adrientetar]

Ken,

Here it is: https://gist.github.com/adrientetar/fc577a75876d9fde6add
This one does not look faulty at first glance.

Ben,

I know, right? I'm not going to cut down my software because there is no end-user support. And features support is a chain just like in web development – as much as end-user softwares have to support features to get them to work, designers have to support them too, and if no one uses them or ask for them things are not going to change.

If support for descriptive names in user software lands in fifty years from now, users will get an immediate added value, without needing any upgrade. That isn't bad in my opinion.

[readroberts]

I do agree that it is a bug that makeotf does not complain about using the 'featureNames' tag with features other than the stylistic alternates field. You will see in in the definition of the FeaturesParam field of the Features table that it is set to NULL except for specific features that provide a definition for it's use, and the use of the field must be provided explicitly and separately by each feature the does use it. Currently a definition of use is provided only for the GPOS 'size' feature, and the GSUB stylistic alternates feature.

[benkiel]

Adrien,

I do not disagree with your stance at all, the eggs need laying for the chickens to be born.

Ben

[adrientetar]

Read,

Interesting. Can you point me to these feature definitions?

Ben,

Cheers.

[readroberts]

OpenType spec at:
http://www.microsoft.com/typography/otspec/
Follow link to "OpenType Layout Tag Registry":
http://www.microsoft.com/typography/otspec/ttoreg.htm
Follow link to 'feature tags":
http://www.microsoft.com/typography/otspec/featuretags.htm
Search document for "FeatureParams".

[adrientetar]

Ah, I thought that by definitions you meant code in the AFDKO.

Currently a definition of use is provided only for the GPOS 'size' feature, and the GSUB stylistic alternates feature.

Well, as I see it cvXX has a FeatureParams definition in the otspec that says how the various strings are used for a UI, what makes it so that it has no definition of use?

[readroberts]

I see that you are correct. The page I was searching was limited to tags in the range p-t, which is why I missed the cvXX definition of FeatureParams. This is definitely a bug in makeotf. The FeatureFile 'featureName' tag is specific to ssXX features. The cvXX FeatureParams field points to a data block with quite a different structure, and different fields; this is why 'ttx' crashes - it is expecting the amount of data associated with the cvXX feature, and is being handed the data block for the ssXX feature instead. makeotf does not yet support building the set of fields associated with the FeatureParams for the cvXX feature.

[readroberts]

The latest version of makeotf does support character variation features.