Open Veerjee opened 7 months ago
Can you tell me what error? It passes all our QA checks and seems to work fine.
ERROR - validation.fontedit.GPOS.GPOS.featuredict.feature table 5.featuretable - There is a nonzero offset to a FeatureParams object, but the associated tag has no definitions for one.
Hi simoncozens,
I hope te above message helps with fixing the NotoSansSiddham-Regular.ttf.
Here is Font Vaidator output:
Hi simoncozens, were you able to look into this. How come this issue can only be seen via this link. It is not showing among the open issues.
You provided the information an hour ago. I have not been able to look into it yet, no.
This issue does appear in the open issues list here: https://github.com/notofonts/siddham/issues
Thank you, Simon. You replied to some of my other posts. I just wanted to ensure this didn't fell off your redar. So kind of you!
Not sure why FeatureParams
cannot be non-null. As for AnchorFormat...
For unhinted ttf regular, GPOS header is at 0x19CE4, lookup list at 0x19D22, claiming 189 lookups. Lookup index 1 points to 0x19F22, claiming 1 subtable at 0x1AC72. That is MarkToBase with 2 classes and BaseArray at 0x1E5E2, claiming 154 BaseRecords. Note that the error is "154 is invalid AnchorFormat". Now the BaseRecords are as follows: | BaseRecord index | class 0 offset | class 1 offset |
---|---|---|---|
0 | 0x1D90 | 0x1E4A | |
1 | 0x1D90 | 0x1E4A | |
2 | 0x0000 | 0x1F9A | |
3 | 0x0000 | 0x1F9A | |
... |
These are offsets from the start of BaseArray, hence offset of 0x0000 points to the number 154, which is interpreted as anchor format.
Now the question is whether offset 0 is legal and the font validation is wrong, or whether it is not and the compiler is wrong. I don't see this explicitly stated in the OpenType spec.
Hmm. ots (opentype sanitizer), which sometimes complains about zero offsets, seems to be happy with this one. I don't have MS FontValidator.
I'm not trying to be lazy here, but this isn't really something I can fix anyway. I'm not generating these offsets manually! If we're getting bad binary output, that might signify a compiler bug.
Yeah I am not sure you can fix this in the font source (other than providing class 0 anchor points for the bases). I haven't seen anything else complaining other than the font validator, so I am leaning towards the font validator being wrong. If 0 is invalid, it should state that and not try to interpret it as a valid pointer.
I don't see this explicitly stated in the OpenType spec.
I was wrong! The BaseRecord table states:
Array of offsets (one per mark class) to Anchor tables. Offsets are from beginning of BaseArray table, ordered by class (offsets may be NULL).
With that I think this issue can be closed and it should be raised with the font validator software.
Same for the FeatureParams
, the details of the validator mention this is ss06 but the specification states that ss01-ss20 have the parameter defined.
Please review this font. The GPOS table is showing error.