Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.postscript > #247
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar
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