2

When printing thin diagonal hatches on inkjet or laser printers, the lines often become uneven in terms of line width. The effect varies depending on printer type, line color/width and hatch angle. I guess that's because the printer's RIP applies different kinds of smoothing algorithm:

example of uneven printed lines

Because it appears on totally different printers, line widths and source applications, I'm quite sure it has something to do with a general printing difficulty.

Is there any kind of preflight correction or general design advice to avoid this effect?

3

It is simply called aliasing. On a laser printer theres not much you can do about it. It simply happens because you are very close to the actual resolution of the printer.

Yes aliasing is highly dependent on exact implementation details of the printer and the size of the actual dots the printer uses. Printers can not really smooth lines though, they may have all kinds of tricks up the on the actual printing level. Inkjets are almost impossible to do anything about in this case.

If you want to do something about this then you can not use vectors you must actually make a bitmap on the native resolution of the printer. Most likely this means writing machine specific printer code. OR you use a printer with MUCH much more resolution.

Calirification

I am not saying one can not do this. I am just saying one can not do this easily through the general printing abstraction. What you want isn't well handled by the abstraction layer, because that's what we want the abstraction to handle. This is the price we pay for having the ability to plug any number of printers to nearly any machine. You can send instructions to the actual printer that does just this.

For example you can send a hairline instruction in postscript. But illustrator can not send hairlines out (Corel can in certain printer drivers). But even with this it does not guarantee that the space between hairlines is constant and does not in fact jump one dot here and one there.

Like i said you can send direct code the the printers too, now you need to write it in a text editor. So for example if you REALLY REALLy want to do this then you can. However it will only work with printers that have same programming interface. For example its possible to send a halftone handler in postscript, this one has the ability to do this. Only it dont work if there is a suitable RIP in between*.

* like at my work. But then, thats also good, I or some student can no longer upload a joke function that mirrors every 10:th uneven page. Which admittedly was hilarious when bound to a check to see who the person printing was. Admittedly IT didn't think it was so funny.

  • But even on output machines where you can inspect the final rasterized output at the printer's native resolution, the aliasing is clearly visible. I don't quite understand why it's happening on a "per line" base if it's related to printer's physical resolution. I would expect it to be seen on every n-th X or Y line instead... – oxident Feb 24 '18 at 14:01
  • 1
    @oxident You dont ever get to set things onto native points if you send vectors. Because you do not know the OFFSET of the native printers grid in compassion with yours. The only way to address this si to write code on low level. Vectors are on purpose abstracted in way that make sit impossible for you to address native resolution even if you wanted to. Also a 600 dpi printer might not be exactly 600 dpi it might be 602 dpi and you dont know that unless you can address the printer on a low level. – joojaa Feb 24 '18 at 14:05
  • I know what you mean. But I would expect the rasterizer of a printer or controller would be able to render the final "dots" evenly across each x-line. Maybe it would result in aliasing in y+1... Could it be a simple math problem (rounding) while calculating effective rasterpoints out of vectordata? – oxident Feb 24 '18 at 14:41
  • I believe it IS just a simple rounding problem, but the solution is not that simple. As @joojaa says, you need to know the exact printer resolution to fix this rounding "error". How thin are your lines? They must be quite thin, for this to be a problem. – Wolff Feb 24 '18 at 16:01
  • 1
    @oxident adobe had this they have removed it since some time in 1990's would be weird for them to bring it back – joojaa Feb 24 '18 at 18:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.