> > 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. _______________________________________________ Evince-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evince-list
