View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003540||Scribus||Internal||public||2006-04-02 02:58||2016-04-13 03:30|
|Platform||x86 Linux||OS||Fedora Core||OS Version||FC5|
|Target Version||Fixed in Version|
|Summary||0003540: Support explicit greyscale colour space|
|Description||Scribus currently supports the /DeviceGrey space though explicit greyscale PDF output, but doesn't seem to offer any way to use /DeviceGrey in CMYK or RGB output.|
It may desirable to be able to have explicitly greyscale colours in the picker that are always output as /DeviceGrey no matter what the output target. They'd be guaranteed never to be altered into impure greys during colour management etc.
I know some printers and designers really want to be able to ensure that they use these "pure greys", or have in the past. I still need to look up details, but I think it's worth putting this bug here. If nothing else, it can be determined to be unneccesary and closed as WONTFIX.
|Note that I'm really not entirely sure this is necessary. It's posible that simple RGB colours where R=G=B will do, possibly with some logic to always export greyscale colours as /DeviceGrey . Or /DeviceGrey use might just not prove that important. It's worth looking into though.|
||I absolutely agree. I have already seen greyscale images that have been ruined in the process, especially in digital printing. IMHO, this very desirable.|
||May suggest setting the priority to high? Scribus praises itself for its world class output qualities, and I feel this has to be implemented somewhere on the road to 1.4.|
we should also add indexed colors too at some point
||plinell, don't you think both extentions should be added to the roadmap? These are very important features.|
|added to roadmap|
||Also monochrome color space (that is, 1-bit B&W images) should be supported. They are very important in e.g. comic book work.|
Here is a more detailed description of how 1 bit images should work when working on comic books. The requirement is that the 1-bit image is line art and the DTP program must preserve all details.
Assume that a 1-bit image is put on top of some other image or element. Further assume that its CMYK values are (c, m, y, k). What needs to go to the printing plate is the value (c, m, y, MAX_K) wherever there are black pixels and (c, m, y, k) for white pixels.
Effectively this is a multiply operation. However it is possible to do this with plain PDF 1.3 without transparency effects. I think the corresponding option in Indesign is "overprint fill" but I'm not entirely sure on that.
The images must _not_ be flattened or converted to CMYK images by Scribus (as currently happens). It is extremely important that the 1-bit image does not go through the RIP's line rasterizer. The only way to ensure that is to write them in the PDF as monochrome images.
||Severity||minor => feature|
||Note Added: 0009584|
|2006-04-20 14:04||christoph_s||Note Added: 0010178|
|2006-04-20 14:22||louisdesjardins||Note Added: 0010181|
|2006-04-21 21:28||christoph_s||Note Added: 0010272|
|2006-04-21 21:34||mhanski||Priority||normal => high|
||Note Added: 0010274|
||Status||new => confirmed|
|2006-04-22 00:50||christoph_s||Note Added: 0010285|
||Note Added: 0010314|
||Product Version||=> 1.3|
|2006-10-14 22:22||mhanski||Relationship added||child of 0004413|
|2012-08-09 15:03||jghali||Relationship added||has duplicate 0011025|
|2012-08-09 15:17||JussiP||Note Added: 0028791|
|2012-08-10 10:31||JussiP||Note Added: 0028799|
|2015-04-15 02:30||Kunda||Tag Attached: comics|
|2015-04-15 02:35||Kunda||Relationship added||child of 0013013|
|2016-04-04 23:13||Kunda||Tag Attached: greyscale|
|2016-04-13 03:30||Kunda||Tag Attached: grayscale|
|2016-04-13 03:30||Kunda||Tag Detached: greyscale|