Re: Concerns about print preview implementation

["Dimi Paun" <dimi lattica com>]

On Mon, May 15, 2006 2:09 pm, Roger Leigh wrote:
> 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.

But your tradeoff is to give up speed and KISS for the case where
the app is buggy. It's easier to fix the app than to setup a workflow
that annoys the user.

> 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.

It works nicely on Mac OS X where they control everything, including
the previewer. I really doubt it will work acceptable in such a different
environemnts as GTK+ apps work in. Even within one OS like Linux you have
multiple viewers and we'll end up with a clunky interface.

> For true platform integration, I would suggest using what the user
> of the platform would expect.

This is a fundamental point. Please look at Swing vs. SWT and so on about
failed/successful models. With this in mind, I think the important issues
here are:
  1. How should the preview be: Inline or external?
     To my mind, the only correct answer is "depends on the platform":
     OS X: preview.app
     Windows: inline
     Linux: TBD (see below)
  2. Speed in (very) important in desktop apps.
     For this reason, we should support incremental rendering
     whenever possible. The ability to render pages as view by
     the user is important, and we should retain that ability
  3. How should the API look like?
     My gut feeling is telling me that inline viewing is more
     difficult from an API perspective. If we get that right,
     the exteranl case will just follow naturally, and will become
     just an implementation detail.
  4. What should preview work in Linux?
     IMO the smart choice would be inline, for the following reasons:
       * consistency with Windows, principle of least surprise
       * consistency with other non-GTK apps (as already mentioned)
       * smaller latency, more interactive

Regardless, at the very least we have to get the API right. And that
means supporting inline rendering IMO.

-- 
Dimi Paun <dimi lattica com>
Lattica, Inc.