Same problem here, and @Claudia-Frank’s suggestion led me to a solution. I’m using Win10-64 and %APPDATA%/notepad++/plugins/ did not exist. I had a fresh install, and I’m 1st timer here today, so that was def related to the source of the problem. After I created these dirs, printing works fine: %APPDATA%/notepad++/plugins %APPDATA%/notepad++/plugins/config One other note… during install I chose to instruct the program to retain config files in the %APPDATA% folder (might be obvious from my comments above, but FYI to clarify that yes, I chose that option during install). Cheers. :)

Yes separate files is better but I’m working on a customer existing project and don’t have to rewrite/optimize it. Thanks for the suggestion.

@Ben-S Automatic encoding detection is a difficult and unreliable thing. The algorithms work heuristically by inspecting the file’s content and can fail under some circumstances. If your file names have a special file extension you could use my AutoCodepage plugin, available via Notepad++ PluginManager. Otherwise there would be the following workaround: Open Windows Notepad. Press and hold the ALT-Key and type at the numeric block of the keyboard the sequence 0239. Press and hold the ALT-Key and type at the numeric block of the keyboard the sequence 0187. Press and hold the ALT-Key and type at the numeric block of the keyboard the sequence 0191. Save the file under the name Header.txt in the folder where your file is stored but avoid to press ENTER before saving. Open a Windows console and navigate to the folder where your file and the newly created Header.txt are stored. Execute the following command: copy /b “Header.txt” + “<Name-of-your-file>” “Result.txt” With this sequence you will add an UTF-8 Byte Order Mark (BOM) to the beginning of your file and store it under the name Result.txt. When you open this file in Notepad++ it should be recognized as UTF-8 encoded.