"No style grouping conflict" issue on Monotype Font Platform

Michael Rafailyk
Posts: 183
I got this error message on Monotype Font Platform this month. Never get this before.

I spoke to their support team, they inspected the files and assured me that the problem is somewhere with my font files and recommended me to check Naming tutorial (what I did of course). Here's what they answered:
Here's how the styles are linked in the project file:
Here's the screenshot of what the style linking looks like in TransType:

Then, to check if it is something with the current font files or not, I created a completely new empty project in Glyphs, linked the styles from scratch according the Naming tutorial, exported standard 18 styles (Thin-Black, upright + italics), and still got the same error on Monotype Font Platform. So from this point I'm not sure where the issue is at all.
I attached the exported font files (without outlines) and I'll be glad if someone can confirm or deny if the styles are linked correctly or not in this test files. Thanks in advance.

I spoke to their support team, they inspected the files and assured me that the problem is somewhere with my font files and recommended me to check Naming tutorial (what I did of course). Here's what they answered:
During our review, we identified certain issues in the font files you provided—specifically within the naming tables, which currently do not fully comply with OpenType specifications. Additionally, inconsistent usage of the fsSelection field has been observed, which can affect styling behavior and overall font reliability.
I tested the font files in Photoshop, Illustrator, TextEdit, TransType, and everywhere style linking works as expected. Unfortunately I don't have access to Word right now. Even Fontbakery didn't say anything about style linking issues. Perhaps, OTMaster could tell more about what happens in a tables inside, but I don't have opportunity to get it now.Here's how the styles are linked in the project file:
Thin
Thin Italic > Italic of Thin
Extra Light
Extra Light Italic > Italic of Extra Light
Light
Light Italic > Italic of Light
Regular
Italic > Italic of Regular
Medium
Medium Italic > Italic of Medium
Bold > Bold of Regular
Bold Italic > Bold and Italic of Regular
Extra Bold
Extra Bold Italic > Italic of Extra Bold
Black
Black Italic > Italic of Black
Thin Italic > Italic of Thin
Extra Light
Extra Light Italic > Italic of Extra Light
Light
Light Italic > Italic of Light
Regular
Italic > Italic of Regular
Medium
Medium Italic > Italic of Medium
Bold > Bold of Regular
Bold Italic > Bold and Italic of Regular
Extra Bold
Extra Bold Italic > Italic of Extra Bold
Black
Black Italic > Italic of Black
Here's the screenshot of what the style linking looks like in TransType:

