From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BEA1.AEDF97AD" Date: Thu, 16 Apr 2009 07:45:48 -0700 Message-ID: From: "Petrie, Glen" Subject: [Printing-architecture] Preview for CPD List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Till Kamppeter , peter sikking Cc: printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BEA1.AEDF97AD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Peter, Till, =20 I believe my understanding from the print-summit was that the new CPD would "always" preview the actual print content, which was based on Peter's usability test results. The concern I have is that the potential processing in creating the preview would include the entire print chain; even though the image is at a very low resolution. This level of processing has a potential large time delay. If the End-User starts making print option changes that affect the preview; the preview image will have to be re-rendered, which may take too much time. =20 I would like to suggest that the CPD add and use, as the default, an internal default image that illustrates the print intent and print options but not the actual print content. This would reduce potential heavy processing for the actual print content preview. However, the user should be able to enable display of the actual print content and willing to accept the potential time delay in creating the actual print content. =20 glen ------_=_NextPart_001_01C9BEA1.AEDF97AD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Peter, Till,

I believe my understanding from the print-summit was = that the new CPD would “always” preview the actual print content, = which was based on Peter’s usability test results. The concern I = have is that the potential processing in creating the preview would include the = entire print chain; even though the image is at a very low resolution. = This level of processing has a potential large time delay. If the End-User starts making print option changes that affect the preview; the preview image will have to be re-rendered, which may take too much = time.

I would like to suggest that the CPD add and use, as = the default, an internal default image that illustrates the print intent and = print options but not the actual print content. This would reduce potential = heavy processing for the actual print content preview. However, the user = should be able to enable display of the actual print content and willing to = accept the potential time delay in creating the actual print = content.

glen

