Re: The printing work has been merged
- From: Alexander Larsson <alexl redhat com>
- To: Yevgen Muntyan <muntyan tamu edu>
- Cc: gtk-devel-list gnome org
- Subject: Re: The printing work has been merged
- Date: Mon, 27 Mar 2006 21:27:37 +0200
On Mon, 2006-03-27 at 12:47 -0600, Yevgen Muntyan wrote:
> Alexander Larsson wrote:
> > On Mon, 2006-03-27 at 02:08 -0600, Yevgen Muntyan wrote:
> >
> >>Hey,
> >>
> >>First of all, I implemented some printing in my application,
> >>and it works!
> >
> >
> > Cool! Did you like the API?
>
> I followed print-editor.c, so I subclassed GtkPrintOperation and
> I do stuff in begin-print and draw-page methods; it works fine.
> But, I do not understand how can a library provide "printing".
> It seems inappropriate for a text widget to create a GtkPrintOperation
> object; and it seems natural (maybe after gnomeprint?) to delegate
> the real job to some PrintJob object which could be sent to a printer,
> or used inside of PrintOperation methods. E.g. it feels just wrong
> that drawing happens in the method of an object which also shows Print
> dialog. I looked at GtkPrintJob, but it seems to be rather internal
> auxiliary class not intended for using in application code.
> Maybe it's just my misunderstanding, but documentation is not very
> clear ;)
While its possible to subclass GtkPrintOperation (that was very much in
the design) I don't expect that to be the main way apps will use it. I
think the main way will be to create a non-subclassed PrintOperation
object and connecting to the draw_page signal on it. If some object want
to "provide" printing i think the best way is to make it have an method
that can render itself to a cairo_t.
GtkPrintJob is an internal object in the unix printing implementation.
It is not used in for instance the Win32 port.
> In any case, it would be really cool if you wrote some five-steps
> printing howto or a rough description of what doing what.
I need to write full API docs of course, but I also want to write some
sort of tutorial. Actually I intend to present this on guadec, so the
paper for Guadec will probably be some form of tutorial.
> > Do we want to expose a write-to-ps to everyone? PDFs are a well known
> > way to send pre-rendered page layouts as files, but postscript is much
> > less widely known.
>
> Well, in our department network consisting of linux machines, xerox
> postscript printers, and lpr, postscript is widely known. I personally
> need postscript much more than pdf here, since I can create postscript
> file, ssh to some department machine, and send the file to print using
> lpr. If I have pdf, I use wonderful acrobat reader to print file to PS,
> and so on.
While I have personally printed to ps and scp:d it to another machine to
print I think that is a sort of fringe usecase, and more of a hint of
how broken the unix print system is. Maybe we should support it, but far
more important is to obsolete this workaround so that not only people
like us can manage to print on remote printers. :)
> And well, postscript is not something ancient and forgotten. People
> dealing with TeX know about postscript. "postscript is much less widely
> known" is rather like "MS Word format is very well known".
Both TeX and MS Word are stuff that end users care about, but postscript
is less so. Its more of a necessary evil that users of TeX are forced to
know about the details of postscript, as its really just an
implementation detail in the unix printing system. In reality people
will be forced to work with postscript files, so we should have some
form of support for it, but the imho goal should be to move away from
users having to know about this stuff.
> > Technically it would be easy to make the pdf backend be a general
> > backend that had a pdf or ps setting in the advanced tab. I'm just not
> > sure if exposing that is a good idea. Opinions?
>
> I believe it should be a well-visible option in the dialog, like a combo
> with PS and PDF in the list. It's really a "I press Print and choose
> Print to PS" thing, not something set once and forgotten forever (of
> course dialog must remember last choice).
I don't quite agree with "well visible", but this sounds like a
generally good thing, as long as we default to PDF, because that is
really a much more viable format for passing pre-rendered files between
different machines and platforms.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl redhat com alla lysator liu se
He's a one-legged coffee-fuelled paramedic with a mysterious suitcase
handcuffed to his arm. She's a time-travelling insomniac mermaid on the trail
of a serial killer. They fight crime!
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]