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

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

Non-caching by execform, which re-executes PaintProc every time

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

Contents

  Non-caching by execform, which re-executes PaintProc every time jdaw1 <jdawiseman@gmail.com> - 2016-03-02 03:47 -0800
    Re: Non-caching by execform, which re-executes PaintProc every time Martin Leese <please@see.Web.for.e-mail.INVALID> - 2016-03-02 11:02 -0700
      Re: Non-caching by execform, which re-executes PaintProc every time jdaw1 <jdawiseman@gmail.com> - 2016-03-02 15:24 -0800
        Re: Non-caching by execform, which re-executes PaintProc every time Martin Leese <please@see.Web.for.e-mail.INVALID> - 2016-03-03 10:28 -0700
          Re: Non-caching by execform, which re-executes PaintProc every time jdaw1 <jdawiseman@gmail.com> - 2016-03-03 15:15 -0800
            Re: Non-caching by execform, which re-executes PaintProc every time Chris Liddell <news@shadesoft.net> - 2016-03-08 07:46 +0000
              Re: Non-caching by execform, which re-executes PaintProc every time jdaw1 <jdawiseman@gmail.com> - 2016-03-09 05:25 -0800
                Re: Non-caching by execform, which re-executes PaintProc every time Chris Liddell <news@shadesoft.net> - 2016-03-10 08:59 +0000
          Re: Non-caching by execform, which re-executes PaintProc every time sjprouty3765@gmail.com - 2016-03-11 13:02 -0800
            Re: Non-caching by execform, which re-executes PaintProc every time jdaw1 <jdawiseman@gmail.com> - 2016-03-11 14:06 -0800
              Re: Non-caching by execform, which re-executes PaintProc every time jdaw1 <jdawiseman@gmail.com> - 2016-03-12 03:43 -0800

#2436 — Non-caching by execform, which re-executes PaintProc every time

My PostScript forms (in my 12k-line program) are being executed every time: execform isn't caching the results. But a simple toy program works fine. Please, what might be causing execform to fail to cache, and how can purported causes be tested? 

Thank you. 


Relevant facts.

* Distiller Pro 11.0.14 (17/12/2015) under Mac OS X 10.11.3. 

* Form dictionaries contain the required /FormType, /BBox, /Matrix, and /PaintProc. 

* If comment out any of the definitions of /FormType, /BBox, /Matrix, and /PaintProc, then execution terminates: 
An error has occured. Items of $error:
$error /errorname = /undefined 
$error /command = execform 
So it seems that, without commenting out, the form is correctly constructed. 

* If none commented out, execution succeeds, but every call of execform re-executes. 

* After every call to execform, the form dictionary contains only that which it originally contained. It does not contain /Implementation. 

* But the following toy program works fine: there are three forms, in an array, and the form is executed once for each. 

%!PS

<< /PageSize [100 100] >> setpagedevice

/TestForms [ 3 {6 dict} repeat ] def
0 1 TestForms length 1 sub
{
	/FormNum exch def
	TestForms FormNum get begin
	/FormNum FormNum def
	/FormType 1 def
	/Matrix matrix identmatrix def
	/BBox [ 0 0 100 100 ] def
	/PaintProc
	{
		begin
		matrix currentmatrix 100 0 translate 90 rotate
		FormNum =
		5 5 moveto
		50 50  50 50 5 95 curveto  50 50 50 50 95 95 curveto  50 50 50 50 95 5 curveto  50 50 50 50 5 5 curveto  closepath
		[ {1 0 0} {0 1 0} {0 0 1} ] FormNum get exec setrgbcolor fill
		setmatrix
		end
	} def  % /PaintProc
	end
} for  % TestForms


/Helvetica-Bold 16 selectfont

1 1 64
{
	2 string cvs
	TestForms
	{
		execform
		50 45 moveto  0 setgray
		dup dup stringwidth pop -2 div 0 rmoveto show
		showpage
	} forall
	pop
} for

() = () =  count =  countdictstack =

[toc] | [next] | [standalone]

#2437

jdaw1 wrote:
> My PostScript forms (in my 12k-line program) are being executed every time: execform isn't caching the results. But a simple toy program works fine. Please, what might be causing execform to fail to cache, and how can purported causes be tested? 

 From the PostScript Landuage reference Manual:
"The form’s definition does not refer to
  variable information in virtual memory, and
  its execution has no side effects in VM."

I have never used a form, but your use of the
variable /FormNum seems to break this rule.
Test this by dumping /FormNum.

-- 
Regards,
Martin Leese
E-mail: please@see.Web.for.e-mail.INVALID
Web: http://members.tripod.com/martin_leese/

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

#2438

>  From the PostScript Landuage reference Manual:
> "The form's definition does not refer to
>   variable information in virtual memory, and
>   its execution has no side effects in VM."
> 
> I have never used a form, but your use of the
> variable /FormNum seems to break this rule.
> Test this by dumping /FormNum.

But the code with FormNum works! It isn't a side effect in VM; it's merely using (from PLRM3): "The dictionary can also contain any additional entries that its PaintProc procedure may require."

In my program 
http://www.jdawiseman.com/papers/placemat/placemat.html
http://www.jdawiseman.com/papers/placemat/placemat.ps
replacing the PaintProc of RayForms with "{pop (*) =} bind" still executes every time, and "{pop} bind" never adds /Implementation to the dictionary. 

So I really don't know what I'm looking for.

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

#2439

jdaw1 wrote:
>>  From the PostScript Landuage reference Manual:
>> "The form's definition does not refer to
>>   variable information in virtual memory, and
>>   its execution has no side effects in VM."
>>
>> I have never used a form, but your use of the
>> variable /FormNum seems to break this rule.
>> Test this by dumping /FormNum.
> 
> But the code with FormNum works!

