GNOME Bugzilla – Bug 169099
printing selected pages
Last modified: 2005-05-18 18:00:14 UTC
It would be really nice to be able to print odd / even pages of the document or only a selection of pages. Sometimes I only need a chapter from a PDF on paper and not the whole document. Or sometimes I'd like to print the PDF, doublesided on my standard single sided inkjet printer.
There was a patch sent to the list about this you could take a look at: http://mail.gnome.org/archives/evince-list/2005-February/msg00038.html
Also this one as well: http://mail.gnome.org/archives/evince-list/2005-February/msg00037.html
What's up with this? Martin did you have time to look at the patches?
Created attachment 46143 [details] [review] updated patch for evince 0.3.0 I've updated the patch for evince 0.3.0 and removed the range_type member from EvPrintJob.
Created attachment 46155 [details] [review] fix first_page of RANGE_ALL (0-based / 1-based confusion)
Comment on attachment 46155 [details] [review] fix first_page of RANGE_ALL (0-based / 1-based confusion) [ My bugzilla skillz are bad, apologies for a useless notification 10 minutes ago ] Thanks for updating the patch and reading my comments! >diff -puNr evince-0.3.0.orig/ChangeLog evince-0.3.0/ChangeLog >@@ -215,6 +219,7 @@ void > ev_print_job_use_print_dialog_settings (EvPrintJob *job, GnomePrintDialog *dialog) > { > GnomePrintConfig *print_config; >+ EvPageCache *page_cache = ev_document_get_page_cache (job->document); > > g_return_if_fail (EV_IS_PRINT_JOB (job)); > g_return_if_fail (GNOME_IS_PRINT_DIALOG (dialog)); >@@ -225,26 +230,39 @@ ev_print_job_use_print_dialog_settings ( > &job->width, &job->height); > gnome_print_config_get_boolean (print_config, > (guchar *)GNOME_PRINT_KEY_DUPLEX, &job->duplex); >+ >+ page_cache = ev_document_get_page_cache (job->document); >+ >+ /* get the printing ranges */ >+ switch (gnome_print_dialog_get_range (dialog)) { >+ case GNOME_PRINT_RANGE_ALL: >+ job->first_page = 1; >+ job->last_page = ev_page_cache_get_n_pages (page_cache); >+ break; >+ case GNOME_PRINT_RANGE_RANGE: >+ gnome_print_dialog_get_range_page (dialog, &job->first_page, &job->last_page); >+ break; >+ default: >+ g_assert_not_reached (); >+ } >+ > gnome_print_config_unref (print_config); > } > > static gboolean > idle_print_handler (EvPrintJob *job) > { >- EvPageCache *page_cache; >- > if (!job->printing) { > ev_document_doc_mutex_lock (); > ev_ps_exporter_begin (EV_PS_EXPORTER (job->document), > job->temp_file); > ev_document_doc_mutex_unlock (); >- job->next_page = 0; >+ job->next_page = job->first_page - 1; This is quite ugly. next/last_page are initialized with 1-based values and here you switch next_page to 0-based, and the meaning of last_page becomes "0-based last_page_plus_one". A more beautiful way (IMO) is to make the 1-based->0-based conversion above, in the code that reads from the dialog (subtract 1 from all values)... > job->printing = TRUE; > return TRUE; > } > >- page_cache = ev_document_get_page_cache (job->document); >- if (job->next_page < ev_page_cache_get_n_pages (page_cache)) { >+ if (job->next_page < job->last_page) { ... and then use "<=" here > #if 0 > g_printerr ("Printing page %d\n", job->next_page); > #endif >diff -puNr evince-0.3.0.orig/shell/ev-window.c evince-0.3.0/shell/ev-window.c >--- evince-0.3.0.orig/shell/ev-window.c 2005-05-03 16:07:10.000000000 +0200 >+++ evince-0.3.0/shell/ev-window.c 2005-05-07 22:46:19.044917748 +0200 >@@ -1031,6 +1031,7 @@ ev_window_print (EvWindow *ev_window) > GnomePrintConfig *config; > GnomePrintJob *job; > GtkWidget *print_dialog; >+ EvPageCache *page_cache; > EvPrintJob *print_job = NULL; > > g_return_if_fail (EV_IS_WINDOW (ev_window)); >@@ -1039,9 +1040,20 @@ ev_window_print (EvWindow *ev_window) > config = gnome_print_config_default (); > job = gnome_print_job_new (config); > >+ page_cache = ev_document_get_page_cache (ev_window->priv->document); >+ > print_dialog = gnome_print_dialog_new (job, (guchar *) _("Print"), > (GNOME_PRINT_DIALOG_RANGE | > GNOME_PRINT_DIALOG_COPIES)); >+ >+ gnome_print_dialog_construct_range_page (GNOME_PRINT_DIALOG (print_dialog), >+ GNOME_PRINT_RANGE_ALL | >+ GNOME_PRINT_RANGE_RANGE, >+ 1, >+ ev_page_cache_get_n_pages (page_cache), >+ NULL, >+ g_strconcat (_("Pages"), " ", NULL)); >+ This leaks the g_strconcat result. You should free it after use. > gtk_dialog_set_response_sensitive (GTK_DIALOG (print_dialog), > GNOME_PRINT_DIALOG_RESPONSE_PREVIEW, > FALSE); Disclaimer: Haven't done evince work for weeks. Might have overlooked something.
Created attachment 46204 [details] [review] updated version Moved 1-based -> 0-based conversion and fixed g_strconcat leak.
Cool thanks. Good thing I pasted that disclaimer below my last comment. I have one more comment. Sorry. The number of pages in the generated PS file is wrong (the %%Pages line) if we're printing a proper subset of pages. If you look at ev-poppler.cc, the second argument of poppler_ps_file_new is hard-coded to the total number of pages, that's where the wrong number comes from. Can you add a new parameter to _begin where you pass the number of pages to be printed? Thanks.
Created attachment 46271 [details] [review] patch with correct Pages line I've added the number of pages to _begin but I'm not sure whether that suffices. I don't know the poppler/xpdf codebase but from a quick glance it looks like the poppler glib interface need to be extended, as it currently assumes that the postscript export starts at page 1 and ends at the specified page. Maybe this doesn't matter but I suspect that the resulting postscript file may have incorrect metadata (embedded fonts?).
Ugh. You're probably right with the embedded fonts. (look at poppler's PSOutputDev::writeDocSetup) I committed the previous version of your patch (where I said the number of pages is wrong). At least that will print, and it will have all necessary fonts (but maybe some more). Want to make a poppler patch ;-)? (The current interface is that way because we thought knowing the number of pages was enough, we didn't think of the fonts)
Created attachment 46304 [details] [review] poppler glib ps page range
Created attachment 46305 [details] [review] evince print range update patch Hopefully fixed for real this time ;) evince patch is no cvs diff due to anoncvs lag but should apply anyway - aside from changelog.
Can you please send the poppler patch on their mailing list? That's usually the quicker way to get patches in...
Ping... Was this ever sent on the poppler list? Any reason it wasnt?
I've sent it five days ago, http://lists.freedesktop.org/archives/poppler/2005-May/000325.html Don't know why it appears as a reply to an other thread in the archive, I wasn't even subscribed before sending my mail...
CCing krh. It would be cool if we could get this in for the next release...
Created attachment 46530 [details] [review] Updated evince patch I just sent a new patch to the poppler list to address krh comments. This patch is adapted to the new api.
Fixed in cvs