info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
setstrokeadjust: what's the disadvantage?
53 views
Skip to first unread message
jdaw1
Apr 27, 2015, 6:25:21 AM4/27/15
to
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.)
true setstrokeadjust
? Indeed, why not always 'true setstrokeadjust'? What's the disadvantage?
(Ref PLRM3 §7.5.2, pp503-504.)
ken
Apr 27, 2015, 9:29:48 AM4/27/15
to
In article <d353a099-6401-463c...@googlegroups.com>,
jdawi...@gmail.com says...
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
jdawi...@gmail.com says...
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
jdaw1
Apr 27, 2015, 11:56:30 AM4/27/15
to
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?
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?
tlvp
Apr 27, 2015, 2:59:53 PM4/27/15
to
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
> The curves and lines might average about an inch in length, and are painted with 0.06 setlinewidth 0 setgray.
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.
jdaw1
Apr 27, 2015, 4:29:15 PM4/27/15
to
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.
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.
tlvp
Apr 27, 2015, 10:43:41 PM4/27/15
to
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
> 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.
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 :-) !
ken
Apr 28, 2015, 2:54:51 AM4/28/15
to
In article <0951df15-771a-4953...@googlegroups.com>,
jdawi...@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
jdawi...@gmail.com says...
> So the disadvantage is all about processor time: thank you.
>
> My PLRM3 says "First printing February 1999".
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.
> (Indeed, it seems likely that a 2015 phone has memory and CPU as good
as those of a typical 1999 computer.)
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.
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?
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
jdaw1
Apr 28, 2015, 5:01:29 AM4/28/15
to
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.
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.
> I guess it depends on whether you want your pages faster or (almost
> trivially, depending on resolution) 'better'.
> Unless you are drawing with something like 0 setlinewidth
> the differing stroke widths will be hard to see.
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.
Mark Carroll
Apr 28, 2015, 5:43:40 AM4/28/15
to
ken <k...@spamcop.net> writes:
(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
(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)
> 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.
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.
I've usually used 0 setlinewidth to mark the lines I am to cut along
after printing. (-:
-- Mark
ken
Apr 28, 2015, 6:27:58 AM4/28/15
to
In article <7c0cc70a-3eb5-4b80...@googlegroups.com>,
jdawi...@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-
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
jdawi...@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'.
>
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.
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
jdaw1
Apr 28, 2015, 7:02:17 AM4/28/15
to
> > 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.
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.
>
> 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.
> 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).
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.
> If you have a reliable RIP (ie one you *know* honours stroke adjustment)
> you can test how it affecgts *that* interpreter.
> 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.
Anyway, I'm taking your advice and not touching the stroke adjustment. Defaults rule. Thank you.
jdaw1
May 1, 2015, 6:16:27 PM5/1/15
to
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?
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?
ken
May 2, 2015, 4:13:55 AM5/2/15
to
In article <6068d7ca-fef2-46db...@googlegroups.com>,
jdawi...@gmail.com says...
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
jdawi...@gmail.com says...
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
jdaw1
May 2, 2015, 6:29:39 AM5/2/15
to
> The only way to tell, I believe, is to actually try it and measure the
> performance.
> ...
> 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.
> manufacturers, and show that the various interpreters don't simply
> ignore the operator, I would be interested in seeing it, just for
> curiosity.
> 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).
0 new messages