GNOME Bugzilla – Bug 344297
Printing: form-feed character should be honoured
Last modified: 2021-07-05 11:00:37 UTC
GtkSourcePrintJob doesn't take into account the form feed character when building the pages for printing a document. If I add a form feed character (<ctrl>L, ^L, ASCII:12) in a text file like this: line 1 line 2 line 3 line 4 ^L line 5 line 6 line 7 line 8 I'd expect the document to be printed on two pages, the first page ending on line 4 and the second starting on line 5. A possible fix should be special casing a line containing the form feed char inside the paginate_paragraph() and print_paragraph() functions, or by adding a marker inside the Paragraph structure that gets set when the form feed char is found.
Why should this character create a page break? We are not Word, and the character is not displayed as a page break, why should it work for printing?
> Why should this character create a page break? Maybe because it's the ASCII code for a page break? ;-) > We are not Word, and the character is not displayed as a page break, > why should it work for printing? gtksourceview is not WYSIWYG already, since what you get on print is different than what you see on the screen; so I'm not asking to add pagination to the text view. gtksourceview should nevertheless honour what I tell it to do - and adding a form feed (correctly *displayed* as an unknown glyph) means that what I want is to forcefully end a page and begin a new one when I *print* a document.
(In reply to comment #2) > > Why should this character create a page break? > > Maybe because it's the ASCII code for a page break? ;-) It's not really "code for a page break" as far as i know. As well as \n is not "code for a new line". It's a control character for some ancient devices; it happened so that \n is used as a line break character, and everybody knows that, but is someone aware about "form feed"? Inserting page break on this character might be a nice feature since noone uses this character in normal text files. But, it should at least be displayed as line break in textview. It would not be right if garbage on screen would mean "page break" (it is garbage, it's not "unknown glyph", it's "unknown glyph" only technically). By the way, there is also a nice character \007 ;)
so, beside theoretical discussions, where is this form feed character used in real life apps? I have this vague recollection that it's used in man pages...
I use it in my C source files, to mark the end of sections of code (included files + macros, types declaration, functions declaration, etc.), so when I print the sources I have some kind of structured print without having to cut & paste the code inside a word processor.
*** Bug 378455 has been marked as a duplicate of this bug. ***
Use cases I incurred into: * I had to print an assembler representation of a PLC program, and wanted to separate different program parts into different pages; * I wanted to print a list of ASCII data that I grouped in sections; * I wanted to print a LaTeX file and thought: "what if gedit had a print option to issue a form-feed after any \newpage and before any \chapter command?" (well, maybe this is slightly offtopic for this bug report); * I wanted to print the LGPL (http://www.gnu.org/licenses/lgpl.txt). Moreover I think it is quite common to use gedit (or any other text editor) to write long texts, divided into chapters, with titles (underlined with fantastic ASCII art effects, such as "==========" on the following line, for example) or "formatted" with wiki-style syntax (for example, *this* is bold); all it's needed to replace a word processor in said cases is page-breaks. Printing support for page-breaks is the minimum requirement; an "Insert page break" command in the Edit menu and a graphical representation of page-breaks (e.g. a dashed horizontal gray line beside the ^L character) would be fantastic additions too. I hope this can help the discussion.
The form feed character is used in RFCs. The bottom and top of each page in an RFC generally have a header and footer, with a form feed character in between to aid in printing. If you try to print with a program that does not honor the form feed character the pages will be split up incorrectly and make the RFC rather unreadable. This is actually how I came across this bug. This seems like something that would be pretty simple to fix -- maybe it can be marked as a gnome-love item if none of the developers are interested in implementing it.
GPL text uses it too :) It's not quite simple (corner cases, you know, how to treat two form feed characters, etc.), but it is not hard either. Main problem is that there is nothing to implement it in: future of gtktextview printing is unclear.
*** Bug 666207 has been marked as a duplicate of this bug. ***
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gtksourceview/-/issues/ Thank you for your understanding and your help.