Re: Concerns about print preview implementation

["John (J5) Palmieri" <johnp redhat com>]

On Mon, 2006-05-15 at 14:37 -0400, Dimi Paun wrote:
> 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.

Actually the KISS method is to launch the external viewer.  It is why I
wrote it first.

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

GTK+ print preview will only display with one viewer across all
applications in a users environment.  The fact that other environments
can change the default behavior will still cause every app to be
consistent. 

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

Windows has a preview dialog in .net not sure about in the win32 api.

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

I'm already writing an inline API for anyone who cares to implement a
preview widget.

>   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

Windows does printing and print preview in a thoroughly inconsistent
way.  At the beginning of the discussion about gtk printing it was
pointed out that windows doesn't even have a consistent print dialog.
Consistency with windows is a non argument.  We are not designing for
windows users.  We are designing for computer desktop users.

>        * consistency with other non-GTK apps (as already mentioned)

That is like a dog chasing its tail.  If we strove for that the desktop
would be doomed to repeat old mistakes over and over again.

>        * smaller latency, more interactive

Nothing says an external viewer is less interactive.  In fact in the
short run it is more interactive.  But then again, either could best the
other at any point in time.

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

We have decided to support it if just for the sake of evaluating it but
someone will have to step up and write the widget. There are pluses and
minuses for each approach.

-- 
John (J5) Palmieri <johnp redhat com>