# \[BR\] No fallback font selected on Windows when using an embedded font

**URL:** <https://forum.juce.com/t/br-no-fallback-font-selected-on-windows-when-using-an-embedded-font/54008>\
**Category:** Windows\
**Created:** [December 5, 2022, 10:38am UTC](https://forum.juce.com/t/br-no-fallback-font-selected-on-windows-when-using-an-embedded-font/54008 "2022-12-05T10:38:18Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![ImJimmi](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/imjimmi/32/10843_2.png) [@ImJimmi](https://forum.juce.com/u/ImJimmi)\
**Post date:** [December 5, 2022, 10:38am UTC](https://forum.juce.com/t/br-no-fallback-font-selected-on-windows-when-using-an-embedded-font/54008/1 "2022-12-05T10:38:18Z")

</div>

We’re embedding a TTF font file in our app using the JUCE binary data mechanism. The font only includes glyphs for latin and cyrilic languages, and so for langauges like Chinese, Korean, and Japanese we were relying on a fallback font being implicitly chosen.

On macOS this works as expected.

On Windows however, the text was completely blank - not even the placeholder `[]` characters were shown.

If we instead installed the font to the system, and used the `juce::Font {"MyFont"}` constructor, we had the expected behaviour where a fallback font was used for any glyphs that aren’t included in the specified font. However we don’t want to rely on the user having the font isntalled on their system - we want to be able to use an embedded font.

The returned result from `juce::translate()` is populated, so it’s something to do with the drawing of that text. We’re drawing the text using a `juce::AttributedString`.

I’ll try to find time to put together a PIP to reproduce the bug, but it should be as simple as using an embedded font and then trying to display a glyph on Windows that’s not included in that font.

---

<div class="post-metadata">

**Author:** ![otristan](https://avatars.discourse-cdn.com/v4/letter/o/f0a364/32.png) [@otristan](https://forum.juce.com/u/otristan)\
**Post date:** [December 5, 2022, 1:46pm UTC](https://forum.juce.com/t/br-no-fallback-font-selected-on-windows-when-using-an-embedded-font/54008/2 "2022-12-05T13:46:31Z")

</div>

use TextLayout and set JUCE\_USE\_DIRECTWRITE to 1

---

<div class="post-metadata">

**Author:** ![ImJimmi](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/imjimmi/32/10843_2.png) [@ImJimmi](https://forum.juce.com/u/ImJimmi)\
**Post date:** [December 5, 2022, 3:13pm UTC](https://forum.juce.com/t/br-no-fallback-font-selected-on-windows-when-using-an-embedded-font/54008/3 "2022-12-05T15:13:12Z")

</div>

Ahh, I’d missed that `AttributedString` doesn’t use `TextLayout` by default… I thought it did! That’s probably something to try then, thanks @otristan!

For now we’ve worked around this by simply embedding extra fonts for the different langauges we’re supporting - which in hindsight is what we should be doing anyway and not relying on some unknown fallback font.

This still appears to be a bug with JUCE though - especially as the behaviour is different between macOS and Windows, and AFAIK there’s no documentation to say whether or not what we’re doing is wrong.