GNOME Bugzilla – Bug 332552
"Page 1 of 0" printed when the document contains only a single tab
Last modified: 2008-06-20 03:20:44 UTC
That bug has been described on https://launchpad.net/distros/ubuntu/+source/gedit/+bug/32308 "I'm running Dapper Drake testing (Flight 4 + updates). The current version of gedit is 2.13.91. Steps to reproduce: Start gedit to create a new document. Look at the print preview. The header says "Page 1 of 1". Now close the print preview and type a single tab character in the document. Look at the print preview again. It now says "Page 1 of 0". Print the document to a file via PDF output and open the PDF file with Evince. There is a rectangle visible where the (invisible) tab character was typed. Also, the header still says "Page 1 of 0". I tried to print the document containing one tab character to my local, USB-connected HP Deskjet 940c printer but the printer did nothing. Perhaps someone else could confirm this so I know it's not a problem with CUPS or my printer setup. http://librarian.launchpad.net/1579890/Screenshot-tab.pdf.png A document with a single tab was created in gedit and then printed to a file via PDF output. The header is wrong and there is a box where the tab whitespace should be"
I am not sure it's a gedit bug: maybe a gtksourceview bug (it's sourceview which takes care of pagination etc) or maybe a bug coming from lower layers, maybe pango itself. Anyway I'll let Paolo handle this, as I do not know the printing code much.
Humm, a mixture of problems here: * The zero number of pages is correct, as it's supposed to ignore lines with only tabs in them... So gtksourceview should not try to print page 1... * libgnomeprint accesses Pango's backend-specific internals to not render "empty glyphs". In Pango 1.11.x I have changed empty glyphs from being glyph number 0 to something else (PANGO_GLYPH_EMPTY right now). This is known to probably change in the future too. libgnomeprint accessing that API directly is scary... * When trying libgnomeprint from HEAD, running gedit and trying the Print Previes yields a symbol not found on gp_gc_set_data. Indeed it's not in libgnomeprint source code anymore (only in the .def file). Don't know what that means. * It's also weird that this tab character only shows up if the tab is the only char in gedit. From the code that I see, it should show up anyway... So, I attach my patch, and leave it to somebody more knowledgable of these layers to resolve this.
Created attachment 60192 [details] [review] EMPTY_CHAR patch Hum.. In print preview, a bunch of g_return_if_fail (glyph < ...) are making sure the tab character is not rendered: (gedit:21872): GnomePrint-CRITICAL **: gnome_rfont_get_glyph_stdadvance: assertion `glyph < GRF_NUM_GLYPHS (rfont)' failed the glyph id that fails the assertion is the new value for an empty glyph... Don't know why it's not doing the same for the actually print to PDF. Anyway, so this patch is half of the solution, making sure gtksourceview doesn't print anything if there are zero pages is the other...
Behdad: I think you should attach your patch to bug #330907.
Ubuntu comment: " Running gedit 2.14.2 and I no longer see the strange page numbering issue in the print preview so the bug has probably been fixed upstream. I still see squares where there should be tab whitespace when I generate a PDF from gedit but I realize that should probably be filed as a separate bug. "
hmmm... this is very strange. Differently from the comment on the Ubuntu bug tracker, I don't see the squares where there should be tab whitespace when I generate a PDF from gedit while I still see the strange page numbering issue in the print preview. Moving to gtksourceview
Now it prints a one-line blank page 1/1, exactly as when printing an empty document.