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


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

Does overwriting a line write it twice?

Started byJohnF <john@please.see.sig.for.email.com>
First post2014-12-01 12:40 +0000
Last post2014-12-02 05:27 +0000
Articles 5 — 3 participants

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


Contents

  Does overwriting a line write it twice? JohnF <john@please.see.sig.for.email.com> - 2014-12-01 12:40 +0000
    Re: Does overwriting a line write it twice? ken <ken@spamcop.net> - 2014-12-01 14:02 +0000
      Re: Does overwriting a line write it twice? JohnF <john@please.see.sig.for.email.com> - 2014-12-02 05:18 +0000
    Re: Does overwriting a line write it twice? jdaw1 <jdawiseman@gmail.com> - 2014-12-01 12:39 -0800
      Re: Does overwriting a line write it twice? JohnF <john@please.see.sig.for.email.com> - 2014-12-02 05:27 +0000

#2104 — Does overwriting a line write it twice?

FromJohnF <john@please.see.sig.for.email.com>
Date2014-12-01 12:40 +0000
SubjectDoes overwriting a line write it twice?
Message-ID<m5hnjs$nml$1@reader1.panix.com>
Suppose you mave something like
  r1 g1 b1 setrgbcolor
  w1       setlinewidth
  x1 y1    moveto
  x2 y2    lineto
  r2 g2 b2 setrgbcolor
  w2       setlinewidth  %%% with w2<w1
  x1 y1    moveto        %%% ----------
  x2 y2    lineto
So you're drawing a different color narrower line 
inside a wider line.
   Does this line get written twice? In particular,
if printed on an inkjet, is ink laid down along the
entire w1-wider line, and then ink laid down again
on top of that along the w2-narrower line?
   If so, would a ps2pdf (and then printing the pdf)
stop that? Or how would you stop that from happening?
That is, just lay down ink once, in color r2,g2,b2
inside the w2-narrower line, and in color r1,g1,b1
along the outside edges between w2 and w1.
   gv'ing a ps file with those instructions looks
like the narrow-inside-wide line is only written once,
but I can't slow down the computer enough to be sure.
However, when printed, the narrow inside line looks
a little darker than intended, though that could
just be printer settings, etc. Thanks,
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [next] | [standalone]


#2105

Fromken <ken@spamcop.net>
Date2014-12-01 14:02 +0000
Message-ID<MPG.2ee6852f858cdb7a9898d2@usenet.plus.net>
In reply to#2104
In article <m5hnjs$nml$1@reader1.panix.com>, 
john@please.see.sig.for.email.com says...

> Suppose you mave something like
>   r1 g1 b1 setrgbcolor
>   w1       setlinewidth
>   x1 y1    moveto
>   x2 y2    lineto
>   r2 g2 b2 setrgbcolor
>   w2       setlinewidth  %%% with w2<w1
>   x1 y1    moveto        %%% ----------
>   x2 y2    lineto
> So you're drawing a different color narrower line 
> inside a wider line.
>    Does this line get written twice? 

