Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.postscript > #2227

Re: setstrokeadjust: what's the disadvantage?

From ken <ken@spamcop.net>
Newsgroups comp.lang.postscript
Subject Re: setstrokeadjust: what's the disadvantage?
Date 2015-04-27 14:29 +0100
Message-ID <MPG.2fa84a0da6ab98399898ed@usenet.plus.net> (permalink)
References <d353a099-6401-463c-95bf-846bf5bd7daf@googlegroups.com>

Show all headers | View raw


In article <d353a099-6401-463c-95bf-846bf5bd7daf@googlegroups.com>, 
jdawiseman@gmail.com says...
> 
> Some very thin black paths, mostly or wholly made by curveto, are to be stroked. Is there a reason why not to
>      true setstrokeadjust
> ? Indeed, why not always 'true setstrokeadjust'? What's the disadvantage? 
> 
> (Ref PLRM3 ยง7.5.2, pp503-504.)


Well, essentially because its extra computation (in the scan 
conversion), so its slower. Yes ths isn't really a huge issue with 
modern computers, but bear in mind that PostScript was originally 
intended to run on printers (and still does, mostly) which tend to have 
shall we say limited computational capability. Even in 1990 when level 2 
was introduced ths was still true.

The normal rule for scan conversion is 'any part of pixel', which 
immediately and cheaply (in computation terms) prevents dropouts 
(disjoint lines and so on). If we turn on stroke adjustment then we may 
end up reducing the rendered width of a line at some point (to keep it's 
width consistent) which means that some pixels won't be painted, even 
though they would normally have been. 

Now it may be that when rendering a curve we have a point (consider a 
sharp corner) where only a single pixel is normally rendered, and that 
pixel is less than fully covered by the stroke. Its possible that the 
stroke adjustment would decide that pixel didn't need to be rendered, 
because its making the line too thick at that point (obviously we are 
talking about a very thn stroke at low resolution and particularly 
unfortunate pixel co-ordinates in device space)

Which brings back the problem of dropout correction, we need to make 
sure that there aren't any unintentional gaps like this in the stroked 
path.

Now stroke adjustment is most useful on low resolution devices, since 
the maximum difference from the requested stroke width and the actual 
rendered width is 2 pixels. Obviously that's going to be more noticable 
at 72 dpi than at 600 dpi. In general scan conversion tends to be more 
computationally intensive at higher resolutions too, so its convenient 
to be able to reduce (or at least, not increase) the problem as the 
resolution rises.

So, its most useful on displays, which tend to be on powerful computers, 
and least useful on printers, which tend to have less powerful 
processors. This is why the setting is device dependent, and its usually 
true on display devices and false on printers.

You can, of course, set it any way you want (though some PostScript rips 
may not actually do anything differntly no matter how its set.....) just 
bear in mind that its less likely to be useful at higher resolutions, 
and at the same time will involve more computation, resulting in reduced 
performace, and since its higher resolution it'll already be slower.

So don't complain if your complex vector art full of '0 setlinewidth' 
curves goes really slowly at 2540 dpi with stroke adjustment turned on 
:-)

(of course, the output will look much nicer with stroke adjustment set 
to true but you would need a magnifier to see those lines anyway......)


			Ken

Back to comp.lang.postscript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

setstrokeadjust: what's the disadvantage? jdaw1 <jdawiseman@gmail.com> - 2015-04-27 03:25 -0700
  Re: setstrokeadjust: what's the disadvantage? ken <ken@spamcop.net> - 2015-04-27 14:29 +0100
    Re: setstrokeadjust: what's the disadvantage? jdaw1 <jdawiseman@gmail.com> - 2015-04-27 08:56 -0700
      Re: setstrokeadjust: what's the disadvantage? tlvp <mPiOsUcB.EtLlLvEp@att.net> - 2015-04-27 14:59 -0400
        Re: setstrokeadjust: what's the disadvantage? jdaw1 <jdawiseman@gmail.com> - 2015-04-27 13:29 -0700
          Re: setstrokeadjust: what's the disadvantage? tlvp <mPiOsUcB.EtLlLvEp@att.net> - 2015-04-27 22:43 -0400
      Re: setstrokeadjust: what's the disadvantage? ken <ken@spamcop.net> - 2015-04-28 07:54 +0100
        Re: setstrokeadjust: what's the disadvantage? jdaw1 <jdawiseman@gmail.com> - 2015-04-28 02:01 -0700
          Re: setstrokeadjust: what's the disadvantage? ken <ken@spamcop.net> - 2015-04-28 11:27 +0100
            Re: setstrokeadjust: what's the disadvantage? jdaw1 <jdawiseman@gmail.com> - 2015-04-28 04:02 -0700
        Re: setstrokeadjust: what's the disadvantage? Mark Carroll <mtbc@bcs.org> - 2015-04-28 10:43 +0100
  Re: setstrokeadjust: what's the disadvantage? jdaw1 <jdawiseman@gmail.com> - 2015-05-01 15:16 -0700
    Re: setstrokeadjust: what's the disadvantage? ken <ken@spamcop.net> - 2015-05-02 09:13 +0100
      Re: setstrokeadjust: what's the disadvantage? jdaw1 <jdawiseman@gmail.com> - 2015-05-02 03:29 -0700

csiph-web