visible invisible vectors

[mglouis]

Why is it that a line with a fill but no stroke, or a line with a 0.0000" or 0.0001" stroke will image in Acrobat Reader or to some output devices? In my experience an object that should either be invisible or microscopic should be , well..., either invisible or microscopic. Toggling page display preferences makes no relevant difference here. This phenomenon is a personal bugbear because we are a printer who claims to match pdf proofs for color breaks and position and we cannot match the relative thickness of these lines as they appear on screen.

#1) I wish to understand why this happens and #2) I wish to know if this is a bug or a feature.

Thanks,
Matt Louis

 

[couriergraphics]

laser printers are at a 72 dpi resolution. Imagesetters are 2400 or 2540. This is why.

 

[leonardr]

Why is it that a line with a fill but no stroke, or a line with a 0.0000" or 0.0001" stroke will image in Acrobat Reader or to some output devices?

Just to follow up on the other response - the actual width of the line is dependent on the resolution of the output device.

Because of this, Acrobat/Reader will (by default) thicken up VERY thin lines (such as the ones that you mention) so that they appear on the low resolution device that is the screen. If you don't like this, Acrobat/Reader 9 has an option to turn it off.

 

[Lukas Engqvist]

This is why it is not recommended to have lines thinner than 0.2 pts. Some RIPs will automatically "fix" hairlines.

 

[mglouis]

So line thickening IS the cause of the Imaging problem, invisible lines being visible, not because RIPs, including Acrobat Reader RIPing to screen, are trying to torment me or because of a rogue setting, but because the pixel grid must be resolved. Lines can be "fixed" also but this is not at play with the scenario I am concerned with.

Rampage, our rip, will take a stroke that is between a device pixel (e.g. LW) and non-zero width and render it up to a device pixel, so in effect line thickening does occur. A choice had to be made to render it down to zero or up to a pixel, and the pixel option wins. This explains why a 2.54 micron line rips at 10.5833 microns.

A related proofing problem is the varying width of device pixels across the production chain. 1px on a display or a laserprinter is wider than 1 px on a 2400 CtP device, and this causes a mismatch between a line a client approves in pdf and the line that does or does not print onm press. Small lines may or may not get lost at plate imaging or get buried by overlapping plates on press (e.g. knockouts)

Acrobat Reader would have to know the display resolution and absolute size of display pixels to attempt to accurately display line widths correctly and even then a choice would have to be made when a line width is between zero and less than a display px width to either drop the line altogether or to image at a px.

Thanks all who helped me wrap my head around this.

As I looked into this issue I ran across some ad hoc info so I might as well share: Older versions of Illustrator, so I am told, will not allow a zero width line. Try it, save it down, open in pitstop and you'll see 0.0001" width (& man does it look fat on screen in Reader). I have Illy CS4 where saving a zero width line causes the line have a none color stroke and upon save to pdf the object is tossed and does not exist as an object in the resulting pdf. Quark's hairline means a device pixel so the width is variable depending on the output device.

Matt Louis