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

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

execform, 75% faded

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

Contents

  execform, 75% faded jdaw1 <jdawiseman@gmail.com> - 2012-07-30 01:57 -0700
    Re: execform, 75% faded luser- -droog <mijoryx@yahoo.com> - 2012-07-30 07:04 -0700
      Re: execform, 75% faded jdaw1 <jdawiseman@gmail.com> - 2012-07-31 06:24 -0700
        Re: execform, 75% faded jdaw1 <jdawiseman@gmail.com> - 2012-07-31 11:40 -0700
          Re: execform, 75% faded luser- -droog <mijoryx@yahoo.com> - 2012-07-31 16:02 -0700
            Re: execform, 75% faded jdaw1 <jdawiseman@gmail.com> - 2012-08-01 00:08 -0700
      Re: execform, 75% faded jdawiseman.bloomberg@gmail.com - 2019-04-20 06:46 -0700
        Re: execform, 75% faded jdawiseman.bloomberg@gmail.com - 2019-04-20 06:46 -0700
    Re: execform, 75% faded Chris <cjl@spamcop.net> - 2012-08-01 07:40 +0000
      Re: execform, 75% faded jdaw1 <jdawiseman@gmail.com> - 2012-08-01 01:02 -0700
        Re: execform, 75% faded Chris <cjl@spamcop.net> - 2012-08-01 08:15 +0000
          Re: execform, 75% faded jdaw1 <jdawiseman@gmail.com> - 2012-08-01 02:53 -0700
            Re: execform, 75% faded ken <ken@spamcop.net> - 2012-08-01 12:56 +0100
            Re: execform, 75% faded Chris <cjl@spamcop.net> - 2012-08-01 12:33 +0000
    Re: execform, 75% faded jdaw1 <jdawiseman@gmail.com> - 2012-08-01 05:47 -0700
      Re: execform, 75% faded jdaw1 <jdawiseman@gmail.com> - 2012-08-01 06:28 -0700
    Re: execform, 75% faded Don Lancaster <don@tinaja.com> - 2012-10-23 08:45 -0700
      Re: execform, 75% faded jdaw1 <jdawiseman@gmail.com> - 2015-04-25 15:05 -0700

#838 — execform, 75% faded

A large PostScript program repeatedly calls execform. The code that is used to generate the execform isn’t always completely known to the calling code, as it in turn calls bits of code supplied by the user as parameters.

I want to call this form one more time, but to be painted faded, such that black is painted as about 25% grey, and greys likewise faded. If PostScript supported transparency, I’d set 75% transparent and that would be that. But, IIRC, not even pdfmark can do that. (And output is to PDF rather than directly to paper, so using pdfmark would be OK.)

Another possibility, rather nasty, would be to compute the bounding box, loop over its x and y sizes and repeatedly overpaint with … moveto … lineto 1 setgray 0.24 setlinewidth stroke. The step size could be the same as the line width. (Perhaps rotated 45°? Perhaps the inner and outer loops shouldn’t be 90° apart — advice welcomed.) This would work, sort of, but is ugly, and could resonate badly with lines of similar angle. Yuck!

Please, does anybody know better?

[toc] | [next] | [standalone]

#840

On Monday, July 30, 2012 3:57:26 AM UTC-5, jdaw1 wrote:
> A large PostScript program repeatedly calls execform. The code that is used to generate the execform isn’t always completely known to the calling code, as it in turn calls bits of code supplied by the user as parameters.
> 
> 
> 
> I want to call this form one more time, but to be painted faded, such that black is painted as about 25% grey, and greys likewise faded. If PostScript supported transparency, I’d set 75% transparent and that would be that. But, IIRC, not even pdfmark can do that. (And output is to PDF rather than directly to paper, so using pdfmark would be OK.)
> 


You can get something like you describe by playing
with the transfer function. Untested, but something
like this should quash your greys 75% closer to white.

[ currenttransfer /exec cvx 
{ 1 exch sub .75 mul 1 exch sub } /exec cvx ] cvx
settransfer

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

#845

On Monday, July 30, 2012 3:04:44 PM UTC+1, luser- -droog wrote:
> You can get something like you describe by playing with the transfer function. Untested, but something like this should quash your greys 75% closer to white. [ currenttransfer /exec cvx { 1 exch sub .75 mul 1 exch sub } /exec cvx ] cvx settransfer

Splendid, thank you. As is typically of this bulletin, replies are swift and informed. Thank you. 

The following program works wonderfully in Adobe Distiller, and just as well in GhostScript. Hurray! But Apple Preview (Snow Lion, software about which I have other grumbles), seems to ignore the settransfer. 



%!

/SquaresForm
<<
	/FormType 1
	/BBox [ 0 0 60 60 ]
	/Matrix matrix identmatrix
	/PaintProc
	{
		pop
		0    setgray  0 dup 60 dup rectfill
		0.5  setgray 12 dup 36 dup rectfill
		0.75 setgray 24 dup 12 dup rectfill
	}
