search

notofonts / siddham

Noto Siddham
SIL Open Font License 1.1
1 stars 0 forks source link

NotoSansSiddham-Regular.ttf GPOS table shows error #24

Open Veerjee opened 7 months ago

Veerjee commented 7 months ago

Please review this font. The GPOS table is showing error.

simoncozens commented 7 months ago

Can you tell me what error? It passes all our QA checks and seems to work fine.

Veerjee commented 7 months ago

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.

Veerjee commented 7 months ago

Hi simoncozens,

I hope te above message helps with fixing the NotoSansSiddham-Regular.ttf. image

Veerjee commented 7 months ago

Here is Font Vaidator output: image

Veerjee commented 7 months ago

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.

simoncozens commented 7 months ago

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

Veerjee commented 7 months ago

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!

miloush commented 7 months ago

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.

simoncozens commented 7 months ago

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.

miloush commented 7 months ago

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.

miloush commented 7 months ago

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.

miloush commented 7 months ago

Same for the FeatureParams, the details of the validator mention this is ss06 but the specification states that ss01-ss20 have the parameter defined.