execform, 75% faded

A large PostScript program repeatedly calls execform. The code that is usedto 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 PostScriptsupported 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?

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

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

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/20120...ansfer_test.ps
http://www.jdawiseman.com/2012/20120..._distiller.pdf
http://www.jdawiseman.com/2012/20120...hostscript.pdf
http://www.jdawiseman.com/2012/20120..._552_71925.pdf

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

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/20120...ansfer_test.ps
>
> http://www.jdawiseman.com/2012/20120..._distiller.pdf
>
> http://www.jdawiseman.com/2012/20120...hostscript.pdf
>
> http://www.jdawiseman.com/2012/20120..._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.

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

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

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 ofthe 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. Hencere-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.

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

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

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

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

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.

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