[xep-support] XEP/PostScript Inline Image Proposal

From: Christian Kriebel <christian.kriebel@assentis.com>
Date: Tue Jan 13 2009 - 06:07:23 PST

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


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.


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

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


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

- 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@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
Received on Tue Jan 13 06:43:50 2009

This archive was generated by hypermail 2.1.8 : Tue Jan 13 2009 - 06:43:56 PST