GNOME Bugzilla – Bug 162036
win32 printing backend
Last modified: 2005-03-25 21:16:17 UTC
GP currently lacks a win32 printing backend. attachment 33997 [details] [review] to bug 158972 has started some work toward this (thanks Hans!). http://cvs.gnome.org/viewcvs/dia/plug-ins/wmf/wmf.cpp?rev=1.28&view=markup is also a good reference. what i think we should do: 1) gnome-print-gdi.c: This file contains Win32 GDI drawing functions. This object creates a temporary MetaFile (EMF) on disk, calling the Win32 GDI functions on it as appropriate. When close() is called, it calls transport->print_file() using that temporary file. 2) modules/gnome-print-win32.c: This file will list the available printers. We can use: EnumPrinters(PRINTER_ENUM_LOCAL|PRINTER_ENUM_NAME, NULL, 5, ...) to fill a PRINTER_INFO_5 array with printer names. We should use INFO5 because it's the fastest call and will work on 9x and NT. We should not simply print to the default windows printer as Hans' above patch does. 3) modules/gnome-print-win32-transport.c: This file will actually do the printing using OpenPrinter(), AddJob(), ScheduleJob(). We should open the correct printer via OpenPrinter() using gnome_print_config_get (gp_transport->config, "Printer").
some useful links, for reference: Printing and print spooling: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/prntspol_62ia.asp Metafiles: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/metafile_8tgz.asp GDI: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/wingdistart_9ezp.asp
Just one more reference (although Dia uses the windoze print dialog, apparently one may need to call PrintDlg() even to get the defaults without the dialog) : http://cvs.gnome.org/viewcvs/dia/app/paginate_gdiprint.cpp?annotate=1.9
When you're ready lets get this into CVS autoconf tests test to be fiddly and it would be useful to get them in place early.
Any progress ?
No, not to speak of - I haven't booted into Win32 in months now. Hans seems to have more experience with this sort of thing than I do. The GP API seems well-suited to streaming a whole PS/PDF document to CUPS, where the pages are inline signals. It doesn't seem particularly well-suited toward sending a different WMF to the printer for each and every page surrounded by a BeginPage()/EndPage() pair, though I imagine that we could somehow wedge it in there. I don't know why this is closed "NEEDINFO" rather than NEW, RFE. I thought that NEEDINFO was only used when the bug couldn't be diagnosed without more information. Here, the diagnosis is clear.
Is it possible to have a print context without a transport? I am thinking that a win32 print context will do the job without requiring a transport, unless you want to print a file. I can look at that once I have a little time.
Created attachment 39212 [details] [review] proposed implementation This is done. Still many improvements could be made IMO, please help testing it.
Comment on attachment 39212 [details] [review] proposed implementation This seems like an excellent start. I suspect there are issues with the glyph list handling - mapping 32 -> 16 bits - skipping y offsets but we can get to this shortly. Please get this into cvs.
I have one comment about the usage of libopt as static. Any particular reason for this? I am able to build the dll version of it. It is just a matter of updating the libtool version as it is pretty old.
fmoraes : I would not worry about popt usage. This code will go into the 2.11 tree, which will rely on glib-2.6. We will move to GOption.
gnome-print-path.h missing from patch
#9, sorry, because I use MSVC heavily during devel. MSVC can't initialize global variables with non-constant, including a reference to symbols of a dll. It wasn't a problem of libtool at my side.
Created attachment 39240 [details] My attempt at having the Windows print context Ivan, here's the version I tried to write, for reference. It did a few things differently, but basically the same (like support for the dash attribute for lines and attempt to match other attributes for fonts, etc...). I've tried your patch and it works but there are a few problems: - the output seems to be too big, causing print out to be cut around printer margins - text alignment seems to be off and fonts are rotated the wrong way (upside down) - the identity matrix detection seems to be incorrect ( < and > mixed together and && used instead of ||) This was a great patch, just needs a few fixes now. All my testing was done with Planner 0.13 port that I've been working on. If you want it to test, let me know.
fmoraes, thank for your reference. SetBkMode(TRANSPARENT) before ExtTextout() is a good idea. > the output seems to be too big, causing print out > to be cut around printer margins I have no problem with scaling/tranlation when printing many sample files of gnumeric, they look like more or less the same as in print preview. I think I should try your testing. > text alignment seems to be off and fonts are rotated > the wrong way (upside down) partially fixed, since I have no problem with text alignment but rotation. > the identity matrix detection seems to be incorrect > ( < and > mixed together and && used instead of ||) fixed.
GDI's line dashing has some problems with user style and dash offset, e.g. win9x doesn't support the so called PS_USERSTYLE mode, and there's no dash offset with GDI. This gdk/win32 bug is related: http://bugzilla.gnome.org/show_bug.cgi?id=162790 I think the implementation/emulation of user style/dash offset for the both cases will be quite similar, and I will fix that a little bit later.
But you did notice your current implementation of dash_offset is broken ? [See my comment in bug #162790, the offset must not modify the start of the line]
Ivan, Forgot to say that I've modified the EnumPrinters call to include CONNECTED printers: PRINTER_ENUM_LOCAL|PRINTER_ENUM_CONNECTIONS At least, that way I can print to a printer from another computer.
ok, this bug needs to be closed. please open new bugs for your new gripes :)
comment 16: see bug 171641 comment 17: see bug 171640