Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
execform, 75% faded
164 views
Skip to first unread message
jdaw1
Jul 30, 2012, 4:57:26 AM7/30/12
to
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?
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?
luser- -droog
Jul 30, 2012, 10:04:44 AM7/30/12
to
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
> 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.)
>
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
jdaw1
Jul 31, 2012, 9:24:58 AM7/31/12
to
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.
> 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
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
jdaw1
Jul 31, 2012, 2:40:15 PM7/31/12
to
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?
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?
luser- -droog
Jul 31, 2012, 7:02:09 PM7/31/12
to
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. :)
Chris
Aug 1, 2012, 3:40:17 AM8/1/12
to
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
jdaw1
Aug 1, 2012, 3:08:58 AM8/1/12
to
> > 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.
> 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
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.
jdaw1
Aug 1, 2012, 4:02:13 AM8/1/12
to
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
> Can't you just replace the form with a procedure containing the marking operations and call the procedure instead of execform? Chris
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.
Chris
Aug 1, 2012, 4:15:37 AM8/1/12
to
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>
> 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 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
jdaw1
Aug 1, 2012, 5:53:49 AM8/1/12
to
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.
> 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
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.
ken
Aug 1, 2012, 7:56:25 AM8/1/12
to
In article <0fa3d714-e8ee-4464...@googlegroups.com>,
jdawi...@gmail.com says...
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
jdawi...@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
> 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
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
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.
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
Chris
Aug 1, 2012, 8:33:10 AM8/1/12
to
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>
> 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.
Preview may be displaying the cached form data - it *should* re-execute
> 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.
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.
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
jdaw1
Aug 1, 2012, 8:47:41 AM8/1/12
to
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.
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.
jdaw1
Aug 1, 2012, 9:28:49 AM8/1/12
to
Ooops: << /AllowTransparency true >> setdistillerparams, of course.
Don Lancaster
Oct 23, 2012, 11:45:17 AM10/23/12
to
< 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: d...@tinaja.com
Please visit my GURU's LAIR web site at http://www.tinaja.com
jdaw1
Apr 25, 2015, 6:05:10 PM4/25/15
to
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
https://groups.google.com/forum/#!topic/comp.lang.postscript/IdQuFp2eHQc
jdawiseman...@gmail.com
Apr 20, 2019, 9:46:09 AM4/20/19
to
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.
/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.
jdawiseman...@gmail.com
Apr 20, 2019, 9:46:46 AM4/20/19
to
“fo” = do.
0 new messages