Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.postscript > #2227
| 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> |
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
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