<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <html><head><meta name="qrichtext" content="1" /><style type="text/css"> p, li { white-space: pre-wrap; } </style></head><body style=" font-family:'DejaVu Sans'; font-size:12pt; font-weight:400; font-style:normal;"> On Monday, May 09, 2011 02:38:19 AM edmund ronald wrote: > Ok, here is a use case: > > I am a hobby photographer, or an art printing service house. > I get in some new heavy Acme media which looks nice but looks like it > will soak up more ink than what I am using. > I set the CPD to "Epson Heavy Matte" and indeed when it prints with the > associated profile black is not yet really black. > So I go to the "advanced" CPD tab, increase density, save the setting back > out under "Acme Super Heavy Matte", and print a profile target, check that > on target blacks are black, run a profile, So far this is all more or less supported by the current CPD code. > use the advanced CPD to > associate the profile with the new settings, This is currently not supported since the CPD does not current understand profiles or settings bundles beyond it's presets feature. But the current CPD design allows users to create custom presets that are then added to the presets drop down list. > and now "Acme Super Heavy > Matte" can be used without complication from the "simple printing" tab of > the CPD. That is basically correct and that is one of the reasons that the CPD has the presets feature. What we are missing here is a way for admins to create system wide CPD presets or for print server admins to create printer specific presets that are then displayed in the users CPD. Having this would alter Edmonds workflow to possibily include a CM expert or printer admin creating a settings bundle and profile and installing this on the print server so that users CPD's (both local and remote to the server) could use these print server specific presets. > > Edmund > > On Mon, May 9, 2011 at 3:52 AM, Robert Krawitz <rlk@alum.mit.edu> wrote: > > On Mon, 09 May 2011 11:48:08 +1000, Graeme Gill wrote: > > > Robert Krawitz wrote: > > >> I don't agree with this reasoning. I think it's important to have all > > >> such options available from all programs with a print dialog; we > > >> should figure out how to present them most effectively. > > > > > > My view is both to agree and disagree: I think that the ability to > > > setup a printer is something that should be put in well tested and > > > maintained code paths and be universally available, rather than > > > relegated to "optional" component that will probably fall into > > > disrepair, or make it hard to access or be inconsistent with the > > > normal printing path. > > > > > > On the other hand, I don't see anybody changing such detailed > > > settings arbitrarily on a print by print basis. The practical way of > > > handling printer setup is with a labelled configuration. The > > > configuration choice would be what can be set from the normal > > > printing dialogue, while creating or altering a configuration would > > > be a separate step "edit/create printer configuration". Where such > > > configuration information would be kept, and the method for > > > accessing and changing it is an interesting technical > > > question. Ideally it should be a remotely available operation, so > > > that creating or examining printing configurations can be done from > > > any place that you can print a document from, accessible from the > > > usual printer information GUI. > > > > I have no problem with that. After all, if you really need to, you > > can create a new configuration from the editor. > > _______________________________________________ > > openicc mailing list > > openicc@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/openicc </body></html>