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@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