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

Groups > comp.lang.postscript > #2226 > unrolled thread

setstrokeadjust: what's the disadvantage?

Back to article view | Back to comp.lang.postscript

Contents

  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

#2226 — setstrokeadjust: what's the disadvantage?

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.)

[toc] | [next] | [standalone]

#2227

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

[toc] | [prev] | [next] | [standalone]

#2228

So the disadvantage is all about processor time: thank you. 

My PLRM3 says "First printing February 1999". It seems likely that a 2015 printer has memory and CPU as good as those of a typical 1999 computer. (Indeed, it seems likely that a 2015 phone has memory and CPU as good as those of a typical 1999 computer.) So, though there was a historical need for 'false setstrokeadjust', I'm guessing that the need has expired. At least mostly, and more and more with each passing year.

A page of a typical example of my output has 226 paths each comprising one moveto ... curveto, and 28 paths comprising one moveto ... lineto. The curves and lines might average about an inch in length, and are painted with 0.06 setlinewidth 0 setgray.

Do you agree that strokeadjust'ing that should be swift on a modern printer?

[toc] | [prev] | [next] | [standalone]

#2229

On Mon, 27 Apr 2015 08:56:30 -0700 (PDT), jdaw1 wrote:

> The curves and lines might average about an inch in length, and are painted with 0.06 setlinewidth 0 setgray.

What are the units for your 0.06 setlinewidth setting? inches? or points? I
as k because whether I

> ... agree that strokeadjust'ing that should be swift on a modern printer?

is less to the point that whether your strokes are thin enough to be
affected. 

At an 0.06 _inch_ linewidth, or 60 mils, adding or dropping a pixel on a
600 dpi resolution printer will be imperceptible, and it won't be worth the
bother to make the relevant computation.

But at an 0.06 _point_ linewidth, you're speaking of a linewidth of
0.000833" (0.06 x 1/72) or rather less than a mil, which is far enough
*below* the resolution of a 600 dpi printer that adding or dropping a pixel
will be *very* noticable, and you should  probably print test pages to see
how such hair-lines are affected.

On a printer with resolution of 2400 dpi or better, on the other hand, even
lines drawn with an 0.06 point linewidth will probably show only minimal
differences with / without strokeadjust (even less as resolution goes up).

'Zat help at all? Cheers, -- tlvp
-- 
Avant de repondre, jeter la poubelle, SVP.

[toc] | [prev] | [next] | [standalone]

#2230

Points (I was quoting PostScript), so 1 pixel at 1200 dpi, being the resolution of my home printer. 

I did test, and it seemed to make no difference, not for the appearance of the output, nor for the time to print. But that could be because of Adobe Distiller, or Mac Preview, or the printer driver, or the printer -- none of which are necessarily the same for all users of my PostScript program.

[toc] | [prev] | [next] | [standalone]

#2231

On Mon, 27 Apr 2015 13:29:14 -0700 (PDT), jdaw1 wrote:

> Points (I was quoting PostScript), so 1 pixel at 1200 dpi, being the resolution of my home printer. 
> 
> I did test, and it seemed to make no difference, not for the appearance of the output, nor for the time to print. But that could be because of Adobe Distiller, or Mac Preview, or the printer driver, or the printer -- none of which are necessarily the same for all users of my PostScript program.

OK. So let me just share with you one tiny cautionary tale, the fate of the
horizontal line in a lower-case letter "e" as printed by Springer Verlag,
using a really high-res printer, with negligible dot-gain, from a .PS file
using a "hair-line" stroke setting, and requiring that horizontal line to
be hair-line thin (unlike the rounded parts of the "e", which were rather
thicker): every instance of an "e" in that book looked like a "c" until,
with help of a thread-counter, you looked carefully at the page and could
discern a faint, ultra-thin horizontal line "-" serving as that crossbar
making a "c" into an "e". Boy, was the author of that volume (no, not me,
but a good friend of mine) miffed! Last time he ever specified hair-line
widths on anything :-) !

Cheers, -- tlvp
-- 
Avant de repondre, jeter la poubelle, SVP.

[toc] | [prev] | [next] | [standalone]

