NotoSansCJK-VF.otf.ttc misses 'name' ID 25 field

[lemzwerg]

[This holds probably for other fonts too, I haven't checked.]

To construct a PS font name for an arbitrary, unnamed font instance, the algorithm in 5902.AdobePSNameGeneration.pdf should be used. To do this properly, however, it is necessary that the font provides a 'Variations PostScript Name Prefix' (name ID 25), which is missing for the subfonts in NotoSansCJK-VF.otf.ttc.

The algorithm describes an alternative way to create such a prefix using name ID 16. Alas, this field is missing, too.

[punchcutter]

Since there is no requirement to contain name ID 25 it shouldn't matter.

The spec says

If name ID 16 is absent, then name ID 1 is considered to be the typographic family name.

For Source Han/Noto CJK there wasn't really any reason to add a name ID 25 so I didn't. Perhaps the tech note should have clarified to fallback to name ID 1, but that's already clearly stated in the OpenType spec.

[lemzwerg]

OK, thanks. However, I still suggest to add ID 25, for a simple reason: The PS names of named instances are NotoSansCJKjp-*, for example NotoSansCJKjp-Thin. Applying the algorithm to derive the PS name prefix from ID 1 gives NotoSansCJKJP, i.e., the last two letters being uppercase. I think it's best if such a difference is avoided.

[punchcutter]

I don't think that difference is particularly meaningful, but it's easy enough to add name ID 25. Named instances are not required to have a PS name so those names could really be anything. I agree with you that it would be nice to have all this consistent, but when those name fields aren't required we can only suggest that font makers put the names that we expect and hope they do.

[lemzwerg]

I think that many people use such prominent fonts as the Noto family as a template for their own work; for this reason it is certainly beneficial if the fonts fulfill the specifications as close as possible, avoiding implicit defaults by even setting the non-required fields (in case it is not too painful to do, which isn't the case here, I believe).

Thanks for considering it!