After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 396475 - Printing in preview mode
Printing in preview mode
Status: RESOLVED FIXED
Product: evince
Classification: Core
Component: printing
0.6.x
Other All
: Normal enhancement
: ---
Assigned To: Evince Maintainers
Evince Maintainers
Depends on: 344515 403717
Blocks:
 
 
Reported: 2007-01-14 15:20 UTC by albrecht.dress
Modified: 2007-05-11 12:46 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16



Description albrecht.dress 2007-01-14 15:20:13 UTC
The present implementation of Evince (0.6.1) does not permit printing in preview mode.  When using evince as a Gtk+-2.10 previewer (the default), this is really annoying if the preview is used e.g. to check if settings are correct.  If I then *really* want to print, I have to close evince and run the print dialogue from my application again which is an extra step and may (depending upon the application) consume some time.

I therefore suggest adding a print button to the tool bar in preview mode.
Comment 1 Carlos Garcia Campos 2007-01-14 15:41:23 UTC
Agree, this is exactly what I said in gtk-devel-list when preview mode was implemented. The problem is that, in this moment, print settings are not passed from gtk+ to evince. We can't print in preview mode because we don't know settings selected by the user. 
This bug depends on bug #344515, once it is fixed we'll add command line options to evince to provide the path to a file containing print settings. 
Comment 2 albrecht.dress 2007-01-14 17:07:36 UTC
IIRC, the Evince preview mode is used only by Gtk+, right?  In this case, IMO
the easiest way would be adding this data in PDF comments [1] by GtkPrint to
the temp file which is probably more robust then passing a file reference
(which at some point must be unref'ed, btw.).  It is only necessary to add the
stuff returned by gtk_print_settings_foreach() there, as the paper size is
already encoded in the PDF file.  And, of course, it is necessary to agree upon
a syntax between gtk+ and Evince for passing this data.  E.g. the comments
might look like

%BEGIN GtkPrint Preview
%print-at=now
%cups-PrintoutMode=Normal
%scale=100
%page-ranges=0,1,42
%cups-job-priority=50
%cups-Quality=FromPrintoutMode
%cups-job-sheets=none,none
% [...more stuff...]
%END GtkPrint Preview

Note that this method does *not* interfere with the "normal" contents of the
PDF file, i.e. you can still copy the preview file from /tmp to some other
location or view it normally with Preview.app/Adobe Reader/Whatever which will
simply ignore this data.

[1] PDF Reference, Version 1.6, Sect. 3.1.2
Comment 3 Carlos Garcia Campos 2007-01-18 15:08:44 UTC
Hmm that would be a nice solution. However, it requires more work in this moment. AFAIK poppler doesn't support embedded comments right now. So it has to be supported by both gtkprint and poppler first.
Comment 4 albrecht.dress 2007-01-18 18:10:40 UTC
I see...  An other approach which does not need any extra infrastructure in poppler (and probably in cairo) would be passing the preview file name and options through the command line, maybe using a RFC 2396 URI.  E.g. by adding an option "--preview-uri", which might look like

--preview-uri=file:/tmp/preview4711.pdf?print-at=now&cups-PrintoutMode=Normal&...

Producing the uri in Gtk+ is trivial, as parsing it in evince.  The only problem /might/ be that the resulting command line is too long some ancient systems.  Usual UNIX systems support something like 32kb, afaik, which should be sufficient...

I really dislike the idea of passing meta information for the preview mode through a file which IMO is not a robust solution!
Comment 5 Christian Persch 2007-02-02 20:36:45 UTC
Since the print preview document is already passed through a file, I don't see any additional problem by passing the print options in a file, too.
Comment 6 Carlos Garcia Campos 2007-05-11 12:46:31 UTC
It should be fixed it in svn trunk.

Thanks.