Execform and cache behavior

[oscpro]

Execform and cache behavior

Hi,

I am writing an application that creates postscript files with embedded forms that are called by the execform operator.

I have two questions:

1- Is the form re-evaluated when I restore a previously saved graphic state?

I have read that the RIP reuse the form from the cache when the graphic state between invocations of the form is the same or that the changes are merely translations.

What happens if I do something like that:

/my-form ... def
...
/gstate-for-my-form gstate def
gstate-for-my-form currentgstate
...
many translations, rotations, scale etc

gsave
gstate-for-my-form setgstate
my-form execform 
grestore
....
many translations, rotations, scale etc

gsave
gstate-for-my-form setgstate
my-form execform 
grestore
....

Does the RIP recognize that the graphic state is the same for each invocation of the form? Is the behavior implementation dependent?

2-
The postscript documents are around 1000 pages each. There are some forms that need to be called on almost every page.

On the other hand, for every set of 20 consecutive pages I need to reuse the same graphic element around 50 times. The graphic element is costly to render so it would be nice to use execform. However as each graphic element is used only for 20 consecutive pages we would end up with 1000 / 20 = 50 forms when only one would be needed for each set.

- If I define a form with the same name each time I start a new set of 20 pages, does the RIP execute the newly defined form and replace the old cache with the new one? Is it implementation dependent?

- Is there a way to remove a form from the cache when I know it is not needed anymore?


Thanks

 

[tgreer]

I'll respond to this in more depth later. I'm on the road. But form caching is implementation dependent. Some RIPs are better than other. What equipment are you using?

If you protect your graphic states with save/restores, you should be okay. CTM changes aren't supposed to matter, but I find that they do with a lot of equipment. So, don't do scale/translate in your PaintProc, and use the identity matrix in your form dictionary.

Unused forms are subject to garbage collection, so you don't have to explicity undeclare them. But you can use "undef", if you like.





Thomas D. Greer

http://www.tgreer.com

Providing PostScript & PDF
Training, Development & Consulting

 

[oscpro]

Thanks for your quick answer.

> Some RIPs are better than other. What equipment are you using?

It's not always under my control. I have used Xerox Docutech 135 and 180 but plan to use iGen3 and also Kyocera FS-9500DN and FS-9520DN. By the way, Kyocera uses a Postscript 3 emulator. Any idea if it works properly with forms?

> So, don't do scale/translate in your PaintProc, and use the identity matrix in your form dictionary.

A useful reminder.

> Unused forms are subject to garbage collection, so you don't have to explicity undeclare them. But you can use "undef", if you like.

Something I don't understand here. With a compiled language, garbage collection is usually done for variables that are not anymore referenced. But for an interpreted language like Postscript, how can the interpreter know that a specific element will not be used later in the program?

 

[tgreer]

Xerox does a good job with PostScript forms. There used to be some problems with the RIP of the 6180, but those have been resolved. The iGen3 is a beautiful machine.

I haven't used Kyocera. As for PostScript emulators, I only have experience with HP's (generally good, had some problems with /DeviceN colorspace, since resolved).

PostScript is indeed interpreted. Complex objects, such as strings, dictionaries, and arrays, are created in VM (Virtual Memory). A pointer to this object is maintained on the operand stack.

While the interpreter cannot know that an object is not referenced "later", it can know the state of VM, the operand stack, and the dictionary stack. So, when an item in VM is not pointed to by anything on the stack or in current dictionaries, it can clear it.

When and how garbage collection occurs is implementation dependent.

So your question about using the same "Key" or form name every 20 pages or so, but with different form dictionary values, is valid PostScript. All of the orphaned form dicts left in VM will be garbage collected.



Thomas D. Greer

http://www.tgreer.com

Providing PostScript & PDF
Training, Development & Consulting

 

[oscpro]

Thanks for your input.

So, for complex objects, using undef or re-defining it makes its previous value candidate for garbage collection.

However for form(s) there are two different things: the form definition and the cached result of the form execution.

My understanding is that the previous strategies affects only the definition of the form.

I guess that the effect on the cached result is implementation dependent.

 

