"No style grouping conflict" issue on Monotype Font Platform

2»

Comments

  • Lorenzo Martinez
    Lorenzo Martinez Posts: 10
    edited June 10

    Michael Rafailyk said:
    Moritz Kleinsorge said:
    I get the same error with a font that I want to release this/next week. 
    What the application do you use to export fonts? I just wonder if it is only Glyphs related, or if the other type design applications also produce a similar result.
    hi! Same boat on this! Ive been trying out various solutions on how to fix this when I upload my fonts. I also have contacted their support team and just like yours, they insisted that there has been no problem with their bot reviewer. It's just that theres a problem on the font that I am submitting.

    I use fontlab 8 on my font developmet. I thought glyphs would fix this issue since this is the app recommended both by the bot and the support email. 

    It says to use glyphs to fix my "fsSelection" and apprantly fontlab 8 doesnt have that feature (or i just cant see it, been looking for it for weeks now)
  • Michael Rafailyk
    Michael Rafailyk Posts: 188
    edited June 10
    Jens Kutilek said:
    The "Regular" in name ID 1 is a bug introduced in the latest Glyphs cutting edge version.
    Yes, they said it will be fixed in next cutting edge version. However, I also tried to export the fonts from older (stable) Glyphs version (3.3.1) which didn't contain this ID1 bug, and Monotype Validator still complaining about style linking error.
    Lorenzo Martinez said:
    I use fontlab 8 on my font development
    Yesterday I thought that the issue only affected Glyphs users, but now it's getting interesting.
    Ive been trying out various solutions on how to fix
    It's a bit difficult to fix something without specific details about the problem. Monotype should provide more information.
    It says to use glyphs to fix my "fsSelection" and apprantly fontlab 8 doesnt have that feature (or i just cant see it, been looking for it for weeks now)
    fsSelection is in OS/2 table.
  • Jens Kutilek
    Jens Kutilek Posts: 377
    If fsSelection is the cause of this ... fsSelection is such a low-level setting that most font editors don't even have a UI to influence its values directly (RoboFont has it, but writes automatic values by default). It's pretty weird that Monotype changes the requirements for something that has worked for decades without telling anyone.
  • John Hudson
    John Hudson Posts: 3,423
    edited June 10
    fsSelection is a bit array in the OS/2 table, with each defined bit having a specific meaning if turned on. Tools like FontLab and Glyphs will automatically set the bits based on other font info data. The important bits are 0 (is italic), 5 (is bold), 6 (is regular), and 7 (use typo metrics*).

    Bit 8 (is WWS family) is sometimes relevant, but largely optional. [It is also potentiially problematic in that it might be correct to use it for one version of a family but then can become inaccurate if the family is extended with new styles.]


    * Bit 7 can be toggled with FontLab’s Font Info / Other Values / Prefer typo metrics. It is on by default.



    Some FontLab settings will be in Font Info, and others in export profiles.

    My impression of Glyphs is that there is often a way to affect small bits of font data by using custom parameters in Font Info, but that it isn’t always obvious which to use and how they should be set.
  • mitradranirban
    mitradranirban Posts: 68
    I think one way to manually fix fsselection bits is to export to UFO, tweak the values in fontinfo.plist, then regenerate from UFO using fontmake / ufo2ft
  • Lorenzo Martinez
    Lorenzo Martinez Posts: 10
    edited June 11
    Hi let me share to you guys the exact reply of monotype. After the first response, I tried to probe them with another email saying that just for the sake of testing, i tried uploading some more well made typeface like Lato typeface, but still the font verification bot does not approve it.

  • Dave Crossland
    Dave Crossland Posts: 1,466
    LeMo aka PatternMan aka Frank E Blokland said:

    Furthermore, if I recall correctly, according to the specs, a font family can only contain one Regular (fsSelection 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 UseTypoMetrics, or 0x0180 with UseTypoMetrics and WWS. 

    I think Frank was onto something here - I suggest to ensure the files have only UseTypoMetrics set for everything, except the Bold, and Italic, and Bold Italic, and set those to their individual and specific values plus UseTypoMetrics. 
  • Jens Kutilek
    Jens Kutilek Posts: 377
    edited June 11
    Yes, Frank is probably right. Except every font editing app set has set the Regular bit on "non-RIBBI Regular fonts" for the last couple of decades. Even in MS's latest and greatest Aptos, the Light font has the Regular bit set, if that may serve as a reference. But sure, Monotype, "overall font reliability"!

  • Jens Kutilek
    Jens Kutilek Posts: 377
    John Hudson said:
    fsSelection is a bit array in the OS/2 table, with each defined bit having a specific meaning if turned on. Tools like FontLab and Glyphs will automatically set the bits based on other font info data. The important bits are 0 (is italic), 5 (is bold), 6 (is regular), and 7 (use typo metrics*).

    My impression of Glyphs is that there is often a way to affect small bits of font data by using custom parameters in Font Info, but that it isn’t always obvious which to use and how they should be set.
    John, you described it more thoroughly than me. I was only thinking about the style linking bits. Font editors usually have a way of setting the WWS and Typo Metrics bits (Glyphs indeed does that via custom parameters).
  • John Hudson
    John Hudson Posts: 3,423
    edited June 11
    @LeMo aka PatternMan aka Frank E Blokland
    Furthermore, if I recall correctly, according to the specs, a font family can only contain one Regular (fsSelection 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.
    The spec isn’t strict on this. When these fsSelection bits were first defined, ‘family’ was widely understood as a 4-style RIBBI grouping. So TestFont Light would be understood as the Regular style of the TestFont Light family.

    Later, when larger families became normal, the some parts of the spec shifted, and this is one of those cases where the spec now recommends against setting fsSelection bit 6 for anything but the Regular style of the larger family. But only says that the bit ‘does not need to be set’, not that it is prohibited.

    But as Jens notes, a lot of tools still follow the older practice of using this flag to indicate the Regular style of a RIBBI grouping.

    In general, the OT spec does not do a great job in terms of clarity what it means by ‘family’ in different contexts, although it is fairly explicit here:

    Bit 6 is not used in widely used in modern applications. If bit 6 is set, then bits 0 and 5 must be clear, else the behavior is undefined. Note that, if both bit 0 and bit 5 are clear, that does not give any indication as to whether or not bit 6 will be clear. For example, Arial Light is not the regular style of Arial and would have all bits cleared. In extended font families, bit 6 does not need to be set for fonts other than the regular style that, nonetheless, use "Regular" for name ID 2. (See Name IDs for more information.)
  • Michael Rafailyk
    Michael Rafailyk Posts: 188
    edited June 12
    LeMo aka PatternMan aka Frank E Blokland said:
    Glyphs apparently handles the font naming in question this way:
    Name table entries in OTM
    Georg fixed that bug today. I just checked the Name table in AFDKO and ID1 is fine now. However, as I said in a previous comment (after exporting from different versions of Glyphs), that was not a reason that cause style linking error in Monotype Validator. Two days ago I asked support to provide more details and possible steps to resolve the issue, so waiting for an answer.
    Jens Kutilek said:
    If fsSelection is the cause of this
    Even if so, then: 1. It's not enough for the support team to say please fix inconsistency of fsSelection in your fonts, that requires all the type designers (who publish with them) to be technically savvy (I mean that most of beginners wants to rely on the default export settings, following tutorials); 2. Instead, it should be directly addressed to applications developers (and explained why these changes are needed in a first place); 3. An updated recommendations (from Monotype) should be provided before (or simultaneously with) implementing such a big changes. And now they have the situation with dozen of reports.
  • Thomas Phinney
    Thomas Phinney Posts: 3,003
    As Monotype hasn’t yet provided guidance as to what exactly they think is wrong, it leaves people guessing at answers.

    I was really hoping it was related to the double-Regular thing. That was at least a non-crazy explanation.

    Some of these guesses would render invalid most large families ever published in the OpenType format. Or even most families of any size. But so far, nobody has come up with a better explanation. That is perturbing!

    (I feel reasonably qualified to make a statement like this, seeing as I was likely the most active single person explaining exactly how to get OpenType naming and style linking “right” to type designers and foundries in the early days of OpenType, from about 2000–2006 or so. I also specified this data for most of the Adobe Type Library getting converted to OpenType.)
  • Moritz Kleinsorge
    Moritz Kleinsorge Posts: 27
    I think Monotype will wonder why no one is submitting new fonts.
  • Tural Alisoy
    Tural Alisoy Posts: 64
    Friends, I think the problem is caused by the damn Monotype. I wonder why it shows that error if everything is fine. I've just checked every option I can think of, but like a virus, that error don't go away.
  • DanRhatigan
    DanRhatigan Posts: 39
    Our font engineers have been scratching their heads over this discussion, because the automated checks in the Foundry Platform have not been changed in about two years. They've touched base with Georg at Glyphs about the recent bug, but the recent uptick of failures that people in the thread have mentioned remain a puzzle. The current plan is to update the checks on the family structure to be more permissive of common permutations. I don’t know when the update will be complete, but as soon as I hear news I'll pass it along.
  • DanRhatigan
    DanRhatigan Posts: 39
    edited 3:35AM
    And @Simon Cozens, on behalf of my German colleague who occasionally uses ChatGPT to help phrase some tricky explanations in English, I promise we’re not sending out automated-with-AI responses to issues that pop up (at least not the support teams I work with most of the time).

Categories