#2232

In article <0951df15-771a-4953-9561-2eff99e5a323@googlegroups.com>, 
jdawiseman@gmail.com says...
 
> So the disadvantage is all about processor time: thank you. 
> 
> My PLRM3 says "First printing February 1999".

Yes, but the feature it was introduced in 1990 in language level 2. 
There were custom implementations even before that if I remember 
correctly, you just couldn't control them, or at least not in a defined 
cross-printer manner.


> It seems likely that a 2015 printer has memory and CPU as good as 
those of a typical 1999 computer.

Hmm, I certainly wouldn't like to count on that.


> (Indeed, it seems likely that a 2015 phone has memory and CPU as good 
as those of a typical 1999 computer.)

That's undoubtedly true, but you might be surprised how hard 
manufacturers of printers strive to hold down the component cost.


> So, though there was a historical need for 'false setstrokeadjust', 
I'm guessing that the need has expired. At least mostly, and more and 
more with each passing year.

I guess it depends on whether you want your pages faster or (almost 
trivially, depending on resolution) 'better'.

Higher resolution (and printers do keep increasing resolution, albeit 
slowly) means more time taken to do scan conversion. If you add stroke 
adjustment, that takes still more time, and for less and less benefit as 
the resolution increases. Remember, the maximum error is 2 device 
pixels, whch is only 1/300 of an inch at 600 dpi. At 1440 dpi (not 
entriely atypical for inkjets) a 2 pixel difference in linewidth is 
1/720 inch. Unless you are drawing with something like 0 setlinewidth 
the differing stroke widths will be hard to see.

And if the resolution goes up again, even harder.


> Do you agree that strokeadjust'ing that should be swift on a modern 
printer?

It will still be slower than *not* doing it, and manufacturers like to 
quote pages per minute as high as possible....

Given that the benefit is minimal at higher resoltuions, why waste the 
time, however small it is ? Though at lower resolutions its defintely 
worth the effort.

And we *do* get beaten up by printer manufacturers over performance, 
seriously!


			Ken

[toc] | [prev] | [next] | [standalone]

#2233

Well, thank you, lots of interesting comments. Hmm. 

To inform the conversation I’ve extracted the relevant parts of a typical example, which can be found at 
http://www.jdawiseman.com/2015/20150428_strokeadjust_test.ps
http://www.jdawiseman.com/2015/20150428_strokeadjust_test.pdf
(distillation done in Adobe Distiller XI).

tlvp: your cautionary tale is good, but not relevant. I’m definitely not using zero width, for the reason you say. And the pattern is a background decorative thing, which I want faint but just visible, and — of course, we are PostScript programmers — without imperfection. 

ken:

> the feature it was introduced in 1990 in language level 2. 
That strengthens the argument for doing it. Even with manufacturers of printers striving to hold down the component cost, it seems likely that a 2015 printer has memory and CPU as good as those of a typical 1990 computer.

> I guess it depends on whether you want your pages faster or (almost
> trivially, depending on resolution) 'better'. 

I suppose I’m trying to understand how much faster, and how much better. These documents might be printed on anything from 300 dpi to ≥2400 dpi. 

> Unless you are drawing with something like 0 setlinewidth
> the differing stroke widths will be hard to see. 
Does 0.06 ≈ 0? If yes, it might be visible. Indeed, I suspect that 0.06 points is about the peak visibility for this. 

So I don’t know. The line width might be that most likely to make a difference. So how slow is it? Can that be tested? It seemed to make no difference going through PostScript → Adobe Distiller XI → Mac Preview 8.0 (859.21) → Samsung ML-2955DW (printing only the central A4 piece of the A3 — non-draft printing will be done by somebody else). That chain has several places where the instruction could have been dropped or ignored. If you can test, please do.

[toc] | [prev] | [next] | [standalone]

#2235

In article <7c0cc70a-3eb5-4b80-a973-52b1e7d744d7@googlegroups.com>, 
jdawiseman@gmail.com says...

Cpmparisons with the performance of a 1990 computer and a modern prtner 
still aren't valid, as a 1990 computer probably had a screen resolution 
of 72 dpi, while a modern printer will easily be printing at 720 dpi or 
higher.

