ejbehr@RS6000.CMP.ILSTU.EDU (Eric Behr) (04/12/91)
Here is something that has bothered me for a long time. When I print some PostScript code containing very thin lines (e.g. 0.001 setlinewidth), some of them seem to be thicker than others. To see that it's best to print a rather fine grid - e.g. every 1/8 inch or so. This shows up on two Apple printers I've used - an old II NT and my Personal NT. Since engines are different in the two, I have no clue as to what may be causing that. Did other people notice that? If so, what's the reason? Eric -- Eric Behr, Illinois State University, Mathematics Department Internet: ejbehr@rs6000.cmp.ilstu.edu Bitnet: ebehr@ilstu
rberlin%birdlandEng@SUN.COM (Rich Berlin) (04/17/91)
In article <9104151944.AA15613@crayola.cs.UMD.EDU>, ejbehr@RS6000.CMP.ILSTU.EDU (Eric Behr) writes: |> Here is something that has bothered me for a long time. When I print some |> PostScript code containing very thin lines (e.g. 0.001 setlinewidth), some |> of them seem to be thicker than others. To see that it's best to print a |> rather fine grid - e.g. every 1/8 inch or so. This shows up on two Apple |> printers I've used - an old II NT and my Personal NT. Since engines are |> different in the two, I have no clue as to what may be causing that. |> Did other people notice that? If so, what's the reason? Eric |> -- |> Eric Behr, Illinois State University, Mathematics Department |> Internet: ejbehr@rs6000.cmp.ilstu.edu Bitnet: ebehr@ilstu The thickness of the line is varying based on where your lines land in device space. This is documented behavior in the redbook. In PostScript Level 2 there's a feature that you can turn on to fix the problem; in the meantime you're stuck having to adjust the line width yourself. The method is documented, but the basic idea is that for every coordinate pair you push on the stack, you adjust the coordinates to land on a pixel boundary. %! % Adjust a coordinate pair to land on pixel boundaries /adj { % x y => x' y' transform round exch round exch itransform } bind def % Then try this test: .001 setlinewidth % Regular grid 0 72 8 div 72 { /n exch def 0 n moveto 72 n lineto stroke n 0 moveto n 72 lineto stroke } for % Adjusted grid 100 0 adj translate 0 72 8 div 72 { /n exch def 0 n adj moveto 72 n adj lineto stroke n 0 adj moveto n 72 adj lineto stroke } for
ejbehr@RS6000.CMP.ILSTU.EDU (Eric Behr) (04/18/91)
As even a casual reader has surmised, the answer is simple: a line touching one or more pixels depending on its exact position. Stupid of me. By the way, how does PS assure that its accuracy in computing "ideal lines" exceeds and will exceed all printers, including the Linotronic 1234470 of A.D. 2004? Seriously, what order of precision is used by the PS interpreter? I know that there are no "ideal lines" in real life... Thanks a lot to all who responded! I tried to acknowledge each reply by mail, but a few letters bounced. Thanks again! E. -- Eric Behr, Illinois State University, Mathematics Department Internet: ejbehr@rs6000.cmp.ilstu.edu Bitnet: ebehr@ilstu