GNOME Bugzilla – Bug 444942
[win32] Glyphs print and preview with black background
Last modified: 2008-05-01 21:28:14 UTC
Third version I have tried. Reported problem previously and later recieved notice that it was fixed?? On my HP Laserjet 4L and on HP color laser 2820--- Prints heavy black lines over the top of where text should be. Previous versions printed the top part of text only or nothing at all. I have been using Win2k but will also test on Linux (kbuntu) if it loads O.K. there. I kind of assumed it would work in Linux. Surprised it dosen't print in windows. I really like this program. Much better than MS or Open Office but can't use it do to the printing problem. Well actually I like it so well I use it whenever I'm sure I don't have to print or I use a different program to print. Thanks a lot John
Thank you for the report. The 1.7.x series is a development branch, and unfortunately you're getting hit with the new printing engine that landed recently. Hopefully the glitches will get ironed out quickly.
Which version are you using now? jody: the earlier versions he tried used gnomeprint. THis is likely the first using gtkprint. This bug may be bug 442746 (a gtk print bug).
I can replicate the problem with svn trunk, and more importantly have been able to build a debuggable library stack to look into it. Glyphs are being rendered with back backgrounds, rather than transparent. No fix available as yet.
At least part of the problem is that we clip to the cell causes cairo to use what it labels a fallback path which seems to use _ADD rather than _OVER. Unfortunately there is breakage on more than one level here. We don't clip rotated text, but that doesn't appear at all. behdad : Any insights ?
Humm, the black background problem is probably a bug in cairo win32 backend. I remember seeing reports like that. As for the other problems you mention I have no idea what's going on. In particular, a rectangular clip should not force cairo to use fallback images at all. Probably easiest to write to cairo list with some more detail, preferably simple C/python test case, so someone with win32/PDF knowledge can look into it.
*** Bug 494489 has been marked as a duplicate of this bug. ***
*** Bug 495837 has been marked as a duplicate of this bug. ***
*** Bug 506170 has been marked as a duplicate of this bug. ***
*** Bug 509035 has been marked as a duplicate of this bug. ***
The workaround seems to be to print to pdf.
My bug report on printing was marked as a duplicate, though the problems were different (margins a mess, printing landscape produced blank pages, etc.). Printing to PDF, either in Gnumeric (which produced nothing at all), or to an external pdf generator (which produced the same results as printing to my HP color laserjet printer) did not resolve anything. I was only able to print by saving as .xls and importing to OpenOffice. (I realize the 1.7.x allows direct export to OpenOffice, but I was using the stable 1.6.x at the time.) Printing problems persist in 1.7.x.
I think this should be fixed with either cairo 1.4.14 or 1.5.6. Can someone test?
No change with git HEAD commit eabd28a655f8ddc73ff71583bb658db796e932cd Author: Adrian Johnson <ajohnson@redneon.com> Date: Fri Jan 18 21:53:04 2008 +1030 I'll try to get a debugable setup this week to dig more deeply.
Does gtk-print use the Win32 cairo surface or the "Win32 printing" cairo surface? AFAIK, the Mozilla folks are using the latter without problem.
_gtk_print_operation_platform_backend_create_preview_surface calls cairo_win32_surface_create rather than cairo_win32_printing_surface_create. Which triggers some fallback code paths in the backend. Making that change does not fix things though. I've delved down to the ExtTextOutW call in the cairo back and things look reasonable at that level. tml pointed out another instance of a similar problem in 518052
*** Bug 520410 has been marked as a duplicate of this bug. ***
Created attachment 106818 [details] Gnumeric source
Created attachment 106819 [details] Resulting PDF
Created attachment 106820 [details] Cairo drawing commands, on Linux These are the cairo commands used to create the PDF on Linux. Theoretically, the output should be identical on Win32, but using a different font backend and surface type. Hopefully this is useful to create a more minimal, reproducible test program for Vlad.
Sorry, the drawing commands are broken because cairo-trace didn't support the PDF surface. I've fixed that now. The relevant bit seems to be: [0] cairo_save (cr1) [0] cairo_new_path (cr1) [0] cairo_rectangle (cr1, 4, 0, 44, 12.75) [0] cairo_clip (cr1) [0] cairo_set_source_rgb (cr1, 0, 0, 0) [0] cairo_move_to (cr1, 41.6377, 1.10938) [0] cairo_get_current_point (cr1, [41.6367, 1.10938]) [0] cairo_save (cr1) [0] cairo_set_scaled_font (cr1, scaled_font6) [0] cairo_show_glyphs (cr1, ["1"], 1) [0] cairo_restore (cr1) "Sheet1" prints out fine, so here it is for reference: [0] cairo_save (cr1) [0] cairo_set_scaled_font (cr1, scaled_font2) [0] cairo_show_glyphs (cr1, ["Sheet1"], 6) [0] cairo_restore (cr1) The "cairo_clip" rectangle is bleeding over past the clip and being filled. If I change the text foreground colors to yellow, red, green, and blue for my "1,2,3,4", I get a yellow, red, green, and blue box, respectively. This seems to violate the documentation that "After cairo_clip(), the current path will be cleared from the cairo context." Windows GDI clipping reference here: http://msdn2.microsoft.com/en-us/library/ms532575(VS.85).aspx
My guess is that if you removed the cairo_clip() from print_cell_gtk(), things might work ok, though that's obviously a hack. http://svn.gnome.org/viewvc/gnumeric/trunk/src/print-cell.c?view=markup To test, I applied a small rotation to the cells so that the "don't clip" path would be hit. Nothing showed up in the print preview, but on paper, I saw my "1, 2, 3, 4" diagonal as expected (with an ever-so-slight rotation applied to them).
I have written a minimal test program based on gnumeric function print_cell_gtk(). The program prints a single cell to the default printer (you should install a PDF printer, like PrimoPDF). I have used real values (from the cairo trace provided by Dom Lachowicz). I have tested the program with the DLLs (cairo 1.5.x) included with gnumeric 1.90 (from http://www.gnome.org/~jody/gnumeric/win32/gnumeric-1.9.0-win32-1.exe) If USE_PRINTING_SURFACE is undefined the default win32 surface is used. if USE_PRINTING_SURFACE is defined the new win32 printing surface is used. Results: If USE_PRINTING_SURFACE is undefined The output is similar to gnumeric : - text with black background (when rotation = 0) - text displayed correctly (when rotation != 0) if USE_PRINTING_SURFACE is defined The output is correct. Conclusion: The problem is obviously caused by the use of the generic win32 surface. The new win32 printing surface should be used for printing (and GTK should be fixed).
Created attachment 108164 [details] the testcase
AFAIR, Jody said that the 1.9.x builds used the Win32 Printing surface. Thanks for doing some further investigation, though.
GTK trunk now has support for cairo_win32_printing_surface. Can someone with Gnumeric installed test and confirm that it's working correctly now? FWIW, bug #518052 seems to be fixed and I think it is the same or very similar to this bug.
I have tested Gnumeric 1.9.x from http://www.gnome.org/~jody/gnumeric/win32/gnumeric-1.9.0-win32-20080404.exe I can confirm that the printing is now fixed.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
*** Bug 530899 has been marked as a duplicate of this bug. ***
I installed(settled) the version 1.9.0http: // www.gnome.org / ~ jody/gnumeric/win32/gnumeric-1.9.0-win3 2-1.exe) The probleme is identical: black pavement
Please try http://www.gnome.org/~jody/gnumeric/win32/gnumeric-1.9.0-win32-20080404.exe it is newer.