Paolo Maggi <paolo maggi polito it> writes:
[I'm one of the developers of the Gimp-Print/Gutenprint printer
drivers, and I'm pretty familiar with the UNIX/Linux printing
toolchain.]
> 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.
I don't agree with all the conclusions you have drawn. I've included
some comments below.
I've been using Mac OS X for the past year in addition to GNU/Linux,
and the Preview.app program used for previewing is well worth looking
at as an alternative. The comments are based on some use of this
previewer.
I'm sure you're aware that Mac OS X also uses CUPS as its default
printing system. The whole printing side of OS X is also well worth
looking at; it's very well done, being both easy to use and allows for
a good amount of control over printing.
If this list would like a detailed set of screenshots of Mac OS X
printing and previewing, I would be happy to provide them.
> * 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.")
This is very true. However, a preview is supposed to be a preview of
what will be printed. By generating the complete PDF print file, we
get to see exactly what would be printed, not just what the preview
code would generate. If you don't render the whole document, it might
potentially be different to what would get printed when you render it
"for real" (if the application is buggy). Using an external viewer
means there's always just a single codepath for both previewing and
printing.
PDF is replacing PS as the default print format. This is already the
case on Mac OS X, where everything must use it. It's going the same
way on GNU/Linux as well, albeit a little more slowly. Just
generating a PDF file and previewing that is *reliable*, and clearly
separates the concerns of generation and previewing/printing. We are
UNIX programmers, and UNIX is all about tools which do specialised
tasks. Delegation of complex tasks like this is a good design
principle. Putting the kitchen sink into a single program is inviting
trouble.
For large documents it will take longer than for a small document, but
I think the benefits outweigh a little slowness, which will not be
noticeable on most machines. It's not noticeable on Mac OS X, apart
for the first time, when Preview.app is launched. Subsequent
previewing is seemingly instantaneous.
> * 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.)
True, but the memory has to be used somewhere, whether it's in the
same process or a different one. It would be more reliable as an
external viewer, since running out of memory, leaking memory,
rendering bugs, etc. won't result in a crash losing all your hard work
(which I have seen too many times with the MS Office print preview in
times past). A full PDF renderer is a complex beast, and you don't
want it taking down the application when it blows up.
> * we virtually add a dependency on an external app
If it's configurable, I don't see a big problem. Most systems come
with at least one PDF or PS previewer of some sort.
> 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.
Preview.app only exists as a single instance. Each time you do a
preview, it results in a new window being created, with the same title
as the old one. So this is true, but is it a problem in practice?
Typically, if you are finished with the preview, you close it before
returning to the application and previewing again, because the preview
is in the foreground.
> 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.
This can also potentially be useful, since multiple previews can be
compared side by side. If you are adjusting things to see the effect,
this is handy.
> 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.
Personally, I don't think special-casing is desirable in any case.
Just run the external viewer and let the user do what they see fit.
> * 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?
It works with Preview.app. All the preview is doing is displaying the
page(s). The size or number of pages is not going to affect its
ability to do its job unless the program is broken. If you keep it
configurable, the user is able to choose the previewer most suitable
for the job (I find gv very usable, for example).
> 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.
I think these are somewhat contentious feature for a preview widget.
This is clearly in the realm of "editing", since you are changing the
document and then re-rendering it. This is not previewing, and IMO
this functionality does not belong in the previewer. The previewer is
showing the document as it would be printed, and should be static.
> * 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.
IMO, the behaviour of the preview should be consistent throughout all
GTK+/GNOME applications (on the same system, not necessarily across
platforms). If you always use an external previewer, you will always
get the same behaviour. This is how it works on Mac OS X, and it
works pretty nicely.
> 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.
This is a good point. But, one thing to consider is that due to the
platform-specific nature of printing on e.g. Windows and Mac OS, you
are not going to get true consistency in any case. For true platform
integration, I would suggest using what the user of the platform would
expect. This means:
- Preview.app on Mac OS X.
- evince on GNOME.
- konqueror on KDE.
- Acrobat Reader on Windows (?).
- ggv with CDE (?)
- etc.
> * 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.
And native Mac OS X applications use Preview.app. Both choices are
potentially wrong, depending upon the platform. For most users, even
on Windows, the preview is just a window that pops up. I doubt they
care if it's part of the application or an external process,
especially if it's not noticeable.
> Stability concerns:
>
> * a bug in evince/$VIEWER would compromise the print preview
> feature of every gtk+ app
True, but that's much better than compromising the application and
losing the user's work. I prefer an external viewer for this reason
alone. I wouldn't want to embed Ghostscript/poppler in every
application, since they are horribly complex (and buggy) beasts, but
this is essentially what you would be doing.
Really, this is the most serious point I would like to bring up. Not
treating the user's data with care would be downright irresponsible.
> * 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.
I'd argue that this isn't the application developer's concern, just
like the browser ultimately used to view a URL isn't their concern
either. If there's a problem launching the previewer, a clearly
written dialogue stating that the previewing program xxxx failed to
start will inform the user where the fault lies, and then they can do
something about fixing it.
Regards,
Roger
--
Roger Leigh
Printing on GNU/Linux? http://gutenprint.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
Attachment:
pgpjjS5CT0kZP.pgp
Description: PGP signature