In the editor, I can do a character-style to force the emojis to use the font “noto-emoji” which is a black and white version of the default full-color-apple-emojis. But when I try to compile into pdf/word, etc. it defaults back to the color version.
If I add my custom “emoji” character style to the compile (using embed fonts, etc.) it refuses to change the font, defaulting to Helvetica. I can change it to “noto-emoji” in the pull-down menu, but it doesn’t actually change or save it as anything but Helvetica…
Found one work-around, but it’s clunky… select the entire manuscript, right-click on the character-style “emoji”, select All text with character style, and then go to menu>Format>Preserve Formatting
This seems… roundabout and unintutive. I’m not even sure how I found it, to be honest.
The fact that using preserve formatting makes it work (thus meaning that Scrivener can actually output this font at compile) leads me to wonder if perhaps you’ve set the style wrong in the styles panel of your compile format…
. . . . . . . .
Or in your style:
. . . . . . .
Of course, if you used this below feature at compile, that’d prevent your font from being compiled as intended:
It needs to be “Determined by Section Layout”.
Anything else (a font selection) will override whatever you’ve set in the compile format.
Just out of curiosity, why are you adding this style to your compile format? Generally you would only want to do that if you wish to change the formatting for the style—like how Manuscript Times would do. If you just want to pass-thru the original formatting though, the style itself is good enough.
Do make sure that the style settings for this character style, in the project, stipulate saving the font family though. If you leave that checkbox off then the compiler will feel free to change the base font. A style will only preserve what we tell it to.
As to the question of Helvetica, that’s a known limitation with the compiler at the moment. You are applying a font that has no characters for the sample text to display itself, so the text engine drops to a default font that does. You can’t actually apply Noto-Emoji at the compile phase on account of this—but again that’s not necessary anyway.
Yeah, again I think at this point you are layering so many workarounds on top of each other that we would rather hope that this current state is “unintuitive”.
I.e. Styles are “Preserve Formatting”, that is one of their primary purposes, unless you override them by name in the compiler. The latter feature itself is a legacy hold-over from the days when styles didn’t exist. It’s largely there for backwards compatibility and a few exotic edge case uses.
Give this test project a compile and see if it works well for you. In my testing it correctly assigns the font, however the program being used to look at the compiled file may not be finding the font, and thus doing what I described above: dropping to a fallback font that works, and thus stock Apple Colour Emoji.
I feel like I’d figured out how to do it, and somehow whatever I did got lost… quite possibly what I did was replaced the “Apple color emoji.ttf” file in my system with a noto-emoji.ttf renamed to “fool” the system, so it got compiled correctly… then in this latest system update to Ventura, it got reset. Whatever the case, it has not been an “easy” matter of simply using something other than the apple color emojis in compile or elsewhere. The Preserve Formatting is the only thing that seems to work consistently.
Most letters are substitutable by the (available) font because they’re using unicodes down in the first 200 numbers… U+0061is Latin lowercase ‘a’, for instance. But Emojis are off-scale for most font-sets, so would default to blanks or “undefined.” (Emojis are typically really high up in the numbers… Smiley face is U+1F600, for example, and most fonts would not have something defined in this “space.”