Increased resolution increases the computation expense.

So the fact that you would turn on stroke adjust for a 1990 computer at 
72 dpi, doesn't mean that by turning it on for a modern printer 
(assuming same processor power) won't slow you down, because the 
resolution isn't the same between the 2 devices.


> > I guess it depends on whether you want your pages faster or (almost
> > trivially, depending on resolution) 'better'. 
> 
> I suppose I?m trying to understand how much faster, and how much better. These documents might be printed on anything from 300 dpi to =2400 dpi. 

Well it depends on the nature of your document, and exactly how tolerant 
you want to be. I'd say, personally (and ths is purely an opinion) that 
at 300 dpi the improvement is small, but the performance cost is not too 
great. At 2540 dpi I'd say the improvement is invisible, and the 
performance cost comparatively high (scan converting curves involves 
touching many more pixels as the resolution rises, and stroke adjusting 
all these, including dropout correcton, obviously will take longer the 
more there are).

 
> > Unless you are drawing with something like 0 setlinewidth
> > the differing stroke widths will be hard to see. 
> Does 0.06 ? 0? If yes, it might be visible. Indeed, I suspect that 0.06 points is about the peak visibility for this. 

The symbol between 0.06 and 0 came out as a tilde on my News Reader, so 
I'm not too sure of the question.

0.06 is pretty thin though, that's 6/100 of a PostScript unit (often 
called a point) and there are 72 units to the inch. So that's 6/7200 of 
an inch.

At 1000 dpi that works out at 0.833 so 1 pixel wide. That's getting 
close to the resolving limit for the human eye at comfortable reading 
distances (ths is, obviously, variable between individuals). However, 
since the line width can vary by up to 2 pixels (but not less than 1) 
that could vary from 1 to 3 pixels wide. Which probably is visible under 
some circumstances since that's 2/1000 of an inch variation.

At 2540 dpi that's 2.1 pixels, which would  be 3 pixels wide (remember, 
any part of pixel rule). That is quite thin enough for stroke adjustment 
to make a difference as the line width may vary from 1 to 5 pixels. As 
above that could possibly be visible, though it pretty close to the 
limit that a human could normally see (1.5/1000 inch).

If we consider a theoretical 5080 dpi printer (I've run across a gravure 
device operating at these resolutions) then that works out at 5 
(precisely, 4.2) pixels. varying between 3 and 7, which is an error of 
8x10-4 or less than 1 thousandth of an inch, and almost certainly 
impercebtible.

As tlvp noted, that's what you get when you work with hairlines. Even 
though you haven't set linewidth to 0, its so close that it might as 
well be, even at comparatively high resolution (that's 1 pixel wide at 
1200 dpi).


> So I don?t know. The line width might be that most likely to make a difference. So how slow is it? Can that be tested? 

