Loading ...
Sorry, an error occurred while loading the content.

Re: Several files to create - best approach?

Expand Messages
  • andrewsc51
    ... You are quire right, I was slowly coming to the same conclusion myself. There is really no need to dismantle and recreate the JVM each time. Instead of
    Message 1 of 8 , Dec 3, 2005
    • 0 Attachment
      >> I realise this means creating and dismantling
      >> the Java VM 4800 times.

      Danny.Fournier@e... wrote:
      > I've ended up registering the FOP classes on my Coldfusion
      > MX server. Then, I can invoke them in my code which
      > is producing PDFs faster and seems to take less of
      > a performance hit on the server.

      You are quire right, I was slowly coming to the same conclusion
      myself. There is really no need to dismantle and recreate the
      JVM each time. Instead of invoking FO from the command line
      each time, I shall be able to have a master Java class, to call
      the FO renderer repeatedly. This way, I should be able to save
      the considerable overhead of having to create a new JVM for each
      file. Based on past experience, I intend to call Jaava garbage
      collection after rendering every few files. I'm not too keen on
      the idea of a single huge memory space growing indefinitely, so I
      rather get rid of leftover bits and pieces at a convenient moment,
      when not much else is in use. My job will be (hopefully) a pure
      batch invoked from the Shell, so I don't have to worry about Web
      session contexts and such.

      > Plus, I can pass FO in memory instead of having to create
      > FO files and pass their path as parameters. Works really
      > well so far.

      This sounds interesting, and I might try it as well. But I place
      a high value on "supportability". In case of any trouble, I want
      to be able to come the morning after, and inspect the
      intermediate files in XML and FO formats. Managing 4800 files
      is well within the capabilities of a Unix box, and I've done
      it before. I don't care if the machine works hard at night,
      as long as I can sleep tight.

      Andrew

      P.S. thanks for other people who responded, pointing me to
      the Lowagie package.
    • vijay chiniwar
      I have done Some thing like this before but am sure, Memory will be a serious issue, between i make use of SVG in my Pdf and have noticed that these SVGs are
      Message 2 of 8 , Dec 6, 2005
      • 0 Attachment
        I have done Some thing like this before
        but am sure, "Memory" will be a serious issue,
        between i make use of SVG in my Pdf and have noticed that these SVGs are stored in memory and never get deleted unless i restart my webserver

        If i can get some way where i can getaway with this images from memory it would be just great

        heres the program for merging pdfs

        you will need a lowagiepdf.jar from iText which is a freeware


        package com.db.eqr.croci.struts.actions;
        /**
        * test.java
        * @author vch
        * @version
        *
        */
        public class test
        {
        public void genPdf()
        {
        String directory=Application.getProperty("pathtoPDFStore")+"/pdfs/";
        String destDirectory=Application.getProperty("pathtoPDFStore")+"/merge/";
        String[] files = //read files from dir here
        PdfReader reader = null;
        Rectangle psize = null;
        Document document = null;
        PdfWriter writer = null;
        Timer t2=new Timer("Time to Merge Documents");
        t2.start();
        for (int index = 0; index < companyIdList.size(); index++)
        {
        files[index]=((String)companyIdList.get(index)+".pdf");
        try
        {
        if (index == 0)
        {
        reader = new PdfReader(directory+ files[index]);
        psize = reader.getPageSize(1);
        document = new Document(psize);
        writer = PdfWriter.getInstance(document,
        new FileOutputStream(destDirectory+"mergedDocument.pdf"));
        document.open();
        }
        else
        {
        reader = new PdfReader(directory + files[index]);
        }
        int n = reader.getNumberOfPages();
        PdfContentByte cb = writer.getDirectContent();
        int i = 0;
        while (i < n)
        {
        document.newPage();
        i++;
        PdfImportedPage page1 = writer.getImportedPage(reader, i);
        cb.addTemplate(page1, .5f, .5f);
        }
        }
        catch(Exception e)
        {
        continue;
        }
        }
        if(document!=null)
        {
        document.close();
        }
        t2.stop();
        }
        }






        andrewsc51 <andrewsc51@...> wrote:
        >> I realise this means creating and dismantling
        >> the Java VM 4800 times.

        Danny.Fournier@e... wrote:
        > I've ended up registering the FOP classes on my Coldfusion
        > MX server. Then, I can invoke them in my code which
        > is producing PDFs faster and seems to take less of
        > a performance hit on the server.

        You are quire right, I was slowly coming to the same conclusion
        myself. There is really no need to dismantle and recreate the
        JVM each time. Instead of invoking FO from the command line
        each time, I shall be able to have a master Java class, to call
        the FO renderer repeatedly. This way, I should be able to save
        the considerable overhead of having to create a new JVM for each
        file. Based on past experience, I intend to call Jaava garbage
        collection after rendering every few files. I'm not too keen on
        the idea of a single huge memory space growing indefinitely, so I
        rather get rid of leftover bits and pieces at a convenient moment,
        when not much else is in use. My job will be (hopefully) a pure
        batch invoked from the Shell, so I don't have to worry about Web
        session contexts and such.

        > Plus, I can pass FO in memory instead of having to create
        > FO files and pass their path as parameters. Works really
        > well so far.

        This sounds interesting, and I might try it as well. But I place
        a high value on "supportability". In case of any trouble, I want
        to be able to come the morning after, and inspect the
        intermediate files in XML and FO formats. Managing 4800 files
        is well within the capabilities of a Unix box, and I've done
        it before. I don't care if the machine works hard at night,
        as long as I can sleep tight.

        Andrew

        P.S. thanks for other people who responded, pointing me to
        the Lowagie package.







        SPONSORED LINKS
        Xml xsl Xsl Xsl fo Xsl-fo Xsl tutorial

        ---------------------------------
        YAHOO! GROUPS LINKS


        Visit your group "XSL-FO" on the web.

        To unsubscribe from this group, send an email to:
        XSL-FO-unsubscribe@yahoogroups.com

        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


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








        ---------------------------------
        Yahoo! Shopping
        Find Great Deals on Gifts at Yahoo! Shopping

        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.