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

Louis Desjardins louis.desjardins at gmail.com
Mon Mar 15 17:10:33 CET 2010

2010/3/15 a.l.e <ale.comp_06 at xox.ch>

> salut louis,

Salut Ale !

>  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.

Hiding them to have a workable color palette is one thing.

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

Again, this sounds fine.

But there is a big but ! At the same time we need to acknowledge that we’re
going to make a decision on those colors coming from an imported document.
First, it’s a good thing that we can have those colors at hand. The next
step is to decide how these colors will be used.

If we cannot implement a "map color option" at the time being, maybe we
could have a dialog showing up asking what to do with those colors : mark
them as process colors or mark them as spot. Since they can be one or
another, mutually exclusive choice, I guess this could be a sane way to take
care of the issue. Then, pursuing in your view, the user have to choice to
see those colors or not in the list (but they do belong to the document once
they are imported).

The Color dialog:
[  ] Remove Unused (already present in the dialog)
[  ] Don’t list Imported (would be added underneath Removed Unused)
"Remove Unused": tooltip as it is.
"Don’t list Imported": tooltip: (Un)checking this option (un)displays the
colors that have been created into Scribus upon the importation of an image
Or something like that!

The warning dialog:
[  ] Imported colors are CMYK
[  ] Imported colors are spot
Tooltip: The colors used in the imported file will be converted to either
spot or CMYK. You will be able to change those color settings afterwards.
The default value is CMYK and should be changed only if you know what you
are doing.

>  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.
I see that a "Change color" dialog now exists. I haven’t had the time to
play with it but this is something most similar to what I have in mind.

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
> Au revoir !


> _______________________________________________
> scribus mailing list
> scribus at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus/attachments/20100315/74945b98/attachment.htm>

More information about the scribus mailing list