Menu
▾
▴
gimp-print-devel
|
From: Robert K. <rl...@al...> - 2010-08-28 00:18:35
|
I have a couple of independent requests for a way to identify all options that may affect color. That includes the options of class STP_PARAMETER_CLASS_OUTPUT, of course, but there are others (ink type, resolution, media type, etc) that can also. The purpose is to identify which settings may be safely changed without invalidating a profile; obviously a profile won't be affected by the media size, but it may be affected by the media type. I'd like to find a way to do this that doesn't break binary compatibility and is also extensible. The problem here is that this information really belongs in stp_vars_t, and changing that structure will cause binary compatibility problems (adding something to the end isn't foolproof, either; if an application has an array of stp_parameter_t's or malloc's one, that won't work). The most obvious thing to me is to change the interpretation of category (const char *). Currently it's intended as a high level, translated description of how controls should be grouped, but nothing in Gutenprint uses it and last I checked PhotoPrint (the only other Gutenprint application that I'm aware of) doesn't appear to either. My thought is to change it to a list of comma-separated keywords, each of which identifies a characteristic of the variable (they could even be generalized to keyword=value, where an empty value just implies a presence). What do people think of this? |
|
From: Kai-Uwe B. <ku...@gm...> - 2010-08-28 04:52:18
|
Am 27.08.10, 20:18 -0400 schrieb Robert Krawitz: > The most obvious thing to me is to change the interpretation of > category (const char *). Currently it's intended as a high level, > translated description of how controls should be grouped, but nothing > in Gutenprint uses it and last I checked PhotoPrint (the only other > Gutenprint application that I'm aware of) doesn't appear to either. > My thought is to change it to a list of comma-separated keywords, each > of which identifies a characteristic of the variable (they could even > be generalized to keyword=value, where an empty value just implies a > presence). > > What do people think of this? Will the future interpretation depend on a Gutenprint version? kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org |
|
From: Alastair M. R. <bla...@fa...> - 2010-08-28 08:49:28
|
Hi :) On 28/08/10 01:18, Robert Krawitz wrote: > The most obvious thing to me is to change the interpretation of > category (const char *). Currently it's intended as a high level, > translated description of how controls should be grouped, but nothing > in Gutenprint uses it and last I checked PhotoPrint (the only other > Gutenprint application that I'm aware of) doesn't appear to either. That's right - PhotoPrint currently makes no use of this. > My thought is to change it to a list of comma-separated keywords, each > of which identifies a characteristic of the variable (they could even > be generalized to keyword=value, where an empty value just implies a > presence). > > What do people think of this? Sounds like a sensible option to me, though if we're talking about a string that client applications have to parse, it'd be nice to have a higher-level helper function that tests for a particular enumerated or #defined category and returns true or false. Then again, if PhotoPrint is about the only direct client app I guess that's not an issue. The vast majority of applications, though, won't actually care much how libgutenprint handles it, since they'll be more concerned about how it's represented in the PPDs. The idea of a list of keywords identifying a characteristic of the option echoes very strongly the tags idea of the Common Printing Dialog, and this might be an idea opportunity to add support for OPOptionTags in the PPDs. (Have any steps been taken in that direction yet? I've been a bit tied up elsewhere, and out-of-the-loop recently, unfortunately...) All the best -- Alastair M. Robinson |
|
From: Robert K. <rl...@al...> - 2010-08-28 14:31:02
|
Date: Sat, 28 Aug 2010 09:14:21 +0100 From: "Alastair M. Robinson" <bla...@fa...> Hi :) On 28/08/10 01:18, Robert Krawitz wrote: > The most obvious thing to me is to change the interpretation of > category (const char *). Currently it's intended as a high level, > translated description of how controls should be grouped, but nothing > in Gutenprint uses it and last I checked PhotoPrint (the only other > Gutenprint application that I'm aware of) doesn't appear to either. That's right - PhotoPrint currently makes no use of this. OK. > My thought is to change it to a list of comma-separated keywords, each > of which identifies a characteristic of the variable (they could even > be generalized to keyword=value, where an empty value just implies a > presence). > > What do people think of this? Sounds like a sensible option to me, though if we're talking about a string that client applications have to parse, it'd be nice to have a higher-level helper function that tests for a particular enumerated or #defined category and returns true or false. Then again, if PhotoPrint is about the only direct client app I guess that's not an issue. Point well taken. The vast majority of applications, though, won't actually care much how libgutenprint handles it, since they'll be more concerned about how it's represented in the PPDs. The idea of a list of keywords identifying a characteristic of the option echoes very strongly the tags idea of the Common Printing Dialog, and this might be an idea opportunity to add support for OPOptionTags in the PPDs. (Have any steps been taken in that direction yet? I've been a bit tied up elsewhere, and out-of-the-loop recently, unfortunately...) We've had *OPOptionHints since 5.2.0-beta4. They're keyed off the data type only and don't (at least what we've implemented thus far) care about anything else. Actually, I notice a little oddity here: we have this: if (num_opts > 3) gzprintf(fp, "*OPOptionHints Stp%s: \"dropdown\"\n", lparam->name); else gzprintf(fp, "*OPOptionHints Stp%s: \"radiobuttons\"\n", lparam->name); but I think it would make more sense the other way around (use radio buttons only if there are no more than 3 options, and use dropdowns if there are more). |
|
From: edmund r. <edm...@gm...> - 2010-08-28 15:51:34
|
I'm well out of my depth here. I'd expect a high-level printer driver to offer single-buttoncombined (media/resolution/inking) choices. Edmund On Sat, Aug 28, 2010 at 4:30 PM, Robert Krawitz <rl...@al...> wrote: > Date: Sat, 28 Aug 2010 09:14:21 +0100 > From: "Alastair M. Robinson" <bla...@fa...> > > Hi :) > > On 28/08/10 01:18, Robert Krawitz wrote: > > > The most obvious thing to me is to change the interpretation of > > category (const char *). Currently it's intended as a high level, > > translated description of how controls should be grouped, but nothing > > in Gutenprint uses it and last I checked PhotoPrint (the only other > > Gutenprint application that I'm aware of) doesn't appear to either. > > That's right - PhotoPrint currently makes no use of this. > > OK. > > > My thought is to change it to a list of comma-separated keywords, each > > of which identifies a characteristic of the variable (they could even > > be generalized to keyword=value, where an empty value just implies a > > presence). > > > > What do people think of this? > > Sounds like a sensible option to me, though if we're talking about > a string that client applications have to parse, it'd be nice to > have a higher-level helper function that tests for a particular > enumerated or #defined category and returns true or false. Then > again, if PhotoPrint is about the only direct client app I guess > that's not an issue. > > Point well taken. > > The vast majority of applications, though, won't actually care much > how libgutenprint handles it, since they'll be more concerned about > how it's represented in the PPDs. > > The idea of a list of keywords identifying a characteristic of the > option echoes very strongly the tags idea of the Common Printing Dialog, > and this might be an idea opportunity to add support for OPOptionTags in > the PPDs. > (Have any steps been taken in that direction yet? I've been a bit tied > up elsewhere, and out-of-the-loop recently, unfortunately...) > > We've had *OPOptionHints since 5.2.0-beta4. They're keyed off the > data type only and don't (at least what we've implemented thus far) > care about anything else. > > Actually, I notice a little oddity here: we have this: > > if (num_opts > 3) > gzprintf(fp, "*OPOptionHints Stp%s: \"dropdown\"\n", > lparam->name); > else > gzprintf(fp, "*OPOptionHints Stp%s: \"radiobuttons\"\n", > lparam->name); > > but I think it would make more sense the other way around (use radio > buttons only if there are no more than 3 options, and use dropdowns if > there are more). > |
|
From: Robert K. <rl...@al...> - 2010-08-28 16:53:33
|
Date: Sat, 28 Aug 2010 17:51:26 +0200 From: edmund ronald <edm...@gm...> I'm well out of my depth here. I'd expect a high-level printer driver to offer single-buttoncombined (media/resolution/inking) choices. What would those options look like? |
|
From: edmund r. <edm...@gm...> - 2010-08-28 17:50:59
|
At the moment I'm thinking combined choices like ------------ [RGB Epson Archival Matte /720dpi] [RGB Epson Archival Matte /1440dpi] [RGB Epson Watercolor / 720dpi] ------------ And maybe a density control and an ink-dry time would be the only ink/media features exposed to the naive user. These would be there to allow people to use a different paper which is close to a known type. These are just my thoughts off the top of my head, in practice one should solicit user feedback from the intended target audience. Edmund On Sat, Aug 28, 2010 at 6:53 PM, Robert Krawitz <rl...@al...> wrote: > Date: Sat, 28 Aug 2010 17:51:26 +0200 > From: edmund ronald <edm...@gm...> > > I'm well out of my depth here. > I'd expect a high-level printer driver to offer single-buttoncombined > (media/resolution/inking) choices. > > What would those options look like? > |
|
From: edmund r. <edm...@gm...> - 2010-08-28 17:55:15
|
Accepted industrial practice as I was taught it is that the RIP salesman sells media, comes in, profiles his media, sets up the RIP "magic folders" and then the unit is locked down for production. I'm thinking if this is good enough for the print trade it might be good enough for us. Edmund PS No printer ever wants me to get near his RIP: They don't know how the thing works, they don't want to know, they just want to press "Print" like on a copier and have a print come out.. On Sat, Aug 28, 2010 at 7:50 PM, edmund ronald <edm...@gm...> wrote: > At the moment I'm thinking combined choices like > ------------ > [RGB Epson Archival Matte /720dpi] > [RGB Epson Archival Matte /1440dpi] > [RGB Epson Watercolor / 720dpi] > ------------ > > And maybe a density control and an ink-dry time would be the only > ink/media features exposed to the naive user. These would be there to > allow people to use a different paper which is close to a known type. > These are just my thoughts off the top of my head, in practice one > should solicit user feedback from the intended target audience. > > Edmund > > > On Sat, Aug 28, 2010 at 6:53 PM, Robert Krawitz <rl...@al...> wrote: >> Date: Sat, 28 Aug 2010 17:51:26 +0200 >> From: edmund ronald <edm...@gm...> >> >> I'm well out of my depth here. >> I'd expect a high-level printer driver to offer single-buttoncombined >> (media/resolution/inking) choices. >> >> What would those options look like? >> > |
|
From: Alastair M. R. <bla...@fa...> - 2010-08-28 19:52:52
|
Hi :) On 28/08/10 18:50, edmund ronald wrote: > At the moment I'm thinking combined choices like > ------------ > [RGB Epson Archival Matte /720dpi] > [RGB Epson Archival Matte /1440dpi] > [RGB Epson Watercolor / 720dpi] > ------------ The biggest problem with doing that is that with half a dozen different resolutions and upwards of 20 supported paper types, you quickly run into a combinatorial explosion of options. What I'd love to see is to have a few presets along the lines of the ones you suggested there, but have the ability for an advanced end-user to define new ones. We did kind of sketch out rough plans along those lines once before, but ran into difficulties trying to figure out how to keep client and server in sync, when the printing backend isn't necessarily on the same machine as the end-user application. That's all a bit beyond the scope of the current subject, though - which was how the existing options (which aren't likely to change significantly in a stable release) could be tagged tagged (a) so that applications can tell which options affect colour, and (b) how they can be tagged to allow user interfaces can present them in a sane(r) manner. If we can end up being somewhat more in sync with the vision of the Common Printing Dialog into the bargain, all well and good. All the best -- Alastair M. Robinson |
|
From: Alastair M. R. <bla...@fa...> - 2010-08-28 23:17:41
|
Hi :) On 28/08/10 15:30, Robert Krawitz wrote: > We've had *OPOptionHints since 5.2.0-beta4. They're keyed off the > data type only and don't (at least what we've implemented thus far) > care about anything else. OK cool - so we have widget hints (http://www.linuxfoundation.org/collaborate/workgroups/openprinting/ppdextensions#Widget_Hinting) but as yet no support for tags (http://www.linuxfoundation.org/collaborate/workgroups/openprinting/ppdextensions#Option_Tagging) and the widget hinting is currently done programmatically. Perhaps, then, it's worth considering taking the opportunity to roll all three concepts (widget hinting, option tagging and indication of colour implications) into the category field, so that it reads something like this? OPOptionHints:"slider input" OPOptionTag:"color" OPOptionTag:"resource saving" AffectsColor:"yes" The PPD generator would then have to build a suitable OPOptionTag line for each tag. Is there a suggestion yet for how the list of color-affecting options should be recorded in the PPD? (Note, I think it's important to keep the AffectsColor - or whatever it ends up being called - item separate from any 'color' OPOptionTag; there are parameters that affect colour response that you wouldn't want to appear in a UI when you select the color tag.) Hope these thoughts are helpful, anyway - feel free to ignore if not! All the best -- Alastair M. Robinson |
|
From: Robert K. <rl...@al...> - 2010-08-28 23:37:25
|
Date: Sun, 29 Aug 2010 00:17:27 +0100 From: "Alastair M. Robinson" <bla...@fa...> Hi :) On 28/08/10 15:30, Robert Krawitz wrote: > We've had *OPOptionHints since 5.2.0-beta4. They're keyed off the > data type only and don't (at least what we've implemented thus far) > care about anything else. OK cool - so we have widget hints (http://www.linuxfoundation.org/collaborate/workgroups/openprinting/ppdextensions#Widget_Hinting) but as yet no support for tags (http://www.linuxfoundation.org/collaborate/workgroups/openprinting/ppdextensions#Option_Tagging) and the widget hinting is currently done programmatically. Perhaps, then, it's worth considering taking the opportunity to roll all three concepts (widget hinting, option tagging and indication of colour implications) into the category field, so that it reads something like this? OPOptionHints:"slider input" OPOptionTag:"color" OPOptionTag:"resource saving" AffectsColor:"yes" The PPD generator would then have to build a suitable OPOptionTag line for each tag. Is there a suggestion yet for how the list of color-affecting options should be recorded in the PPD? Kai-Uwe has one suggestion about how to record it (*ColorOption). Another possibility is to not put those options in the PPD file at all (if you want to create PPD files designed for specific combinations with supplied profiles). (Note, I think it's important to keep the AffectsColor - or whatever it ends up being called - item separate from any 'color' OPOptionTag; there are parameters that affect colour response that you wouldn't want to appear in a UI when you select the color tag.) Hope these thoughts are helpful, anyway - feel free to ignore if not! The (repurposed) category field isn't (in my view, at least) intended to be that directly related to the generated PPD file; it should be more general, and PPD file generators (and the foomatic data generator) can use it, as could GUI applications. So you may want to think about how this could best serve PhotoPrint, for example. |
|
From: Alastair M. R. <bla...@fa...> - 2010-08-29 10:14:54
|
Hi :) On 29/08/10 00:37, Robert Krawitz wrote: > Kai-Uwe has one suggestion about how to record it (*ColorOption). OK. One of the big advantages of this idea, by the way, is that there are moves afoot to make it possible to store printer-option metadata in ICC profiles themselves. That means that ultimately, one will be able to select an ICC profile, and have all the critical options set automatically to match that profile, while leaving everything else untouched. > Another possibility is to not put those options in the PPD file at all > (if you want to create PPD files designed for specific combinations > with supplied profiles). Which sounds more like Edmund's suggestion, where the user-facing PPD would effectively only expose predefined option presets, and maybe a few tweaking options. (This is actually possible today, using PhotoPrint and a shell script as a replacement CUPS backend. I never got as far as releasing the glue code for doing this, but it's pretty trivial.) > The (repurposed) category field isn't (in my view, at least) intended > to be that directly related to the generated PPD file; it should be > more general, and PPD file generators (and the foomatic data > generator) can use it, as could GUI applications. Fair enough - so in principle, do you think that (a) it's desirable to add support for OPOptionTags in the PPDs, and that (b) the possible change in interpretation of the category field would be an opportunity we shouldn't miss for doing so? If so, the rest's just a question of syntax. > So you may want to > think about how this could best serve PhotoPrint, for example. As far as PhotoPrint goes, I would love to be able to pop up a message when closing the Print Setup dialog, saying something along the lines of "Warning - you have changed the following options which affect colour output - this will invalidate your ICC profile: Resolution, Composite Gamma, etc..." As for the rest, it'd be nice to put a small icon or two beside each option in the print setup dialog indicating its scope. To do that, I'd need to know at build time what tags I'm likely to encounter, though. All the best -- Alastair M. Robinson |
|
From: Kai-Uwe B. <ku...@gm...> - 2010-08-30 06:08:36
|
Am 29.08.10, 11:14 +0100 schrieb Alastair M. Robinson: > On 29/08/10 00:37, Robert Krawitz wrote: >> Another possibility is to not put those options in the PPD file at all >> (if you want to create PPD files designed for specific combinations >> with supplied profiles). > > Which sounds more like Edmund's suggestion, where the user-facing PPD > would effectively only expose predefined option presets, and maybe a few > tweaking options. (This is actually possible today, using PhotoPrint > and a shell script as a replacement CUPS backend. I never got as far as > releasing the glue code for doing this, but it's pretty trivial.) How are PPD colour options are identified if the options are not in the PPD? Say, two queues with two different ICC profile and different colour related options like paper type. What can a user do to switch the separation profile in the application? Does the app still see the colour options for matching to a custom profile? kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org |
|
From: Robert K. <rl...@al...> - 2010-08-28 20:37:51
|
Date: Sat, 28 Aug 2010 19:50:53 +0200
From: edmund ronald <edm...@gm...>
At the moment I'm thinking combined choices like
------------
[RGB Epson Archival Matte /720dpi]
[RGB Epson Archival Matte /1440dpi]
[RGB Epson Watercolor / 720dpi]
------------
And maybe a density control and an ink-dry time would be the only
ink/media features exposed to the naive user. These would be there to
allow people to use a different paper which is close to a known type.
These are just my thoughts off the top of my head, in practice one
should solicit user feedback from the intended target audience.
That's something we can always do later.
|
|
From: Alastair M. R. <bla...@fa...> - 2010-08-30 09:29:50
|
Hi :) On 30/08/10 07:06, Kai-Uwe Behrmann wrote: > How are PPD colour options are identified if the options are not in the > PPD? Say, two queues with two different ICC profile and different > colour related options like paper type. What can a user do to switch the > separation profile in the application? Does the app still see the colour > options for matching to a custom profile? Well, the way I did it with my experiments was to have a PPD file that contained only one option that looked like this: *OpenUI *PPPreset/PhotoPrint Preset: PickOne *OrderDependency: 10 AnySetup *PPPreset *DefaultPPPreset: R300_Tesco *PPPreset R300_Tesco/R300 Matte: "%%GSPhotoPrintPreset: R300_Tesco_20060126.preset" *PPPreset R300_Glossy/R300 Glossy: "%%GSPhotoPrintPreset: R300_7DayShop_Glossy_20060121.preset" *PPPreset R300_Plain/R300 Plain: "%%GSPhotoPrintPreset: R300_Plain_20060122.preset" *CloseUI: *PPPreset (Wow - it was 4 years ago I was playing with this stuff!) Each of those presets bundled up the printer queue, paper type, colour settings and colour profile - so the end-user could just hit print, send un-colour-managed (i.e. implicitly sRGB) print data and get a decent looking print out of the printer. The low-level printer options are effectively hidden from the application, and replaced with high-level ones. (The down-side is of course the need to have some way of installing new presets and editing existing ones.) If you wanted to use something along those lines but handle colour conversion application-side, or provide a separate option for setting the printer profile, then you could just key that off the preset. Note that I'm not saying it should necessarily be done this way - just mentioning that I know it's possible, since I've had it working in the past! All the best -- Alastair M. Robinson |
|
From: Kai-Uwe B. <ku...@gm...> - 2010-08-30 10:26:36
|
Am 30.08.10, 10:29 +0100 schrieb Alastair M. Robinson: > On 30/08/10 07:06, Kai-Uwe Behrmann wrote: > >> How are PPD colour options are identified if the options are not in the >> PPD? Say, two queues with two different ICC profile and different >> colour related options like paper type. What can a user do to switch the >> separation profile in the application? Does the app still see the colour >> options for matching to a custom profile? > > Well, the way I did it with my experiments was to have a PPD file that > contained only one option that looked like this: > *OpenUI *PPPreset/PhotoPrint Preset: PickOne > *OrderDependency: 10 AnySetup *PPPreset > *DefaultPPPreset: R300_Tesco > *PPPreset R300_Tesco/R300 Matte: "%%GSPhotoPrintPreset: > R300_Tesco_20060126.preset" > *PPPreset R300_Glossy/R300 Glossy: "%%GSPhotoPrintPreset: > R300_7DayShop_Glossy_20060121.preset" > *PPPreset R300_Plain/R300 Plain: "%%GSPhotoPrintPreset: > R300_Plain_20060122.preset" > *CloseUI: *PPPreset > (Wow - it was 4 years ago I was playing with this stuff!) > > Each of those presets bundled up the printer queue, paper type, colour > settings and colour profile - so the end-user could just hit print, send > un-colour-managed (i.e. implicitly sRGB) print data and get a decent looking > print out of the printer. Presets, cupsICCProfile and similiar PPD options or groups are all fine for their purpose. But they only provide a administrator choosen ICC profile. So please do not mix that with user provided ICC profiles. > The low-level printer options are effectively hidden from the application, > and replaced with high-level ones. (The down-side is of course the need to > have some way of installing new presets and editing existing ones.) > If you wanted to use something along those lines but handle colour conversion > application-side, or provide a separate option for setting the printer > profile, then you could just key that off the preset. Agreed, tagging options does not interfere with presets. > Note that I'm not saying it should necessarily be done this way - just > mentioning that I know it's possible, since I've had it working in the past! I understand, it is at least working in that scope. But unfortunedly it does not scale nicely. The ICC proposed meta tag is much more flexible and it can be used to scale very well. Let us compare the preset with the ICC meta tag approach: (For unprepared readers, the ICC meta tag is a standardised way to embedd translateable key/value pairs inside a ICC profile. This can be used for PPD options.) Creation Presets: + relatively simple, can be done by hand following a simple convention + tools are easily created to help with that process - does not scale to any other device class applications want to support Meta data in ICC profiles: + needs special tools to embedd and edit the PPD options + tools are particially availabel + scales well many other device class applications want to support Installation Presets: + more secure workflow + works nice for canned profiles coming with the print driver - needs admin privileges - does not scale to thierd party and custom profiles Meta data in ICC profiles: + more secure workflow + works nice for canned profiles coming with the print driver + needs no admin privileges (other than for global installation) + scales well to thierd party and custom profiles + no special installation program, just copy into profile path Usage Presets: + pretty assignment of ICC profiles to print options - apps have to be updated to make use of Meta data in ICC profiles: + pretty assignment of ICC profiles to print options - apps have to be updated to make use of Internationalisation is possible with both systems. As a application and system developer the ICC meta tag convinces me much more than a solution which puts all logic inside a specialised PPD + ICC profiles package. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org |
|
From: Alastair M. R. <bla...@fa...> - 2010-08-30 12:01:57
|
Hi :) On 30/08/10 11:23, Kai-Uwe Behrmann wrote: > I understand, it is at least working in that scope. But unfortunedly it > does not scale nicely. The ICC proposed meta tag is much more flexible > and it can be used to scale very well. Agreed 100%. > Meta data in ICC profiles: > + needs special tools to embedd and edit the PPD options That one's a "-" in my view - other than that, agreed once again :) > + scales well many other device class applications want to support I'm not 100% sure I understand you there - do you mean, for example, a scanner's ICC profile could hypothetically contain XSane exposure, gamma, contrast settings, in the same way as printer settings are embedded in a printer profile? > As a application and system developer the ICC meta tag convinces me much > more than a solution which puts all logic inside a specialised PPD + ICC > profiles package. Again, agreed. All the best -- Alastair M. Robinson |
|
From: Kai-Uwe B. <ku...@gm...> - 2010-08-30 12:09:09
|
Am 30.08.10, 13:01 +0100 schrieb Alastair M. Robinson: > On 30/08/10 11:23, Kai-Uwe Behrmann wrote: >> Meta data in ICC profiles: >> + needs special tools to embedd and edit the PPD options > > That one's a "-" in my view - other than that, agreed once again :) yes, a typo. >> + scales well many other device class applications want to support > > I'm not 100% sure I understand you there - do you mean, for example, a > scanner's ICC profile could hypothetically contain XSane exposure, gamma, > contrast settings, in the same way as printer settings are embedded in a > printer profile? ... and xorg's key/values, which are the ones I practical started with. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org |
|
From: Hal V. E. <hv...@gm...> - 2010-09-01 18:37:18
|
On Monday, August 30, 2010 05:01:47 am Alastair M. Robinson wrote: > I'm not 100% sure I understand you there - do you mean, for example, a > scanner's ICC profile could hypothetically contain XSane exposure, > gamma, contrast settings, in the same way as printer settings are > embedded in a printer profile? XSane might not be a good example since it always scans in raw mode when color management is enabled (IE. settings like exposure, gamma are not used). But another example where this would apply is to UFRAW where the profile meta data would have information on settings like exposure, gamma and so on. Unlike the printer case where the logic to handle this could (should?) is isolated in the common print dialog input apps like RAW conversion programs and scanning software will need to be made aware of this meta data for this to work. Hal |
|
From: Michael S. <ms...@ap...> - 2010-09-01 15:37:36
|
On Aug 30, 2010, at 3:23 AM, Kai-Uwe Behrmann wrote: > ... > Meta data in ICC profiles: > + needs special tools to embedd and edit the PPD options > + tools are particially availabel > + scales well many other device class applications want to support - break as soon as driver options are changed > Installation > Presets: > + more secure workflow > + works nice for canned profiles coming with the print driver > - needs admin privileges > - does not scale to thierd party and custom profiles > > Meta data in ICC profiles: > + more secure workflow How? > + works nice for canned profiles coming with the print driver > + needs no admin privileges (other than for global installation) - needs admin privileges > + scales well to thierd party and custom profiles > + no special installation program, just copy into profile path - tied to specific driver version(s) > Usage > Presets: > + pretty assignment of ICC profiles to print options > - apps have to be updated to make use of No, just the toolkits and/or common print dialog need to be updated. > Meta data in ICC profiles: > + pretty assignment of ICC profiles to print options > - apps have to be updated to make use of Again, this is a toolkit issue; most applications should not be doing their own print dialogs... > > > > Internationalisation is possible with both systems. > As a application and system developer the ICC meta tag convinces me much > more than a solution which puts all logic inside a specialised PPD + ICC > profiles package. > > kind regards > Kai-Uwe Behrmann > -- > developing for colour management > www.behrmann.name + www.oyranos.org > > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Gimp-print-devel mailing list > Gim...@li... > https://lists.sourceforge.net/lists/listinfo/gimp-print-devel ________________________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair |
|
From: Kai-Uwe B. <ku...@gm...> - 2010-09-01 16:02:04
|
Am 01.09.10, 08:37 -0700 schrieb Michael Sweet: > On Aug 30, 2010, at 3:23 AM, Kai-Uwe Behrmann wrote: >> ... >> Meta data in ICC profiles: >> + needs special tools to embedd and edit the PPD options >> + tools are particially availabel >> + scales well many other device class applications want to support > > - break as soon as driver options are changed With a new driver the old ICC profile is not valid anyway. So thats intentional and correct. A way to display the non matching ICC profiles on bottom of a profile selector list would be useful. >> Installation >> Presets: >> + more secure workflow >> + works nice for canned profiles coming with the print driver >> - needs admin privileges >> - does not scale to thierd party and custom profiles >> >> Meta data in ICC profiles: >> + more secure workflow > > How? As the PPD options and a properly prepared ICC profile can be checked to match or not to. To remember, osX has a similiar approach since years with storing monitor IDs inside a special tag in display ICC profiles and check if the profile matches the current device. Matching ICC profiles are placed on top of the ICC profile selector for that device. Non matching can even be discarted on osX SL. The new ICC meta tag design is just a generalisation of that approach. >> + works nice for canned profiles coming with the print driver >> + needs no admin privileges (other than for global installation) > > - needs admin privileges Users can of course install ICC profiles into their private ICC profile paths. Say $HOME/.local/share/color/icc needs not admin rights. >> + scales well to thierd party and custom profiles >> + no special installation program, just copy into profile path > > - tied to specific driver version(s) Again, thats intentional. Even canned profiles must change if the driver changes its colour rendering. Its like a ABI break to speak in developers tongue. >> Usage >> Presets: >> + pretty assignment of ICC profiles to print options >> - apps have to be updated to make use of > > No, just the toolkits and/or common print dialog need to be updated. > >> Meta data in ICC profiles: >> + pretty assignment of ICC profiles to print options >> - apps have to be updated to make use of > > Again, this is a toolkit issue; most applications should not be doing their own print dialogs... Thats merely a detail outside of the proposal. >> Internationalisation is possible with both systems. >> As a application and system developer the ICC meta tag convinces me much >> more than a solution which puts all logic inside a specialised PPD + ICC >> profiles package. >> >> kind regards >> Kai-Uwe Behrmann >> -- >> developing for colour management >> www.behrmann.name + www.oyranos.org >> >> >> ------------------------------------------------------------------------------ >> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program >> Be part of this innovative community and reach millions of netbook users >> worldwide. Take advantage of special opportunities to increase revenue and >> speed time-to-market. Join now, and jumpstart your future. >> http://p.sf.net/sfu/intel-atom-d2d >> _______________________________________________ >> Gimp-print-devel mailing list >> Gim...@li... >> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel > > ________________________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > > > Mit freundlichen Grüßen Kai-Uwe Behrmann -- Programmierung für Farbmanagement www.behrmann.name + www.oyranos.org |
|
From: Alastair M. R. <bla...@fa...> - 2010-09-01 19:25:58
|
Hi :) On 01/09/10 16:59, Kai-Uwe Behrmann wrote: >> - break as soon as driver options are changed > With a new driver the old ICC profile is not valid anyway. So thats > intentional and correct. A way to display the non matching ICC > profiles on bottom of a profile selector list would be useful. The breakage as soon as driver options are changed is also no problem at all when the metadata in the ICC profile contains sufficient data to inform the user *why* a particular profile is no longer valid, and how the situation can be resolved. That's the biggest issue with ICC profiles currently - that they're relatively inscrutable and when something drifts it can be very hard to pin down the cause. (Different batch of ink? Paper? Did I accidentally change a driver setting? Or did I install a new version of the driver?) > Again, thats intentional. Even canned profiles must change if the driver > changes its colour rendering. Its like a ABI break to speak in > developers tongue. At the risk of going off on another tangent, what we currently lack is any way of signalling whether or not a new version of the driver will invalidate profiles. Can we include some kind of serial number in the PPD that will be bumped when, and only when, some change that affects colour response is made? (In PhotoPrint I use an MD5 hash of a "standard" print job to detect output changes, but that's not a viable solution for a higher-level application that never sees the raw printer data. It's also no help whatsoever in pinpointing which option change has caused the discrepancy.) All the best -- Alastair M. Robinson |
|
From: Robert K. <rl...@al...> - 2010-09-02 01:03:16
|
Date: Wed, 01 Sep 2010 20:25:46 +0100
From: "Alastair M. Robinson" <bla...@fa...>
On 01/09/10 16:59, Kai-Uwe Behrmann wrote:
>> - break as soon as driver options are changed
> With a new driver the old ICC profile is not valid anyway. So thats
> intentional and correct. A way to display the non matching ICC
> profiles on bottom of a profile selector list would be useful.
The breakage as soon as driver options are changed is also no
problem at all when the metadata in the ICC profile contains
sufficient data to inform the user *why* a particular profile is no
longer valid, and how the situation can be resolved. That's the
biggest issue with ICC profiles currently - that they're relatively
inscrutable and when something drifts it can be very hard to pin
down the cause. (Different batch of ink? Paper? Did I
accidentally change a driver setting? Or did I install a new
version of the driver?)
Neither is it a problem (as far as driver options, at any rate) if the
PPD files are locked down so that any options that can affect color
can't be changed by the user.
> Again, thats intentional. Even canned profiles must change if the driver
> changes its colour rendering. Its like a ABI break to speak in
> developers tongue.
At the risk of going off on another tangent, what we currently lack
is any way of signalling whether or not a new version of the driver
will invalidate profiles. Can we include some kind of serial
number in the PPD that will be bumped when, and only when, some
change that affects colour response is made?
Any suggestions about how to automate it, so that the coder doesn't
have to remember to change something manually?
(In PhotoPrint I use an MD5 hash of a "standard" print job to
detect output changes, but that's not a viable solution for a
higher-level application that never sees the raw printer data.
It's also no help whatsoever in pinpointing which option change has
caused the discrepancy.)
|
|
From: Kai-Uwe B. <ku...@gm...> - 2010-09-02 05:46:44
|
Am 01.09.10, 21:03 -0400 schrieb Robert Krawitz: > Date: Wed, 01 Sep 2010 20:25:46 +0100 > From: "Alastair M. Robinson" <bla...@fa...> > At the risk of going off on another tangent, what we currently lack > is any way of signalling whether or not a new version of the driver > will invalidate profiles. Can we include some kind of serial > number in the PPD that will be bumped when, and only when, some > change that affects colour response is made? > > Any suggestions about how to automate it, so that the coder doesn't > have to remember to change something manually? Maybe the Gutenprints unprint command of a reference version can be applied in a test scenario to detect any changes. E.g. 5.0 is considerd a reference and all upcomming versions are compared to unprint-5.0 . Once it breaks eigther bump to Gutenprint 6.0 then thats reflected in the PPD. Or bump a *GutenprintColorAPI variable inside PPD? Not shure if it makes sense. Its just an idea. > (In PhotoPrint I use an MD5 hash of a "standard" print job to > detect output changes, but that's not a viable solution for a > higher-level application that never sees the raw printer data. > It's also no help whatsoever in pinpointing which option change has > caused the discrepancy.) kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org |
|
From: Alastair M. R. <bla...@fa...> - 2010-09-02 07:56:57
|
Hi :) On 02/09/10 06:43, Kai-Uwe Behrmann wrote: > Maybe the Gutenprints unprint command of a reference version can be > applied in a test scenario to detect any changes. E.g. 5.0 is considerd > a reference and all upcomming versions are compared to unprint-5.0 . > Once it breaks eigther bump to Gutenprint 6.0 then thats reflected in > the PPD. Or bump a *GutenprintColorAPI variable inside PPD? The only problem with that is that once it changes, your reference has to change for future runs. Since you don't want to bump every printer's colour version just because some other printer's response has changed, you'd then have to keep track of which level each printer's reached! It might make more sense to store a value digested from current response - but it would have to be derived from a few rows printed at each resolution the printer supports, because for variable-drop-size inkjets it's entirely possible for the colour response to remain the same at one resolution but change at another. That might end up being quite expensive to compute. All the best -- Alastair M. Robinson |
Thanks for helping keep SourceForge clean.
X