Yes (assuming x1, x2, y1, y2 don't change value)


> In particular,
> if printed on an inkjet, is ink laid down along the
> entire w1-wider line, and then ink laid down again
> on top of that along the w2-narrower line?

No. The actual print head doesn't understand any print language at all. 
What happens is that a RIP (Raster Image Processor) interprets the input 
(PostScript in this case) and renders it to a bitmap. The bit depth and 
resolution of the bitmap depend on the printing capabilities of the 
printer, but for inkjets this is usally 1 bpp. So you end up with 4x1bpp 
images, one per ink.

The raster samples are used, more or less directly, to determine when 
the ink gets laid down.

So internally the line gets written twice, but that just means the page 
buffer pixels are written and then overwritten. The final raster only 
includes one colour at each pixel.

Its very common in PostScript and PDF to have partially obscured 
elements on the page.


>    If so, would a ps2pdf (and then printing the pdf)
> stop that? Or how would you stop that from happening?

It won't happen. Also, you cna do exactly the same construction in PDF 
as you have done in PostScript, and a PostScript to PDF converter would 
almost certainly preserve that construct. Doing aything else would be 
very difficult.


> That is, just lay down ink once, in color r2,g2,b2
> inside the w2-narrower line, and in color r1,g1,b1
> along the outside edges between w2 and w1.
>    gv'ing a ps file with those instructions looks
> like the narrow-inside-wide line is only written once,
> but I can't slow down the computer enough to be sure.

For a screen rendering its entierly possible that it *is* written twice, 
there often isn't any point in rendering to an intermediate bitmap and 
then squirting that to the display, better to use the display as the 
page buffer.

But for screen display it does depend very much on the application, 
Ghostscript for instance will rener to an intermediate bitmap and then 
blit that to the display. But it does 'sync' the output, so certain 
drivers will draw each element to the bitmap, then refresh the screen 
with the current bitmap. This would have the effect of drawing the line 
twice if you looked really carefully (and were running under a debugger 
so you could stop the applicatio, it'll be too fast otherwise)


			Ken

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


#2107

FromJohnF <john@please.see.sig.for.email.com>
Date2014-12-02 05:18 +0000
Message-ID<m5ji3u$nc5$1@reader1.panix.com>
In reply to#2105
ken <ken@spamcop.net> wrote:
> john@please.see.sig.for.email.com says...
>> Suppose you mave something like
>>   r1 g1 b1 setrgbcolor
>>   w1       setlinewidth
>>   x1 y1    moveto
>>   x2 y2    lineto
>>   r2 g2 b2 setrgbcolor
>>   w2       setlinewidth  %%% with w2<w1
>>   x1 y1    moveto        %%% ----------
>>   x2 y2    lineto
>> So you're drawing a different color narrower line 
>> inside a wider line.
>>    Does this line get written twice? 
> 
> Yes (assuming x1, x2, y1, y2 don't change value)
> 
>> In particular,
>> if printed on an inkjet, is ink laid down along the
>> entire w1-wider line, and then ink laid down again
>> on top of that along the w2-narrower line?
> 
> No. The actual print head doesn't understand any print language at all. 
> What happens is that a RIP (Raster Image Processor) interprets the input 
> (PostScript in this case) and renders it to a bitmap. The bit depth and 
> resolution of the bitmap depend on the printing capabilities of the 
> printer, but for inkjets this is usally 1 bpp. So you end up with 4x1bpp 
> images, one per ink.

Thanks, Ken. That (overprinting) had been my big worry about
generating ps code in the above form.

> The raster samples are used, more or less directly, to determine when 
> the ink gets laid down.
> 
> So internally the line gets written twice, but that just means the page 
> buffer pixels are written and then overwritten. The final raster only 
> includes one colour at each pixel.
> 
> Its very common in PostScript and PDF to have partially obscured 
> elements on the page.
> 
>>    If so, would a ps2pdf (and then printing the pdf)
>> stop that? Or how would you stop that from happening?
> 
> It won't happen. Also, you cna do exactly the same construction in PDF 
> as you have done in PostScript, and a PostScript to PDF converter would 
> almost certainly preserve that construct. Doing aything else would be 
> very difficult.
> 
>> That is, just lay down ink once, in color r2,g2,b2
>> inside the w2-narrower line, and in color r1,g1,b1
>> along the outside edges between w2 and w1.
>>    gv'ing a ps file with those instructions looks
>> like the narrow-inside-wide line is only written once,
>> but I can't slow down the computer enough to be sure.
> 
> For a screen rendering its entierly possible that it *is* written twice, 
> there often isn't any point in rendering to an intermediate bitmap and 
> then squirting that to the display, better to use the display as the 
> page buffer.
> 
> But for screen display it does depend very much on the application, 
> Ghostscript for instance will rener to an intermediate bitmap and then 
> blit that to the display. But it does 'sync' the output, so certain 
> drivers will draw each element to the bitmap, then refresh the screen 
> with the current bitmap. This would have the effect of drawing the line 
> twice if you looked really carefully (and were running under a debugger 
> so you could stop the application, it'll be too fast otherwise)
> Ken

I'd been (until your explanation) confused by what I was seeing gv do.
The overlaid w2(narrow)-on-top-of-w1(wide) lines seemed like they were
being written "together" just once (I hadn't thought to try running gv
under a debugger). On the other hand, gv was very obviously displaying
lines one after another, not the entire image all at once. And in that
case, it seemed to me that the overlaid lines would necessarily be
written individually/twice (which they apparently are). But that's no
problem as long as printers don't do it. Thanks again,
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

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


#2106

Fromjdaw1 <jdawiseman@gmail.com>
Date2014-12-01 12:39 -0800
Message-ID<16a70667-0a9e-4918-b7b5-fa6f5e459085@googlegroups.com>
In reply to#2104
Quite often I use code like:

% path construction, perhaps intricate
gsave 3 setlinewidth 0 setgray stroke grestore 1 setlinewidth 1 setgray stroke

It works well, and does just what you want it to do. Carry on.

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


#2108

FromJohnF <john@please.see.sig.for.email.com>
Date2014-12-02 05:27 +0000
Message-ID<m5jika$nc5$2@reader1.panix.com>
In reply to#2106
jdaw1 <jdawiseman@gmail.com> wrote:
> Quite often I use code like:
> 
> % path construction, perhaps intricate
> gsave 3 setlinewidth 0 setgray stroke grestore 1 setlinewidth 1 setgray stroke
> 
> It works well, and does just what you want it to do. Carry on.

Thanks, Julian. (Saw other post referencing your "placemat" code,
but hadn't looked at it enough to notice the above construction.
Interesting mix, financial services and wine tasting:)
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [standalone]


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


csiph-web