Then, to check if it is something with the current font files or not, I created a completely new empty project in Glyphs, linked the styles from scratch according the Naming tutorial, exported standard 18 styles (Thin-Black, upright + italics), and still got the same error on Monotype Font Platform. So from this point I'm not sure where the issue is at all.
I attached the exported font files (without outlines) and I'll be glad if someone can confirm or deny if the styles are linked correctly or not in this test files. Thanks in advance.
Tagged:
0
Comments
-
I don’t have time to check the font files themselves. BUT... everything else you show and say seems correct to me. Weird that they Monotype won’t say anything more specific (though I can understand them not wanting to replace QA and testing). If Fontbakery is good with it, I would think it would be OK. I think they implemented all the style-linking checks that Adobe’s CompareFamily (from the AFDKO) does, although running that is not a bad idea, just to be sure.
Also, just as a side note and long shot thing... check also that your usWeightClass settings are correct for all styles?
0 -
Hi Thomas. Yes, Weight Class settings are correct, this is where I started to set up the instances. Thanks for mentioning CompareFamily, I think I will install AFDKO to see more details.
Also here's the other things I tried (but error persists in all cases):
- Link the styles according to tutorial.
- Not link any styles at all.
- Link only these four: Regular/Italic/Bold/Bold Italic.0 -
Your name IDs 1 and 2 are correct for the 4-style RIBBI family linking. And your name IDs 16 and 17 are correct for the OpenType preferred family naming.
Your ID6 is a hyphenated concatenation of the ID16 and ID17 entries. That’s not contrary to the spec, I think, but my practice is to concatenate ID1 and ID2, so e.g.TestFontMedium-Italic
rather thanTestFont-MediumItalic
That’s the only thing I see in the name table that is different from what I would expect/do.
0 -
Adobe practice is to have name ID 6 be a concatenation of 16 and 17. So that part seems just fine to me.
0 -
John, thanks for checking it.Your ID6 is a hyphenated concatenation of the ID16 and ID17 entries. That’s not contrary to the spec, I think, but my practice is to concatenate ID1 and ID2This is how Glyphs handle it by default. I think if this behaviour were wrong or even critical, then the other Glyphs users would complain about it, but that's not the case.
I was surprised that yesterday I made this pretty default test setup from scratch, and Monotype Font Validator still display that error anyway. That error blocking the submissions from being submitted, so it is a Situation. I asked their support if they have similar requests from the other foundries and they answered they didn't. I asked if they can check if it is a system bug, and they answered:These checks are part of our minimum quality criteria for onboarding fonts into the Monotype Fonts platform. The example data you shared has been very helpful in confirming that the current behavior—preventing the upload of fonts with these issues—is intentional and designed to protect quality, not a system bug.So I'm not sure what my next step should be. By one hand, the fonts seems to be okay, by the other hand, Monotype support says it is something with the font files. I also asked about it on Glyphs forum (for the reason the fonts were exported from this application), I'll see if anyone there answers.
0 -
I installed AFDKO and run comparefamily command for these Test fonts. Here's the fragments from the report related to the style linking and the name table.
Passed checksSingle Face Test 1: Length overrun check for name ID 18. Max 63 characters, must be unique within 31 chars. Single Face Test 2: Length overrun check for name IDs 1,2, 4, 16, 17. Max 63 characters. Single Face Test 3: Check that name ID 4 (Full Name) starts with same string as Preferred Family Name, and is the same as the CFF font Full Name. Single Face Test 5: Check that CFF PostScript name is same as name table name ID 6. Single Face Test 8: Check SubFamily Name (name ID 2) for Regular Style, Bold Style, Italic Style, and BoldItalic Style Single Face Test 10: Check that no Bold Style face has OS/2.usWeightClass of less than 500 Single Face Test 12: Check that Italic style is set when post table italic angle is non-zero, and that italic angle is reasonable. Single Face Test 14: Warn if Bold/Italic style bits do not match between the head Table and OS/2 Table Single Face Test 20: Warn if there are double spaces in the name table font menu names. Single Face Test 21: Warn if there trailing or leading spaces in the name table font menu names. Family Test 1: Verify that each group of fonts with the same nameID 1 has maximum of 4 fonts. Family Test 2: Check that the Compatible Family group has same name IDs in all languages except for the compatible names 16,17,18, 20, 21 and 22. Family Test 3: Check that the Compatible Family group has same Preferred Family name (name ID 16)in all languagesID 16 in all other languages. Family Test 5: Check that style settings for each face is unique within Compatible Family group, in all languages. Family Test 6: Check that the Compatible Family group has a base font and at least two faces, and check if weight class is valid. Family Test 7: Check that all faces in the Preferred Family group have the same Copyright and Trademark string. Family Test 8: Check the Compatible Family group style vs OS/2.usWeightClass settings. Max 2 usWeightClass allowed. Family Test 9: Check that all faces in the Compatible Family group have the same OS/2.usWidthClass value. Family Test 11: Check that Mac and Windows menu names differ for all but base font, and are the same for the base font. Family Test 13: Check that no two faces in a preferred group have the same weight/width/Italic-style values when the OS/2 table fsSelection bit 8 (WEIGHT_WIDTH_SLOPE_ONLY) is set. Family Test 17: Check that fonts have OS/2 table version 4.
Menu Name ReportPreferred Menu Mac Compatible Menu Windows Compatible Menu Test/Black Test Black Test Black/Regular Test/Black Italic Test Black Italic Test Black/Italic Test/Extra Bold Test Extra Bold Test Extra Bold/Regular Test/Extra Bold Italic Test Extra Bold Italic Test Extra Bold/Italic Test/Extra Light Test Extra Light Test Extra Light/Regular Test/Extra Light Italic Test Extra Light Italic Test Extra Light/Italic Test/Light Test Light Test Light/Regular Test/Light Italic Test Light Italic Test Light/Italic Test/Medium Test Medium Test Medium/Regular Test/Medium Italic Test Medium Italic Test Medium/Italic Test/Regular Test Regular Test Regular/Regular Test/Italic Test Italic Test Regular/Italic Test/Bold Test Bold Test Regular/Bold Test/Bold Italic Test Bold Italic Test Regular/Bold Italic Test/Semi Bold Test Semi Bold Test Semi Bold/Regular Test/Semi Bold Italic Test Semi Bold Italic Test Semi Bold/Italic Test/Thin Test Thin Test Thin/Regular Test/Thin Italic Test Thin Italic Test Thin/Italic Preferred Family: Test Italic Angle from post.italicAngle: Test-BlackItalic: -11.310 Test-ExtraBoldItalic: -11.310 Test-ExtraLightItalic: -11.310 Test-LightItalic: -11.310 Test-MediumItalic: -11.310 Test-Italic: -11.310 Test-BoldItalic: -11.310 Test-SemiBoldItalic: -11.310 Test-ThinItalic: -11.310 Test-Black: 0.000 Test-ExtraBold: 0.000 Test-ExtraLight: 0.000 Test-Light: 0.000 Test-Medium: 0.000 Test-Regular: 0.000 Test-Bold: 0.000 Test-SemiBold: 0.000 Test-Thin: 0.000 Preferred Family: Test isBold from hhea.mscStyle: Test-Bold: Bold Test-BoldItalic: Bold Test-Black: Not Bold Test-BlackItalic: Not Bold Test-ExtraBold: Not Bold Test-ExtraBoldItalic: Not Bold Test-ExtraLight: Not Bold Test-ExtraLightItalic: Not Bold Test-Light: Not Bold Test-LightItalic: Not Bold Test-Medium: Not Bold Test-MediumItalic: Not Bold Test-Regular: Not Bold Test-Italic: Not Bold Test-SemiBold: Not Bold Test-SemiBoldItalic: Not Bold Test-Thin: Not Bold Test-ThinItalic: Not Bold Preferred Family: Test isItalic from hhea.mscStyle: Test-BlackItalic: Italic Test-ExtraBoldItalic: Italic Test-ExtraLightItalic: Italic Test-LightItalic: Italic Test-MediumItalic: Italic Test-Italic: Italic Test-BoldItalic: Italic Test-SemiBoldItalic: Italic Test-ThinItalic: Italic Test-Black: Not Italic Test-ExtraBold: Not Italic Test-ExtraLight: Not Italic Test-Light: Not Italic Test-Medium: Not Italic Test-Regular: Not Italic Test-Bold: Not Italic Test-SemiBold: Not Italic Test-Thin: Not Italic Preferred Family: Test usWeightClass from OS/2.usWeightClass: Test-Black: 900 Black (Heavy) Test-BlackItalic: 900 Black (Heavy) Test-ExtraBold: 800 Extra-Bold (Ultra-bold) Test-ExtraBoldItalic: 800 Extra-Bold (Ultra-bold) Test-Bold: 700 Bold Test-BoldItalic: 700 Bold Test-SemiBold: 600 Semi-bold (Demi-bold) Test-SemiBoldItalic: 600 Semi-bold (Demi-bold) Test-Medium: 500 Medium Test-MediumItalic: 500 Medium Test-Regular: 400 Normal (Regular) Test-Italic: 400 Normal (Regular) Test-Light: 300 Light Test-LightItalic: 300 Light Test-ExtraLight: 200 Extra-Light (Ultra-light) Test-ExtraLightItalic: 200 Extra-Light (Ultra-light) Test-Thin: 100 Thin Test-ThinItalic: 100 Thin Preferred Family: Test usWidthClass from OS/2.usWidthClass: All fonts have the same value: 5 Medium (normal)
ErrorsSingle Face Test 11: Check that BASE table exists, and has reasonable values Error: font Test-Black does not have a BASE table. This is necessary for users who are editing in a different script than the font is designed for.
And the same following error for each upright style:Family Test 11: Check that Mac and Windows menu names differ for all but base font, and are the same for the base font. Error: The Mac and Windows Compatible Names for the regular face of a style-linked group should be the same. Font Test-Black Mac Compatible Name: Windows Compatible Name: Test Black
Does this report confirm that the fonts are fine and the problem is not on my end?
Or that two errors are somehow important?
0 -
Yup, that all looks good. A name length overrun was going to be my next suggestion of things to check, but your fonts pass that test. [Name ID length is confusing to some people, because the specification refers to 63 characters, but those are single-byte 8-bit characters, so a double-byte Unicode encoded name string needs to be limited to 31 characters.]
Presence of a BASE table is an internal Adobe test. There is no spec requirement for a font to include a BASE table. [It determines how a font will behave within mixed-script text in a CJK environment, so reflects Adobe’s Asian market activities.]
The last error refers to the ‘Mac Compatible Name’, by which I presume it means name ID 18. This is an optional name ID, that is not included in most fonts, and enables one to include a Mac-specific Full Name if you want it to differ from name ID7. I don’t think I have ever used it, and it certainly isn’t common. The spec is light on explanation for it, and I wouldn’t be surprised if there are more than a handful of people who remember why it was specified in the first place.
0 -
Michael Rafailyk said:
- Link only these four: Regular/Italic/Bold/Bold Italic.
0 -
@John Hudson Thank you for the explanation regarding that errors. Even if they are minor, it is good to know what they mean.
@Tural Alisoy There are no problem with this. I linked those 4 styles the same way as in your example, with the same style grouping, just in another application so the interface is different there. It is made by tutorial(s) and checked both: in tables of exported fonts, and in real testing in applications. Everything works as expected.
I assume that the problem is on the Monotype side in their Font Validator. I messaged them again and sent them the test fonts and AFDKO report.
0 -
I tested the “test” font you sent from the Monotype dashboard and got the same error you got, “No style grouping conflicts” and “No duplicate style names”. However, I tried to send it by removing the word Regular from the box I checked on the left in the screenshot I sent you, Font Validator didn’t show that error. But then I sent my edit first and then sent your file, this time I got that error.
Overall, it’s a clean update of support team for Monotype to fix a problem. Because unfortunately, they worked better before all the font platforms got it.
0 -
Tural Alisoy said:I tried to send it by removing the word Regular from the box I checked on the left in the screenshot I sent you, Font Validator didn’t show that error.
I tried to upload different pairs of styles to see what will happen:
– If I upload just 4 RIBBI styles, there is no error.
– If I upload just Medium and Medium Italic, there is no error.
– If I upload 4 RIBBI styles + Medium and Medium Italic, the error is there.0 -
John: IIRC, NameID 18 was for Mac Classic usage?
Michael: Yes, Tural is mistaken. Those settings are generally reasonable, and that is how one does style-linking for a normal four-member family, or for those styles as part of a larger family (as in the case at hand).
The only minor issue I see is, you have a style group (name ID 1) of “TestFont Regular” and a style (name ID 2) of “Regular”... AFAICT that style group probably ought to just be “TestFont”
Maybe that is what is triggering Monotype.0 -
@Tural Alisoy What you see in FontLab Font Info when you decompile a font is not necessarily reflective of what was in an upstream source, and involves interpretation of the font data. I agree that having ‘TestFont Regular’ as the style group name instead of simply ‘TestFont’, but there isn’t a specific piece of data in the font that corresponds to that field in FL Font Info, so you’re seeing what the program has come up with from trying to interpret the naming in the CFF and name tables of the font.0
-
I run spot command in AFDKO, and Name ID1 for all 4 RIBBI styles exactly contains "Regular" after the family name. Here's the report for Regular style:
nameId = name value 1 = TestFont Regular 2 = Regular 3 = 1.000;MR;TestFont-Regular 4 = TestFont Regular 6 = TestFont-Regular 16 = TestFont 17 = Regular
UPD.
In Glyphs project, I added the parameter "Style Map Family Names" for 4 RIBBI instances, to override Name ID1, and set the value to "TestFont". However, even after this, the error still persists in Monotype. So it is not the reason.0 -
Just a hunch: Try style-linking only the RIBBI styles, not the extended family members.0
-
@Simon Cozens just tried and that didn't work either.
What interesting is if I upload only 4 RIBBI members (or any other 4 styles so there are no more than 2 style groups) – there is no error. But if I upload more than 4 styles, the error occurs.
The problem is that support provided very limited information:we identified certain issues in the font files you provided—specifically within the naming tables, which currently do not fully comply with OpenType specificationsThey definitely should provide more details (I asked them about it today) because I made this pretty standard family for test, and checked it in AFDKO, Fontbakery, Fontspector, (and also checked style linking in applications), and can't reproduce the issues with Name table from their test. So the question is what they used to check the Name table.
0 -
Michael Rafailyk said:Do you mean that "Style group" should not contain "Regular" in it?0
-
Tural Alisoy said:why it has to be Regular in the first screenshot I sent. If it's Bold, why is it Regular? I don't know, maybe I'm thinking wrong.
"FamilyName Regular" is a style group for 4 Normal RIBBI styles.
"FamilyName Condensed" is a style group for 4 Condensed RIBBI styles.
"FamilyName Medium" is a style group for 2 styles: Medium and Medium Italic.– Do you mean that "Style group" should not contain "Regular" in it?If you read my previous comment, I already tried to export 4 RIBBI styles without "Regular" in the style group ID1 field (using the custom parameter), and checked the Name ID1 of exported files with AFDKO's spot command. The result is the same.
– Yes, because it might be considered a problem for them.
0 -
0
-
I get the same error with a font that I want to release this/next week.0
-
Looks like there will be a ton of such reports for them.Here’s some information from ChatGPT that my friend shared with me today. I don’t know how accurate it is because you know, it's AI, and the only way to check it is to join Monotype's Discord/Slack groups and read the announcements for the latest few month. So I just quote it as is:Monotype Platform updated their style grouping validation engine a few months ago. They announced it partly in Slack and Discord groups. Previously they were more loyal when font styles have fsSelection = 64 (i.e. Regular bit), even if it is Thin or Black. Now they have introduced a stricter rule - only the style that you want to see as Regular can have Regular bit in style linking.0
-
Hi Michael, I had a quick look with OTM at the font data you supplied. Here are some observations, for what they are worth. Overall, the naming tables are pretty minimal, and I would at least always include a copyright notice (nameID 0), but that aside.
Your family is set to ‘TestFont’, and you include the weight names in nameID 1 for Windows. This is necessary for Light, Medium, Black, etc., to be recognized on Windows, but doing the same for the Regular style may cause a mismatch in the full name (and is redundant anyway, I reckon). The full name is expected to be a combination of nameID 1 and 2. However, originally the spec required that ‘Regular’ be omitted from the full name if it is the default style. You use ‘TestFont Regular’, which likely worked fine historically. Nowadays, it is more common to include ‘Regular’ in the full name, and by this naming logic, if nameID 1 is ‘TestFont Regular’ and nameID 2 is ‘Regular’, then the full name (nameID 4) should become ‘TestFont Regular Regular’. The same applies to the associated Italic, Bold, and Bold Italic styles. This matches the experience of Tural.
By the way, I still have to get used to seeing the macOS entries completely omitted. ID 18 of the Mac entries was meant for applications that could not handle full names longer than 31 characters in Carbon-based apps, like old MS Word versions (otherwise the font did not show up). Perhaps it still makes sense to include Mac records for nameID 1, 2, and 4, just to be safe. After all, one never knows if these are still used by some PDF generators or Mac-based prepress pipelines relying on legacy APIs. But maybe this is my age.
Furthermore, if I recall correctly, according to the specs, a font family can only contain one Regular (0x0040 or 0x00c0 with TM). Your Light, Regular, Medium, Black, etc. all have a 0x00c0 entry, which at least theoretically may lead to unexpected grouping or behavior in some applications. I would argue that, with the exception of the ‘real’ Regular, this should be 0x0000 (not assigned), or 0x0080 with TM, or 0x0180 with TM and WWS. That said, setting Regular on multiple fonts has been a common workaround to address inconsistencies in font selection and fallback on various platforms, even if it conflicts with the strict spec.0
Categories
- All Categories
- 44 Introductions
- 3.8K Typeface Design
- 474 Type Design Critiques
- 554 Type Design Software
- 1.1K Type Design Technique & Theory
- 638 Type Business
- 828 Font Technology
- 29 Punchcutting
- 506 Typography
- 120 Type Education
- 312 Type History
- 74 Type Resources
- 109 Lettering and Calligraphy
- 30 Lettering Critiques
- 79 Lettering Technique & Theory
- 528 Announcements
- 84 Events
- 110 Job Postings
- 164 Type Releases
- 169 Miscellaneous News
- 274 About TypeDrawers
- 54 TypeDrawers Announcements
- 118 Suggestions and Bug Reports