My first post was ”Hello World”, and now my second is RIP. That was fast!
No – in this case RIP is Raster Image Processing. This is not an area in which I am an expert, but I am learning. The RIP is the part of the printer that takes e.g. postscript and generates the final bitmap needed to color the page.
In my many years with programming, I have experienced many graphics challenges. From mono-chrome, interlaced screens, over 8 colors, then 256 colors VGA, and now 24 bits of color – 8 bits for each of Red, Green & Blue – RGB. The printed version however, hasn’t really interested me that much.
Nevertheless, when you are deeply involved in all the processes of writing a book, some degree of printing knowledge becomes mandatory. See also https://klauselk.com/authors-tools/.
Colors
The first challenge is the color-space. In printing CMYK is used – Cyan-Magenta-Yellow and K for Key, which is black. This is just like the four toners in your home-office deskjet.
Each color gets a percentage from 0 to 100. If the first three are all 100%, you get a black output. It may be somewhat brownish if colors “peek through”.
Instead you can use 100% K – definitely cheaper. It is however also possible to choose 100% on all four colors, creating an even darker black. Only this requires a very good paper-quality. It is not difficult to imagine how the paper can go to pieces after being soaked four times. There are specifications of paper, describing how many percent color it can take. The “superblack” would require 400%.
RGB is all about adding colors emitted from the screen, while CMYK is about blocking colors in the light reflected back from the paper. RGB is said to be “additive” as more of it all moves towards white. Opposed to this, CMYK is “subtractive”. Here more of it all moves us towards black.
You can create colors with CMYK that don’t even exist in RGB.
When I get a little wiser, we may look into the “gamut”, which is the mapping of colors into RGB values.
Some printing-services require CMYK color-scale in the graphics they receive for printing, while others are OK with RGB. In fact, RGB can be many things, which is why some manufacturers defined sRGB – the “s” is for “standard”. The printing service’s RIP converts from sRGB to CMYK on the fly. However, there is no guarantee that printer A and printer B does this in the same way. If you are creating print-on-demand stuff that may be printed all over the world, this is something you want to avoid.
Transparency
The second challenge is Transparency. On screen we have the three RGB values. But sometimes we also have α (alpha), which is the transparency. This is used for drop-shadows and other nice effects. Just like Raster-Printers can convert from RGB to CMYK, they can also “flatten” the image before printing it. And also in this case, the results may vary.
If you have graphics software, you want to utilize “layers”. This allows you to work on the background, separated from foreground, which again is separated from artistic text – while in a fourth layer you may have “guides”. Layers are however, another form of transparency. So, these may also be a reason to “flatten” the image before it is shipped.
The third challenge that I will bring up here, is the use of PDF-files. PDF is a often preferred by printing services.
Most of us expect PDF to somehow be the final word – “this is how it looks”. It turns out that there are several PDF-formats. Some will e.g. embed the fonts used. If this is not done, the printing service may just select another font. Not good. See https://en.wikipedia.org/wiki/Portable_Document_Format.
Some PDF-formats support layers while others don’t. If an image is exported to an older PDF, it is normally flattened. But with newer formats, the layers might make it all the way to the printer – again with unknown results.
Some programs can flatten the images as part of the export. In other programs, it is recommended to make a copy of the “source” file in the native graphics format, and then in the copy move all graphics to a single layer. Additionally, transparent objects must be made non-transparent. One way to do this is to go via bitmaps. You may e.g. export the whole thing to JPG or to a non-transparent PNG, and re-import into the graphics program. Alternatively you may get away with a transformation into curves.
This is the reason you need to do all this in a copy – if done in the original, it is not easy to continue editing afterwards.
It would be nice to be able to investigate a PDF-file before shipping it. The best I have found so far is ImageMagick.
This program has a simple viewer and an advanced command-line interface, and it can handle a lot of formats.
In the simple viewer, you can e.g. load a file, and transparent areas will show as a “checkerboard” – if there are no colored areas below.
The commandline may be used to show layers:
$ magick identify testfile.pdf testfile.pdf[0] PDF 1058x720 1058x720+0+0 16-bit sRGB 384KB 0.000u 0:00.006 testfile.pdf[1] PDF 1058x720 1058x720+0+0 16-bit sRGB 384KB 0.000u 0:00.005 testfile.pdf[2] PDF 1058x720 1058x720+0+0 16-bit sRGB 384KB 0.000u 0:00.003
The above snippet shows three layers, using array-syntax, inside the file, and that the file is using sRGB.
The next shows another file without layers – using CMYK:
$ magick identify coverV2.pdf coverV2.pdf PDF 1077x741 1077x741+0+0 16-bit ColorSeparation CMYK 3.192MB 0.016u 0:00.005