If you have a reliable RIP (ie one you *know* honours stroke adjustment) 
you can test how it affecgts *that* interpreter. It may not have the 
same effect on another RIP as they may not (probably won't) use the same 
algorithm for scan-conversion, stroke adjustment, drop-out correction 
etc.

Simply run your job with stroke adjustment true and false and see what 
the difference in rendering time is.

If your RIP will print to a file (eg TIFF) then you can examine the 
files easily enough in an image editor. Somethign like Photoshop will 
even 'diff' the files for you, so you have some hope of seeing the 
differences.


>It seemed to make no difference going through PostScript ? 

You would need to be certain that your RIP honoured the setting. Just 
because it doesn't throw an error doesn't mean it will actually *do* 
anything with it. Also your RIP's scan-conversion may normally be so 
slow (but, perhaps, super accurate) that turning on stroke adjustment 
makes no difference.


>Adobe Distiller XI ? 

I'd expect that Distiller will produce a PDF file with an ExtGState 
containing a /SA key, if you set stroke adjust to true.

What happens to it after that depends on the PDF consumer (see below)


>Mac Preview 8.0 (859.21) ? 

Doesn't deal with PostScript, as far as I'm aware, except by converting 
t to PDF, so....

In this case the 'printer' is your display, so it depends what (if 
anything) Preview does with stroke adjustment. Note that Acrovbat (which 
I believe is the underlying technology on Preview) does anti-aliasing, 
and that will make it pretty well impossible to work out what the actual 
stroke width is, in pixels. It also, of course, minimises the whoile 
problem of inconsistent stroke widths anyway.

At least with Acrobat (Pro at any rate) you can turn off anti-aliasing, 
and I've often seen PDF files where stroke adjustment is clearly not 
applied. However, I can't recall ever seeing a PDF file that actually 
sets /SA in the ExtGstate, I actually had to refer to the spec to find 
out what it was called, that's how often you see PDF files with it 
set....

My guess is that most PDF consumers simply ignore it.


> Samsung ML-2955DW (printing only the central A4 piece of the A3 ? non-
draft printing will be done by somebody else).

No idea, depends on the RIP in the printer (which likely won't match the 
one used for your non-draft print anyway) and I don't know whose that 
is. Its entirely possible that the printer simply ignores the setting of 
stroke adjust.

You could print your document with and without automatic stroke 
adjustment and then take a magnifier and scrutinise the two looking for 
single pixel differences, especially round curves.

If you can't see the difference anyway, then why bother setting it ? 

To get a feel for the performance cost, try running your document 
through Ghostscript with and without stroke adjustment. It won't tell 
you exactly how much the cost will be on other RIPS but it will give you 
some feel for how your specific job exercises the Ghostscript 
implementation.

You'll need to run it at several resolutions of course, both with and 
without stroke adjustment (I'd recommend you use PostScript, not PDF, as 
the input to ensure that the parameter is correctly defined). You could 
also then look at the output in each case and see whether you think the 
benfit important or not. Again, this won't tell you exactly how another 
RIP will perform, but it's not entirely without utility, it'll give you 
some idea and at the moment the discussion is rather theoretical.

			Ken

[toc] | [prev] | [next] | [standalone]

#2236

> > I suppose I'm trying to understand how much faster, and how much better. > > > These documents might be printed on anything from 300 dpi to =2400 dpi. 
> 
> Well it depends on the nature of your document, and exactly how tolerant 
> you want to be. I'd say, personally (and ths is purely an opinion) that 
> at 300 dpi the improvement is small, but the performance cost is not too 
> great. At 2540 dpi I'd say the improvement is invisible, and the 
> performance cost comparatively high (scan converting curves involves 
> touching many more pixels as the resolution rises, and stroke adjusting 
> all these, including dropout correcton, obviously will take longer the 
> more there are).

I have asked for expert advice and received it. You say that the gain is between zero and tiny, and the cost in time can be significant. As I was advised in my youth, take good advice, and take it. I'm taking it. Thank you. 

No stroke adjustments for me. 


> The symbol between 0.06 and 0 came out as a tilde on my News Reader, so 
> I'm not too sure of the question.

The symbol was approximately-equal-to, but you answered the question. 




> If you have a reliable RIP (ie one you *know* honours stroke adjustment) 
> you can test how it affecgts *that* interpreter. 

I don't know that it honours it, and am after general answers. 



> You could print your document with and without automatic stroke 
> adjustment and then take a magnifier and scrutinise the two looking for 
> single pixel differences, especially round curves.

Did that, with no apparent difference. But that might be the stroke adjustment request being ignored. 



Anyway, I'm taking your advice and not touching the stroke adjustment. Defaults rule. Thank you. 

[toc] | [prev] | [next] | [standalone]

#2234

ken <ken@spamcop.net> writes:
(snip)
> Higher resolution (and printers do keep increasing resolution, albeit 
> slowly) means more time taken to do scan conversion. If you add stroke 
> adjustment, that takes still more time, and for less and less benefit as 
> the resolution increases.
(snip)

That's interesting, I hadn't realized.

> Unless you are drawing with something like 0 setlinewidth 
> the differing stroke widths will be hard to see.
(snip)

I've usually used 0 setlinewidth to mark the lines I am to cut along
after printing. (-:

-- Mark

[toc] | [prev] | [next] | [standalone]

#2240

From 'Emulation of the setstrokeadjust Operator', Adobe Technical Note #5111, 31 March 1992, §2.3 on page 9:

http://partners.adobe.com/public/developer/en/ps/sdk/5111.Stroke_Adj.pdf

Both PostScript Level 2 systems and Display PostScript(tm) systems are able to perform an automatic adjustment to paths that causes them to be rendered at uniform widths. This automatic stroke adjustment can be turned on and off with the setstrokeadjust operator. Stroke adjusted paths are actually rendered slightly faster on Level 2 systems than non-stroke adjusted paths, so that you might want to stroke adjust paths for performance reasons alone, even when the improved appearance is not a consideration.

Does Adobe's 
> Stroke adjusted paths are actually rendered slightly 
> faster on Level 2 systems than non-stroke adjusted paths

suggest that the arguments about speed are mistaken?

[toc] | [prev] | [next] | [standalone]

#2241

In article <6068d7ca-fef2-46db-8c2c-cb97fefed43d@googlegroups.com>, 
jdawiseman@gmail.com says...
> 
> From 'Emulation of the setstrokeadjust Operator', Adobe Technical Note #5111, 31 March 1992, §2.3 on page 9:
> 
> http://partners.adobe.com/public/developer/en/ps/sdk/5111.Stroke_Adj.pdf
> 
> Both PostScript Level 2 systems and Display PostScript(tm) systems are able to perform an automatic adjustment to paths that causes them to be rendered at uniform widths. This automatic stroke adjustment can be turned on and off with the setstrokeadjust operator. Stroke adjusted paths are actually rendered slightly faster on Level 2 systems than non-stroke adjusted paths, so that you might want to stroke adjust paths for performance reasons alone, even when the improved 
appearance is not a consideration.
> 
> Does Adobe's 
> > Stroke adjusted paths are actually rendered slightly 
> > faster on Level 2 systems than non-stroke adjusted paths
> 
> suggest that the arguments about speed are mistaken?

As I said, implementations vary, and it might be that an already slow 
scan conversion is not slower (and indeed may even be faster) with 
stroke adjustment turned on.

The only way to tell, I believe, is to actually try it and measure the 
performance. If it truly is faster on Adobe interpreers then I would 
expect Adobe to have it turned on permanently (I certainly would in 
their place).

Bear in mind that many early level 2 implementations were hardware RIPs 
and may have had custom ASICs to improve rendering. Adobe's Emerald and 
Jade RIPs did I believe, and the early CPSI RIPS (which initially ran on 
Sun SPARC) had optional hardware assist in the form of expansion cards. 
So those *might* have been faster because of hardware acceleration. Or 
maybe not, it was all a long time ago and while I remember that the 
ColorBurst board accelerated colour handling I don't recall what the 
PixelBurst board did. It might only have been screening.

Another possibility is that there are two implementations (on level 2 
Adobe RIPS), an older one for compatibility with level 1 and a newer one 
only used when stroke adjustment is turned on. Then it may be that the 
newer impleemntation (which does not have to care about backward 
compatibility) is faster. This is the sort of thing we do in Ghostscript 
quite frequently, eventually the deprecated system is removed, if no 
problems show up.

If you can gather performance figures from several different 
manufacturers, and show that the various interpreters don't simply 
ignore the operator, I would be interested in seeing it, just for 
curiosity.


				Ken

[toc] | [prev] | [next] | [standalone]

#2242

> The only way to tell, I believe, is to actually try it and measure the 
> performance. 
> ...
> If you can gather performance figures from several different 
> manufacturers, and show that the various interpreters don't simply 
> ignore the operator, I would be interested in seeing it, just for 
> curiosity.

I have neither the kit nor the expertise to do that. And to be done properly it would have to be done properly. Otherwise one might believe that one setting is typically 20% faster, only because it wasn't tested on the kit on which it is twenty times slower. Hence my hoping that it could be answered by theory. 


> If it truly is faster on Adobe interpreers then I would 
> expect Adobe to have it turned on permanently (I certainly would in 
> their place).

That is very fair, and again suggests respecting defaults.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.postscript

csiph-web