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


Groups > comp.lang.postscript > #247

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

From ken <ken@spamcop.net>
Newsgroups comp.lang.postscript
Subject Re: PDF to PDF (gs?): rich RGB black to plain K (CMYK) black?
Date 2011-06-09 14:00 +0100
Message-ID <MPG.285ad44425ba0fc4989848@usenet.plus.net> (permalink)
References <208ecf3d-3629-4672-9a3e-135e44701d6b@p13g2000yqh.googlegroups.com> <MPG.28568d9998586243989843@usenet.plus.net> <6d0f8a6c-3430-4b2f-8852-ddb0e772e4ac@v8g2000yqb.googlegroups.com> <MPG.2857fdd2309a7c4c989846@usenet.plus.net> <da825ba1-f2f2-4ffe-8ea2-5cd3b4518e73@p13g2000yqh.googlegroups.com>

Show all headers | View raw


In article <da825ba1-f2f2-4ffe-8ea2-5cd3b4518e73
@p13g2000yqh.googlegroups.com>, sd@imi.aau.dk says...

> > If for some reason that isn't acceptable, you could replace the
> > 'setgray' with '0 0 0 4 -1 roll setcmykcolor' which uses CMYK
> > directly.
> >
> 
> Ahh - thanks for that; now that looks very promising to me :) !
> 
> I did the replacement, called that version HackRGB-cmyk.ps, and tried
> this:
> 
> 
> gs -dNOPAUSE -dBATCH -sDEVICE=ps2write -sOutputFile=./blah-slide-
> gsps2w.ps ./blah-slide.pdf
> gs -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=./blah-slide-
> hackRGB-cmyk.pdf ./HackRGB-cmyk.ps ./blah-slide-gsps2w.ps
> # check separations
> gs -sDEVICE=tiffsep -dNOPAUSE -dBATCH -dSAFER -dFirstPage=1 -
> dLastPage=1 -sOutputFile=p%02d.tif blah-slide-hackRGB-cmyk.pdf && eog
> p01.tif 2>/dev/null
> 
> 
> ... and - partial success here: CMY plates are *finally* blank white -
> but the K plate is inverted (what should be white background, is shown
> in black; and the letters are grayer than that) :)

Oops, my fault, try '0 0 0 4 -1 roll 1 exch sub' instead. Gray is 
inverse polarity and so 1 setgray produces white while 0 setgray 
produces black. Subtracting from 1 will yield the reverse result. which 
should work.

> Interestingly, the
> same effect is shown if I open blah-slide-hackRGB-cmyk.pdf in
> `evince`, too. Also interestingly, if I use the `pdftops` output (blah-
> slide-tops.ps), then the final pdf is not inverted - but the
> separations show again black text on all four CMYK plates:
> 
> gs -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=./blah-slide-
> hackRGB-cmyk.pdf ./HackRGB-cmyk.ps ./blah-slide-tops.ps
> # check separations
> gs -sDEVICE=tiffsep -dNOPAUSE -dBATCH -dSAFER -dFirstPage=1 -
> dLastPage=1 -sOutputFile=p%02d.tif blah-slide-hackRGB-cmyk.pdf && eog
> p01.tif 2>/dev/null
> 
> ... 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....


> ... the difference from HackRGB-cmyk.ps being:
> 
> - 0 0 0 4 -1 roll setcmykcolor
> + 0 0 0 4 -1 roll -1 mul 1 add setcmykcolor
> 
> ... along with an added piece of code that will do the same for
> setgray values.

Mea culpa, I forgot to invert the gray values. Still, well done on 
sorting out the setgray yourself !

> ... and now, I do get black text on white background only in the K
> plate, while CMY plates are blank white :) Although, I'm not sure how
> accurate of a formula K=1-R is; if someone can suggest a more accurate
> formula, please write back!

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 :-)

> > I should also mention that going from PDF to PostScript and back
> > to PDF is a potentially lossy process which can introduce errors
> > and odd artefacts, you should check files carefully after this
> > conversion. I haven't tested this code particularly.
> >
> 
> 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); I guess hyperlinks would be gone
> too - but it doesn't matter really; as this is a document specifically
> intended for a print shop :)

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.


> > If you print directly to PostScript then you can eliminate one
> > conversion step, which is probably worthwhile.
> >
> 
> I haven't really tried this, but as far as I can see, there are
> several PostScript dialects

Not really. There are three basic levels, 1 to 3 where 1 is ancient, 2 
is quite old and 3 is (comparatively) new. Most producers only create 
level 2 PostScript anyway, which will run on any printer you can buy, or 
could have bought in the last 10 years probably.

Only specialist DTP applications like Quark XPress, Adobe Illustrator, 
IDesign etc generally create level 3 PostScript. However, if you start 
form a PDF file and convert to PostScript using something like Acrobat, 
it may offer to save as level 3. Generally that should be fine, but you 
might want to check that one with your printer if you ever find yourself 
doing it.

OTOH If they can accept PDF I'd be amazed if their Rip couldn't also 
handle level 3 PostScript.



		Ken

Back to comp.lang.postscript | Previous | NextPrevious 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