>> def  % /SquaresForm

<< /PageSize [84 228] >> setpagedevice

12 12 translate
SquaresForm execform

0 72 translate
gsave
{/null exec 0.2 mul 0.8 add} dup 0 currenttransfer put settransfer
SquaresForm execform
grestore

0 72 translate
SquaresForm execform

showpage

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

#847

Ooops, my error. It works in Adobe Distiller, but •not• in Ghostscript (using PS2PDF.com’s version 3010, revision 864, serialnumber 42), nor in Apple Preview (Version 5.5.2, 719.25). 

See
http://www.jdawiseman.com/2012/20120731_settransfer_test.ps
http://www.jdawiseman.com/2012/20120731_settransfer_test_adobe_distiller.pdf
http://www.jdawiseman.com/2012/20120731_settransfer_test_ghostscript.pdf
http://www.jdawiseman.com/2012/20120731_settransfer_test_preview_552_71925.pdf

Any suggestions for a PostScript technique that will work in GS?

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

#848

On Tuesday, July 31, 2012 1:40:15 PM UTC-5, jdaw1 wrote:
> Ooops, my error. It works in Adobe Distiller, but •not• in Ghostscript (using PS2PDF.com’s version 3010, revision 864, serialnumber 42), nor in Apple Preview (Version 5.5.2, 719.25). 
> 
> 
> 
> See
> 
> http://www.jdawiseman.com/2012/20120731_settransfer_test.ps
> 
> http://www.jdawiseman.com/2012/20120731_settransfer_test_adobe_distiller.pdf
> 
> http://www.jdawiseman.com/2012/20120731_settransfer_test_ghostscript.pdf
> 
> http://www.jdawiseman.com/2012/20120731_settransfer_test_preview_552_71925.pdf
> 
> 
> 
> Any suggestions for a PostScript technique that will work in GS?

Ick. Well, as I often say, Shocking but not Surprising!

I should have thought of this first:
Override 'setgray'!

/oldsetgray /setgray load def
/setgray { .2 mul .8 add oldsetgray } def

You might be tempted to use //immediately-loaded
names, but then you're assuming /setgray is an
operator which is not guaranteed. As far as 
assumptions go in this game, this one's pretty
safe. But it's a good habit to apply them
with caution. :)

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

#850

> > Any suggestions for a PostScript technique that will work in GS? 
> Ick. Well, as I often say, Shocking but not Surprising! I should have thought of this first: Override 'setgray'! 

> /oldsetgray /setgray load def /setgray { .2 mul .8 add oldsetgray } def 


If the painting routine were a routine, that would work. But it is a form, called by execform, typically without any fading wrapping (without the partial invisibility cloak). So on being re-invoked there is no guarantee that the code will actually be executed.

Also, the Ghostscript working/non-working is more complicated than previously described, hence my earlier confusion. If the Ghostscript output is opened with (at least some) Adobe products, it works. But if the Ghostscript output is opened with Apple Preview, it doesn’t work. My guess is that Adobe Distiller adjusts the painting colour and paints normally, whereas Ghostscript might embed the transfer within the PDF, this being ignored by Preview. But that’s a guess.

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

#3384

I’m attempting to use settransfer with bitmap images. It works with one (image faded); not with two (images not faded). All three images are of the same ‘type’.




/Logo_Data
currentfile
<< /Filter /ASCIIHexDecode  /Intent 0 >>
/ReusableStreamDecode filter
% Much data here
>
def



gsave   newpath   /DeviceRGB setcolorspace
[ currenttransfer   /exec cvx   1   /exch cvx   /sub cvx  0.25  /mul cvx   1   /exch cvx   /sub cvx ] cvx bind settransfer

<< /width 1147  /height 1395 >> begin
Logo_Data 0 setfileposition
<<
	/ImageType 1
	/Width width
	/Height height
	/ImageMatrix [1 0 0 -1 0 height]
	/DataSource  Logo_Data << >> /DCTDecode filter
	/BitsPerComponent 8
	/Decode [0 1 0 1 0 1]
>> image
end

grestore





Why might settransfer sometimes fo nothing? Even if set to extreme fading? Is there a subtlety?

Thank you. 

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

#3385

“fo” = do.

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

#849

On Mon, 30 Jul 2012 01:57:26 -0700, jdaw1 wrote:

> A large PostScript program repeatedly calls execform. The code that is
> used to generate the execform isn’t always completely known to the
> calling code, as it in turn calls bits of code supplied by the user as
> parameters.
> 
> I want to call this form one more time, but to be painted faded, such
> that black is painted as about 25% grey, and greys likewise faded. If
> PostScript supported transparency, I’d set 75% transparent and that
> would be that. But, IIRC, not even pdfmark can do that. (And output is
> to PDF rather than directly to paper, so using pdfmark would be OK.)
> 
> Another possibility, rather nasty, would be to compute the bounding box,
> loop over its x and y sizes and repeatedly overpaint with … moveto …
> lineto 1 setgray 0.24 setlinewidth stroke. The step size could be the
> same as the line width. (Perhaps rotated 45°? Perhaps the inner and
> outer loops shouldn’t be 90° apart — advice welcomed.) This would work,
> sort of, but is ugly, and could resonate badly with lines of similar
> angle. Yuck!
> 
> Please, does anybody know better?

FWIW, I would urge you to find a solution other than execform. The whole 
point of execform is that the result of executing execform repeatedly 
produce exactly the same markings - thus the form can be cached in some 
implementation specific manner, and second and subsequent calls to it are 
(potentially) much quicker. Any solution that you come up with to get 
what you want will be dependant on the internal operations of a given 
rip, and won't be certain to work on another implementation - as you have 
found!

Can't you just replace the form with a procedure containing the marking 
operations and call the procedure instead of execform?

Chris

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

#851

On Wednesday, August 1, 2012 8:40:17 AM UTC+1, Chris wrote:
> Can't you just replace the form with a procedure containing the marking operations and call the procedure instead of execform? Chris

But my output has complicated elements that are repeated many times. E.g., see
http://www.jdawiseman.com/2012/20120725_olympic.pdf 
Without forms that file would be on the chunky side of ten megs. 

I suppose the faded version of my forms could be wrapped in its own form, which would then call the ‘inner’ form as a routine rather than as a form. Even though inelegant, that might be the way forward. (And anyway, Ghostscript seems to ignore forms.) But even that has the problem that there is no guarantee that the innermost code parameters set colours with setgray rather than, for example, setrgbcolor. 

¿”Innermost parameters”? Huh?
This code is really code, rather than page description. See, for an idea of the degree of possible parameterisation, the following:
http://www.jdawiseman.com/placemat.html
E.g., my software’s parameters that contain arbitrary user-chosen colour-setting code include CrossHatchingBackgroundStrokeCode, CrossHatchingTitlesStrokeCode, RaysStrokeCode, TastingNotesColumnStrokeCode, and others. Hence re-def’ing setgray might not suffice.

Maybe the better solution would be to grouch to Apple that Preview ignores PDF’s embedded transfers. 

Again, let me praise this bulletin board, whose regulars seem to know lots and know it promptly. Thank you.

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

#852

On Wed, 01 Aug 2012 01:02:13 -0700, jdaw1 wrote:

> On Wednesday, August 1, 2012 8:40:17 AM UTC+1, Chris wrote:
>> Can't you just replace the form with a procedure containing the marking
>> operations and call the procedure instead of execform? Chris
> 
> But my output has complicated elements that are repeated many times.
> E.g., see http://www.jdawiseman.com/2012/20120725_olympic.pdf Without
> forms that file would be on the chunky side of ten megs.
<SNIP>

I don't follow that argument. The form dictionary contains a procedure 
(PaintProc) with all the marking operations. All I'm suggesting is that 
you slightly modify the existing PaintProc so you can use it as a 
standalone procedure (outside the context of the form dictionary). Do not 
"bind" the procedure!

This would not involve any more PS code than using execform, but means 
you can reliably influence the behaviour of the procedure between 
invocations (something you cannot safely do with execform).

Chris

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

#853

On Wednesday, August 1, 2012 9:15:37 AM UTC+1, Chris wrote:
> I don't follow that argument. The form dictionary contains a procedure (PaintProc) with all the marking operations. All I'm suggesting is that you slightly modify the existing PaintProc so you can use it as a standalone procedure (outside the context of the form dictionary). Do not "bind" the procedure! This would not involve any more PS code than using execform, but means you can reliably influence the behaviour of the procedure between invocations (something you cannot safely do with execform). Chris

Yes, that would have the effect you say. But the example output contains twenty-two copies of several complicated graphics. Using execform and Adobe Distiller causes the PDF to hold only two copies of each graphic (should be one, but it’s two), the third and subsequent instances being replaced with a pointer to the second. That greatly lightens the PDF, and might speed printing. If it is possible to dodge the Preview failure to render transfers without losing that lightness, that would be preferred. 

Also, no need to modify PaintProc. It can just be called differently: “dup /PaintProc get exec” rather than “execform”, which can be done by re-def’ing execform.

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

#854

In article <0fa3d714-e8ee-4464-8c56-272a085501aa@googlegroups.com>, 
jdawiseman@gmail.com says...
> 
> On Wednesday, August 1, 2012 9:15:37 AM UTC+1, Chris wrote:

> Yes, that would have the effect you say. But the example output 
contains twenty-two copies of several complicated graphics. Using 
execform and Adobe Distiller causes the PDF to hold only two copies of 
each graphic (should be one, but it?s two), the third and subsequent 
instances being replaced with a pointer to the second. That greatly 
lightens the PDF, and might speed printing. If it is possible to dodge 
the Preview failure to render transfers without losing that lightness, 
that would be preferred. 

In the specific instance of converting the PostScript to PDF, you can 
change the setting of transfer functions. Select Settings->Edit Adobe 
PDF settings. Select 'Color' from the list on the left. Near the bottom 
of the dialog is a control labelled 'When transfer functions are found'. 
Select 'Apply'.

This *may* get the effect you are looking for butfor the reasons Chris 
gives its equally likely that it will not. The whole point of a form is 
that it is supposed to be the have the same effect every time it is 
used, which allows the interpreter to efficiently reuse it.

And you are correct, the pdfwrite device (NOT Ghostscript) does not 
preserve PostScript forms on conversion to PDF. At least in part because 
hardly anyone uses forms and those that do rarely use it in the intended 
fashion.


			Ken

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

#855

On Wed, 01 Aug 2012 02:53:49 -0700, jdaw1 wrote:

> On Wednesday, August 1, 2012 9:15:37 AM UTC+1, Chris wrote:
<SNIP> 
> Yes, that would have the effect you say. But the example output contains
> twenty-two copies of several complicated graphics. Using execform and
> Adobe Distiller causes the PDF to hold only two copies of each graphic
> (should be one, but it’s two), the third and subsequent instances being
> replaced with a pointer to the second. That greatly lightens the PDF,
> and might speed printing. If it is possible to dodge the Preview failure
> to render transfers without losing that lightness, that would be
> preferred.

Preview may be displaying the cached form data - it *should* re-execute 
the PaintProc because the transfer function is changed, but it might not 
be.

Have you checked whether Preview applies transfer functions at all? Even 
without the form involved?

Basically, what you're doing is *not* what forms are designed for, so 
it's likely to be problematic.


Here's a thought: what about, before the first call to execform, doing:
<</MaxFormItem 0>> setuserparams

That should disable the form cache, on any compliant interpreter. Then 
you should be able to use the redefining setgray trick mentioned earlier. 
Make sure the PaintProc isn't bound, though.

> Also, no need to modify PaintProc. It can just be called differently:
> “dup /PaintProc get exec” rather than “execform”, which can be done by
> re-def’ing execform.

That assumes that the PaintProc never paints outside the form bounding 
box, and that the form matrix is an identity matrix. You can, of course, 
manually set all that up before execing the PaintProc, but if you're not 
using the form cache, why bother faffing about with a form dictionary.

Chris

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

#856

Lots of clues. 

First, I need to investigate whether 
<< /TransferFunctionInfo /Apply >> setdistillerparams
will work.

Failing that, I need to investigate 
<< /TransferFunctionInfo /Apply >> setdistillerparams
mark /ca 0.2 /SetTransparency pdfmark

A report will follow. 

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

#857

Ooops: << /AllowTransparency true >> setdistillerparams, of course. 

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

#1018

On 7/30/2012 1:57 AM, jdaw1 wrote:
> A large PostScript program repeatedly calls execform. The code that is used to generate the execform isn’t always completely known to the calling code, as it in turn calls bits of code supplied by the user as parameters.
>
> I want to call this form one more time, but to be painted faded, such that black is painted as about 25% grey, and greys likewise faded. If PostScript supported transparency, I’d set 75% transparent and that would be that. But, IIRC, not even pdfmark can do that. (And output is to PDF rather than directly to paper, so using pdfmark would be OK.)
>
> Another possibility, rather nasty, would be to compute the bounding box, loop over its x and y sizes and repeatedly overpaint with … moveto … lineto 1 setgray 0.24 setlinewidth stroke. The step size could be the same as the line width. (Perhaps rotated 45°? Perhaps the inner and outer loops shouldn’t be 90° apart — advice welcomed.) This would work, sort of, but is ugly, and could resonate badly with lines of similar angle. Yuck!
>
> Please, does anybody know better?
>


Of course.

< http://www.tinaja.com/glib/pstrans2.pdf >

-- 
Many thanks,

Don Lancaster                          voice phone: (928)428-4073
Synergetics   3860 West First Street   Box 809 Thatcher, AZ 85552
rss: http://www.tinaja.com/whtnu.xml   email: don@tinaja.com

Please visit my GURU's LAIR web site at http://www.tinaja.com

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

#2224

Just so that it isn't lost, the non-pickling of settransfer by Ghostscript is further discussed in 
https://groups.google.com/forum/#!topic/comp.lang.postscript/IdQuFp2eHQc

[toc] | [prev] | [standalone]

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

csiph-web