Skip to main content
A
Anonymous
July 25, 2013
Question

How to align fine parallel lines with coordinate system?

  • July 25, 2013
  • 2 replies
  • 2173 views

I'm not sure how to explain this. Please pardon my code if it is bad or my terminology if it is wrong, as I'm a novice ps programmer.

What I'm trying to do is draw a pattern of vertical lines, which I want to be based on a resolution of 100 dpi. If I write "72 100 div 1 scale" then I have changed the coordinate system so I have an effective horizontal resolution of 100 units per inch, is that correct? Is this the correct way to change the resolution of the coordinate system? In other words, can we really change the resolution of the user space (irrespective of the device space)? I understand that there are actually no dots in user space and dots do not actually exist until rasterization, but please pardon my use of the term dpi to mean units of the coordinate system when I refer to the user space.

My goal is to render graphics that will come out accurately on a printer. Since most laser printers have a resolution that is a multiple of 100, then I reason that during rasterization lines sized in multiples of 1/100" will be precise (e.g. @17258182 dpi, 1 user space unit = 6 device space units or dots). This is to avoid rounding errors resulting from converting from 72 dpi to say 600 dpi. Does this make sense? Is this a sound premise?

If I'm on the right path thus far, then I use the following code to render a series of vertical lines which alternate between one unit and three units in width separated by spaces of one unit:

/w 1 def

20 {currentpoint w 20 rectfill w 1 add 0 rmoveto /w w 2 xor def} repeat

Prior to the above, I place a moveto command. If I write say "360 500 moveto" then the lines do not render as expected (I'm using ghostscript and gsview). If however, I write "363.6 500 moveto" then the lines render as expected. The code segment would be as follows:

363.6 500 moveto

72 100 div 1 scale

/w 1 def

20 {currentpoint w 20 rectfill w 1 add 0 rmoveto /w w 2 xor def} repeat

So 360 appears to be round number in that it is evenly divisble by 72 and also 0.72 (the scale factor) and appears to be a more round number than 363.6. I think perhaps I'm missing something in the math to get coordinates that will align so that all the lines will render evenly. On the other hand, if I do the scale first, then the moveto, the results are reversed: @360(x) renders okay, but @363.6(x) does not.

Can someone explain to me why this is so, and how to align to the coordinate system to render a precise series of lines?

This topic has been closed for replies.

2 replies

D
Dr.Adam
Inspiring
August 6, 2013

Just quick note about resolution

Postscript programming is totally independent with device resolution

the Postscript only see 72 dots per inch - which match the way in offset screening ...

However the PS applications draw or fill 2 inch which means 144 dots !  then the PS Interpreter/Rip will handle the output to be exactly two inches wither your printer is 600 DPI or 1200 DPI   it will be two inches - you - The Application Coder - don't have to worry at all about the output device resolution and that is the unique and petty thing in Postscript.

Cheers

Adam

T
Test Screen Name
Legend
July 28, 2013

This is more complex than it might seem. The PostScript rule is to imagine the page as something like graph paper, then contruct the exact paths you need over the top - that is, draw the lines between two points, extending out to the required thickness. Now you fill every box which has any part of the width of the line inside it. This means that line widths are likely to vary by 1 pixel. There is a technique of setting the line centre exactly half way through the actual coordinate system, so widths are rounded consistently throughout a figure. This requires some work in the device coordinate system to get the position of each point. There used to be a tech note about this but I haven't seen it in years.

You can't really say anything about correct printer rendering from a screen view though!

A
Anonymous
July 28, 2013

Thank you for your response, Test Screen Name. PostScript's way of producing lines of a specified thickness centered around a path is what I meant to avoid by using rectfill instead of lineto. To acquire the necessary precision of the lines and intervening spaces, we can say start here and paint so many units up and to the right. While it is true that results on screen may not match printed output, I set the screen view to 100 dpi resolution and zoom to 100 dpi, and if rendered properly it will look right on screen. The actual test that I do, however, is to rasterize the page to a bitmap, and then I can see exactly how many pixels make up the width of each line and space. A tech note about this would be very helpful . There's definately something going on that I don't fully understand.

T
Test Screen Name
Legend
July 29, 2013

I see now why you used rectfill, but it really makes no difference. The same rules apply, since your rectangle results in filling all of the device pixels through which it passes. You cannot just use user coordinates and make assumptions about device coordinates. I think you are assuming that

(a) the device resolution is exactly what the box says, and equal in X and Y directions

(b) the device grid conveniently aligns with the user grid, such that the axes for both grids are equal

Also, even if you align with the grid you potentially have boundary effects - if a line is drawn such that it is exactly on the edge of the device pixel, is the pixel filled? Which pixel - the one to the left, the one to the right, both?

I think your idea has some legs but you need to now get low level and dirty with the device coordinates.

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices