Re: Problem with preview and the blocking print dialog

On Thu, 2006-05-11 at 14:35 -0400, Jody Goldberg wrote:
> On Wed, May 10, 2006 at 04:51:48PM -0500, Federico Mena Quintero wrote:
> > On Wed, 2006-05-10 at 17:42 -0400, John (J5) Palmieri wrote:
> > > I'm implementing the preview code in gtkprint.  I have decided to use an
> > > external helper (default is evince) to do print preview.  The idea was
> > > to write out to a pdf in /tmp and launch the external helper when the
> > > user hits the preview button.
> > 
> > <ignorant>
> > 
> > Why do we have an external helper?
> > 
> > Gnome-print would save everything to its own internal metafile, and then
> > it would spit it to a gnome-canvas.  Could we make Cairo just render
> > everything to a preview window?
> > 
> > </ignorant>
> This was a performance nightmare in libgnomeprint because it would
> queue up the entire document in a metafile which could easily reach
> into the hundreds of megs.  The new code is a huge improvement in
> supporting per page rendering.  If that can avoid the overhead then
> there are benefits to inline rendereing.  Some of the new features
> Lutz added to gnomeprintui such as drag-n-drop page reordering and
> subsetting are not really feasible with an external 

I guess not having to render the whole document is a distinct advantage
of the in-process preview. 

What does subsetting mean? Just changing the page ranges from the
preview window? That sounds useful.

 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a lonely skateboarding paranormal investigator in a wheelchair. She's a 
violent thirtysomething politician from out of town. They fight crime! 

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]