Unicode characters messed up after linebreak - unicode

Question

Certain combinations of Unicode characters seem to be problematic. I'll show you what I mean using Notepad++.
Create a new text file in Notepad++ and change the encoding to UTF-8 (BOM doesn't matter).
Copy and paste the following four arrows: ↑↓↙↘. This should look like fine (see first image below).
Now insert a newline after the second arrow (Windows/Unix doesn't matter). Now the first line still looks fine, but the arrows in the second line are replaced by placeholder boxes (see second image below).
Saving and reopening makes no difference. Still boxes in the second line. Remove the linebreak, and everything looks fine again.
This problem isn't exclusive to Notepad++. Other programs also show garbage when loading the text file with a linebreak. Surprisingly, the standard Windows Notepad displays it just fine.
This is the working file, once in hex and once within Notepad++:
E2 86 91 E2 86 93 E2 86 99 E2 86 98
This is the broken file. Notice all that's different is the added linebreak (0D 0A).
E2 86 91 E2 86 93 0D 0A E2 86 99 E2 86 98
Can anybody share some light on what's happening here?
Edit: I'm writing a program that creates output in a text format. I stumbled upon the problem when several text editors wouldn't display my program's output correctly, so I first assumed there was something wrong with my program. As it stands, its output is just fine. So the real question is:
Is there a way to change the second (broken) example so that it will display correctly in your typical editor?

Answer 1

This is a font problem that exhibits some bugs or deficiencies in text editors. One might actually ask why e.g. Notepad++ shows “↙↘” at all when it is using Courier New (which I think is its default font). That font (as well as many other fonts) do not contain those characters at all.
Looking at the sample in the question you can probably see that in “↑↓↙↘”, the first two characters are in different style from the other two. The reason is that they are displayed in two different fonts. (I see them in Arial and in DejaVu Sans. Your mileage may vary, depending on fonts installed in your system and your browser’s fallback font list.)
Similar things happen e.g. in Notepad++ and Notepad. When the primary font being used does not contain all the characters in the text, the program uses some fallback font(s). This might be hard-wired in the program code, or it might be user-settable.
For some reason, in Notepad ++, the font fallback mechanism fails in some situations. It also happens if you just delete the first two characters, or initially enter just “↙↘”. Apparently, what precedes those characters on the same line affects the font selection mechanism. You might consider submitting a bug report, but it might be classified as a feature, not a bug. After all, asking a program to render characters that do not appear in a font that the program has been set to use might cause general failure, rather than just a failure in some cases.
The solution is that when using a text editor to view data, the editor should be set to use a font that contains all the characters appearing in the text. See a list of fonts supporting “↙” (not exhaustive, but probably covers rather well the fonts you can expect a normal computer to have installed). In a text editor, you might wish to use a monospace font; in that case, DejaVu Sans Mono might be adequate (unless there are other relatively uncommon special characters – the font has only 3,310 glyphs).