Does anyone has a slightest idea, or even a suggestion, of why we have these two commands on Windows but not on Linux? What is the difference?
This was recently discussed in this bug:
https://sourceforge.net/tracker/?func=detail&atid=604306&aid=979164&...
whose findings can be summarized as follows:
- Linux has the single Print command, it offers a choice between PS/bitmap printing, and it works (at least the PS printing works, I didn't test bitmap printing much).
- Windows has "Print" and "Print Direct". The former works but offers no PS/bitmap switch, and works only as a bitmap. The latter offers the switch but does not work :)
I think it's high time to do something about this mess.
On Wed, 2007-10-10 at 20:01 -0400, bulia byak wrote:
Does anyone has a slightest idea, or even a suggestion, of why we have these two commands on Windows but not on Linux? What is the difference?
The difference is that print direct always used Inkscape's internal PS renderer. The print command used on specific to your installation. If you're compiled with GNOME-Print, that would be print. On Windows, this uses the Win32 print driver. The "Print Direct" button only appears if you have some other driver hiding the PS version.
--Ted
On 10/10/07, Ted Gould <ted@...11...> wrote:
The difference is that print direct always used Inkscape's internal PS renderer. The print command used on specific to your installation. If you're compiled with GNOME-Print, that would be print. On Windows, this uses the Win32 print driver. The "Print Direct" button only appears if you have some other driver hiding the PS version.
OK, but why this needs to be two different commands in the UI? Or at least, why both are present on my win xp?
Also, do we really need to use the "command specific to installation"? What advantages does it give us? And how it actually works - what does it get from Inkscape?
On Wed, 2007-10-10 at 21:54 -0400, bulia byak wrote:
On 10/10/07, Ted Gould <ted@...11...> wrote:
The difference is that print direct always used Inkscape's internal PS renderer. The print command used on specific to your installation. If you're compiled with GNOME-Print, that would be print. On Windows, this uses the Win32 print driver. The "Print Direct" button only appears if you have some other driver hiding the PS version.
OK, but why this needs to be two different commands in the UI? Or at least, why both are present on my win xp?
Incase you want to use the PS print... I can't see much use for it now that we've got the output extension for postscript.
Also, do we really need to use the "command specific to installation"? What advantages does it give us? And how it actually works - what does it get from Inkscape?
Well, the specific stuff gets us direct printing with things like the Windows print dialog. So, I think that's important.
But, what we should probably do is get rid of "Print Direct".
--Ted
On 10/12/07, Ted Gould <ted@...11...> wrote:
OK, but why this needs to be two different commands in the UI? Or at least, why both are present on my win xp?
Incase you want to use the PS print... I can't see much use for it now that we've got the output extension for postscript.
Do you mean users will need to save as PS and then print the PS file? Why can't this be done directly?
Also, do we really need to use the "command specific to installation"? What advantages does it give us? And how it actually works - what does it get from Inkscape?
Well, the specific stuff gets us direct printing with things like the Windows print dialog. So, I think that's important.
OK, but what does it get from Inkscape - PS, bitmap, anything else? If (as I suspect) it's always bitmap, is it possible in principle to combine the native dialog with an _option_ to print via PS? Or PS printing on Windows does not work at all?
Sorry for probably stupid questions, I never used printing before...
On Fri, 2007-10-12 at 02:56 -0300, bulia byak wrote:
OK, but what does it get from Inkscape - PS, bitmap, anything else? If (as I suspect) it's always bitmap, is it possible in principle to combine the native dialog with an _option_ to print via PS? Or PS printing on Windows does not work at all?
Sorry for probably stupid questions, I never used printing before...
Okay, yeah, I think we're talking at each other but not really understanding each other. Let me step back a little bit.
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.
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.
Does that make sense?
--Ted
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?
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.
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
participants (2)
-
bulia byak -
Ted Gould