that this setting was true per default on one machine, but false on others

It would depend on what version was first installed on each of these machines.
Recently, DirectWrite was defaulted to On for new installs, whereas on older versions, it was defaulted to Off.
So yes, “true per default on one” and “false on others” is perfectly understandable.

@Alan-Kilborn said in Insert Unicode characters not working - please help:

@ZsoltKántor

You may also want to try this setting enabled for your situation:

Thanks @Alan-Kilborn , this works, the two downsides what I observed is that the characters overall are a little bit thicker, and np++ start up a bit slower.
But good to know about this option :)

Solved issue for me as well, thanks a lot! The odd thing is, that this setting was true per default on one machine, but false on others… so hat the issue on some machines, even same NP++ version, same file etc. tried everything but nothing worked, until found this post!

    Set or create a string, of type (REG_SZ), value called EnableHexNumpad in the registry key HKEY_CURRENT_USER\Control Panel\Input Method\

    Assign the value data 1 to this key

I was looking for a long time for solution to this. Thank you!
It’s weird that is not a default thing after so many years.
Cheers

@ZsoltKántor

You may also want to try this setting enabled for your situation:

Thanks @Alan-Kilborn , this works, the two downsides what I observed is that the characters overall are a little bit thicker, and np++ start up a bit slower.
But good to know about this option :)

No point in changing the default

It’s always a “hard sell” to get a default changed anyway. :-)

I wonder if there’s ever a good reason for having that option off?

A quick search of the forum shows:

• some find DirectWrite more fuzzy
• LineWrap issue
• Split-line Margin issues
  …

After those three, I stopped following the links. I can see that whatever the default state of that toggle, we’re going to get questions about why NPP works the way it does (or outright complaints about how awful the most recent change was). No point in changing the default, I guess. :-)

I wonder if there’s ever a good reason for having that option off? Should we lobby Don to change the default state of that option for future versions? (it might head off questions like this in the future)

I think I saw some discussion somewhere that having it on can cause performance issues.

So maybe it is 6-of-one, half-a-dozen of the other: Do we want more my-characters-don’t-display questions, or more my-N++ -is-slow questions? :-)

I always run with DirectWrite on, but I don’t do a lot of things with file types that appear to be cycle-hogs (e.g. XML). But, thinking about it now, even careting through N++'s config file xml stuff is rather slow for me – perhaps it is related to DirectWrite? Hmmm…

You may also want to try this setting enabled for your situation

Checking for confirmation: When I pasted the text into my v8.1.1 with DirectWrite checked, it showed the fancy integral characters; if I have DirectWrite unchecked (and re-start NPP, of course) then it doesn’t render. And both of those were with the same Deja Vu Sans Mono font, which doesn’t natively have those glyphs. (Same results with a fresh unzip with Courier New selected). So yes, I think there’s a good chance that turning on the DirectWrite option will help the @ZsoltKántor, even if the active font doesn’t have them.

I wonder if there’s ever a good reason for having that option off? Should we lobby Don to change the default state of that option for future versions? (it might head off questions like this in the future)

You may also want to try this setting enabled for your situation:

notepad.exe font is Lucida Console and

Lucida Console does not have those glyphs, as of the version that came with my Windows 10 machine:

Lucida Sans Unicode does have them.

As @guy038 explained, Windows sometimes chooses a fallback font compared to the font you have set in a given application… But I’ve found that Windows favors doing that substitution in built-in Microsoft apps; whereas in externally-produced applications like Notepad++, Windows OS seems less-likely to apply the fallback fonts.

Sites like fileformat.info will show lists of fonts that do contain a glyph for a particular

• U+2230 ( ∰ ) volume integral symbol @ https://www.fileformat.info/info/unicode/char/2230/fontsupport.htm
• U+2231 ( ∱ ) clockwise integral symbol @ https://www.fileformat.info/info/unicode/char/2231/fontsupport.htm

