GNOME Bugzilla – Bug 117599
Implement Printing
Last modified: 2004-12-22 21:47:04 UTC
Implement a print command. I'm not sure whether to use the GPOutputDev (with its suboptimal font support) or PSOutputDev.
I have filed Bug 99339 in the Red Hat Bugzilla database - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=99339 - for inclusion of GPdf as the Gnome 2 application for viewing and printing PDF files. The only feature necessary for inclusion in the distribution is the printing feature. Any estimate on how long it may take for GPdf to get this ability (even if it has to piggy-back XPdf 2's built-in printing capability)?
Hy Printing is implemented in gpdf-outlines branch. It should be easily backported to HEAD for quick availibility. What is missing at now: - Custom range widget (planned) - Print status feedback dialog with page thumbnails (planned) - Print preview -- ?but does this really make sense? :-) (planned) P.S.: While I was studying gpdf rendering architecture, printing seems so obvious I had to try it to validate my understanding.
`Sometimes we're afraid because there might be a monster in the room, and sometimes we're afraid because there is a monster in the room. When it's just "might be", the thing to do is get information. In the bedroom, when there might be a monster, we turn on the lights. In programming, we do an experiment.' Thanks, Remi. Why can't I just `try to validate my understanding' like you do ;-) I haven't tried it yet. You are using gnome-print with correct private headers (>= 2.2.1.4), aren't you? Did you test with files using embedded Type 1 and Type 1C (don't know if you have some of these) fonts. Does it work? Thanks.
Yes, I'am using the 2.3.1 versions of lib GP & GPui, with the font download patch from bugzilla. It fixes the font looking problem, but not the integral sign. I think this is normal because the font download feature is not used in gpdf. Badly I didn't patch gpdf for using it, so I couldn't verify. I had a look at it but perhaps it is not as straight forward as it could seems. If you have a patch (for GPOutputDev) around, let me know ...
This needs to go on before gnome 2.4 ships in september. For the real desktop user this is a big regression. in 2.2 you could print pdfs and in 2.4 you can't (because ggv has dropped pdf support). Please consider getting special permission for late changes Maybe just merge the whole pdf-outlines tree.
I think it should. I still have a few things to do before reaching minimum stability & quality, but it might be good for mid august. All features I want to add will be there. After that it will be time for review ! and fixes ;-)
This is a new feature, well after the feature freeze. Please see http://developer.gnome.org/dotplan/tasks.html#ApprovingFreezeBreaks
Ok. I do it.
Attaching a patch against HEAD implementing (synchronous) printing. I tried a port from the branch to head. It did print but was unacceptably slow with large documents (e.g. PDF spec, 1100 pages). Was it fast for you Remi? I know that it's my code in GPOutputDev and maybe the gnome-print code that is so slow, not your implementation. This patch uses the print class from Xpdf and generates PostScript directly. This PostScript gets fed into gnome-print. It should be as fast as Xpdf's printing. The patch doesn't implement asynchronous printing with a progress dialog yet. Have to do it tomorrow. Attaching also the HIGgified version of the progress dialog glade file from the branch. Remi, can you review my patch?
Created attachment 18978 [details] [review] patch with print implementation, based in part on gpdf-outlines branch
Created attachment 18979 [details] HIGgified progress dialog glade file
Yes badly it's slow. This is why I threaded the code and thought cancel button was usefull. Using PSOutputDev is fine for now, as a workaround for Gnome 2.4, but we'll have to fix performance problems, either us in gpdf -- if we have some :-) --, or GP hackers in GP, for Gnome 2.6 or further releases. The code is very new and this is acceptable (from the developer point of view). I'll have a look at the patch ASAP ...
My feedback about the patch. First, I test it by applying to HEAD. I ignored Makefile.am changes needed and focused on patch. I also ignored UI xml file changes (assumed they will be in final patch) The lone problem I saw is about gnome-print-dialog. When testing in outlines branch I noted that gtk_widget_destroy(print_dialog) crashed when printing several times (two or three times). Have you the same crash ? I didn't test (and debug) further because I attribute that behavior to a temporary problem (& I'll have time to fix later). nevertheless I prefer leak than crash. Attach patch with that statement disabled.
Created attachment 18983 [details] [review] print_dialog destroy statement disabled
+ gnome_print_dialog_construct_range_page ( + GNOME_PRINT_DIALOG (dialog), + /* (GNOME_PRINT_RANGE_CURRENT | would be the default -> very bad */ + (GNOME_PRINT_RANGE_ALL | GNOME_PRINT_RANGE_RANGE), + 1, control->priv->pdf_doc->getNumPages (), + NULL, (const guchar *)_("_Pages ")); What's the last space in "_Pages " for?
Created attachment 19006 [details] screenshot demonstrating spacing with and w/o trailing space
the label to the right of the label "Pages" will be placed too close without the trailing space. You might call this a hack around a gnome print ui problem.
I see, but surely there must be a more elegant way to solve that, without requiring all translations to be updated when the problem is solved. I'm still at unease with that.
Yes, the translatable string can be shortened to _Pages. The code has to append the space then. When the real problem is solved, only the code has to change.
Sounds good.
Created attachment 19034 [details] [review] Updated patch: fixes a leak, splits "_Pages ", this should really work with HEAD
I tried that patch (10934) with HEAD, and got a /opt/gnome24/src/gpdf/xpdf/PDFDoc.h:55: undefined reference to `PSOutputDev::PSOutputDev[in-charge](char*, XRef*, Catalog*, int, int, PSOutMode)'
Move PSOutputDev sources from gnome_pdf_viewer_SOURCES to libgpdf_a_SOURCES in Makefile.am. It should fix the link problem.
Created attachment 19056 [details] [review] Including the fix from Remi's last comment, this time tested against fresh checkout
Created attachment 19088 [details] [review] New patch, including progress dialog. Not multi-threaded because I don't want to add threaded code now.
Created attachment 19155 [details] [review] Updated Patch. For today's CVS. Without Zoom breakage
*** Bug 121142 has been marked as a duplicate of this bug. ***
*** Bug 128151 has been marked as a duplicate of this bug. ***
Shouldn't this bug be closed? Printing is now in, AFAIK.
Hmm, can't remember if there was a reason to leave it open.