Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.postscript > #249

Re: PDF to PDF (gs?): rich RGB black to plain K (CMYK) black?

Show all headers | View raw

In article <fd01f57e-e9b3-4839-9ba8-5c732bcfc506
@m4g2000yqk.googlegroups.com>, sd@imi.aau.dk says...

> > It only occurs (in the code I wrote at least) when R=G=B, so its a 
shade
> > of gray. In that case it doesn't matter what component you choose, they
> > are all the same :-)
> >
> 
> Yes, but I meant more from a perceptual perspective: for instance, I
> am pretty certain that black as (CMY)K:(0,0,0),1 on paper should
> correspond to RGB:0,0,0 on screen; and that white as (CMY)K:(0,0,0),0
> should correspond to RGB:1,1,1. However, would RGB:0.8,0.8,0.8 map
> linearly to K:0.2 - or are there some 'transformations' involved, when
> mapping perception of grayscale from screen to paper (e.g. instead of
> K=1-R, may be something like K=1-0.2*(5^R) would be more
> appropriate) ?

If you're worried about colour fidelity, you shouldn't be using an 
application which produces RGB to produce documents for print ;-)

This has long been a criticism of Microsoft Office and Publisher, people 
who care about colour want (at the very least!) to be able to specify 
CMYK colours, not RGB. The whole colour model is different (reflective 
vs transmissive).

Seriously, I wouldn't worry about it too much, I expect it'll be close 
eough for your.
n

> > > Right - and a note to myself: after pdf to ps (and thus in the 
final
> > > roundrip from ps to pdf) text information is gone - all the font
> > > glyphs apparently become treated as curves (since I cannot select or
> > > copy the text in `evince` anymore); ...
> >
> > pswrite is *really* basic, ps2write does a much better job. All text is
> > converted to outlines by pswrite, which is one resaon the output tends
> > to be huge. There are many other compromises too.
> >
> 
> Just to make sure - I was using the ps2write (not pswrite) in the
> example above, and that also seems to 'flatten' the text (although, as
> I noted, I don't mind that, and the other compromises - as long as the
> print comes out nice :) )..

ps2write really should never convert text to outlines, worst case it 
might produce bitmaps instead of scalable fonts. I don't think there's 
any way it can convert to outlines (I ha d arecent request for that, so 
I'm reasonably sure ;-)


> Thanks for noting that; good to have the notion, that level 2 should
> still be generally safe to use.
> 
> I guess 'dialects' was the wrong word to use; when I wrote that, I was
> referring more to this type of problem:
> 
> > > ... and since the debug text "in replacement setrgbcolor" never
> > > appears on stdout, this means the procedure is not even triggered!
> >
> > Presumably because there are no colours specified using setrgbcolor....
> >
> 
> ... if not a different dialect, then sure there seems to be different
> ways of specifying color: for instance, depending on how a conversion
> from PDF to PS is performed, the PS file may or may not specify colors
> using setrgbcolor.

Well PostScript is a programming language; there are usually multiple 
ways of achieving the same end in programming languages. Some may be 
preferable.

One reason to use "/DeviceRGB setcolorspace R G B setcolor" instead of 
"R G B setcolorspace" would be if you were going to specify lots of 
colours. Saving the 5 bytes per time of setcolor vs setrgbcolor can 
mount up if you do lots of them leading to smaller files. These days 
nobody really cares much about that ;-)

Also there are a number of operators which use the current color space, 
so if you are going to be working in RGB its often more efficient to set 
the colour space to RGB, and then just go. Same for other spaces of 
course.

Microsoft Office used to (probably still does) create patterns by 
drawing lots of teeny tiny images in an Indexed (ie palette) colour 
space. it was hideously inefficient because it would set the current 
colour space to RGB then save the graphics state, set the colour space 
to the paletted space and draw the image, then restore back to 
DeviceRGB, rinse and repeat.

The RIP I was working on at the time did a certain amount of work 
whenever the colour space changed. By switching inanely back and forth 
like that the files took a long time to process. We eventually added a 
cache to cater for the situation.

Setting the colour space to the paletted colour, drawing all the images 
and then restoring back would have been *much* more efficient....

But concerns like those went away when people stopped sending PostScript 
files to RIPs using a 9,600 Kbits/sec serial interface :-)


