Why do some characters display as a block unless special characters are anywhere on the same line?

mkupper

This is for many versions of npp including v8.5.2. See below for the npp debug info if needed.

I have noticed that some characters display as a block (▯) unless certain other characters are anywhere on the same line of text. In that case the characters display correctly.

Npp seems to be switching the character set used to display a line of text on the fly if certain characters exist on the line.

I’m trying to understand the behavior better so that npp displays things consistently in my files which are nearly always .txt extension files. Some of them have the UTF-8 BOM and others don’t. The behavior I’m asking about is the same regardless of the BOM.

An example of this is ↛ which is U+219B or RIGHTWARDS ARROW WITH STROKE

U+219B displays correctly if any of these characters are anywhere on the same line as the U+219B

ڌ U+068C ARABIC LETTER DAHAL
ง U+0E07 THAI CHARACTER NGO NGU
ย U+0E22 THAI CHARACTER YO YAK

― U+2015 HORIZONTAL BAR

⁄ U+2044 FRACTION SLASH

← U+2190 LEFTWARDS ARROW
↑ U+2191 UPWARDS ARROW
→ U+2192 RIGHTWARDS ARROW
↓ U+2193 DOWNWARDS ARROW

⇒ U+21D2 RIGHTWARDS DOUBLE ARROW

⇔ U+21D4 LEFT RIGHT DOUBLE ARROW

That’s not a full list. I know of about 1000 characters that trigger npp into displaying U+219B correctly.

U+219B is not the only character with this issue. I know of about 500 characters that are like this. Here is a sample.

‣ U+2023 TRIANGULAR BULLET
․ U+2024 ONE DOT LEADER
‥ U+2025 TWO DOT LEADER
‧ U+2027 HYPHENATION POINT
⁋ U+204B REVERSED PILCROW SIGN
℗ U+2117 SOUND RECORDING COPYRIGHT (P)
℠ U+2120 SERVICE MARK
↖ U+2196 NORTH WEST ARROW
↗ U+2197 NORTH EAST ARROW
↘ U+2198 SOUTH EAST ARROW
↙ U+2199 SOUTH WEST ARROW
↚ U+219A LEFTWARDS ARROW WITH STROKE
↛ U+219B RIGHTWARDS ARROW WITH STROKE
↜ U+219C LEFTWARDS WAVE ARROW
↝ U+219D RIGHTWARDS WAVE ARROW

Debug info for a copy of npp that reproduces the issue:
Notepad++ v8.5.2 (32-bit)
Build time : Apr 4 2023 - 19:48:53
Path : c:\bin\npp-v8.5.2\portable\notepad++.exe
Command Line :
Admin mode : OFF
Local Conf mode : ON
Cloud Config : OFF
OS Name : Windows 11 Home (64-bit)
OS Version : 22H2
OS Build : 22621.1555
Current ANSI codepage : 1252
Plugins :
mimeTools (2.9)
NppConverter (4.5)
NppExport (0.4)

PeterJones

@mkupper ,

This is essentially what is talked about https://community.notepad-plus-plus.org/post/84315 and in the replies. If you go to Settings > Preferences > MISC and checkmark Use DirectWrite and restart Notepad++, it should hopefully render those characters better. (We have asked for that option to be on by default, but the Developer has chosen not to.)

mkupper

Thank you @PeterJones - Enabling the DirectWrite setting fixed the issue. At first I thought though that DirectWrite was also causing lines of text to get spread out more in the vertical direction but npp either settled down or I got used to it.

One comment is that in the thread you reference there is “… are properly displayed ONLY IF the current line contains a character with codepoint over the BMP …”

The examples I provided were all with BMP characters. You don’t need to use a character that’s beyond the BMP.

That thread also said that the special character had to be at the front of the line. When I tested I found it could be anywhere in the line and it would cause the ▯(s) on that line to instantly be displayed correctly.

Alan Kilborn

@mkupper said in Why do some characters display as a block unless special characters are anywhere on the same line?:

One comment is that in the thread you reference there is “… are properly displayed ONLY IF the current line contains a character with codepoint over the BMP …”
The examples I provided were all with BMP characters. You don’t need to use a character that’s beyond the BMP.
That thread also said that the special character had to be at the front of the line. When I tested I found it could be anywhere in the line and it would cause the ▯(s) on that line to instantly be displayed correctly.

There are a lot of ways to get into your original situation. No one knows them all (probably). Previous statements were likely made with some experimentation with an exact data situation, and conclusions drawn at that time. Your data is different, and the results are as well.

I wouldn’t think too hard about it. Just enable DirectWrite and move on.

PeterJones

@mkupper said in Why do some characters display as a block unless special characters are anywhere on the same line?:

One comment is that in the thread you reference there is “… are properly displayed ONLY IF the current line contains a character with codepoint over the BMP …”
The examples I provided were all with BMP characters. You don’t need to use a character that’s beyond the BMP.

You rather misunderstood Guy’s statement,

if the DirectWrite option is not checked, the four Unicode characters … are properly displayed ONLY IF the current line contains a character with codepoint over the BMP

The “four Unicode characters” in question were 25F4, 25F5, 25F6, and 25F7, none of which are themselves above the BMP. What Guy’s experiments showed was that, if DirectWrite was not checkmarked, then those four characters would not be shown correctly unless they were preceded by a character above the BMP. So it was having a character above the BMP that made those four in-the-BMP characters display properly.

And, as Alan said, that discussion was about those four clock characters specifically, not about every possible problem that is solved by DirectWrite being enabled.