Hi @m4rc1e

For Roman VF:

1. ValueNameID for AxisValue11 is wrong. It should be Roman, not Normal (the nameID for the value is to be created in the name table). It also should be of Format 3, with a linked value of "1.0", not "0".
2. nameID3 is wrong, should be "3.000;GOOG;Roboto", not "Roboto".

For Italic VF:

1. ValueNameID for AxisValue3 is wrong. It should be Regular, not Italic (the nameID for the value is to be created in the name table).
2. nameID3 "3.000 GOOG Roboto-Italic" is technically correct, but it would be better to use the more conventional "3.000;GOOG;Roboto-Italic".

For both:

1. nameID25 is missing
2. as well as the postscriptNameID for NamedInstance in the fvar table.

Thanks! I'll push an update before next Wed.

@thlinard Again, thank you so much for your detailed feedback here :)

1. ValueNameID for AxisValue11 is wrong. It should be Roman, not Normal (the nameID for the value is to be created in the name table). It also should be of Format 3, with a linked value of "1.0", not "0".

AFAIK Google Fonts doesn't use Roman or Normal in font name particles, only Regular and all 3 are mostly elided.

However, I think Normal has entered into the files because @m4rc1e has generated these using the varLib to split the slnt axis into separate/dual roman/italic files.

@m4rc1e please look into this and report back here what you find :) I wonder that the varLib output should be changed, and this may effect the files the API outputs...

2. nameID3 is wrong, should be "3.000;GOOG;Roboto", not "Roboto".

I believe nameID 3 is somewhat arbitrary; the version and the vendor metadata can be obtained elsewhere. I'm OK with it being just "Roboto", but I'm curious if you have any cases where this causes an issue, rather than a mere inconsistency with the previous string.

For Italic VF:

1. ValueNameID for AxisValue3 is wrong. It should be Regular, not Italic (the nameID for the value is to be created in the name table).

I'm not sure I follow you; the italic files should not have Regular anywhere, I think.

2. nameID3 "3.000 GOOG Roboto-Italic" is technically correct, but it would be better to use the more conventional "3.000;GOOG;Roboto-Italic".

Do you know where this convention was established? Maybe AFDKO?

For both:

1. nameID25 is missing
2. as well as the postscriptNameID for NamedInstance in the fvar table.

@m4rc1e did your recent update address these?

@thlinard Again, thank you so much for your detailed feedback here :)

1. ValueNameID for AxisValue11 is wrong. It should be Roman, not Normal (the nameID for the value is to be created in the name table). It also should be of Format 3, with a linked value of "1.0", not "0".

AFAIK Google Fonts doesn't use Roman or Normal in font name particles, only Regular and all 3 are mostly elided.

Hi @davelab6

Say otherwise: AxisValue 11 (of the ital axis) used nameID 295, which is the nameID used by AxisValue 10 (of the wdth axis). Even if the name is ellided, something was wrong in the creating process. It's corrected in version 3.001.

However, I think Normal has entered into the files because @m4rc1e has generated these using the varLib to split the slnt axis into separate/dual roman/italic files.

@m4rc1e please look into this and report back here what you find :) I wonder that the varLib output should be changed, and this may effect the files the API outputs...

1. nameID3 is wrong, should be "3.000;GOOG;Roboto", not "Roboto".

I believe nameID 3 is somewhat arbitrary; the version and the vendor metadata can be obtained elsewhere. I'm OK with it being just "Roboto", but I'm curious if you have any cases where this causes an issue, rather than a mere inconsistency with the previous string.

Yes, arbitrary. But also here I have some doubts about the creating process: if the value is arbitrary, the value must be different, otherwise many apps will confuse fonts. I'm more at ease with a nameID such as "3.00x;GOOG;Roboto-Italic", because I feel like the name follows a pattern defined by an automated process.

But it's true, strictly speaking, there is nothing wrong in nameID 3.

For Italic VF:

1. ValueNameID for AxisValue3 is wrong. It should be Regular, not Italic (the nameID for the value is to be created in the name table).

I'm not sure I follow you; the italic files should not have Regular anywhere, I think.