> And I guess, that is what would limit the usability
> of a script like HackRGB.ps?

You could sitll do it. You would need to monitor calls to setcolor 
instead of setrgbcolor, check the current colour space and if its 
/DeviceRGB check the three components. If they are the same then you 
could set the colour space to Gray, and call setcolor with one 
component. You would need to remember what the last colour space was, so 
that on the next call to setcolor you could restore the original space 
first. Obviously you would also monitor setcolorspace calls in case the 
space changed after the last setcolor.

Clearly the complexity of the challenge goes up, but its still possible.


				Ken

Back to comp.lang.postscript | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

PDF to PDF (gs?): rich RGB black to plain K (CMYK) black? sdaau <sd@imi.aau.dk> - 2011-06-05 22:49 -0700
  Re: PDF to PDF (gs?): rich RGB black to plain K (CMYK) black? Matti Vuori <xmvuori@kolumbus.fi> - 2011-06-06 08:41 +0000
  Re: PDF to PDF (gs?): rich RGB black to plain K (CMYK) black? Helge Blischke <h.blischke@acm.org> - 2011-06-06 11:26 +0200
    Re: PDF to PDF (gs?): rich RGB black to plain K (CMYK) black? sdaau <sd@imi.aau.dk> - 2011-06-06 04:29 -0700
  Re: PDF to PDF (gs?): rich RGB black to plain K (CMYK) black? ken <ken@spamcop.net> - 2011-06-06 14:05 +0100
    Re: PDF to PDF (gs?): rich RGB black to plain K (CMYK) black? sdaau <sd@imi.aau.dk> - 2011-06-06 08:34 -0700
      Re: PDF to PDF (gs?): rich RGB black to plain K (CMYK) black? ken <ken@spamcop.net> - 2011-06-06 17:28 +0100
      Re: PDF to PDF (gs?): rich RGB black to plain K (CMYK) black? ken <ken@spamcop.net> - 2011-06-07 10:21 +0100
        Re: PDF to PDF (gs?): rich RGB black to plain K (CMYK) black? sdaau <sd@imi.aau.dk> - 2011-06-09 05:28 -0700
          Re: PDF to PDF (gs?): rich RGB black to plain K (CMYK) black? ken <ken@spamcop.net> - 2011-06-09 14:00 +0100
            Re: PDF to PDF (gs?): rich RGB black to plain K (CMYK) black? sdaau <sd@imi.aau.dk> - 2011-06-09 06:48 -0700
              Re: PDF to PDF (gs?): rich RGB black to plain K (CMYK) black? ken <ken@spamcop.net> - 2011-06-09 16:06 +0100
          Re: PDF to PDF (gs?): rich RGB black to plain K (CMYK) black? tlvp <mPiOsUcB.EtLlLvEp@att.net> - 2011-09-16 18:33 -0400
    Re: PDF to PDF (gs?): rich RGB black to plain K (CMYK) black? sdaau <sd@imi.aau.dk> - 2011-06-06 09:17 -0700
      Re: PDF to PDF (gs?): rich RGB black to plain K (CMYK) black? Helge Blischke <h.blischke@acm.org> - 2011-06-06 19:30 +0200
        Re: PDF to PDF (gs?): rich RGB black to plain K (CMYK) black? ole.hoppe@gmail.com - 2012-01-25 06:40 -0800
          Re: PDF to PDF (gs?): rich RGB black to plain K (CMYK) black? Helge Blischke <h.blischke@acm.org> - 2012-01-25 16:09 +0100
            Re: PDF to PDF (gs?): rich RGB black to plain K (CMYK) black? ole.hoppe@gmail.com - 2012-01-26 06:41 -0800
              Re: PDF to PDF (gs?): rich RGB black to plain K (CMYK) black? Helge Blischke <h.blischke@acm.org> - 2012-01-26 21:07 +0100
              Re: PDF to PDF (gs?): rich RGB black to plain K (CMYK) black? ole.hoppe@gmail.com - 2012-01-26 12:57 -0800
            Re: PDF to PDF (gs?): rich RGB black to plain K (CMYK) black? ole.hoppe@gmail.com - 2012-01-26 12:58 -0800

csiph-web