Ctrl+Shift+B resulting Exp SmBold instead of Bold in Indesign

[rikzafsh]

I am using Indesign 2020 and Windows 11. When I press Ctrl+Shift+B in Indesign, it makes Junicode Regular becomes Exp SmBold instead of Bold. However, if the text has been set to Bold, pressing Ctrl+Shift+B will make the text become Regular.

[kenmcd]

What version of the fonts? Variable or statics? What version of InDesign? What Operating system?

[rikzafsh]

Latest version, but earlier version is also like that. I use static font. Indesign 2019 and 2020. Windows 10 and 11 (I use two different laptop and still have the same problem).

[kenmcd]

Latest version

Which "latest version" specifically?

[psb1558]

I'm getting a different effect: the shortcut for bold type does nothing at all in my copy of InDesign. It does work with Elstob. I'll check over the style linking.

[psb1558]

The problem was a stray parameter that was messing up the style linking (I'm not sure how). It's working for me now, and it should be fixed with the next release

[kenmcd]

The problem was a stray parameter that was messing up the style linking (I'm not sure how).

What did you find? I checked and did see the issue, so I am curious.

[psb1558]

One of the instances (I forget which one) had a Glyphs custom parameter "Style name as STAT entry" (I don't remember when or why I added it--probably some misconceived experiment). It didn't trigger the production of a STAT table, but it must have somehow interfered with the style linking when fontmake generated the font files. After I deleted the parameter. When I deleted the parameter and generated the file, the style linking started to work properly again.

[kenmcd]

Hmmmm... quite odd. I do not see any STAT table in the Normal/Regular or the Exp/SmBold (although they could have one). Since this change has fixed the issue, I really wonder what it was. So I will be interested in running a diff with the working fonts to see what changed.

[psb1558]

Right. I also checked for a STAT table and didn't find one. So my theory is that the presence of the parameter somehow caused fontmake either to not do style linking at all when generating the fonts or to do it improperly. After all, a STAT table does the job that style linking does, but in a more modern way. But I'm far from certain.

[psb1558]

Looked at the fsSelection and macStyle bits in the current and the next version and saw no difference. So as of now I have no idea what I broke before or what I have fixed.

[kenmcd]

You know I love a good mystery... :-) I saw nothing wrong with the static fonts style-linking so I am intrigued. It could just be an InDesign issue. This only involves the statics, and the few I checked have no STAT tables - so that does not appear to be the issue. But maybe I should see if any of them have a STAT table.

Maybe only some (or one) of the static fonts had a STAT table (from your "Style name as STAT entry" setting). And I wonder if the user had the variable also installed - but that should not matter as the family name includes the "VF."

Part of my curiosity is I am trying to get really familiar with STAT entries, and fvar instances, and style-linking in variable fonts. Like I am with static fonts. I want to be able to just look at it and see the issues. I'm on a quest!

Gonna go run a ttx STAT dump on the whole static directory and see if it shows any STAT tables in the statics.

[psb1558]

I did a ttx dump on the whole static otf directory and found no STAT table in any of them. Didn't check the ttf, though.

[kenmcd]

I did a ttx dump on the whole static otf directory and found no STAT table in any of them. Didn't check the ttf, though.

OK.

[psb1558]

The (mysteriously) fixed fonts should now be in the new release, 2.209.