Re: [CREATE] swatches
On Wed, Mar 6, 2013 at 3:41 PM, Olivier Berten wrote: I indeed stopped working at it as it seemed nobody was interested in it (on the developers' side at least).. On the developers' side -- maybe. As for users, SB would probably get more attention if it had features similar to those of Gpick - color harmony tools etc. In general, I feel that SB is underpromoted (which is my fault too). Alexandre Prokoudine http://libregraphicsworld.org ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] swatches
Hi Olivier, I indeed stopped working at it as it seemed nobody was interested in it (on the developers' side at least)... From the perspective of Scribus, SwatchBooker is an indespensable tool. We have dedicated a separate page in our online docs to your work, as well as mentioned it several times in different contexts in the docs and our Wiki. As far as development is concerned, I guess our guru didn't look further into it because the licences are incompatible (GPL 2 vs. GPL 3). I might add that our OS/2/eCS and Haiku maintainers are planning to port the required libraries to their respective platforms, so SB can be run on these as well. I'd be very sad if SB must be considered dead, as it can really be a life saver. My 2 ct. Christoph ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] swatches
On Thu, Jan 24, 2013 at 11:56 PM, Craig Bradney wrote: Hi Sounds like a good idea. I guess my question is how fast is the format developing? That is, per the website: Limitations Colors only. Support for gradients, color schemes, patterns, textures is expected for version 0.8 Wondering if it makes sense to start if 1.0 is due soon. Thoughts? As far as I can tell, Olivier isn't currently working on this project. Alexandre Prokoudine http://libregraphicsworld.org ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] swatches
On 22/01/13 5:18 PM, Alexandre Prokoudine wrote: Hi, It looks like the topic of swatches gradually faded into oblivion. Personally, I think that Olivier came up with a very sane file format in his SwatchBooker project: - any color model + mapping to an embedded ICC profile - flat colors and gradients - spot color are possible - i18n-ized names That pretty much covers all we need except probably textures, but the file format is extensible enough. So why are we still doing a fallback to GIMP's GPL? Could we please move on? We've managed to do it so well with OpenRaster. Alexandre Prokoudine Hi Sounds like a good idea. I guess my question is how fast is the format developing? That is, per the website: Limitations Colors only. Support for gradients, color schemes, patterns, textures is expected for version 0.8 Wondering if it makes sense to start if 1.0 is due soon. Thoughts? Craig ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
[CREATE] swatches
Hi folks, Not sure if Olivier Berten is attending LGM, but maybe you could discuss unified swatches file format? Personally, I'd like to see SwatchBooker's file format being used as one (probably extended to feature bitmap materials), so that we could promote best practices of creating swatches. But that's just me :) Alexandre Prokoudine http://libregraphicsworld.org ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] swatches
Hi! I'm not attending this year... FYI SwatchBooker's developement version (stalled for a while now) reads and writes bitmap patterns. It also reads gradients from gimp and photoshop... but this is where it stopped so no writing yet... Olivier Le 02/05/12 09:38, Alexandre Prokoudine a écrit : Hi folks, Not sure if Olivier Berten is attending LGM, but maybe you could discuss unified swatches file format? Personally, I'd like to see SwatchBooker's file format being used as one (probably extended to feature bitmap materials), so that we could promote best practices of creating swatches. But that's just me :) Alexandre Prokoudine http://libregraphicsworld.org ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] Swatches color file format
Did this get resolved for you Stephen? Jon On Fri, 2008-08-29 at 21:48 +1000, Stephen Griffiths wrote: I would like to know how close the specification is to completion. one specific interest is the sRGB tag, I would like to know if it will be removed in favor of something like RGB space= r=n.n b=n.n g=n.n / where the space tag if just left as empty. ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create -- Jon Phillips San Francisco, CA + Guangzhou + Beijing GLOBAL +1.415.830.3884 CHINA +86.1.360.282.8624 [EMAIL PROTECTED] http://www.rejon.org IM/skype: kidproto Jabber: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] Swatches color file format
Jon Phillips wrote: Did this get resolved for you Stephen? Jon On Fri, 2008-08-29 at 21:48 +1000, Stephen Griffiths wrote: ... Yes, Thankyou. cheers, Stephen. ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] Swatches color file format
On Saturday 30 August 2008, you wrote: one specific interest is the sRGB tag, I would like to know if it will be removed in favor of something like RGB space= r=n.n b=n.n g=n.n / where the space tag if just left as empty. Why would this be better ? It came up in misc. discussions. One factor is that it makes intent explicit, instead of possibly an accidental oversight. Another thing is it makes validation and checks simpler and able to catch more. That's why I believe the space attribute was set as required, if it was wanted to be sometimes empty then the attribute would just have been marked as optional. (empty is bad, like empty alt attributes on HTML images) Actually I was interested in knowing why removing sRGB in favor of RGB would be a good idea :) But now that I think of it, I remember that we are considering to make the sRGB tag mandatory, to be certain that the palette can be used everywhere, even in application that don't have color management, or that don't support the color space of the original color. So that's an other reason to have sRGB as a seperate tag. -- Cyrille Berger ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] Swatches color file format
On Aug 29, 2008, at 1:48 PM, Stephen Griffiths wrote: I would like to know how close the specification is to completion. one specific interest is the sRGB tag, I would like to know if it will be removed in favor of something like RGB space= r=n.n b=n.n g=n.n / where the space tag if just left as empty. If possible, it's best to have sRGB explicitly so. Then there is clear intent. space, when allowed, should never be blank. Note that I say should ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] Swatches color file format
Hello, On Friday 29 August 2008, Stephen Griffiths wrote: I would like to know how close the specification is to completion. Well I think the basics are in place. Now, there are some things lacking (spot colors), and, it's just waiting for someone who knows about those issues to work on it. one specific interest is the sRGB tag, I would like to know if it will be removed in favor of something like RGB space= r=n.n b=n.n g=n.n / where the space tag if just left as empty. Why would this be better ? -- Cyrille Berger ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] Swatches color file format
On Aug 29, 2008, at 5:30 PM, Cyrille Berger wrote: one specific interest is the sRGB tag, I would like to know if it will be removed in favor of something like RGB space= r=n.n b=n.n g=n.n / where the space tag if just left as empty. Why would this be better ? It came up in misc. discussions. One factor is that it makes intent explicit, instead of possibly an accidental oversight. Another thing is it makes validation and checks simpler and able to catch more. That's why I believe the space attribute was set as required, if it was wanted to be sometimes empty then the attribute would just have been marked as optional. (empty is bad, like empty alt attributes on HTML images)___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
[CREATE] Swatches...
As I'm currently trying to write a swatch editor/viewer/convertor software in PyQt, I'm going on with the reflexion about what's a swatch and other questions about it: http://create.freedesktop.org/wiki/index.php/Swatches Any comments and contributions are welcome... Olivier ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] Swatches...
LO Olivier, this is very interesting to see this match discussion coming again after a so long time of inactivity. In fact the main action of the create list would have been this one : find an agreement of a standard file format, and location on file system. This is required by graphic jobs because swatches are often shared between several documents, made with several application. The need of consistency in there, and not only the need of productivity. But : Inkscape feel difficulties, because SVG don't make a big deal of swatch and that defs would only allow gradient swatch. I've told about it with Joncruz quickly in Montreal last years, and this couls be use to define flat colr, but not very smart. Inkscape and Scribus are not CMYK compliant (which can be seen though the .gpl format) so that colours exported from both apps would not be consistent within scribus without the addition of an extra attribute for this. Scribus spec for this sounds interesting to me. In this way, the convertor, wouldn't make sense, but since, as far as i know, nothing has been decided on this, there's still a place for it. And yes, we would finally one day may be think of a kind of a spot color swatch in which special color could be defined, including textures. This could also be the birth of an OpenSwatch project. I don't really know how much to help you, may be because i don't much about your plans, but i'm really to follow as much as i can. Cedric ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] Swatches: Proposition J
Am 23.06.08, 17:53 -0400 schrieb MenTaLguY: On Mon, 2008-06-23 at 19:59 +0200, Cyrille Berger wrote: Ok, now that I have cooled down a little bit (I hope I haven't offend anyone, but please, don't move spec around without a discution), I can be a little bit rational, and make a few comments. I think your posted response was perfectly reasonable. The main interest is that it allows to define a color in a non-RGB colorspace, like you allow too, but your proposal doesn't allow a fallback for application that can only read and use RGB, that would mean they simply can't use the color. The lack of an sRGB fallback built-in is a major problem with my approach. My thinking at the time I wrote the original spec was that fallback color specifications could be provided as an extension, but I did not pursue that further once I realized that the CREATE swatches work had proceeded and I needed to synchronize with it rather than continue off on my own. However, if a color is simultaneously specified in several different color spaces, those specifications are going to conflict since the conversion between color spaces is dependent on factors like rendering intent which are not specified at all in the current form of Proposition H. There does need to be a way to specify which of the several color specifications is (are?) authoritative and which are derived. In the case of my format, the authoritative specification would be the color element, and any derived specifications would be children of it. I think the simplest way to address this in the adopted CREATE swatch format, would be to designate the first specification for a swatch as authoritative, and the remainder as derived. Then there is color vs rgb for the tag name. Well, originally, we choosed the second form for the validation purpose, after what Liam said about validation in the OpenRaster thread last week, it seems it doesn't matter much anymore. On the other hand, for me it would suck to have to go through the code in krita to change that (and I don't know if there are other who have allready implemented the draft and would be unhappy about the change). I'm not really concerned with tag or attribute names: they are largely cosmetic, and changing them at this point would be needless trouble for you and others. The only thing your proposal have, and that the current draft doesn't have is spot color, but it's not because I am against, or anyone else, it's just that I don't know what would be the requirements for defining spot colors, so I prefer to leave that to other. Spot colors were actually the motivating reason for me to design the format. But having somewhat caught up with the discussion I am not as satisfied with my solution as I had been. I'd say a wide gamut reference, like CIE*Lab or CIE*XYZ, is one good thing for spots. Out of my head, a name would be the other part. Setting spot colors aside for the moment, because I need to think about them more, there are actually several non-cosmetic differences that I'm concerned with: 1. The ability to embed an ICC profile in the swatch file itself (as base-64 encoded data), rather than requiring the user to distribute it as an additional sidecar file. Unless implementations provide a convenient way to bundle the profile with the swatches, I do not think the color management features of the swatch format will get used. 2. Allowance in the schema for including annotations using attributes and elements from foreign namespaces, at least in specific places (my proposal is perhaps overly generous in this regard). If the schema permitted extensions, it would be possible to include foreign annotations in defined places, knowing that all conformant implementations which did not understand them would be guaranteed to safely ignore them. This would reduce the need for the main specification to support features like spot colors. But it can become as well a burden to must embedd arbitrary large, practical 3kB - 3MB, ICC profiles. My go would be to have one references, ideally one of the ICC deployed PCS', and one or more additional colour spaces to allow for native colour descriptions without an absolute need for conversions. 3. By requiring dependencies (e.g. color spaces) to appear before their dependents (e.g. colors), I eliminated the need for forward references, which would otherwise have increased implementation complexity and precluded pure streaming approaches to parsing. In my experience, forward references are rarely implemented properly by first-generation third party implementations of a format. In the case of SVG, it was something we had to spend quite a bit of time straightening out when we inherited the Sodipodi codebase, and I believe forward references have been an issue for librsvg in the past as well. The added complexity of forward references
Re: [CREATE] Swatches: Proposition J
On Tue, 2008-06-24 at 09:37 +0200, Kai-Uwe Behrmann wrote: Spot colors were actually the motivating reason for me to design the format. But having somewhat caught up with the discussion I am not as satisfied with my solution as I had been. I'd say a wide gamut reference, like CIE*Lab or CIE*XYZ, is one good thing for spots. Out of my head, a name would be the other part. The most important thing is simply the ability to say this is a spot color, so that an application knows to put the color on its own separate plate with the given name. The color specification which comes along with a spot color is actually not that important -- it may be arbitrary and it is ignored in the final print workflow (the print operator only looks at the name on the separated plate). Not all spot colors are even really colors -- consider their use in specifying varnish areas for example. When possible and appropriate, it may also be desirable to also specify an exact calibrated color for a spot color, to improve preview quality, but having thought about it for a bit I think that is really an orthogonal issue to spot colors. But it can become as well a burden to must embedd arbitrary large, practical 3kB - 3MB, ICC profiles. My go would be to have one references, ideally one of the ICC deployed PCS', and one or more additional colour spaces to allow for native colour descriptions without an absolute need for conversions. Using one of the standard ICC PCSs would be adequate. The most important thing is that, if you give someone a swatch file with calibrated colors, you shouldn't have to do anything additional for them to get the calibrated colors. Using xlink:href to arbitrary ICC profiles is an extremely poor solution; aside from the need to distribute the profiles separately, it requires that the ICC profiles be placed in the same relative or absolute path on the users' machine that they were on the swatch creators'. This is the same reason that most standards like PNG, TIFF, etc. only support direct embedding of ICC profiles, despite the fact that profiles can get rather large. So practically, making the rendering intent optional and defaulting to zero, plus some warning and a small explanation why, like the above, would be good to have associated to a rendering intent part in the draft. I think that is reasonable. Can Cmyk channels go from 0...1 or 0...100? The value indicating full saturation varies between file formats (and sometimes even within the same one). There is no official range for CMYK or most any other color model. -mental signature.asc Description: This is a digitally signed message part ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] Swatches: Proposition J
On Monday 23 June 2008, you wrote: On Mon, 2008-06-23 at 19:59 +0200, Cyrille Berger wrote: Ok, now that I have cooled down a little bit (I hope I haven't offend anyone, but please, don't move spec around without a discution), I can be a little bit rational, and make a few comments. I think your posted response was perfectly reasonable. The main interest is that it allows to define a color in a non-RGB colorspace, like you allow too, but your proposal doesn't allow a fallback for application that can only read and use RGB, that would mean they simply can't use the color. The lack of an sRGB fallback built-in is a major problem with my approach. My thinking at the time I wrote the original spec was that fallback color specifications could be provided as an extension, but I did not pursue that further once I realized that the CREATE swatches work had proceeded and I needed to synchronize with it rather than continue off on my own. However, if a color is simultaneously specified in several different color spaces, those specifications are going to conflict since the conversion between color spaces is dependent on factors like rendering intent which are not specified at all in the current form of Proposition H. There does need to be a way to specify which of the several color specifications is (are?) authoritative and which are derived. In the case of my format, the authoritative specification would be the color element, and any derived specifications would be children of it. I think the simplest way to address this in the adopted CREATE swatch format, would be to designate the first specification for a swatch as authoritative, and the remainder as derived. Yes that would be a good solution. I also wonder if we shouldn't impose sRGB to be defined. I thought it was the case, but rereading the space, it appears it is optional. 1. The ability to embed an ICC profile in the swatch file itself (as base-64 encoded data), rather than requiring the user to distribute it as an additional sidecar file. Unless implementations provide a convenient way to bundle the profile with the swatches, I do not think the color management features of the swatch format will get used. I must say for that the same reason as Kai-Uwe, I don't like the idea of embedding binary blobs into XML. There are a few ideas about this: * Jon Cruz's idea of a more general swatch format (for gradients...). That could be used, in the future, for transporting a color swatch with its icc profiles * url for downloading (rights and security issues ?) 2. Allowance in the schema for including annotations using attributes and elements from foreign namespaces, at least in specific places (my proposal is perhaps overly generous in this regard). If the schema permitted extensions, it would be possible to include foreign annotations in defined places, knowing that all conformant implementations which did not understand them would be guaranteed to safely ignore them. This would reduce the need for the main specification to support features like spot colors. Yes definitively. 3. By requiring dependencies (e.g. color spaces) to appear before their dependents (e.g. colors), I eliminated the need for forward references, which would otherwise have increased implementation complexity and precluded pure streaming approaches to parsing. In my experience, forward references are rarely implemented properly by first-generation third party implementations of a format. In the case of SVG, it was something we had to spend quite a bit of time straightening out when we inherited the Sodipodi codebase, and I believe forward references have been an issue for librsvg in the past as well. The added complexity of forward references is justified for SVG, but I am less sure that that is true of swatch files. Yes I agree. It's also needed for type of colorspaces, in Krita, we have some color spaces, that are not yet used (and might never be) in other applications, it wouldn't make sense to have them in the spec (until other applications are interested). And, HDR support could also be an extension. 4. If we specify a color in a color space with a specific ICC profile, we also need to know what rendering intent to use when converting the color to other color profiles/models. In many cases this is going to depend on the use of the color. Relative colorimetric is probably the most reasonable default, but for certain specific colors other rendering intents make more sense (e.g. absolute colorimetric for spot colors in some color matching system), and I think it needs to be possible to indicate this in the swatch file. Shouldn't it be the choice of the user ? Even if, I guess, it could be usefull in case of multiple color representation, to specify the rendering intents that was used to generate that specific color. -- Cyrille Berger
Re: [CREATE] Swatches: Proposition J
Hi, I don't know who edited the wiki and I really want to know why the draft was removed and move the content of the draft to the list of propositions ? I really think that kind of changes need to be discussed on the list (that's why I don't like free-for-all wiki for hosting the content of the spec in the first place :/) That said, I am not against adjustement to the spec, since it's still a draft, but I would be really annoy by big adjustment, since we had an agreed over most of its content, and that the biggest part is implemented in krita. -- Cyrille Berger ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] Swatches: Proposition J
Hi, Ok, now that I have cooled down a little bit (I hope I haven't offend anyone, but please, don't move spec around without a discution), I can be a little bit rational, and make a few comments. The key difference between your proposition and the draft is color name=Blue cs=my_printer c=1 0.25 0 0 / vs rgb space=prof01 r=1 g=0.25 b=0/ I note a second difference, the draft allows to set the value in a different color space for the same colors, while I don't see it as possible in your proposal. The main interest is that it allows to define a color in a non-RGB colorspace, like you allow too, but your proposal doesn't allow a fallback for application that can only read and use RGB, that would mean they simply can't use the color. Then there is ' c=1 0.25 0 0 ' against ' r=1 g=0.25 b=0 ' . I must say I prefer the second form, I agree that spliting a string containing numbers separated from spaces is easy, but why do the job twice, once in the XML parser and a second time while decoding the color ? Besides, with c =1 0.25 0 0 which is red ? the first one, or the third one ? While with r=1 g =0.25 b =1, you don't ask the question, you just know. Then there is color vs rgb for the tag name. Well, originally, we choosed the second form for the validation purpose, after what Liam said about validation in the OpenRaster thread last week, it seems it doesn't matter much anymore. On the other hand, for me it would suck to have to go through the code in krita to change that (and I don't know if there are other who have allready implemented the draft and would be unhappy about the change). The only thing your proposal have, and that the current draft doesn't have is spot color, but it's not because I am against, or anyone else, it's just that I don't know what would be the requirements for defining spot colors, so I prefer to leave that to other. -- Cyrille Berger ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] Swatches: Proposition J
Well, we could lock the spec at versioned intervals and the main page when we want. Agree? Jon On Mon, 2008-06-23 at 19:27 +0200, Cyrille Berger wrote: Hi, I don't know who edited the wiki and I really want to know why the draft was removed and move the content of the draft to the list of propositions ? I really think that kind of changes need to be discussed on the list (that's why I don't like free-for-all wiki for hosting the content of the spec in the first place :/) That said, I am not against adjustement to the spec, since it's still a draft, but I would be really annoy by big adjustment, since we had an agreed over most of its content, and that the biggest part is implemented in krita. -- Jon Phillips San Francisco, CA + Guangzhou + Beijing GLOBAL +1.415.830.3884 CHINA +86.1.360.282.8624 [EMAIL PROTECTED] http://www.rejon.org IM/skype: kidproto Jabber: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] Swatches: Proposition J
On Mon, 2008-06-23 at 19:27 +0200, Cyrille Berger wrote: I don't know who edited the wiki and I really want to know why the draft was removed and move the content of the draft to the list of propositions ? I really think that kind of changes need to be discussed on the list (that's why I don't like free-for-all wiki for hosting the content of the spec in the first place :/) That was my fault, I'm afraid. I fell out of the process early on, and was trying to catch up the past few days all at once. I didn't realize there was a separate draft phase before introducing a proposition for discussion. That said, I am not against adjustement to the spec, since it's still a draft, but I would be really annoy by big adjustment, since we had an agreed over most of its content, and that the biggest part is implemented in krita. Yes. I do not think it would be appropriate to make major backwards-incompatible adjustments to Proposition H at this point, simply for that reason. -mental signature.asc Description: This is a digitally signed message part ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] Swatches: Proposition J
On Mon, 2008-06-23 at 19:59 +0200, Cyrille Berger wrote: Ok, now that I have cooled down a little bit (I hope I haven't offend anyone, but please, don't move spec around without a discution), I can be a little bit rational, and make a few comments. I think your posted response was perfectly reasonable. The main interest is that it allows to define a color in a non-RGB colorspace, like you allow too, but your proposal doesn't allow a fallback for application that can only read and use RGB, that would mean they simply can't use the color. The lack of an sRGB fallback built-in is a major problem with my approach. My thinking at the time I wrote the original spec was that fallback color specifications could be provided as an extension, but I did not pursue that further once I realized that the CREATE swatches work had proceeded and I needed to synchronize with it rather than continue off on my own. However, if a color is simultaneously specified in several different color spaces, those specifications are going to conflict since the conversion between color spaces is dependent on factors like rendering intent which are not specified at all in the current form of Proposition H. There does need to be a way to specify which of the several color specifications is (are?) authoritative and which are derived. In the case of my format, the authoritative specification would be the color element, and any derived specifications would be children of it. I think the simplest way to address this in the adopted CREATE swatch format, would be to designate the first specification for a swatch as authoritative, and the remainder as derived. Then there is color vs rgb for the tag name. Well, originally, we choosed the second form for the validation purpose, after what Liam said about validation in the OpenRaster thread last week, it seems it doesn't matter much anymore. On the other hand, for me it would suck to have to go through the code in krita to change that (and I don't know if there are other who have allready implemented the draft and would be unhappy about the change). I'm not really concerned with tag or attribute names: they are largely cosmetic, and changing them at this point would be needless trouble for you and others. The only thing your proposal have, and that the current draft doesn't have is spot color, but it's not because I am against, or anyone else, it's just that I don't know what would be the requirements for defining spot colors, so I prefer to leave that to other. Spot colors were actually the motivating reason for me to design the format. But having somewhat caught up with the discussion I am not as satisfied with my solution as I had been. Setting spot colors aside for the moment, because I need to think about them more, there are actually several non-cosmetic differences that I'm concerned with: 1. The ability to embed an ICC profile in the swatch file itself (as base-64 encoded data), rather than requiring the user to distribute it as an additional sidecar file. Unless implementations provide a convenient way to bundle the profile with the swatches, I do not think the color management features of the swatch format will get used. 2. Allowance in the schema for including annotations using attributes and elements from foreign namespaces, at least in specific places (my proposal is perhaps overly generous in this regard). If the schema permitted extensions, it would be possible to include foreign annotations in defined places, knowing that all conformant implementations which did not understand them would be guaranteed to safely ignore them. This would reduce the need for the main specification to support features like spot colors. 3. By requiring dependencies (e.g. color spaces) to appear before their dependents (e.g. colors), I eliminated the need for forward references, which would otherwise have increased implementation complexity and precluded pure streaming approaches to parsing. In my experience, forward references are rarely implemented properly by first-generation third party implementations of a format. In the case of SVG, it was something we had to spend quite a bit of time straightening out when we inherited the Sodipodi codebase, and I believe forward references have been an issue for librsvg in the past as well. The added complexity of forward references is justified for SVG, but I am less sure that that is true of swatch files. 4. If we specify a color in a color space with a specific ICC profile, we also need to know what rendering intent to use when converting the color to other color profiles/models. In many cases this is going to depend on the use of the color. Relative colorimetric is probably the most reasonable default, but for certain specific colors other rendering intents make more sense (e.g. absolute colorimetric for spot colors in some color matching system), and I think it needs to be possible to indicate
Re: [CREATE] Swatches: Proposition J
On Monday 23 June 2008, you wrote: Well, we could lock the spec at versioned intervals and the main page when we want. Agree? Or just make clear that changes to main page and spec are to be discussed on list before. It seems it was mostly a misunderstanding. -- Cyrille Berger ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
Re: [CREATE] Swatches: Proposition J
On Monday 23 June 2008, you wrote: On Mon, 2008-06-23 at 19:27 +0200, Cyrille Berger wrote: I don't know who edited the wiki and I really want to know why the draft was removed and move the content of the draft to the list of propositions ? I really think that kind of changes need to be discussed on the list (that's why I don't like free-for-all wiki for hosting the content of the spec in the first place :/) That was my fault, I'm afraid. I fell out of the process early on, and was trying to catch up the past few days all at once. I didn't realize there was a separate draft phase before introducing a proposition for discussion. It's more the other way around ;p The draft was made after the propositions were debated on the list. That said, there is room for improvements on the draft, there are two major open issues (I think, or is anyone thinking of something else ?) : [1] spot colors [2] metadata For [1] I don't know how to solve it. As for [2], I would like a more general discution about it, and have an uniform solution for all create spec (color swatch, gradient swatch, ... and OpenRaster), if I find time to launch such a discution this week, I will try to do it. -- Cyrille Berger ___ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
