Paolo Maggi <[EMAIL PROTECTED]> writes: [I'm one of the developers of the Gimp-Print/Gutenprint printer drivers, and I'm pretty familiar with the UNIX/Linux printing toolchain.]
> looking at the previous mails about print preview it seems people > are oriented toward using an external viewer for print previewing. > However we still think this is a bad idea for several reasons. I don't agree with all the conclusions you have drawn. I've included some comments below. I've been using Mac OS X for the past year in addition to GNU/Linux, and the Preview.app program used for previewing is well worth looking at as an alternative. The comments are based on some use of this previewer. I'm sure you're aware that Mac OS X also uses CUPS as its default printing system. The whole printing side of OS X is also well worth looking at; it's very well done, being both easy to use and allows for a good amount of control over printing. If this list would like a detailed set of screenshots of Mac OS X printing and previewing, I would be happy to provide them. > * it needs to create an external file containing a printed version > of the entire document and save it on the file system (We think we > should try to render and preview pages on request and as Alex said: > "I guess not having to render the whole document is a distinct > advantage of the in-process preview.") 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. PDF is replacing PS as the default print format. This is already the case on Mac OS X, where everything must use it. It's going the same way on GNU/Linux as well, albeit a little more slowly. Just generating a PDF file and previewing that is *reliable*, and clearly separates the concerns of generation and previewing/printing. We are UNIX programmers, and UNIX is all about tools which do specialised tasks. Delegation of complex tasks like this is a good design principle. Putting the kitchen sink into a single program is inviting trouble. For large documents it will take longer than for a small document, but I think the benefits outweigh a little slowness, which will not be noticeable on most machines. It's not noticeable on Mac OS X, apart for the first time, when Preview.app is launched. Subsequent previewing is seemingly instantaneous. > * launching an external app could be slow and memory greedy, > especially if the viewer has to render the whole document (which > could be big, include images, etc.) True, but the memory has to be used somewhere, whether it's in the same process or a different one. It would be more reliable as an external viewer, since running out of memory, leaking memory, rendering bugs, etc. won't result in a crash losing all your hard work (which I have seen too many times with the MS Office print preview in times past). A full PDF renderer is a complex beast, and you don't want it taking down the application when it blows up. > * we virtually add a dependency on an external app If it's configurable, I don't see a big problem. Most systems come with at least one PDF or PS previewer of some sort. > Usability concerns: > > * A frequent use case (and there are probably more) is launching > the preview, going back to the document to modify it and then > relaunch the preview: with an external viewer the user ends up with > two or more instances of the preview, each window with the same > title, so that it's virtually impossible to tell which one is up to > date. Preview.app only exists as a single instance. Each time you do a preview, it results in a new window being created, with the same title as the old one. So this is true, but is it a problem in practice? Typically, if you are finished with the preview, you close it before returning to the application and previewing again, because the preview is in the foreground. > This could be very annoying since the user will have to remember to > always close the external print preview window before opening a > second one. This can also potentially be useful, since multiple previews can be compared side by side. If you are adjusting things to see the effect, this is handy. > Note that we could special case evince to deal with this scenario > (adding command line options etc), but that won't work for any other > external viewer. Personally, I don't think special-casing is desirable in any case. Just run the external viewer and let the user do what they see fit. > * As explained many times when evince was created, the evince UI is > so neat because it was thought with a clear use case in mind: > multipages documents in portrait mode. However not all gtk apps that > do printing are document oriented: think of CAD apps, image editors > and probably others: is the evince UI well suited for previewing > those documents? It works with Preview.app. All the preview is doing is displaying the page(s). The size or number of pages is not going to affect its ability to do its job unless the program is broken. If you keep it configurable, the user is able to choose the previewer most suitable for the job (I find gv very usable, for example). > Features concerns: > > * There are features that clearly cannot be implemented using an > external viewer, but that we think could be very interesting. For > instance showing the print margins, drag & drop of the print > margins, live page orientation changes or other live changes to page > setup properties like you can do for example in MS Excel or OOCalc. I think these are somewhat contentious feature for a preview widget. This is clearly in the realm of "editing", since you are changing the document and then re-rendering it. This is not previewing, and IMO this functionality does not belong in the previewer. The previewer is showing the document as it would be printed, and should be static. > * preview embedding: for instance gedit currently embeds the > preview in the tab and we are pretty happy with it. Sure, someone > may argue that we should not do it, but I don't think that this kind > of policy decisions belong in a toolkit. Beside there may be other > apps where an embedded preview may make even more sense. 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. > Consistency concerns: > > * using an external viewer, means that an app behaves differently > on every system, since the installed evince version may vary or even > a different viewer could be used. This is also problematic for the > documentation since the UI may be different. This is a good point. But, one thing to consider is that due to the platform-specific nature of printing on e.g. Windows and Mac OS, you are not going to get true consistency in any case. For true platform integration, I would suggest using what the user of the platform would expect. This means: - Preview.app on Mac OS X. - evince on GNOME. - konqueror on KDE. - Acrobat Reader on Windows (?). - ggv with CDE (?) - etc. > * the API has been designed to allow the usage of native print > dialogs on Windows and MacOS X so that programs running on those OS > will have a native look and field: requesting an external viewer is > contradictory with this choice since, for instance, native Windows > applications normally use embedded print preview. And native Mac OS X applications use Preview.app. Both choices are potentially wrong, depending upon the platform. For most users, even on Windows, the preview is just a window that pops up. I doubt they care if it's part of the application or an external process, especially if it's not noticeable. > Stability concerns: > > * a bug in evince/$VIEWER would compromise the print preview > feature of every gtk+ app True, but that's much better than compromising the application and losing the user's work. I prefer an external viewer for this reason alone. I wouldn't want to embed Ghostscript/poppler in every application, since they are horribly complex (and buggy) beasts, but this is essentially what you would be doing. Really, this is the most serious point I would like to bring up. Not treating the user's data with care would be downright irresponsible. > * ditto for faulty installs of the external print previewer. Note > that this kind of bugs may be a pain to deal with for the app > developer. I'd argue that this isn't the application developer's concern, just like the browser ultimately used to view a URL isn't their concern either. If there's a problem launching the previewer, a clearly written dialogue stating that the previewing program xxxx failed to start will inform the user where the fault lies, and then they can do something about fixing it. Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gutenprint.sourceforge.net/ Debian GNU/Linux http://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
pgptgrmGGVqsO.pgp
Description: PGP signature
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list