Is there a way to do a new Page Brake

PeterJones

@AlanRobbo-69 said:

Hi, is there a way to do a new Page Brake in Notepad++ ?
so at that point a New Page will be Printed.
Thank You.

So, the “positive” answer: to insert the ASCII 12 Form Feed (U+000C, which is the “page break” for old-fashioned printers), you can use the Edit > Character Panel, and double click on the FF.

Depending on your Settings > Preferences > Editing 2 > Non-Printing Characters settings, you may or may not be able to enter that character by other means – with “Prevent control character (C0 code) typing into document” checkmarked, you cannot use the windows Alt+012 to enter that character, whereas if it’s not checkmarked, you can: but the Character Panel overrides that setting, and will still enter that character into the document. To be able to see that the character is there, you need to have View > Show Symbol > Show Control Characters and Unicode EOL enabled – if it’s enabled, you’ll see a FF in a reverse-text box; if it’s not enabled, you won’t see anything, but you will be able to use arrow keys to move left or right across the invisible character, and you’ll see the status bar column number change even though the typing caret appears to be in the same place.

But (and it’s a big but), the printing algorithm that Notepad++ uses sends the Scintilla replacement boxed-FF glyph to the printer, instead of sending the actual character. (Furthermore, I think that modern Windows printer drivers don’t interpret the ASCII 12 as a “new page”). You might be able to copy the text file directly to the printer from the command line (or from Notepad++'s Run > Run… dialog) using old MS-DOS style commands, like Run > Run > COPY "$(FULL_CURRENT_PATH)" /B PRN (where PRN could be PRN or LPT1 or \\ComputerName\PrinterShareName), and that might bypass some of the printer drivers and instead send the raw ASCII to the printer, which your printer might interpret as a control to move to the next page … but if you do, then you lose the rest of Notepad++'s rendering (which means it won’t follow your Notepad++ font settings or line-numbering or headers or syntax highlighting).

So the short summary: you can insert the form feed character, but Notepad++'s print algorithm doesn’t treat that form-feed character as a page break, so to get that character to behave as you want it to, you’d probably have to print using MS-DOS-era print commands, hoping that modern Windows still allows such.

update: what I said here is essentially what I said in 2019 in this old discussion; that discussion concludes that the ability to handle form-feeds as page breaks would need to be implemented in the Scintilla library (which Notepad++ uses) before Notepad++ could offer it as a feature.

AlanRobbo 69

@PeterJones
Thank you,
For some reason it won’t work!
I do not know how Printers Work, unfortunately I am too old to learn anymore.

Perhaps the Programmers could add a “New Page” Feature.
To Bypass the Manufactures Lacking.
In my search for a solution, I have come across many asking for the same thing,
They are trying to Break Sub’s & Functions into something Better Looking.

Mark Olson

@AlanRobbo-69 said:

Perhaps the Programmers could add a “New Page” Feature.

This feels like an excellent example of something that would be best implemented in a plugin. Given how many other things the core devs already have to juggle, I rather doubt users are best served by having those devs try to understand the mystical arcana of modern printer drivers.

Unfortunately I am definitely not the right person to create such a plugin, but maybe somebody else reading this could try and devise a plugin to make NPP play nicer with printers. Maybe such a plugin already exists; I haven’t done any research because I have no need for one.

I’ve always felt that if I needed something printed, I would be much better off converting it into something like a docx or a PDF and using a PDF viewer or Microsoft Word to try printing it out.

PeterJones

@Mark-Olson ,

I rather doubt users are best served by having those devs try to understand the mystical arcana of modern printer drivers.

Turns out, in this instance, it’s really simpler than people made out – and you need 0 knowledge of printer drivers to implement it. I’ve got proof-of-concept code working already, and once I am able to get the Preferences option working, I will be submitting an issue and PR to implement this.

Explanation: What notepad++ does is loop through the document, and passes the start/end to the scintilla print formatter, then scintilla returns where in that range it stopped processing; the next loop through, the new “start” is the end of the previous range (fence posts are properly accounted for in the conversation). So for this, all I have to do is search if there’s a FF character between start and end, and if there is, temporarily change the end that it sends to Scintilla for asking for the next page. the real logic/implementation was about 12 lines of code in one already-existing function, and an hour or so of experiment/testing/debug. The more difficult part is the GUI/preferences, which I’ve never done before, and which require edits in a half dozen different pieces of source code that all must interact properly.

Side note: In more than a decade of people complaining here in the forum about the lack of page break, LITERALLY NO ONE ever bothered to make an issue of it – at least that I could find, by searching “form feed”, “formfeed”, or “page break” in the Issues tracker, open or closed issues.

PeterJones

@Mark-Olson, @AlanRobbo-69,

I have an initial implementation available through the GitHub action build for now (https://github.com/pryrt/notepad-plus-plus/actions/runs/26252176986#artifacts – artifacts should be there in a few minutes from when I post)

If you have Text Of Line[FF][EOL]NextPage then the [FF] will be the end of page1 and NextPage will be the beginning of page2
If you have Something[EOL][FF]NextPage, then the Something will be the end of page1 and [FF]NextPage will be the beginning of page2
I don’t recommend it, but Text of[FF] Line[EOL]SomethingElse will put Text of[FF] Line on page1 and SomethingElse on page2 (this is due to the fact that scintilla will always go to the end of the line, even if it goes beyond the “end position” that you passed it, and it doesn’t consider FF an EndOfLine character for this purpose. That would have to be fixed in Scintilla, as there’s nothing I can do about it from the N++ end.)
View > Show Symbol: if Show Control Characters & Unicode EOL is on, then Notepad++'s display and the printed file will include the FF box-glyph. If it’s off, then neither N++ nor the printed file will show the FF box-glyph.

The option defaults to OFF. To turn it on, use Settings > Preferences > Print > Print formfeed as page break.

I hope that you (and other interested parties) would test it over the next few days. I will likely create the issue right after posting this message (update: Issue #18059), but will wait until this weekend to submit the PR, in case there are obvious things that would improve it before I submit it to the codebase.

Coises

@PeterJones:

Just a thought… would it make sense to:

recognize the case where a form feed is on a line by itself (preceded and followed by EOL) and in that case exclude the entire line (so the form feed does not appear in the printout at all)? If I’m following your code and the way you say SCI_FORMATRANGEFULL works, it seems that should be possible. That way it wouldn’t be necessary to change the Show Symbol setting between editing (so you can see what you’re doing) and printing (to get a clean printout).
as an extension of that, add an option that defines a user-specified string (such as === page ===) which, when it occurs by itself on a line, indicates a page break (instead of a form feed)? That would complicate the preferences (ugh!) but I think it would be easier for most users to use… at least, I presume control characters are a little obscure to most non-programmers.

PeterJones

@Coises ,

I’m not convinced there’s a purpose behind hiding some FF symbols that way, but not others. If you don’t want to see FF in the printout, hide control characters. This is already-expected behavior for users. Can you explain why this new feature should contain a “mixed mode”
FF is the ASCII character that has for 40+ years meant “new page” in text files when printing. I can fully understand and support adding that meaning to Notepad++ usage. Some other random string, otoh, seems to be encroaching on “I want a word processor” (and other that FF, I don’t think anyone ever asked for other page break capabilities). And I think adding that virtually guarantees rejection of the PR

Coises

@PeterJones said:

I’m not convinced there’s a purpose behind hiding some FF symbols that way, but not others. If you don’t want to see FF in the printout, hide control characters. This is already-expected behavior for users. Can you explain why this new feature should contain a “mixed mode”

It could be that I’ve misunderstood the purpose of this feature. I assumed that some users wanted a simple way to add page breaks for printing to otherwise plain text documents without importing the text into a word processing program or using some other workaround. In such a scenario they would not want to see the form feed graphic in the printed version, but they would want to see it when editing.

It’s not that I think it would be good to treat some form feed symbols differently than others, it’s that — if I understand what you wrote about SCI_FORMATRANGEFULL correctly — there is no way, without changing either the content of the document or the Scintilla settings, to suppress the form feed graphic unless it is on a line by itself.

Since I thought giving users a way to create page breaks was the point, I mentioned this as something that might make that easier.

FF is the ASCII character that has for 40+ years meant “new page” in text files when printing. I can fully understand and support adding that meaning to Notepad++ usage. Some other random string, otoh, seems to be encroaching on “I want a word processor” (and other that FF, I don’t think anyone ever asked for other page break capabilities). And I think adding that virtually guarantees rejection of the PR

Well, the original poster in this thread just asked for a way to cause a page break — I didn’t see any mention of form feeds. If the purpose is to properly print existing text files containing ASCII control codes, there’s more than just form feed to consider; but I don’t get the impression that was ever within the scope of this project. Maybe form feed is far and away the most common control code that is currently unsupported; I honestly don’t know about that.

I suspect you are right about the greatly increased likelihood of rejection if an alternate character string field were added to the Preferences.

My thoughts were just that… thoughts. Above I attempted to explain those thoughts, but (despite possible appearances) I don’t mean this to argue for expanding the scope of your changes. I think it’s entirely reasonable to leave it as you have it.

PeterJones

It could be that I’ve misunderstood the purpose of this feature. I assumed that some users wanted a simple way to add page breaks for printing to otherwise plain text documents without importing the text into a word processing program or using some other workaround. I

That is the way this one was phrased. However, using the ASCII FF is the only way I can justify page break, because anything else is word processing. And since most of the historical ones have suggested FF, that’s the one easiest to sell to Don.

there is no way, without changing either the content of the document or the Scintilla settings, to suppress the form feed graphic unless it is on a line by itself.

That is what I found, as far as I can tell.

I originally wanted to print to one chat before the FF, then advance to the chat after FF for the next page, but Scintilla always continuing until the next line-end, even beyond the supplied end-position argument, made that not work.

I think that trying to make the search more complicated would be computationally expensive (doing this forward search at every page is technically O(N*P), which approaches O(N^2) for small pages already, so I wanted to keep it as simple as possible). Maybe I’ll pull a “Don” on this one: (assuming there are no functional problems) I’ll put in the PR as is, and if users complain, then I’ll see if it can be made more complex to hide some or all FF glyphs without hiding other control glyphs

Coises

@PeterJones said:

I’ll see if it can be made more complex to hide some or all FF glyphs without hiding other control glyphs

I know (from one of my projects) you can control individual character representations; so to hide all form feeds you could save the current representation of 0x0C, set it to something that won’t print (I don’t know if you can set an empty string or if that would reset it to default display, requiring you to use something like a zero width space instead), and then restore it after printing; but I don’t know if that would cause a visual glitch in the document display.