- From: "Richard Boaz" <riboaz xs4all nl>
- To: gtk-list gnome org
- Cc: paul linuxaudiosystems com
- Subject: Re: gtk_print
- Date: Thu, 28 Aug 2008 13:33:42 +0200 (CEST)
On Sat, Aug 23, 2008 at 2:32 AM, Paul Davis <paul linuxaudiosystems com>
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
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? ;)
] [Thread Prev