gedit fails to obey page breaks when printing

Bug #904032 reported by Vernon Cole on 2011-12-14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
gedit (Ubuntu)

Bug Description

I am attempting to use gedit to spool the printout from a legacy program to an ink jet printer.
The file is in ASCII, with a form feed character defining each page.
Gedit displays the form feed as a box with the hexadecimal value 000C in it.
This is all good.

When I select "print" from the gedit menu, it sends the text to the printer neatly formatted with
a header and page numbering of its own.
This is also acceptable.

When the legacy program created the text, it determined that additional information should appear
an a new form, so it wanted to eject the nearly full form, and begin the next block of information
beneath a new header. It emitted a form feed to produce that effect.

Gedit happily creates a graphic box with 000C in it, prints the box, and proceeds to print the legacy
header (which says "page 2" on it) on the bottom of page One. When it runs out of paper, it
prints its Page 2 header, continues to print the legacy second page, a 000C box, and the header for
the legacy "page 3" and part of page three until it runs out of paper again, and so forth.

Unicode 000C is defined as a white space control character, as are carriage return and line feed.
You don't print them, you obey them. Do the same for form feed. Be kind to old programs and old
programmers. If my C program contains a "printf" statement with a "\f" in it, give me a new sheet
of paper on the printout. That way your page 2 will also be my page 2 and the printout will appear
pretty much like the programmer (myself in a previous millennium) intended.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: gedit 3.2.1-0ubuntu2
ProcVersionSignature: Ubuntu 3.0.0-13.22-generic 3.0.6
Uname: Linux 3.0.0-13-generic x86_64
NonfreeKernelModules: fglrx
ApportVersion: 1.23-0ubuntu4
Architecture: amd64
Date: Tue Dec 13 16:35:03 2011
ExecutablePath: /usr/bin/gedit
 PATH=(custom, no user)
SourcePackage: gedit
UpgradeStatus: No upgrade log present (probably fresh install)

Vernon Cole (vernondcole) wrote :
Sebastien Bacher (seb128) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

Changed in gedit (Ubuntu):
importance: Undecided → Wishlist
Sebastien Bacher (seb128) wrote :

While I understand where you come from your usecase is really a corner case, as an user text editor gedit just prints things as they get rendered on screen, you might just want to "lp file" to print your file...

Vernon Cole (vernondcole) wrote :

Yes, I ended up using "lp" to obtain a printout. I don't want to have to teach people how to do that. The point of having a GUI system is not having to use the command line. Gedit is the tool that opens when I click on a .txt file. Printing should be a one step operation after that. We're supposed to be making it easy for them (the command line challenged).

The report has been forwarded to Gnome, and a link established. Thanks for your help! The link and how-to were perfect.

Changed in gedit:
importance: Unknown → Wishlist
status: Unknown → New
Changed in gedit (Ubuntu):
status: New → Triaged
Changed in gedit:
status: New → Invalid
Changed in gedit:
importance: Wishlist → Unknown
status: Invalid → Unknown
Changed in gedit:
importance: Unknown → Wishlist
status: Unknown → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.