Re: gtk_print

["Richard Boaz" <riboaz xs4all nl>]

On Sat, Aug 23, 2008 at 2:32 AM, Paul Davis <paul linuxaudiosystems com>
wrote:

 On Sat, 2008-08-23 at 00:28 +0100, Chris Vine wrote:
 > On Fri, 22 Aug 2008 19:04:19 -0400
 > Paul Davis <paul linuxaudiosystems com> wrote:
 > > On Fri, 2008-08-22 at 14:12 +0100, Chris Vine wrote:
 > > > On Fri, 22 Aug 2008 13:40:20 +0200 (CEST)
 > > > "Richard Boaz" <riboaz xs4all nl> wrote:
 > > > [snip]
 > >
 > >  [ ... snip snip snip ... ]
 > >
 > > this sounds like a disaster of an API.
 > >
 > > most other GTK/GDK APIs that involve things that ultimately come down
 > > to pixels seem to have variants that allow you to provide
 > > unstructured data and structured data, sometimes in multiple formats.
 > > there is often a way to get data directly from a file too.
 > >
 > > a print API that hides all the hard work of printer discovery and
 > > configuration but then prevents you from pointing it at a file to get
 > > the data to be printed seems fundamentally broken.
 >
 > On the issue of printing a postscript file under windows, I don't think
 > GTK+ should be expected to provide its own postscript interpreter, just
 > because windows does not natively support printing postscript in the
 > way that unix-like OSes do.

 aha. a very fair point, and one that is highly relevant to the OP's
 question. Richard, i think you need to think carefully about how you
 would print this file *outside* of GTK. if selecting a printer and
 identifying the file to be sent there is not enough to get the job done,
 its a bit hard to expect GTK to go the extra mile and work this way.

=====

Hi again (sorry to be coming back to this so much later, was away...),

I guess what I'm really looking for is a separation between the two
distinct functionalities currently provided by GtkPrint.  As it is, it
provides two distinct features:

1) identification (and selection) of known/found printers, and
2) issuing commands for selected printer, commands being currently limited
to the Cairo family.

In my case, I have a *file* that I want to send to the printer.  If the
printer is PS-aware, then sending the file is enough, interpretation
happens at the printer (no?).  So, I need the functionality described by
1), but not the functionality described by 2).  Except that on windows
they are, seemingly, inseparable.

As stated, this is only a problem in the windows platform since
GtkPrintUnixDialog in conjunction with GtkPrintJob will send a manually
generated PS-file to the selected printer.

I guess I don't understand why this is available only on Unix?

For my 2-step solution, I have found a program (PrintFile) that will send
a PS file to a printer on Windows.  What exactly prevents the
functionality provided by this program from being imported into Gtk for
windows?; effectively providing the non-portable Unix print functionality.
 The only thing it does is send a PS file to the printer disabling the
windows driver from interpreting it as text, much like GtkPrintUnixDialog
and friends.

I realize that GtkPrint is a recent addition to the library and that first
editions do not necessarily provide all possible desired functionality; I
don't have a problem with this, evolution is what it is.  But I do wonder
if this gap (as perceived by me) will be addressed in some future release.

Or is windows so special that this isn't really possible?  ;)

cheers,

richard