On Sat, Aug 23, 2008 at 2:32 AM, Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx> 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 _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
