[scribus] What's the future of "Display only used colors"?

[a.l.e]

salut louis,

>>> just try to insert that image
>>>
>>> http://www.openclipart.org/people/axcesar/axcesar_Rosa.svg
>>>
>>> and tell me if you're interested in seeing all those FromSVG#062a00 to
>>>       
>> show
>>     
>>> up in your color list.
>>>       
>
> How I look at this is if you have imported that image, you need those
> colors. I am not sure that filtering them out will be the way to go. We need
> an extra step in between or maybe this is what you had in mind when you say
> "filter them out"?

yes,  those colors are needed to print and display the image.
but if i import 5 roses in 5 different colors, the palette will be 
polluted by dozens of colors which -- on the one side -- can't be 
removed but -- on the other side -- i will never want to use in my 
document outside of that imported figure (in some case i will use one of 
those colors).

what i want is an option not to see them, if i wish so.


yesterday, i had a few discussions about this feature request and i 
think that the way to go is to flag the colors, when they are 
automatically created.

colors which have that flag can be hidden in the same way we currently 
hide unused colors.


as soon as you apply a color to a shape or frame in the document the 
flag is removed from that single color.


> One sure thing is if there are more than a few colors,
> those colors will need to be either set to process colors or to be mapped to
> fewer spot colors in order to make that usable. In no way will a user want
> to work with dozens of colors and set them as spot colors, unless the job is
> sent to a color printer (machine) that will convert them on the fly as the
> job is processed and printed. If this is meant to be used this on an offset
> press, then plates come into play and the number of colors will become
> critical plate-wise and cost-wise. We need a way to handle this.
>   

very interesting point. no idea how scribus (or inkscape) could handle 
this, but that would also be a very neat future (i guess more difficult 
to implement than what i am proposing...)

ciao
a.l.e