Is there a way to do a new Page Brake

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.

mpheath

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

fml2

@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 ===”).

MarkusBodensee

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

MarkusBodensee

@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

Can someone please fix the typo in the thread name (brake -> break)? Thanks!