[tgreer]

The PLRM is silent on the matter. I am making the assumption that when you redefine a form... i.e same key different form dict, that the interpreter knows, somehow, to clear the form cache. But I don't know that for a fact, and getting implementation details from vendors is like squeezing blood from a stone.

I would suggest making a test file, and processing through Acrobat Distiller as sort of a "reference implementation" of a PostScript interpreter. That will give you somewhat of an "expected behavior" to expect from other Adobe-based RIPs. Then if things aren't performing the way you expect, you have a basis for a discussion with the vendor.



Thomas D. Greer

http://www.tgreer.com

Providing PostScript & PDF
Training, Development & Consulting

 

[tgreer]

I did get some more detailed information from John Deubert at Acumen Training.

To summarize what he told me:

When Forms are defined, the interpreter adds an /Implementation key to the form dictionary. This is what actually identifies the form. When the cached entity is created (it's actually a display list), it is tagged with the same Implementation "key".

So if you redefine a particular form, it gets a new Implementation key, thus breaking the tie to the previous cached entity. The forms cache also has a garbage collection feature, and clears cached forms according to a "least used" algorithm.



Thomas D. Greer

http://www.tgreer.com

Providing PostScript & PDF
Training, Development & Consulting

 

[oscpro]

I was trying to figure out the implications of your last post.

So let summarize with an example of what I want to do.

Suppose I have a document of 1000 pages with 4 "global forms". These forms can be used anywhere in the document. On the other hand for every sequence of 4 pages I have a "local form" that is used only in this sequence, 2 times in every page. (These numbers are arbitrary numbers as an example).

Here how the structure of the document could be:

- begin of the file
- define the 5 global forms

--- sequence 1: page 1 to 4 ---
- before page 1: define the local form 1-4
- page 1: execform global form #1
- execform local form 1-4 (two times)
- page 2: execform global form #2
- execform local form 1-4 (two times)
- page 3: execform global form #3
- execform local form 1-4 (two times)
- page 4: execform global form #4
- execform local form 1-4 (two times)
- after page 4: undefine local form 1-4 which is not needed anymore

--- sequence 2: page 1 to 4 ---
- before page 5: define the local form 5-8
- page 5: execform global form #1
- execform local form 5-8 (two times)
- page 6: execform global form #2
- execform local form 5-8 (two times)
- page 7: execform global form #3
- execform local form 5-8 (two times)
- page 8: execform global form #4
- execform local form 5-8 (two times)
- after page 5: undefine local form 5-8 which is not needed anymore
....

Suppose the cache can only hold the 4 global forms + 1 local form. When starting sequence 2 (before page 5) we need more room in the cache for form 5-8. What happens there? On one hand, form 1-4 has been undefined. But on the other hand the local form 1-4 has been used 8 times when each of the global form has only been used 1 time.

Will the interpreter discard the form 1-4 because it has been undefined or will it discard one of the global form because it is one of the "least used"?

Obviously I want the former because I know that form 1-4 will not be used anymore while I know that each of the global form will be used again.

 

[oscpro]

There was a typo at the beginning of the"pseudo-code" in my previous post.
Instead of
- define the 5 global forms
we should have:
- define the 4 global forms

 

[tgreer]

Hmmm.

My first thought is that you should set the cache properly to make sure you're getting the "most" out of the forms cache:

<< /Password 0 /MaxFormCache 250000>> setsystemparams
<< /MaxFormItem currentsystemparams /MaxFormCache get >> setuserparams

The first line sets the system paramemter MaxFormCache to 250,000 bytes. This is arbitrary, you can provide whatever value your printer will support, based on available memory. The system parameters password is usually "0".

The second line sets the user parameter MaxFormItems to the maximum value of the form cache.

In your scenario, though, I don't think you can predict which forms will be cleared from the cache. It seems reasonable that the "global" forms would indeed fall victim to the garbage collection, IF the garbage collection occured between pages 1 & 2.

That's a pretty big if, though.



Thomas D. Greer

http://www.tgreer.com

Providing PostScript & PDF
Training, Development & Consulting