On Fri, 2007-10-12 at 13:27 -0400, bulia byak wrote:
On 10/12/07, Ted Gould <ted@...11...> wrote:
The printing extension interface is basically a simple renderer interface. Things like setting styles and paths. There are several extensions that implement this interface: PS, PDF-Cairo, Win32 and GNOME-Print. Each of these can take the document and write it to the renderer that it uses. So when printing is done in Win32 the document is "rendered" onto the Win32 print driver directly.
OK, can you point me to the file in which this rendering happens?
Well, where it is all initialized and setup to execute is in src/print.cpp best function to start with is sp_print_document(). But, it's pretty ugly. Basically it sets up the module (the first name for extensions) and then wraps the C++ object in C functions. The C functions are the ones that are called externally.
The implementation of the Win32 driver is done in src/extension/internal/win32.cpp. I'm kinda confused on how it works. It seems like it doesn't implement the whole interface, I'm curious if it just always prints as bitmap. For a better example you can look at emf-win32-print.cpp.
The print direct button was there so that you could always use the PS renderer to create a postscript file. This was largely intended to work around buggy or incomplete drivers that may be default for certain builds. Also, you could use it to create PS files. I don't think we need this anymore as it is more intuitive to "Save As..." PS and then print the file if you wanted to work around the Win32 print driver.
I agree that we must only have _one_ print command. If this has to be Windows native one on Windows, OK with me - I use Linux anyway :) Though personally I would still prefer to have the explicit PS/bitmap switch on Windows too because this is a meaningful choice depending on the nature of the document.
I agree, and I believe that the Output extension supports this.
--Ted