-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cvXX featureNames yields corrupt binary code #35
Comments
Adrien, As far as I know/remember, featureNames is just supported for ssXX. Best, |
What is stated in the OpenTypeFeatureFileSpecification.html file agrees. |
|
What does the "spot -tname" output look like, in terms of showing these featureNames strings? |
It is worth pointing out, that currently, nothing supports names for ssXX. I don’t know what support is for cvXX. |
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. |
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". |
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. |
Ken, Here it is: https://gist.github.com/adrientetar/fc577a75876d9fde6add 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. |
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. |
Adrien, I do not disagree with your stance at all, the eggs need laying for the chickens to be born. Ben |
Read, Interesting. Can you point me to these feature definitions? Ben, Cheers. |
OpenType spec at: |
Ah, I thought that by definitions you meant code in the AFDKO.
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? |
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. |
The latest version of makeotf does support character variation features. |
I tried to add featureNames to my cvXX features in the same way it is done with ssXX, here is a sample code:
The AFDKO gives no warning or error whatsoever yet ttx decompilation errors:
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
The text was updated successfully, but these errors were encountered: