<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=Content-Type content=text/html;charset=ISO-8859-1>
<META content="MSHTML 6.00.2800.1479" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=#000000 bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Brian,</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>You can extract almost everything from the XEP
intermediate format (SVG drawings seem to be encoded ???).</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2> It is a flat XML format, organized in
pages, with x and y coordinate for every element.</FONT></DIV>
<DIV><FONT face=Arial size=2>Details see here <A
href="http://www.renderx.com/reference.html#appendix_C">http://www.renderx.com/reference.html#appendix_C</A></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>This approach works fine if you have a linear
workflow:</FONT></DIV>
<DIV><FONT face=Arial size=2>1) process section 1</FONT></DIV>
<DIV><FONT face=Arial size=2>2) process section 2 with starting page information
from previous step</FONT></DIV>
<DIV><FONT face=Arial size=2>3) process next sections</FONT></DIV>
<DIV><FONT face=Arial size=2>...</FONT></DIV>
<DIV><FONT face=Arial size=2>n) extract necessary information for indexes and
TOC from the XEP intermediate format files (based on rx:pinpoint
data)</FONT></DIV>
<DIV><FONT face=Arial size=2>n+1) build TOC</FONT></DIV>
<DIV><FONT face=Arial size=2>n+2) build indexes</FONT></DIV>
<DIV><FONT face=Arial size=2>n+3) assemble book</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>This concept fails with pointers (references/links)
between sections, as you may have to change the pagination of a previous
section while rendering a new section.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Cheers, Jost</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial>Jost Klopfstein<BR>*Axos Technologies Inc.*<BR>OnDemand
& Transactional Document Solutions, powered by XML<BR>IT
Consulting<BR><BR>*604 628-2248 Phone*<BR>604-324-2380 Fax<BR>jost
(at) axostech.com<BR><A class=moz-txt-link-freetext
href="http://www.axostech.com">http://www.axostech.com</A><BR></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<BLOCKQUOTE dir=ltr
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=bjbutler@bjbsoftware.com href="mailto:bjbutler@bjbsoftware.com">Brian
J. Butler</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=xep-support@renderx.com
href="mailto:xep-support@renderx.com">xep-support@renderx.com</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Friday, June 03, 2005 10:53
AM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [xep-support] Splitting of
large document</DIV>
<DIV><BR></DIV><FONT size=-1><FONT face="Helvetica, Arial, sans-serif">The
biggest memory consumer seems to be the process that compresses the PDF
document. I find that our document requires more than 3GB to process
with this option enabled and less than 1.5GB without it.<BR><BR>Try the
turning this option off in your xep.xml file as shown
below:<BR><BR> <!-- Backend options
--><BR> <generator-options
format="PDF"><BR> <!-- <option
name="COMPRESS" value="false"/> --><BR>
<!-- <option name="PDF_VERSION" value="1.3"/>
--><BR>
</generator-options><BR> <BR>By the way, I
have a problem similar to yours. Our 2200 page book is only one part of a
larger catalog. Unfortunately, the other sections contain references to
products in the main section. I had posted some messages here earlier to
see if there is a way to write page numbers and other data into the XEP log. I
thought I would extract the data with an editor and put it in a database,
using it later to look up page references for the other sections. I don't
think this is possible, but someone suggested looking at the XEP intermediate
format. I have not done this yet. If you look at it and can
distill the information I would like to know how to do it. If I try it
first, I will post here.<BR><BR>BJB<BR></FONT></FONT><BR>Jost Klopfstein
wrote:
<BLOCKQUOTE cite=mid013701c4c297$a8f36470$0602a8c0@Toshiba type="cite"><PRE wrap="">Mike, Brian,
Thanks for your hints.
The document is in the 1000+ pages class with plenty of large SVG drawings
(>500 Kbytes).
I will check with my customer if I can drop the references between chapters.
If so, then I can use the split technology and build the TOC and Indexes
from the separate sections in XEP intermediate format.
Otherwise they have to buy a bigger server...
Does anyone know if there is an option to prevent XEP's in memory
processing?
Cheers, Jost
----- Original Message -----
From: "Mike Trotman" <A class=moz-txt-link-rfc2396E href="mailto:mike.trotman@datalucid.com"><mike.trotman@datalucid.com></A>
To: <A class=moz-txt-link-rfc2396E href="mailto:xep-support@renderx.com"><xep-support@renderx.com></A>
Sent: Friday, June 03, 2005 3:05 AM
Subject: Re: [xep-support] Splitting of large document
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">I have successfully processed 100mB+ documents of 1000+ pages - mainly
consisting of heavily formatted tables with 15 x 20 cells per page,
multiple pages per table, lots of data per cell, footnotes etc.
This included bookmarks and a simple Table Of Contents with internal
links to individual tables.
By placing each table / document chunk within a separate
<fo:page-sequence> I was able to keep the memory requirements very low
(not much more than the default).
I'm now also using XSLT pre-processing where I produce each
<fo:page-sequence> in a separate XSL-FO file and generate a master
processing document which sets up regions and page masters
and contains a list of the separate <fo:page-sequence> files to include.
I then process this master list with a simple XSLT to produce the final
FO for output to PDF.
I haven't used indexes (the TOC references etc. are constructed by the
XSLT) - so don't know what sort of overhead this produces.
Mike
Brian J. Butler wrote:
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">I have also been working on a very large document (88MB FO file, 2200
pages of technical text and drawings). I can offer the following three
suggestions:
1. Make sure your Java -Xmx size is as large as possible. With
Windows this will be approximately -Xmx1600Mb.
2. Use the XEP flag to turn off PDF compression (in xep.xml or command
line). This will result in a very large PDF, but you can compress it
after rendering by opening it in Adobe Acrobat and then saving.
3. Switch to a 64-bit Solaris platform (Opteron processors). We
benchmarked one of these machines and found that we can -Xmx almost
unlimited memory. The speed is also very fast.
BJB
Jost Klopfstein wrote:
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">Hi,
I ran into memory problems while rendering a large book with TOC,
indexes and references between sections.
I first thought I could just render section by section into XEP
intermediate format and then assemble the pieces with some custom
code into a large PDF using the PDF output generator.
However I will loose the TOC, indexes and the references between
sections.
Any ideas?
Thanks,
Jost
</PRE></BLOCKQUOTE></BLOCKQUOTE>
<BLOCKQUOTE type="cite"><PRE wrap="">------------------------------------------------------------------------
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap="">Jost Klopfstein
*Axos Technologies Inc.*
OnDemand & Transactional Document Solutions, powered by XML
IT Consulting
*604 628-2248 Phone*
604-324-2380 Fax
jost (at) axostech.com
<A class=moz-txt-link-freetext href="http://www.axostech.com">http://www.axostech.com</A>
</PRE></BLOCKQUOTE><PRE wrap="">--
Brian J. Butler
BJB Software, Inc.
76 Bayberry Lane
Holliston, MA 01746
E-mail: <A class=moz-txt-link-abbreviated href="mailto:bjbutler@bjbsoftware.com">bjbutler@bjbsoftware.com</A>
Web: <A class=moz-txt-link-freetext href="http://www.bjbsoftware.com">http://www.bjbsoftware.com</A>
Phone: 508-429-1441
Fax: 419-710-1867
</PRE></BLOCKQUOTE><PRE wrap="">
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 267.5.2 - Release Date: 03/06/2005
Message Scanned by ClamAV on datalucid.com
-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to <A class=moz-txt-link-abbreviated href="mailto:majordomo@renderx.com">majordomo@renderx.com</A> from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service
</PRE></BLOCKQUOTE><PRE wrap=""><!----><A class=moz-txt-link-freetext href="http://www.renderx.com/terms-of-service.html">http://www.renderx.com/terms-of-service.html</A>
</PRE>
<BLOCKQUOTE type="cite"><PRE wrap=""> </PRE></BLOCKQUOTE><PRE wrap=""><!---->
-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to <A class=moz-txt-link-abbreviated href="mailto:majordomo@renderx.com">majordomo@renderx.com</A> from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service <A class=moz-txt-link-freetext href="http://www.renderx.com/terms-of-service.html">http://www.renderx.com/terms-of-service.html</A>
</PRE></BLOCKQUOTE><BR><PRE class=moz-signature cols="72">--
Brian J. Butler
BJB Software, Inc.
76 Bayberry Lane
Holliston, MA 01746
E-mail: <A class=moz-txt-link-abbreviated href="mailto:bjbutler@bjbsoftware.com">bjbutler@bjbsoftware.com</A>
Web: <A class=moz-txt-link-freetext href="http://www.bjbsoftware.com">http://www.bjbsoftware.com</A>
Phone: 508-429-1441
Fax: 419-710-1867
</PRE></BLOCKQUOTE></BODY></HTML>