The code with FormNum *sometimes* works.  It
is up to you, but I would still try dumping
it to see what happens.

-- 
Regards,
Martin Leese
E-mail: please@see.Web.for.e-mail.INVALID
Web: http://members.tripod.com/martin_leese/

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

#2440

So I've hacked part of my big program to:

RaysForms SheetNum
<<
	/FormType 1
	/BBox [ 0 0 595 842 ]
	/Matrix matrix identmatrix
	/PaintProc {pop (*RaysForms, PaintProc) = SheetNum =}
>> put

It lies in a SheetNum loop. Later in the code this is invoked with 

RaysForms SheetNum get dup execform (+*) = {pop =} forall (-*) =

which, every time, sends to the log:

+*
BBox
FormType
PaintProc
Matrix
-*

So something else is the problem. But what?

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

#2447

On Thu, 03 Mar 2016 15:15:29 -0800, jdaw1 wrote:
> So something else is the problem. But what?

There are many, many reasons that a form may not be considered a 
candidate for caching, most/all of which are implementation dependent. In 
fact, there is no requirement to cache forms since that, in itself, is 
entirely implementation dependent.

So likely, the only way to get a categorical answer on this would be from 
an Adobe engineer who works on Distiller.

One guess would be the BBox: I've known at least one PS interpreter that 
wouldn't cache a form as large as 595x842pts (although, I will grant that 
it makes less sense with a product like Distiller).

Have you checked the PDF output? The content may well end up in a form in 
the PDF, even if it's judged that in the Postscript world, the PaintProc 
requires to be re-executed.

Chris

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

#2448

> One guess would be the BBox: I've known at least one PS interpreter that 
> wouldn't cache a form as large as 595x842pts 

Good thing to test, thank you, but no cigar. Shrinking BBox to [ 0 0 72 72 ] made no difference. 



> Have you checked the PDF output? The content may well end up in a form in 
> the PDF, even if it's judged that in the Postscript world, the PaintProc 
> requires to be re-executed.

Another good idea. How could that be shown in Adobe Professional XI? Or would I have to manually disassemble the PDF? 

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

#2449

On Wed, 09 Mar 2016 05:25:01 -0800, jdaw1 wrote:
> 
>> Have you checked the PDF output? The content may well end up in a form
>> in the PDF, even if it's judged that in the Postscript world, the
>> PaintProc requires to be re-executed.
> 
> Another good idea. How could that be shown in Adobe Professional XI? Or
> would I have to manually disassemble the PDF?

I don't have XI, but I think earlier versions would show form resources 
somewhere in the preflight tool reports.

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

#2450

On Thursday, March 3, 2016 at 9:28:42 AM UTC-8, Martin Leese wrote:
> jdaw1 wrote:
> >>  From the PostScript Landuage reference Manual:
> >> "The form's definition does not refer to
> >>   variable information in virtual memory, and
> >>   its execution has no side effects in VM."
> >>
> >> I have never used a form, but your use of the
> >> variable /FormNum seems to break this rule.
> >> Test this by dumping /FormNum.
> > 
> > But the code with FormNum works!
> 
> The code with FormNum *sometimes* works.  It
> is up to you, but I would still try dumping
> it to see what happens.
> 
> -- 
> Regards,
> Martin Leese
> E-mail: please@see.Web.for.e-mail.INVALID
> Web: http://members.tripod.com/martin_leese/


I think Martin Lesse has the right idea.  To prevent the variable in the form construction, you can do this:

        /PaintProc 
        { 
                begin 
                matrix currentmatrix 100 0 translate 90 rotate 
                //FormNum = 
                5 5 moveto 
                50 50  50 50 5 95 curveto  50 50 50 50 95 95 curveto  50 50 50 50 95 5 curveto  50 50 50 50 5 5 curveto  closepath 
                [ {1 0 0} {0 1 0} {0 0 1} ] //FormNum get exec setrgbcolor fill 
                setmatrix 
                end 
        } def  % /PaintProc

I.e. use early binding (//FormNum) so the variable name no longer exists in the PaintProc.  Try that and see if it helps.

Thanks!

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

#2451

On Thursday, 10 March 2016 08:59:04 UTC, Chris Liddell  wrote:
> I don't have XI, but I think earlier versions would show form resources 
> somewhere in the preflight tool reports.

Thank you, it is there. 
Edit > Preflight...; Options > Browse Internal PDF Structure...

Hmm. It would be convenient to name the XObjects, to assist browsing. Alas adding /Name to the execform dictionary seems not to work. Alas.




On Friday, 11 March 2016 21:02:14 UTC, sjprou...@gmail.com  wrote:

> I.e. use early binding (//FormNum) so the variable name no longer exists in the PaintProc.  Try that and see if it helps.

Thank you, but not a cigar this time. It just can't be done with that form of early binding. 
0 1 10 {/i exch def ... //i ...} for
fails. The //i is executed before the code in which it sits is executed, so there is, at that time, no instance of i. Doing this is horrible: 
10 -1 0 {/i exch def  [ /i2 i i /mul cvx /def cvx ... /<operator> cvx ... i ...] cvx} for
11 {exec} repeat

But sometimes further simplifying the PaintProc so that it has no variables still doesn't get it to be stored. Distiller seems to use awkward to reverse-engineer heuristics, so that it can be stored on first execution, on second, sometimes, or not at all. Yuck.

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

#2452

FYI, question now asked at 
https://forums.adobe.com/thread/2114240 

[toc] | [prev] | [standalone]

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

csiph-web