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
_______________________________________________
gtk-devel-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
