I’ve just decoded a situation with bringing a Scrivener output into publishing program, not InDesign this time.
The problem is that Frutiger Neue LT Pro with Book face gets named ‘Frutiger Neue LT Pro Book’, visibly on the S3 user interface.
Then an importing program after export of course can’t find that font, at best says it’s non-existent and tells you to substitute it.
Relevant images show S3’s interface misnaming, then InDesign properly separating font and face, and finallly how Windows 10 latest sees the font, which is correct for each face even though you can see only one here.
You can see that another Linotype LT font gets similarly mistreated, as do all face variants of this one.
I would expect there to be a certain amount of impossibility in avoiding all such cases like this, given there is a lack of universal standards in how fonts should be named internally, between different file formats, software and operating systems. We ran into a lot of this when getting iOS/Win/Mac roughly on the same page with regards to fonts. In fact a lot of fonts we had to actually override how things work internally because there was no good solution for how each system refers to fonts differently (yes, even between iOS and macOS!).
While I do not have that particular font installed, I see others in the list that present themselves similarly (with family other details in the name), and in checking WordPad it seems they are referred to the same there as well. Have you double-checked to see whether a document compiled from Scrivener loads incorrectly in WordPad, or if a document created in WordPad using these fonts also does not import as expected into the other program?
Here is my example: “OliveGreen Mono Light”, in Scrivener and WordPad, but just “OliveGreen Mono” as a family (of which Light is one variant among over half a dozen) in Fonts.
