Concerns about print preview implementation

[Paolo Maggi <paolo maggi polito it>]

Hi,

	looking at the previous mails about print preview it seems people are
oriented toward using an external viewer for print previewing.

However we still think this is a bad idea for several reasons.

Some of them have been already pointed out in previous threads. 
We'll briefly sum up the ones that concern us the most:

* it needs to create an external file containing a printed version of the
entire document and save it on the file system (We think we should try to
render and preview pages on request and as Alex said: "I guess not having to render 
the whole document is a distinct advantage of the in-process preview.")

* launching an external app could be slow and memory greedy, especially if the viewer 
has to render the whole document (which could be big, include images, etc.)

* we virtually add a dependency on an external app

Beside there are other issues which make us doubt the validity of this solution:


Usability concerns:

 * A frequent use case (and there are probably more) is launching the preview, going back
to the document to modify it and then relaunch the preview: with an external viewer the user
ends up with two or more instances of the preview, each window with the same title, so that
it's virtually impossible to tell which one is up to date.
This could be very annoying since the user will have to remember to always close the external print 
preview window before opening a second one.
Note that we could special case evince to deal with this scenario (adding command line options etc), 
but that won't work for any other external viewer.

* As explained many times when evince was created, the evince UI is so neat because it was
thought with a clear use case in mind: multipages documents in portrait mode. However not all
gtk apps that do printing are document oriented: think of CAD apps, image editors and probably
others: is the evince UI well suited for previewing those documents?


Features concerns:

 * There are features that clearly cannot be implemented using an external viewer, but that we think
could be very interesting. For instance showing the print margins, drag & drop of the print margins,
live page orientation changes or other live changes to page setup properties like
you can do for example in MS Excel or OOCalc.

 * preview embedding: for instance gedit currently embeds the preview in the tab and we are pretty happy
with it. Sure, someone may argue that we should not do it, but I don't think that this kind of policy decisions
belong in a toolkit. Beside there may be other apps where an embedded preview may make even more sense.


Consistency concerns:

 * using an external viewer, means that an app behaves differently on every system, since the installed
evince version may vary or even a different viewer could be used. This is also problematic for the
documentation since the UI may be different.

 * the API has been designed to allow the usage of native print dialogs on Windows and MacOS X
so that programs running on those OS will have a native look and field: requesting an external viewer is 
contradictory with this choice since, for instance, native Windows applications
normally use embedded print preview. 


Stability concerns:

 * a bug in evince/$VIEWER would compromise the print preview feature of every gtk+ app

 * ditto for faulty installs of the external print previewer. Note that this kind of bugs may be a pain
to deal with for the app developer.


Ciao,
Paolo Borelli and Paolo Maggi