AxisValue 3 (of the wght axis) use nameID 2 ("Italic"). Its nameID, even ellided, should be Regular ("Italic" doesn't belong to the wght axis). Again, something wrong in the creating process (even if, with the ellision, the error will not be visible). Still not corrected in version 3.001.

1. nameID3 "3.000 GOOG Roboto-Italic" is technically correct, but it would be better to use the more conventional "3.000;GOOG;Roboto-Italic".

Do you know where this convention was established? Maybe AFDKO?

Possibly, I don't remember.

ValueNameID for AxisValue11 is wrong. It should be Roman, not Normal (the nameID for the value is to be created in the name table). It also should be of Format 3, with a linked value of "1.0", not "0".

This is arbitrary however it does make more sense. I've updated this in v3.001. Thank you.

nameID3 is wrong, should be "3.000;GOOG;Roboto", not "Roboto".

nameID3 is identical to the v2.138, which is simply "Roboto". The Italic VF's nameID 3 is modified by our instancer. I could post process this but these split fonts are only temporary and should only be used on the web. See below for more info.

For Italic VF:

ValueNameID for AxisValue3 is wrong. It should be Regular, not Italic (the nameID for the value is to be created in the name table).
nameID3 "3.000 GOOG Roboto-Italic" is technically correct, but it would be better to use the more conventional "3.000;GOOG;Roboto-Italic".

The Italic font is instantiated from the main font using fontTools varLib instancer so it has updated nameID 3 itself. We have split the fonts due to browsers having patchy support for the ital and slnt axis. In the future when browser support is better, we'll release the family as a single font. For DTP users I suggest they use the static fonts. For apps, they can use the single VF. All fonts are tagged and can be found here, https://github.com/TypeNetwork/Roboto/releases/tag/v3.001.

For both:

nameID25 is missing
as well as the postscriptNameID for NamedInstance in the fvar table.

Postscript names are not mandatory according to the spec. Truthfully, we don't have an elegant way to add them. For Literata, I've written an ad hoc script which will add them post generation.

Do I think they're necessary? well it's difficult to tell. When I've added them to particular families, the variable sliders in Indesign have stopped working. VF naming as far as I can tell is akin to a game of whack-a-mole at the moment. I will write a report regarding these issues and share it with Adobe and MS (this unfortunately will take some time). For the time being, these issues do not affect the web fonts. I reckon we'll focus on better naming next quarter and in the next year.

Hi @m4rc1e

ValueNameID for AxisValue11 is wrong. It should be Roman, not Normal (the nameID for the value is to be created in the name table). It also should be of Format 3, with a linked value of "1.0", not "0".

This is arbitrary however it does make more sense. I've updated this in v3.001. Thank you.

Not exactly arbitrary. You could use Roman to form nameID 25.

AxisValue 3 (of the wght axis) still uses nameID 2 ("Italic") in v3.001, btw.

Postscript names are not mandatory according to the spec.

Not mandatory, but without that Photoshop can't use the sliders when Roman and Italic are two distinct files. So, yes, it's not mandatory, but it's a very small price to pay, right?

Truthfully, we don't have an elegant way to add them.

This is what I suspected. 😀

Do I think they're necessary? well it's difficult to tell. When I've added them to particular families, the variable sliders in Indesign have stopped working. VF naming as far as I can tell is akin to a game of whack-a-mole at the moment. I will write a report regarding these issues and share it with Adobe and MS (this unfortunately will take some time). For the time being, these issues do not affect the web fonts. I reckon we'll focus on better naming next quarter and in the next year.

No, Adobe VF fonts work perfectly well with InDesign (named instances + sliders). They use nameID 25 + postscriptNameID + AxisValue format 2. We talked about this when we tested gftools-fix-vf-meta.py, but you didn't answer me about AxisValue format 2: I understand that this is still one more step, and Adobe could definitely do an effort, but at the time, as I reported to you, I tested and it works.

At least with nameID 25 + postscriptNameID only, the named instances work in Photoshop + InDesing + Illustrator.

No, Adobe VF fonts work perfectly well with InDesign (named instances + sliders).

I've attached Libre Caslon Text which has been run through gftools fix-vf-meta. The sliders do not work for this family in Indesign. After removing the STAT and ps names in the fvar instances, the sliders do work.

Also, if a family consists of a Roman VF and an Italic VF, the wght slider doesn't work properly for the Italic styles, regardless of the family having STAT tables.

AxisValue format 2

any source for this? it should definitely work with all other formats, otherwise it is broken.

libre_caslon_indesign_tests.zip

I've just reread through #2391 looking for more info regarding format 2 Axis Values. I'm on the fence of whether they're a benefit tbh. I agree with John's sentiments. Peter Constable also doesn't mention that they're required for Adobe apps either.

No, Adobe VF fonts work perfectly well with InDesign (named instances + sliders).

I've attached Libre Caslon Text which has been run through gftools fix-vf-meta. The sliders do not work for this family in Indesign.

I know, this is why I made it clear: nameID 25 + postscriptNameID + AxisValue format 2 (gftools fix-vf-meta doesn't add AxisValue format 2).

I've attached a special Libre Caslon Text version: the files are done exactly like Adobe VFs (like Adobe Source Serif VF, for example). The sliders work in InDesign.

LibreCaslonText-format2.zip

After removing the STAT and ps names in the fvar instances, the sliders do work.

But doing VFs with wobbly STAT tables or no STAT tables at all is not a solution. At least "the Adobe way" meets the standards (even if some are non-mandatory). Even if, I agree, it shouldn't be necessary to do the same: the proof is that Illustrator does without. But this is the current state of the support, if you want to release VFs now and not in 10 years, you have to deal with the state of the support at the present time.

Also, if a family consists of a Roman VF and an Italic VF, the wght slider doesn't work properly for the Italic styles, regardless of the family having STAT tables.

It works with nameID 25 + postscriptNameID + AxisValue format 2. Test the special Libre Caslon Text I attached.

Btw, about your test fonts without STAT table and with minimal fvar table: it's "the Apple way". Apple Skia is done this way. As Skia is only one file (no supplementary file for Italic), Adobe (at least the InDesign team) didn't have to test the link between two VFs (Roman and Italic) made this way, maybe that's why it doesn't work (and besides the sliders don't work in your version: if we are on an italic named instance, and we switch to sliders, the italic is lost).

And, for the sack of completness: STAT table (format 1 and 3) + minimal fvar table = "the Microsoft way" (Microsoft Bahnschrift is done this way).

@thlinard thanks for the test fonts, they work perfectly. I'm willing to concede and update gftools fix-vf-meta to use format 2 values if they will also work for a wght only roman font. If we do update the format, we'll write some tests so it doesn't slip through in the future.

My only dislike of using format 2 is the fact it cannot handle linked values. This means we need to include two values for the Regular style. This is a violation of the spec however, it seems Adobe is aware of this.

I agree that updating this now is good for future proofing.

But doing VFs with wobbly STAT tables or no STAT tables at all is not a solution

Lol. There's absolutely nothing wrong with the previous STAT. I'm willing to update simply because it may take Adobe a while to support the other formats. I'll raise this with them as well.

But doing VFs with wobbly STAT tables or no STAT tables at all is not a solution

Lol. There's absolutely nothing wrong with the previous STAT. I'm willing to update simply because it may take Adobe a while to support the other formats. I'll raise this with them as well.

Well, I was talking about your test fonts, "in Apple fashion" (without STAT table).

But if you're referring to the version 3.001 posted here, "absolutely nothing wrong" is not completely exact. You can't use nameID 2 ("Italic") for any axis other than the Italic axis. Yet, it's used for wght axis. Minor error because the elision won't make it visible, but if these fonts are to be used for testing by software vendors, they better be error-free. When we have complaints to make, it's better to have a clean ass (pardon my French: expression of my native language translated literally 😁).

Do you know where this convention was established? Maybe AFDKO?

Hi @davelab6

Btw, you were right: this convention originates from Adobe.

The NameID=3 (UniqueID) string shall contain a string that is unique, and not shared by another font. Ideally, it should also be unique from different versions of the same font.
The convention used by Adobe Systems is to concatenate the head.FontRevision number, OS/2.Vendor string, and CFF.FontName separated by semicolons (0x3B or U+003B, depending on the ScriptID). The following is an example of a NameID=3 string:
6.009;ADBE;KozGoPr6N-Medium

https://www.adobe.com/content/dam/acom/en/devnet/font/pdfs/5149.OTFname_Tutorial.pdf

Ok, I've just pushed v3.002. Thanks to @thlinard for proofing the STAT, fvar and name tables.

Having merged it, Marc has tested this version with the v2.x all-static-fonts version currently served in the API, and in an email, Marc reported the following Visual Regressions:

1 Vertical Metrics are different on Win Chrome < 73. This is due to Chrome < 73 using the hhea metrics whilst versions after use the win/typo for variable fonts.

This is not an issue with the fonts, so not actionable.

2 Italics are a little narrower.

@m4rc1e please post a comparison image or toggling GIF of a paragraph of text, showing the differences between the old and new italics.

3 Font hints match well < 26pt. Above this and the fonts look slightly different on Windows only.

Please post an image showing the differences. Since its at large 26pt+ sizes, I expect it will be acceptable.

4 Thin appears slightly heavier. Still working out why.

Probably because Chrome uses freetype for VFs, and the differences between DWrite and FreeType are most visible in Thin weight designs. As in (1), this is a Chrome issue, so not actionable. Also depending on what happens with https://bugs.chromium.org/p/chromium/issues/detail?id=1041569 this may change again.

1 Vertical Metrics are different on Win Chrome < 73. This is due to Chrome < 73 using the hhea metrics whilst versions after use the win/typo for variable fonts.

This is not an issue with the fonts, so not actionable.

fsSelection bit 7 isn't enabled (fonttools/fontbakery#3021), it is intentional?

@m4rc1e please update the PR title with the correct v number, I believe its v3.002 at the time of merge