[xep-support] XEP/PostScript Inline Image Proposal

[Christian Kriebel]

Hello Michael, Kevin

I would like to ask you to verify the proposal below. We face the issue described there at a number of customers. We could offer you that we make the necessary modifications on the xep source but ask you to incorporate it into an official release of xep. 

Would this or a similar approach work for you ?

Thanks and best wishes 
Christian Kriebel

---------------------------------------

    XEP/PostScript Inline Image Proposal
    ====================================
    Benjamin Lutz, Assentis Technologies AG
    2009-01-12


SUMMARY

This is a proposal for changing the way XEP stores images in PostScript 
files. This is deemed useful because the method XEP uses now for storing 
images leads to problems with large files and XEROX RIPpers.


PROBLEM DESCRIPTION

XEP embeds in PostScript files by storing the compressed image bytestream 
and applying the decompression filters as well as  ReusableStreamFilter to 
that bytestream. The XEROX RIP has two problems with this: first, it 
appears to have a hardcoded limit on the number open file streams, and it 
uses file streams for ReusableStreamFilter objects. With semi-large 
documents that contain a few thousand images, the XEROX RIP hits that limit 
and aborts processing of the PostScript file with an error message. Second, 
when the ReusableStreamFilter is not used, large documents with 10000 
images or more cause an extreme slow down in the XEROX RIP, presumably 
because of the large amount of memory required to have all images loaded 
concurrently.

Assentis assumes that both problem can be worked around by not storing 
images at the beginning of the PostScript file (“document header”), but by 
storing them instead near the position where they are actually used (either 
the “page header” or the actual image position, i.e. “inline”). This 
requires much fewer images to be concurrently used; after the image is 
used, the memory it requires can be recollected by the PostScript garbage 
collector.


SUGGESTED SOLUTION

The best way to make it possible to inline images is to change the 
PostScript generator, i.e., XEP. Several option exist for configuring the 
new behaviour:

- Make inlining of images the new behaviour; the old behaviour is no
  longer used. No configuration is necessary.

- Make inlining of images the new default behaviour, but fall back to the
  old behaviour when an image is used multiple times. The number of times
  the same image must be reused to fallback to using a document-global
  image should be configured, otherwise a document with thousands of
  images, where every image is used twice, might still cause the above
  mentioned issues.

- Allow enabling of inlining globally by adding a new configuration option
  to xep.xml, the XEP configuration file.

- Allow inlining of images by enabling/disabling inlining in the document. A
  new processing instruction might be used for that, e.g.
  <?xep-postscript-inline-image true?> and <?xep-postscript-inline image 
  false?> which statefully and context-independently enable and disable
  image-inlining when they are encountered. By default, inlining would be
  disabled.

- Allow inlining of images by adding a new optional attribute to the
  xep:image tag, e.g. <xep:image inline="true" .../>. The implicit default
  would be inline="false", i.e. use the old behaviour.

Much of the required functionality, particularly the detection of multiple 
references to the same image, already exists in XEP. What remains is 
implementing the code for parsing any new configurables and for inserting 
images in a position other than the file header. Thus implementing a 
solution with one of the listed options should require more 2 weeks of 
effort at the most.

-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to majordomo at renderx.com from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/terms-of-service.html