@PeterJones said:

@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.

I like your specification, @peterjones , but I am not sure if I understood the subsequent discussion of you and @coises in the right way (due to possible language barrier).

So I want to drop my 5 cent to the specification, sorry if that is even what you meant all along. But I think, it is slightly different.

My expectation/specification would be like that:

• Even during printing, under no circumstances, a character is omitted at the output. So if control characters are enabled to be shown, they are also visible on the printing output. So FF should not be “cut away or replaced by page break”, but only the meaning of page break is added at the printing output.
  and
• The interpretation/action of a control character takes place (directly) after the position of the control character in the document (exatly like with CR and/or LF, line break is done directly after these control chars). This would be consistant behaviour of control char interpretation.

Now, if I understood correctly, it is not possible to cut/split directly after FF and send the page break to Scintilla, but only to cut/split after CR and/or LF. In this case, my specification would be:

• Add page break always after the next possible CR and/or LF, means, applied to your examples:
  Text: FirstText[FF][EOL]SecondText[EOL]ThirdText --> Printing Output: FirstText[FF][EOL][page break]SecondText[EOL]ThirdText
  Text: FirstText[EOL][FF]SecondText[EOL]ThirdText --> Printing Output: FirstText[EOL][FF]SecondText[EOL][page break]ThirdText
  Text: FirstText[EOL]SecondText[FF]ThirdText[EOL]FourthText --> Printing Output: FirstText[EOL]SecondText[FF]ThirdText[EOL][page break]FourthText
  So each line is finished with an [EOL]. Control characters of another line belong to the line in which they are in, and are applied at next possible [EOL].
• So, nevertheless, the standard should be to have [FF][EOL] in the document for a page break then

For me, that would be a universally applicable solution and interpretation of control characters.

@fml2 said:

@Coises said:

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

I must say: I like the idea! It does not try to retain the function of an obscure and invisible character FF, but rather briings the functionality in a clear and concious way to the user.

One might argue that the same could also apply to the linebreaks (why express them with invisible characters rather than with special markers like “=== newline ===”), but new lines have a natural visualisation in a text editor whereas page breaks do not.

Ideally, both ways to insert a page break would be possible, with a corresponding option (check mark) to “consider” that way (e.g. “Start a new page at FF when printing” and “Start a new page at this marker when printing: _________” – with the input field for the marker; default could be “=== new page ===”).

I would second, that the idea of @coises is a good one. But IMHO, such kind of “string interpretation” would more be a feature to be implemented in a plug-in or in a script rather than in the core application. It is not an ordinary standard, but rather a user-specific extension and interpretation.

AFAIK, the only official way to have a page break is to use the form feed (hex 0xC - ASCII control character) as a page-break.

@Coises said:

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

I must say: I like the idea! It does not try to retain the function of an obscure and invisible character FF, but rather briings the functionality in a clear and concious way to the user.

One might argue that the same could also apply to the linebreaks (why express them with invisible characters rather than with special markers like “=== newline ===”), but new lines have a natural visualisation in a text editor (in a sense, a text editor has the WYSIWYG functionality :-) ) whereas page breaks do not.

Ideally, both ways to insert a page break would be possible, with a corresponding option (check mark) to “consider” that way (e.g. “Start a new page at FF when printing” and “Start a new page at this marker when printing: _________” – with the input field for the marker; default could be “=== new page ===”).

@AlanRobbo-69 said:
They are trying to Break Sub’s & Functions into something Better Looking.

HTML supports break-after style. An idea that can take a little extra work. Could add comments to the source file to indicate break page directives. This is quite a poor solution with the comments just to locate the tag to replace easier in the HTML source though if can do without making comments then it can save the code source from being dirtied with these extra comments.

Example in Python:

'''Add break page comments into the document'''
# break-after: page
class hungry():
    ...

Menu Plugins -> NppExport -> Export to HTML and the HTML body will look like:

<body>
<div style="float: left; white-space: pre; line-height: 1; background: #FFFFFF; "><span class="sc6">'''Add break page comments into the document'''</span><span class="sc0">
</span><span class="sc1"># break-after: page</span><span class="sc0">
</span><span class="sc5">class</span><span class="sc0"> </span><span class="sc8">hungry</span><span class="sc10">():</span><span class="sc0">
    </span><span class="sc10">...</span><span class="sc0">
</span></div></body>

Replace the tag:

<span class="sc1"># break-after: page</span>

with

<span style="break-after: page"></span>

Open the HTML file in a Web Browser and print. This small example will print 2 pages.

A script or plugin might better to reduce the extra work though may require time to create something worthwhile. Break based on certain styled keywords taking into account the line count per page might be some factors for a developer to consider.

@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.

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

1. 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.

2. 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.

1. 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”

2. 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

Just a thought… would it make sense to:

1. 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).

2. 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.

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.

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.

@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.

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.

@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.