------_=_NextPart_001_01C9BEA1.AEDF97AD-- From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Apr 2009 10:23:55 -0700 Message-ID: References: <49E768BF.6030404@apple.com> From: "Petrie, Glen" Subject: Re: [Printing-architecture] [Printing-summit] Preview for CPD List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael R Sweet Cc: printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org, Till Kamppeter Good idea but I still believe it should be the User's choice > -----Original Message----- > From: Michael R Sweet [mailto:msweet@apple.com] > Sent: Thursday, April 16, 2009 10:20 AM > To: Petrie, Glen > Cc: Till Kamppeter; peter sikking; printing-architecture@lists.linux- > foundation.org; printing-summit@lists.linux-foundation.org > Subject: Re: [Printing-summit] Preview for CPD >=20 > Petrie, Glen wrote: > > > > > > Peter, Till, > > > > > > > > I believe my understanding from the print-summit was that the new CPD > > would "always" preview the actual print content, which was based on > > Peter's usability test results. The concern I have is that the > > potential processing in creating the preview would include the entire > > print chain; even though the image is at a very low resolution. This > > level of processing has a potential large time delay. If the End-User > > starts making print option changes that affect the preview; the preview > > image will have to be re-rendered, which may take too much time. > > > > > > > > I would like to suggest that the CPD add and use, as the default, an > > internal default image that illustrates the print intent and print > > options but not the actual print content. This would reduce potential > > heavy processing for the actual print content preview. However, the > > user should be able to enable display of the actual print content and > > willing to accept the potential time delay in creating the actual print > > content. >=20 > *Or* you could display the default image while generating the actual > preview image (with some sort of animated progress indicator/spinner) > so that you get the best of both worlds. >=20 > -- > ______________________________________________________________________ > Michael R Sweet Senior Printing System Engineer From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <49E768BF.6030404@apple.com> References: <49E768BF.6030404@apple.com> Date: Thu, 16 Apr 2009 13:29:49 -0400 Message-ID: From: Ira McDonald Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Printing-architecture] [Printing-summit] Preview for CPD List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael R Sweet , Ira McDonald Cc: "Petrie, Glen" , printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org Hi, I agree with Glen's suggestion - default images for preview should ALWAYS be the fallback - for the limited-resource embedded environment REAL preview images are NOT a good idea. I also agree with Mike (and Glen) that displaying the default image WHILE generating the real preview image is a friendly design approach. Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Blue Roof Music/High North Inc email: blueroofmusic@gmail.com winter: 579 Park Place Saline, MI 48176 734-944-0094 summer: PO Box 221 Grand Marais, MI 49839 906-494-2434 On Thu, Apr 16, 2009 at 1:19 PM, Michael R Sweet wrote: > Petrie, Glen wrote: >> >> >> Peter, Till, >> >> >> >> I believe my understanding from the print-summit was that the new CPD >> would =93always=94 preview the actual print content, which was based on >> Peter=92s usability test results. =A0The concern I have is that the >> potential processing in creating the preview would include the entire >> print chain; even though the image is at a very low resolution. =A0This >> level of processing has a potential large time delay. =A0 If the End-Use= r >> starts making print option changes that affect the preview; the preview >> image will have to be re-rendered, which may take too much time. >> >> >> >> I would like to suggest that the CPD add and use, as the default, an >> internal default image that illustrates the print intent and print >> options but not the actual print content. =A0This would reduce potential >> heavy processing for the actual print content preview. =A0However, the >> user should be able to enable display of the actual print content and >> willing to accept the potential time delay in creating the actual print >> content. > > *Or* you could display the default image while generating the actual > preview image (with some sort of animated progress indicator/spinner) > so that you get the best of both worlds. > > -- > ______________________________________________________________________ > Michael R Sweet =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Senior Pri= nting System Engineer > _______________________________________________ > Printing-summit mailing list > Printing-summit@lists.linux-foundation.org > https://lists.linux-foundation.org/mailman/listinfo/printing-summit > From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <49E76EA6.10306@gmail.com> Date: Thu, 16 Apr 2009 19:45:10 +0200 From: Till Kamppeter MIME-Version: 1.0 References: <49E768BF.6030404@apple.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Printing-architecture] [Printing-summit] Preview for CPD List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ira McDonald Cc: printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org, Michael R Sweet I also agree with the use of a default image, once, while waiting for a live preview and second, on systems not capable of generating previews due to restricted resources, and also for the case that the client application does not support live preview (for example it did not get changed towards the printing dialog but Lars' stage-1-CPDAPI-patched GTK or Qt is used). Till Ira McDonald wrote: > Hi, > > I agree with Glen's suggestion - default images for preview > should ALWAYS be the fallback - for the limited-resource > embedded environment REAL preview images are NOT a > good idea. > > I also agree with Mike (and Glen) that displaying the default > image WHILE generating the real preview image is a friendly > design approach. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <49E76FA1.2020300@gmail.com> Date: Thu, 16 Apr 2009 19:49:21 +0200 From: Till Kamppeter MIME-Version: 1.0 References: <49E768BF.6030404@apple.com> <49E76EA6.10306@gmail.com> In-Reply-To: <49E76EA6.10306@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Printing-architecture] [Printing-summit] Preview for CPD List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Till Kamppeter Cc: printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org, Michael R Sweet We should also try to get the best for the live preview. For example it should render only the visible page (and the CPDAPI should support that). Till Till Kamppeter wrote: > I also agree with the use of a default image, once, while waiting for a > live preview and second, on systems not capable of generating previews > due to restricted resources, and also for the case that the client > application does not support live preview (for example it did not get > changed towards the printing dialog but Lars' stage-1-CPDAPI-patched GTK > or Qt is used). > > Till > > Ira McDonald wrote: >> Hi, >> >> I agree with Glen's suggestion - default images for preview >> should ALWAYS be the fallback - for the limited-resource >> embedded environment REAL preview images are NOT a >> good idea. >> >> I also agree with Mike (and Glen) that displaying the default >> image WHILE generating the real preview image is a friendly >> design approach. > > From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <1C296078-3075-4D08-BE61-6CE082C165DB@mmiworks.net> From: peter sikking In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 17 Apr 2009 20:08:11 +0200 References: Subject: Re: [Printing-architecture] Preview for CPD List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Petrie, Glen" Cc: printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org, Till Kamppeter Glen wrote: > I believe my understanding from the print-summit was that the new =20 > CPD would =93always=94 preview the actual print content, which was = based =20 > on Peter=92s usability test results. and the usability test results proved that the preview is a huge success and needs to be 100% "true". users will fully depend on it to start trusting the print process, and trust cannot be betrayed by a quick hack. no generic image can be a replacement and no army of engineers can discuss away this requirement. the speed with which the preview is generated is of course also 100% a usability issue. we basically have 1 second (on modern hardware) to get that first page there. we will have a busy indication for that one second (max) wait. the optimisation opportunities are of course in that the longest side of the page is a low (225 at the moment) fixed (compile time, I say) number of pixels. there is going to be no resizing of the dialog, and no zooming of the preview. that is designed in, for other UI reasons, but it comes in handy here. the second optimisation opportunity is that only the first page needs to be 'immediately' there, in case of N-up > 1 more pages but the needed fidelity is proportionately lower (in integer steps, another optimisation opportunity). every trick in the book will probably have to be used to get a specialised preview pipeline up to speed. remember that when the printing dialog comes up that it occupies users' attention and hence has a licence to hog processor resources. I have no qualms about that. the preview is one big conn-trick, it simply needs to never get caught cheating, whatever the print is. without a real preview there is simply no common printing dialog. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 11:54:49 -0700 Message-ID: References: <1C296078-3075-4D08-BE61-6CE082C165DB@mmiworks.net> From: "Petrie, Glen" Subject: Re: [Printing-architecture] Preview for CPD List-Id: Printing architecture under linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: peter sikking Cc: printing-architecture@lists.linux-foundation.org, printing-summit@lists.linux-foundation.org, Till Kamppeter > and the usability test results proved that the preview is a huge > success and needs to be 100% "true". users will fully depend on > it to start trusting the print process, and trust cannot be > betrayed by a quick hack. >=20 > no generic image can be a replacement and no army of engineers > can discuss away this requirement. >=20 In the end, the application may decide to just send you a "caned image"; thus, the "preview" of what is mute. It is never just usability nor engineering who should decide; it is the end user. Usability and engineering provide options in the best way(s) they can. It should be the user choice.