So if you can find a monospace font there that meets your font licensing requirements, you could download that font and set it as the font you use in Notepad++. (What annoys me is that all of the Deja Vu fonts, except the Deja Vu Sans Mono that I use in NPP, support those glyphs.)

The fact that you see small boxes, instead of real characters, means that :

• Your current N++ font cannot handle these characters

• Your OS did not find out a substitute font to display the character glyphs

• Finally, your OS did not find out a fallback font, too !

As for me, I generally use the monospaced font Consolas and the current version of this font ( on my old Win XP SP3 laptop ! ) just displays boxes with an question mark inside !

But , if I change the default font in Settings > Style configurator... > Global Styles > Default style > Font style > Font name and choose, for instance, Lucida Sans Unicode or Microsoft Sans Serif or Tahoma, I do get the characters ∰ and ∱ :-))

I bet your Notepad.exe current font is Microsoft Sans Serif, isn’t it ?

Best Regards

guy038

e.g.:
U+2230 ( ∰ ) volume integral symbol
U+2231 ( ∱ ) clockwise integral symbol

In Np++ a box appears instead the symbol:

In notepad.exe symbols look fine:

Thanks again!

I don’t understand why you cannot achieve this operation ?

• If I press, successively, the +, 0, 3, 8 and 8 keys, on the numeric keypad, while holding down the Alt key, I do get the Έ character ( GREEK CAPITAL LETTER EPSILON WITH TONOS ), once the Alt key released !

Refer to https://www.unicode.org/charts/PDF/U0370.pdf

• If I press, successively, the 0, 3, 8 and 8 keys, on the numeric keypad, I do get the „ character ( DOUBLE LOW-9 QUOTATION MARK ). Why ? Because :

  • First the decimal input 0388 is evaluated modulo 256 so, giving the decimal value 0132

  • Then, the character, of numeric value 132 ( and hex value 84 ) is the ANSI character „, which stands for the Unicode character of code-point U+201E ( DOUBLE LOW-9 QUOTATION MARK )

Thus, may be, your system don’t have the recent Unicode input method ! In that case, you’ll have to edit the Registry and follow the method described in the Transition to Unicode chapter of this page :

https://en.wikipedia.org/wiki/Alt_code

which says :

So a method was developed to enter Unicode, in Windows, using the hexadecimal code point. To enable it, a user must :

• Set or create a string, of type (REG_SZ), value called EnableHexNumpad in the registry key HKEY_CURRENT_USER\Control Panel\Input Method\

• Assign the value data 1 to this key

• Reboot or log out/in

=> A leading +, on the numeric keypad, then allows entry of a hexadecimal Unicode value (using the main keyboard for A–F )

Best Regards,

guy038

Try to print U+0388, that is Έ
Here we have no characters, and still trying to insert that character I end up inserting: „ (a quotation mark)

Can you try please U+0388 on your side?
Thanks!

You did a small mistake !

In order to get the character of Unicode code-point U+22D5 :

• Preferably, ensure that the Numlock key is enabled !

• Hold down the Alt key

• First, press the + key of the numeric keypad ( Important ! )

• Then press, successively, on each digit of the hexadecimal code :

  • If it’s a number, between 0 and 9, press the corresponding key on the numeric keypad

  • if it’s a letter, between A and F, press the corresponding key on the main keyboard

• Release the Alt key

=> The ⋕ character should appear at caret position !

You probably forgot to press, first, the + key on the numeric keypad. So, your OS thought you were typing a classical Alt and 0nnn sequence ( with 000 < nnn < 255 ) which can produce all the characters of your ANSI encoding, visible with the Edit > Character Panel N++ menu option !

And, as letters are not allowed in the sequence, because nnn is a 3-digits number, the OS just considered the sequence ALT and 5, which finally returns the ♣ character !

Refer to the 3 chapters DOS, Windows and Transition to Unicode of the page :

https://en.wikipedia.org/wiki/Alt_code

Best Regards,

guy038