"m. allan noah" <kitno455 at gmail.com> writes: > Well, if we dont use params, our only choice with the current API is > more well-known options. One advantage of moving maintained backends > to a new package would be the possibility of regularizing/requiring > such options...
+1 on more well-known options +1 on regularising options -1 on requiring more options Unless you pick your well-known options extremely carefully, requiring them may put undue burden on backend implementers. Anything beyond requiring the currently well-known options in the standard would be questionable at best. As mentioned on the ICC thread, adding "tags" to options to indicate what general area functionality they provide/affect seems like something that deserves some thought. Options could then indicate to frontends that they affect colour and speed, for example. The CommonPrintingDialog[1] is heading in that direction and want to use the tags for grouping purposes and let users pick the set of tags (and therefore options) that they care about. This solves the problem where users are completely overwhelmed by the myriad of available options in a tabbed dialog where you can never find what you're looking for (hint: the options is always on the last tab you check). [1] http://www.linuxfoundation.org/en/OpenPrinting/CommonPrintingDialog The currently defined well-known options seem to be fairly well-defined although I'm not so sure that the definition for preview mode is easy to satisfy on the backend side in all situations. With respect to the resolution, it is not clear from whose point of view (user, frontend, backend) this is defined (and who should be responsible for adjusting the image data if the device doesn't support the resolution). Hope this helps, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS Corporation FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962