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

Groups > comp.lang.postscript > #2235

Re: setstrokeadjust: what's the disadvantage?

Show all headers | View raw

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

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