Re: New API questions

["Nickolay V. Shmyrev" <nshmyrev yandex ru>]

> > 3. Third. We had requests to print pages in reverse order. In older view
> > it was possible with "From ... to ..." entry by passing bigger page in
> > first spinner and smaller one in second. Now I see this control was
> > removed in CVS. Do you have any plans to implement such functionality.
> 
> The functionality is already in CVS. I've just not hooked it up yet.
> Will do so in the next couple of days.
> 

Ups, I haven't noticed it. I was playing with current CVS, but the
reverse checkbox is placed in the copies selector somehow and it's
not shown. 

Placement in copies looks strange for me. I'm not an usability expert
anyhow, but it seems that some other UI improvements to dialog usability
can be made. For example, label "n pages to 1" for me looks like
designed for programmers :) Will something like  "Several pages to one
..." better than the current label. Another very confusing thing is
"Even/Odd checkboxes". When I click on  "Even" and then on "Odd"
checkbox "Even" became selected. That's is certainly not what user
expects. I'd better use something like radio "Both, Even, Old". Actually
I wonder if all this advanced functionality can fit in one dialog.
Probably our usability list can say something or at least flame on it.
That is why I am asking is there some mockups for a new dialog or
another type of proposal. Sorry for above if you like present state ;)

> libgnomeprint(ui) was designed to take over the generation of
> PostScript/PDF/SVG/whatever data. If you use the gnome-print-API
> (gnome_print_moveto, gnome_print_fill...), libgnomeprint will be able to
> do lots of cool stuff:
> - printing n-to-1 (even 1-to-n: posters for poor people)
> - reverse order
> - pages "1,5-8"
> - drag and drop pages from one print preview to the print preview of
> another application and thus merge for example abiword and gnumeric
> files...
> 
> As I doubt that you'll implement all of this in evince, you need to
> suppress elements all over the GUI. How should we do that? Making the
> elements insensitive? Hiding them (and probably rearranging the visible
> ones)? How to do it technically? For what do you need the dialog,
> anyways?
> 

About printing itself. You see there are several task that libgnomeprint
can deal with - first of all, access to system hardware (that is the
common part). Second, conversion between formats (cairo <-> postscript
<->pdf <-> pixbuf <-> gnomeprint metaformat). That is also quite common
although, for some apps like gedit or gnumeric it's better to create
data in gnomeprint metaformat or probably with cairo in the future. But
for some apps like our evince, it's much easier to generate postscript.
But we still need dialog functionality and functionality to access the
printer. Older API allow as to do that, newer don't. We can't work with
our postscript files and it seems almost impossible for us to create
documents in gnoemprintui metaformat. 

Probably when cairo will be used, it would be acceptable although
I can't say if it will work (for example poppler which already depends
on cairo in theory can be adopted to cairo printing, but some formats
like djvu has libraries that generate Postscript and will never work
with cairo, mozilla also btw). 

Due to such problem with already have a lot of requirements that really
hard to satisfy (for example, poppler only generates A4 and there is no
way to make it respect page settings in the dialog and so on).

So, we need the ability to "embed" our app between document generation
code and sending data to printer. That task was handled by
gnome_print_set_file function that've never became stable part of API.
Or we need a way to convert postscript to gnomeprint metaformat for
passing it through printing framework.

> > 7. Probably evince will be useful as print preview widget in the future.
> > Probably we can investigate such question and try to implement it
> > somehow.
> 
> The preview widget is just a viewer for gnome-prints internal meta
> format. This format can be converted by libgnomeprint to PostScript,
> PDF, SVG and images (gdk-pixbuf). I am not convinced that a dependency
> on an external program to render that meta format would add benefits.
> 
> As a sidenote: It seems that the print preview dialog is a relict of the
> past. firefox displays in the tab. So does the gedit (CVS). The abiword
> team is getting alarmed if someone finds out that the print output
> differs from the document shown in the application.
> 

And about preview. You see it's a widget and it's almost the same widget
as evince main view. You know, implementing a good custom widget is very
hard, just because it requires very careful attention to details like
accessibilty and so on. That is why I am asking about common parts of
evince work and gnomeprintui work. Probably we can find some common part
in our widgets and work on them together. Users will ask you for
continuous pages in print preview one day, then you'll remember evince
once again :)

Let me note that there is no problem with dependency. Evince depends
on libgnomeprintui, so common parts may be placed there. 

Although probably such monster will be too complicated to handle, may be
I am wrong and small code that just do it's work will be better than
common widget that handles everything. That's why I am asking what do 
other people think about it.