Rasters | Colecandoo!

Lineart vs Greyscale scans for text

March 21, 2015 Leave a comment

When faced with creating artwork a black and white book from a previous print that has no digital artwork available, the fastest and cheapest option is to scan the book. This assumes that there are no changes to the text, that the book is for print only, and that the client has allowed the spine to be cut off of the book so that the pages can scan through a document feeder. If the book is text only with no halftone, I would recommend the scans end up as 1200 dpi linearts. This is fine if the book is text only, but if the text contains images such as photographs, then two scans are required – one for the text (linearts), and one for the images (300dpi greyscales). The two sets of scans then have to be combined by placing the images into InDesign.
One might ask “why not use greyscale scans at 1200dpi”? Apart from the filesize when printing – the text will look terrible. To understand why high resolution doesn’t always equal better quality, the answer lies in one process: Rasterising.
Regardless whether a greyscale scan is 300dpi, 600dpi or 1200dpi, the scan will still have to go through the rasterising stage on the copier where a filter is applied to make the shades of grey that the artwork may contain. This is usually done with a halftone filter in the copier’s RIP software. This is where the images are converted into halftone dots – measured in LPI – Lines (of dots) Per Inch.
Using a 150lpi halftone filter, here is what happens when the same images are rasterised (click on the image to see at correct size):
The 600dpi and 1200dpi images do look better than the 300dpi, but the type is still not sharp, and looks bumpy. This is because of the halftoning that is occurring in the RIP. Despite the resolution the text was scanned, the bumps on each image are in the same spots in each scan (though the severity of the “bumps” is different with the dpi)
Lineart images are different in that there are no shades of grey, and do not have halftone applied to them. So once passing through a 150lpi halftone filter, here is how the images look after being rasterised (click on the image to see at correct size):
Here, the difference in dpi does matter, as the 1200dpi lineart is sharper than the 600dpi lineart, which is definitely sharper than the 300dpi lineart
Here is the side-by-side comparison (click on the image to see at correct size):
So by creating the book with separate scans for the images and type, the quality will be greatly improved, but will take longer to set up.

Filed under Page Layout, Rasters Tagged with dpi, lpi, scans, type

Lineart “Spicks and Specks” remover for scanned text

September 21, 2014 Leave a comment

The task of removing the spots from a lineart scan is a boring task, but a necessary one when trying to create an identical copy of previously printed text.

The usual way of minimising the clean-up of rogue dots is to scan the original as a 1200 dpi greyscale, and using combinations of levels and curves to remove the highlights and emphasise the shadows, then convert the greyscale to lineart using the 50% Threshold. Nevertheless, sometimes there are stubborn dots that won’t go away with this process. Also, scanning hundreds of images at 1200 dpi in greyscale (so the images can be 1:1 converted to lineart using the 50% Threshold) requires lots of memory and hard drive space, so in this brief the pages were scanned as lineart images.

One particular brief was to recreate a novel exactly as it had been printed previously, but as the book was last printed 15 years ago, the native files were no longer available. While the cover could be re-set, the black and white text had to be scanned in, rather than use Optical Character Recognition (OCR) and format the text into a new InDesign (this would take too long and require many proofs). The client gave permission to cut the cover from the book so that the text could be fed through the scanner’s Auto Document Feeder (ADF).

A script was already produced that would remove rogue dots – but sadly did not work with the latest versions of Photoshop. An answer turned up in a post to the Adobe Forums when Evgeny Trefilov (17^th post in) presented a filter he had made. Initially, it too did not work with the latest version of Photoshop, but a 64-bit plug-in was created to work with CS6 and above. Evgeny’s plugin does require the images to be greyscale.

Above: the user interface of Evgeny’s plug-in. Set the Threshold, Max Value, Block Size and C value as above, but to fine-tune the script so that dots don’t disappear above “i”s or letters don’t fill in, adjust the two red sliders until the desired results are achieved.

For this brief, a sample file was used (out of the many that were scanned) to test Evgeny’s filter, and once refined to make sure that only the rogue dots were removed but other larger dots preserved (e.g. the dot in the letter “i” or a full-stop), an action was made in photoshop to:

Convert from lineart to greyscale;
Run Evgeny’s plug-in;
Convert from greyscale back to lineart;
Save and close.

This plugin (download here) and action worked well and certainly saved dozens of hours of removing rogue dots from lineart scans of text.

It should be stressed that this plugin was appropriate for scanned lineart text, but as for cleaning up illustrations, diagrams or photographs, be careful as the incorrect settings can have major consequences.

So correcting the scanned pages is one thing, while one of the techniques from this article was used to place the pictures into a new InDesign file.

Filed under Rasters, Scripts

Live Text Masking in InDesign

November 4, 2012 Leave a comment

Until now, to make a text-mask with InDesign, type normally has to be converted to curves so that the type can now be treated like a placeholder. This works fine until the type has to change, such as:

Correcting a typographical error;
Including more text or resizing it; or
During a data merge.

In these instances, it would be ideal for the type to still be live so that changes could be made while maintaining the masking of the type.

Surely someone had thought of this before… but instead of being an easy search in Google, it took hours of research to find this little nugget of information from the Phoenix InDesign Users Group:

Excited, I followed the instructions to the letter, but discovered that this trick isn’t true text masking. Let me explain.

A text mask created the usual way of converting to curves and then placing the image within the new shape works this way:

However, a text mask created using the tutorial from the Users Group behaves more like a stencil. That is, it does mask the image, but shows the stencil:

This is fine if the background is white… but in this instance the background is pale yellow. The solution in this instance is to make the image to be masked sent to the background, and the image which is in the background become the foreground:

So while this technique works, it does not work as well as masking within shapes, given that:

not all effects (drop shadows, bevels, transparencies) can be applied to the masked text; and
the background effectively is brought forward; and the item to be masked is effectively in the background.

This technique also works with background images. To demonstrate this, I’ve upgraded an earlier post featuring “Square Pegs Round Holes” to demonstrate how this masking works with live text.

As usual, files for the above demonstration can be found here.

Filed under Fonts & Type, Rasters, VDP Tagged with Data Merge, InDesign, Mask, Text

Keeping a “Fit” Image, or making an Image Fit?

August 17, 2012 Leave a comment

UPDATE 2020-01-02: Since the release of InDesign 2020, more image fitting options have been added, such as “Keep Existing” in the Data Merge content placement options panel; and Content Aware Fit that was introduced in InDesign CC 2019. However, this article will remain for posterity.

Adobe InDesign’s frame fitting options can be quite useful, but with ten possible combinations it can be difficult to remember what fitting option to use.

Rather than use trial and error, why not refer to a chart which I’ve made especially for this purpose?

The downloadable PDF version for print is available from this link.

Filed under Page Layout, Rasters

Lineart scans: Multiply or overprint?

September 21, 2011 1 Comment

While i’m not sure about the behind-the-scenes technical differences between the two, but it would appear that there is a feature of multiply on lineart images which isn’t so great once a PDF is flattened.

Using the following demonstration, i’ve placed the same two images side by side – one greyscale, one lineart, then one applied with multiply and then one applied with overprint.

From here, i’ve exported to PDF with two major considerations: using Acrobat 4 compatibility and downsampling CMYK and greyscale images.

Now, once the PDF is analysed using a third party plug-in Enfocus Pitstop, I can see things which Acrobat Professional would not normally tell me. In this instance, the greyscale images have been unaffected and essentially appear the same. However, the lineart image which had the multiply effect on it has dropped in resolution from 1200 DPI to 350 DPI; and it has gone from being a lineart image (1 bit per channel) to being a greyscale image (8 bits per channel).

So multiply has effectively flattened the lineart as a greyscale and compressed it based upon the compression settings for greyscale images. The lineart image set to overprint on the right is unchanged – it is still 1-bit at 1200 DPI.

What this means is that sharp, crisp lineart which has had a multiply effect applied to it (presumably to behave as an overprint) can render as not so sharp greyscales. This also means that rather than outputting as lineart, the image will be rendered as halftone dots.

If linearts have to appear as if they are overprinting, use the overprint function from the attributes panel.

Further to this, if a PDF is made using higher Acrobat compatibility settings and no downsampling is applied, it may appear that the PDF is fine in Enfocus Pitstop, but to print a PDF to final output it must ultimately be flattened at the RIP and the same thing will happen as in the example above.

Filed under PDFs, Rasters

“Spot” the difference of soft light with overprint preview

August 23, 2011 2 Comments

I recently found myself being the “bad guy” after having to instruct a customer to resupply their artwork given that many of the effects applied to the pictures in InDesign would not print as desired.

In short, the artwork was an annual report printed in full colour plus a metallic silver spot colour. Originally supplied PDF only, everything looked fine on first glance with the overprint preview off. However, while the document was being manually preflighted using Acrobat’s Output Preview, I had noticed that a greyscale-like effect on the silver had disappeared once I had entered the Output Preview. Concerned, I restarted Acrobat to make sure the glitch was not software related, but again the same thing appeared. This happened on several machines and it soon became apparent that the artwork would in fact print as it appeared in Output Preview rather than the normal preview.

The customer was then contacted and informed of the situation. After replying that the artwork looked fine on his screen, the customer was then instructed to turn the overprint preview on within InDesign, and lo and behold… he began to see what I saw. He then told me he had used the soft light effect.

To demonstrate the phenomenon, I have created a new InDesign file with five elements: a rectangle coloured with Pantone 871C; a rectangle coloured with the default green which ships with InDesign; a stock photo with the soft light effect applied , and two captions of the colours in the rectangles. In the before image, the Separations preview is turned off.

and this is how the InDesign file looked after the separations preview was turned on:

resulting in the image disappearing from Pantone 871C rectangle. However, the image still appears over the process green rectangle.

Ultimately, this means that the effect is only reproducable over process colour, and not spot colour, regardless whether it is metallic or not.

Interestingly as well was the fact that in Live preflight, there was no error warning of this particular feature of the soft light effect, so if I was purely to obey the live preflight and not check my file with the separations preview or overprint preview, this would have been completely missed.

The lesson here? Always check artwork using the separations preview to make sure the artwork will appear as designed, and that some effects will work in process only.