# \\mscr unicode character display in REPL with Windows

**URL:** <https://discourse.julialang.org/t/mscr-unicode-character-display-in-repl-with-windows/10290>\
**Category:** General Usage\
**Created:** [April 11, 2018, 8:43pm UTC](https://discourse.julialang.org/t/mscr-unicode-character-display-in-repl-with-windows/10290 "2018-04-11T20:43:38Z")\
**Posts on this page:** 1\
**Showing post:** 13

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [August 28, 2019, 8:13pm UTC](https://discourse.julialang.org/t/mscr-unicode-character-display-in-repl-with-windows/10290/13 "2019-08-28T20:13:30Z")

</div>

> [@braamvandyk](#):
>
> OK, back from holiday, so I had time to run a little test. Turns out it is a bit deeper. If I run Julia inside Git Bash, with the **same font** , all of `\scrA` to `\scrZ` actually display just fine. Running Julia inside PowerShell or the Windows console still displays placeholders instead, even though the characters display just fine in Atom. Git bash (mintty) is set to use UTF-8, which - to my knowledge - the Windows console does not handle properly.

Sorry to resurrect an old thread, but I wanted to note that there is a simple explanation for this puzzle: when a glyph is not present for a character in a given font, decent text-rendering software switches to a [“fallback” font](https://en.wikipedia.org/wiki/Fallback_font) to find a glyph for that character. Mintty (used by git bash) supports fallback fonts, but the Windows console [does not](https://github.com/JuliaLang/julia/issues/7267#issuecomment-478262752). So, probably your font does _not_ have the `\scrA` character, but Mintty switches to a fallback font whereas the Windows console gives up. This has nothing to do with UTF-8.

---

_[View the full topic](https://discourse.julialang.org/t/mscr-unicode-character-display-in-repl-with-windows/10290)._