GNOME Bugzilla – Bug 141241
[Plan] Gnome print integration
Last modified: 2005-07-23 21:34:01 UTC
I think this is something that should be hacked in cooperation with mozilla hackers. They have two bugs filed about it and, once they are fixed, we could just remove a bunch of code in epiphany and be happy ;) Also once we could add a simple api to gtkmozembed so that you wont need any xul code to print a page (good for possible usages in other GNOME apps). Dialog http://bugzilla.mozilla.org/show_bug.cgi?id=193001 Backend http://bugzilla.mozilla.org/show_bug.cgi?id=192999 The main problem appear to be the backend since they'd prefer to not add yet another one (mainteinance pain). Though, given the increased importance of GNOME integration, if we can do the work and maintain it, maybe we can manage to convince them. That should probably the first item in our action plan. In theory we could print on a intermediate ps file, as clahey patch did, though that sounds a bit of an hack (could it give problems ?). Additionally I think we should solve the problem with libgnomeprint dialog. It's not higgy and more importantly there is no separation between print setup/print job. Are there plans/bugs open about it ?
*** Bug 120924 has been marked as a duplicate of this bug. ***
Plan bugs are used to track the work on next version major changes. You are welcome to add requests, design notes, to ask clarifications, to offer to help with it.
*
i've read the mozilla-bugs... i wonder.... i'm sure you all know kde's print dialog.... kprinter...what is very nice, is that kprinter is an application, you can start it with a ps file on stdin, and it will correctly print it. this technique allows kde users to use a nice print dialog from mozilla or acroread for example. all they have to do is replace lpr-whatever with kprinter. why isn't gnome doing the same? as i've read thru the mozilla-bugs, someone mentioned that the gnome print dialog can't do all the stuff (print 4pages on one page) if he is fed with only ps data. why? are there any problems with a kprinter like architecture? or to ask the other way: why don't we create gprinter?
In resposse to above: gnoem print is much mroe than kprinter- its a drawing context that not only takes care of freetype font usage and interantionisation, but also can render to arbitary backend (e.g. pixmap for use in print preview). The above soution exits in patch form (see mozilla bug below) but its Ugly As Hell (tm) and you loose gnomeprint functionality (see gPDF, which dows something similar) To the rest: Ok. this seems basically the same bug as http://bugzilla.mozilla.org/show_bug.cgi?id=192999 So Owen, if you're reading, can you fill in where you left stuff with blizzard? It'd be useful to know. It looks like it'd actually be a Good Thing for the mozilla developers if they used gnome print for postscript generation as it appears (http://bugzilla.mozilla.org/show_bug.cgi?id=234182) they currently have freetype and i18n issues there. If we can convince them that libgnomeprint usage for pdf output and general printing on linux is the best idea then maybe that'll assue their fears of adding 'yet another backend' - the others can then be deprecated and removed. Given the recent friendly sounds between the two camps this could be a possiblity. Owen, Marco, what do you think? BTW, i volunteer for working on a moxilla backend.
If we can write and maintain a libgnomeprint backend, I think it would be good and we can reasonably expect to convince them.
Just to offer a few data points 1) I am writing a gnomeprint cmd line app on the lines of kprinter for use by apps like acrobat. So it will exist for mozilla if so desired. 2) It would be nice if they could code directly to libgnomeprint but I don't see it as a crystal clear win. The current thinking is that we would deprecate the drawing api and use cairo at some point (no dates/timelines)
>The current thinking is that we would deprecate the >drawing api and use cairo at some point (no dates/timelines) Well, then I'd definately not push to get a gnome print backend added to mozilla. That seem to leave us with no good solutions on the short time. I dont think gprinter is a good solution for this specific problem. Users would have to go through two dialogs, which is worst than just using xprint. We are left with libgnomeprintui+mozilla ps backend thing. Though that would require to sync functionalities. Some functionalities would already need to be added to mozilla backend and I dont want to imagine the pain if libgnomeprintui get new features added.
Is there no way we can shortcut the 1st dialog in the gprinter solution?
The dialogs are part of libgnomeprintui. My prefered short term solution would be to see libgnomeprintui used for its dialogs but to use libgnomeprint as nothing more than a transport mechanism. mozilla would dump raw content (postscript ?) to it.
>My prefered short term solution would >be to see libgnomeprintui used for its dialogs but to use libgnomeprint as >nothing more than a transport mechanism. mozilla would dump raw content >(postscript ?) to it. That would require either to add the missing functionalities to the poscript mozilla backend or have a way in libgnomeprintui to disable them. Chpe, do you remember what exactly is missing ?
the mozilla ps backend need improvement. Currently page rendering for printing is poorer than Konqueror one. to http://bugzilla.gnome.org/show_bug.cgi?id=141241#c7 I'm willing to say that is this could exist it could be a good point/a good start. Under my kde environnements I'm currently using this ( kprinter ) for OpenOffice because of features of kde printer ( mails with attachement as PDF ) and for users it's not a so great deal.
Mass reassigning of Epiphany bugs to epiphany-maint@b.g.o
As you may know, Galeon from XD2 had libgnomeprintui integration - via print to file and gnome_print_job_set_file - although some options didn't work. Together with the libgnomeprint patch from bug 166564 this would look like a decent printing possibility, at least from the user perspective. I could probably do the porting / updating of the ximian patch but first I'd like to know whether the maintainers would be interested at all.
Thanks for the offer! I'm ready to accept a patch that uses the libgnomeprintui dialogue and uses mozilla to print to a file and hand that off to gnomeprint as an intermediate solution. As far as I can see, evince does the same thing; so I see no problem with Epiphany doing the same. A half-finished port of the XD2 galeon gnome-print patch to Epiphany exists in attachment 19924 [details] [review] in bug 120924. It's probably totally bit-rotten though; mostly the GnomePrintConfig->MozillaPrintConfig code could still be a useful starting point.
Jörg: Can you give us a status update; did you write this patch? If so, I'd like to get this in before gnome 2.12 feature freeze. Thanks!
Sorry, I was pretty busy the last weeks. I've written a very experimental patch back in May but haven't got time to write a clean one. As I've got some exams the next two weeks, I can probably not work on it until July, 15. Unfortunately that would be after feature freeze. I'll try to get to it before but I can't promise.
Thanks for the update! That's only 1 week into the freeze and before UI freeze; since this is a desktop integration bug, we should be able to convince RT to make an exception :)
Created attachment 49568 [details] [review] First draft of libgnomeprint integration So, finally got some time to create a first draft of the libgnomeprint integration. Could someone please review this patch before UI freeze? Hopefully I didn't break anything and the coding style is not too inappropriate as I'm new to epiphany code...
Created attachment 49598 [details] [review] Updated patch Updated patch as discussed with chpe in irc: Added postscript printer check to show an error dialog when selecting pdf printer, handle prepare-close event to cancel printing, and some minor fixes.
Created attachment 49600 [details] [review] 3rd patch attempt Again a small update: Make sure to remove cancel callback in any case and add print resp. message dialog to the appropriate window group.
Thanks again for the patch!