[BUG] Mono-space fonts do not appear mono-spaced

[slipbits]

Is there an existing issue for this?

• [x] I have searched the existing issues

Description of the Issue

Win 11-64 NPP 8.8.1

Related bugs: Some monospaced fonts are misaligned with syntax highlight #13713 Broken font-spacing when configuring fonts in a 'light' font weight variant #11244

There is a misalignment of columns with mono-fonts. For example: SlipHeader* header[] = { new SlipHeader() // 0 "( < > )" , new SlipHeader() // 1 "( < < > > )" Shows that the columns for ',' are the same, but on the monitor it shows that a 4-char displacement. That is, on the screen "{" and "," are given in column 27, but on the screen the "," appears directly under the "w" in "{ new". I have counted off the columns to both fro column 1, and the count is the same for both.

I've tried several fonts, both those marked as mono and those not so marked, all yielding similar results. The visual appearance doesn't correspond to the column number as given at the bottom bar.

The effect is that items which are at the same column number appear on the monitor as if they were at different columns.

thanks for all that you've done; art

Steps To Reproduce

1. Open a file with mono-spaced text (such as source code).
2. Select a mono-spaced font in Settings->Style Configurator

Current Behavior

mono-spaced source files are not mono-spaced causing columns to appear misaligned on the monitor

Expected Behavior

Mono-spaced files should be mono-spaced with a mono-spaced font.

Debug Information

Notepad++ v8.8.1   (64-bit)
Build time : May  3 2025 - 18:41:09
Scintilla/Lexilla included : 5.5.6/5.4.4
Boost Regex included : 1_85
Path : C:\Program Files\Notepad++\notepad++.exe
Command Line : 
Admin mode : OFF
Local Conf mode : OFF
Cloud Config : OFF
Periodic Backup : ON
Placeholders : OFF
Scintilla Rendering Mode : SC_TECHNOLOGY_DIRECTWRITE (1)
Multi-instance Mode : monoInst
File Status Auto-Detection : cdEnabledNew (for current file/tab only)
Dark Mode : ON
OS Name : Windows 11 Pro (64-bit)
OS Version : 24H2
OS Build : 26100.4349
Current ANSI codepage : 1252
Plugins : 
    mimeTools (3.1)
    NppConverter (4.6)
    NppExport (0.4)

Anything else?

[pryrt]

Cannot reproduce / It works for me:

SlipHeader* header[] = { new SlipHeader()             //  0  "( < > )" 
                       , new SlipHeader()             //  1  "( < < > > )"

---

• What theme are you using?
• Have you edited your theme?
• What programming Language do you have selected?
• What are your Settings > Preferences > Indentation > Indent settings for that language?
• Are the characters before the comma on the second line spaces, tabs, or a mix of both? (it will help if you turn on View > Show Symbol > Show Space and Tab)

In my example, I used spaces for the indentation, and everything lines up properly. If I have tabs set at 4 characters per tab, and replace the first T*4 spaces with T tabs instead, it still lines up for me:

But when you say it is off by "4", that's strongly suggestive to me that you have a mix of tabs and spaces, and you are miscounting the number of characters vs apparent width -- a screenshot with the Show Space and Tab will really help with debugging your problem for you.

[softmgr]

This issue is likely caused by inconsistent indentation characters in the source code. For example, some lines use tabs for indentation, while others use spaces.

[tobwen]

I'm experiencing exactly the same issue out of the blue. It worked for years without a problem. As you can see in the screenshot, I'm using 100% spaces, no tabs, no magic.

Interesting. It only happens when setting Courier New to 9pt. When setting it to 10pt and zoom out a bit, it works again.

[pryrt]

I'm experiencing exactly the same issue out of the blue. ... As you can see in the screenshot, I'm using 100% spaces, no tabs, no magic.

And yet you chose not to answer most of the questions/clarifications that were requested from the original person. That same information might help us find something for you.

Interesting. It only happens when setting Courier New to 9pt. When setting it to 10pt and zoom out a bit, it works again.

One intriguing data point, but the other info requested will make it easier to try to help you (or the OP).

(Also, you need to provide the Debug Info, because your setup may have slight differences compared to the above)

[pryrt]

@tobwen showed the screenshot,

Seeing def main():, I am assuming Python. I manually typed your code (or close to it: since the spacing issue was before the help=, I didn't type as much in that attribute value). For other reference, here is what I used:

def main():
    parser = argparse.ArgumentParser(description='Process document batches')
    parser.add_argument('--input-dir', type=Path, default='02-input',                           help='1')
    parser.add_argument('--processing-dir', type=Path, default='03-processing',                 help='1')
    parser.add_argument('--distribution-dir', type=Path, default='04-distribution',             help='1')
    parser.add_argument('--max-workers', type=int, default=12,                                  help='1')
    parser.add_argument('--batch-size', type=int, default=25,                                   help='1')
    parser.add_argument('--min-batch', type=int, default=16744,                                 help='1')
    parserz.add_argument('--processed-file', type=Path, default='verteilt',                     help='1')
    parser.add_argument('--job', choices=['processing', 'distribution', 'all'], default='all',  help='1')
    parser.add_argument('--timestamp', type=str,                                                help='1')
    parser.add_argument('--verbose', '-v', action='store_true',                                 help='1')

Looking at your colors, once I was back on a PC, I started cycling through the themes until I found that it seems to match the colors of Deep Black. As I was going through all the themes before that, everything was lined up. But then for Deep Black, it got out of alighment. For example, here it is lined up with Dark Mode Default (but changed to Courier New = 9pt instead of the Consolas = 10pt that it starts with):

If I then cycle down to Deep Black, which defaults to Courier New = 9pt, it gets out of alignment:

So I can replicate your problem. But I was also to easily find the issue: Go to Language: Python and start cycling through the Style: entries. The Style: BUILTINS default overrides the font size to size 10:

Because it does that, then pairs like type=int, which are both using builtin keywords, are actually in 10pt font instead of 9pt font.
If you manually change that back to Font size: [blank], then everything lines up:

This would explain why, for @tobwen , it didn't line up when the default font size was 9pt but did when it was 10pt.

I cannot figure out what Language @slipbits was using (too many C-derived langauges look like that code snippet), so I then cannot determine for sure which Theme was being used, so I cannot confirm whether there are one or more Styles for that Language in that Theme that also override font and/or size.

The root cause is that some Theme authors accidentally or intentionally changed the font and/or size for one or more Language styles inside their theme, rather than letting it inherit those from the theme's Default Style, thus causing a mismatch if someone changes the Default Style font or size for a given theme.

---

Likely solution for individuals seeing this Issue:

If you are seeing code that should be in monospace font, but characters get slightly out of alignment in your theme:

1. Go to Style Configurator for your active theme
2. Double-check what font and font-size are in Language: Global Styles > Style: Default Style
3. In the Language chooser, pick the Language that your current file is in
4. Go through each of the Style: entries for that Language, and make sure that Font name and Font size pulldowns are either blank/empty, or that they exactly match the Default Style values from step 2
5. Once you've done that for all Styles on that Language, everything should line up correctly.
6. Save & Close to make that change permanent

From now on, everything should line up for that Language in that Theme.

[tobwen]

@pryrt Please let me explain.

And yet you chose not to answer most of the questions/clarifications that were requested from the original person. That same information might help us find something for you.

I wanted to do this, that's why I've opened the style configuration at all. I thought: "Oh, why is it set to 9? I'm like Adrian Monk, I need an odd value" and after setting it to 10, it worked. So I thought, maybe it's a rounding issue or whatever and I reported this. Problem solved.

I didn't think it's further down because I'm overriding ALL the settings in the override/default section. The size AND the font! That's why I never thought, it might be somewhere else.

And since TWO people of billion users (literally), I thought: it's my fault. Nobody else is affected. I don't want to make more noise as needed.

Thanks for your help and fix.

[softmgr]

I think I've found the root of the problem. Just leaving a placeholder here - I'll add more tomorrow.

[pryrt]

I think I've found the root of the problem.

The root of the problem is that many themes have one or more languages in which one or more styles have a hardcoded fontSize instead of letting them inherit the Default Style's fontSize for that theme. That means that if you change the Default Style's fontSize, then any style in a theme that has a hardcoded fontSize will not inherit from the Default Style, and will be a different size; once you have a line with mixed font sizes, even monospaced fonts won't appear monospaced, because the "mono" requires all the characters to be the same font size.

I am curious what you think the "root" is, presumably "caused" by some code in your thought process, that could explain it better than "different font sizes cannot and should not maintain 'monospaced alignment' when used in the same text file."

If I have a document that's monospaced with 11 point Default Style, if there's a couple of characters that are 24 point (using extremes to drive home the point), how do you think code can make those monospaced 24pt characters have the same column width as the normal monospaced 12pt characters? For those columns, would you expect Notepad++ to display every other line in those columns with the width needed for 24pt?

Screenshots with the example Python code make it obvious:

• with mismatching fontSize for Python BUILTINS style:
• with proper fontSize = empty for BUILTINS, so it inherits:

Notepad++ is doing exactly what it should -- rendering each character with the fontSize defined for the style. It's just a poorly designed Theme / Style Configurator setting value that is causing the mismatch. The exaggerated 24pt makes this obvious that it's the font size setting, not any misbehaving code.

[softmgr]

sample file: READ.md.zip

@donho @pryrt @tobwen @slipbits We first performed a clean installation of the latest Notepad++ version 8.8.3, using the default settings to open the sample file. The font rendering is not monospaced (text does not align properly), as shown below:

Next, we uninstalled Notepad++ and deleted its user configuration files located at: C:\user\<current user>\AppData\Roaming\Notepad++. Then we installed an older version, Notepad++ 8.5.8. Again, using default settings, we opened the same sample file. This time, the text was displayed in monospaced format, as shown below:

So, where does the issue lie? After reviewing the source code of Notepad++ 8.5.8 and 8.6 (this bug started appearing from v8.6 onwards), I discovered a key difference in the default settings.

In version 8.5.8, the default rendering engine is set to:

writeTechnologyEngine _writeTechnologyEngine = defaultTechnology;

But starting from version 8.6, the default was changed to:

writeTechnologyEngine _writeTechnologyEngine = directWriteTechnology;

Let's verify if this is indeed the cause. We uninstall version 8.5.8 again and remove the user configuration files. Then, we install the latest Notepad++ version 8.8.3. In the program settings, we change the rendering mode to GDI (most compatible), as shown below:

After restarting Notepad++, we open the sample file again. This time, the text is displayed in monospaced format, as shown here:

Conclusion: This doesn't appear to be a bug in Notepad++ itself, but rather an issue with how Scintilla handles rendering. Specifically, it seems to be a bug in Scintilla's DirectWrite rendering mode.

---

Postscript: I also tested with a third-party font called Microsoft YaHei Consolas, available at:

https://github.com/byzod/Microsoft-Yahei-Consolas

After installing the font and setting it as the default font in Notepad++, the text renders in a monospaced layout even under DirectWrite mode, as shown below:

However, this is achieved via font substitution rather than programmatic changes. Ultimately, this issue should be addressed by the Scintilla project maintainers.

---

In addition, I found that when selecting the rendering mode -> GDI (most compatible), the Microsoft YaHei Consolas font only renders as monospaced at specific font sizes (e.g., 9, 12, 15, 18, 24). This is likely a bug in the font file itself. In contrast, traditional monospaced fonts like Consolas and Courier New do not have this issue.

However, the GDI (most compatible) rendering mode has several limitations: On Windows 7, some Unicode characters cannot be displayed properly, and it also tends to have higher CPU usage. Therefore, the best solution for now is to use the DirectWrite rendering mode and select a suitable font.